from: http://www.allthingsdistributed.com/2006/03/a_word_on_scalability.html
Amazon CTO对伸缩性的解释
…
What is it that we really mean by scalability? A service is said to be scalable if when we increase the resources in a system, it results in increased performance in a manner proportional to resources added. Increasing performance in general means serving more units of work, but it can also be to handle larger units of work, such as when datasets grow.
— 简单说，系统的吞吐和性能能随着投入的服务器资源数量的增加而成正比的增加
…
from: http://www.infoq.com/articles/Anti-Patterns-Alois-Reitbauer;
Alois Reitbauer介绍了几个使用DB方面的反模式：
1. Misuse of O/R Mappers
O/R mapper框架可以大幅提高开发效率，开发者 不理解实际表结构的话，在使用O/R mapper框架时，常常会进入误区：
a. 对O/R Mapper的loading behavior 不了解，往往无意中访问一个对象的属性，就导致了一个复杂的SQL语句被生成并被执行，有时这种情况会导致非常大量的数据库访问；
b. O/R Mapper通常被配置为lazy load模式，导致开发者不知道关联对象实际被访问的时间，可能会导致性能上的一些问题；而O/R Mapper框架为了保持lazy load模式，往往还会持有相关db connection相当长的时间，这又导致对DB服务器的压力；
2.Load More Data Then Needed
— hunter: 感觉并不是一个很严重的问题，remote 调用一般比较昂贵，我们应该尽量返回粗颗粒度的对象
BigTable的使用原则处处透着Web 2.0的设计原则，也是BASE原则的体现（牺牲一致性），BASE原则是Web 2.0设计的高度抽象
================================================
从围绕着Google App Engine的大量讨论中，Todd Hoff总结出了一组优化使用分布式及高可伸缩性存储系统——如BigTable——的指导原则。Todd从定义BigTable的适用范围开始论述。由于BigTable引入的各种代价，只有在以下情况下使用BigTable才能带来益处：a)需要伸缩到巨量的用户数，b)更新与读取操作相比比例很小。Todd还着重强调为了“优化读取速度和可伸缩性”，所采取的理论路线与关系数据库中的做法存在根本的分歧，很可能初看起来是违背直觉甚至相当冒险的。关系数据库的世界是以防止错误为根基的；以正规化（normalization）为工具消除重复和防止更新异常。为了提高可伸缩性，数据应该重复而非正规化。Flickr久悬着了这种路线，决定让“评论重复出现于评论者和被评论者两个用户数据分片中，而非单独建立一个评论关系”(hunter:绝！)，因为“如果把用户数据分片作为可伸缩性的单元，就没有地方放置这种关系”。因此，虽然去正规化（denormalization）违背了“关系数据的伦理”，但它是BigTable数据范式不可缺少的组成部分。
Powered by WordPress
