发布时间 : 星期五 文章NoSQL数据库学习教程更新完毕开始阅读24a5d7523c1ec5da50e270b1
http://blog.sina.com.cn/mpl398235717
到30Gbit/sec！Voltaire产品的端口甚至更多；简直不敢想象。（如果你想了解这类超高性能网络的最新进展，请关注Andreas Bechtolsheim在Standford开设的课程。）
各种操作的时间，以2001年夏季，典型配置的 1GHz 个人计算机为标准： 执行单一指令
从L1 高速缓存取一个字 从内存取一个字
从磁盘取连续存放的一个字 磁盘寻址并取字
以太网
1 纳秒 2 纳秒 10 纳秒 200 纳秒 8 毫秒
2GB/s
Tim还指出Jim Gray的
名言中后半句所阐述的真理：―对于随机访问，硬盘慢得不可忍受；但如果你把硬盘当成磁带来用，它吞吐连续数据的速率令人震惊；它天生适合用来给以RAM为主的应用做日志（logging and journaling）。‖
时间闪到几年之后的今天，我们发现硬件的发展趋势在RAM和网络领域势头不减，而在硬盘领域则止步不前。Bill McColl提到用于并行计算的海量内存系统已经出现：
内存是新的硬盘！硬盘速度提高缓慢，内存芯片容量指数上升，in-memory软件架构有望给各类数据密集的应用带来数量级的性能提升。小型机架服务器（1U、2U）很快就会具备T字节、甚至更大量的内存，这将会改变服务器架构中内存和硬盘之间的平衡。硬盘将成为新的磁带，像磁带一样作为顺序存储介质使用（硬盘的顺序访问相当快速），而不再是随机存储介质（非常慢）。这里面有着大量的机会，新产品的性能有望提高10倍、100倍。
Dare Obsanjo指出如果不把这句真言当回事，会带来什么样的恶劣后果—— 也就是Twitter正面临的麻烦。论及Twitter的内容管理，Obsanjo说，―如果一个设计只是简单地反映了问题描述，你去实现它就会落入磁盘 I/O的地狱。不管你用Ruby on Rails、Cobol on Cogs、C++还是手写汇编都一样，读写负载照样会害死你。‖换言之，应该把随机操作推给RAM，只给硬盘留下顺序操作。
Tom White是Hadoop Core项目的提交者，也是Hadoop项目管理委员会的成员。他对Gray的真言中―硬盘是新的磁带‖部分作了更深入地探讨。White在讨论MapReduce编程模型的时候指出，为何对于Hadoop这类工具来说，硬盘仍然是可行的应用程序数据存储介质：
本质上，在MapReduce的工作方式中，数据流式地读出和写入硬盘，MapReduce是以硬盘的传输速率不断地对这些数据进行排序和合并。 与之相比，访问关系数据库中的数据，其速率则是硬盘的寻道速率（寻道指移动磁头到盘面上的指定位置读取或写入数据的过程）。为什么要强调这一点？请看看寻道时间和磁盘传输率的发展曲线。寻道时间每年大约提高5%，而数据传输率每年大约提高20%。寻道时间的进步比数据传输率慢——因此采用由数据传输率决定性能的模型是有利的。MapReduce正是如此。
虽然固态硬盘（SSD）能否改变寻道时间/传输率的对比还有待观察，White文章的跟贴中，很多人都认为SSD会成为RAM/硬盘之争中的平衡因素。
Nati Shalom对内存和硬盘在数据库部署和使用中的角色作了一番有理有据的评述。 Shalom着重指出用数据库集群和分区来解决性能和可伸缩性的局限。他说，―数据库复制和数据库分区都存在相同的基本问题，它们都依赖于文件系统/硬盘 的性能，建立数据库集群也非常复杂‖。他提议
http://blog.sina.com.cn/mpl398235717
http://blog.sina.com.cn/mpl398235717
的方案是转向In-Memory Data Grid（IMDG），用Hibernate二级缓存或者GigaSpaces Spring DAO之类的技术作支撑，将持久化作为服务（Persistence as a Service）提供给应用程序。Shalom解释说，IMDG
提供在内存中的基于对象的数据库能力，支持核心的数据库功能，诸如高级索引和查询、事务语义和锁。IMDG还从应用程序的代码中抽象出了数据的拓扑。通过这样的方式，数据库不会完全消失，只是挪到了―正确的‖位置。
IMDG相比直接RDBMS访问的优势列举如下：
? 位于内存中，速度和并发能力都比文件系统优越得多 ? 数据可通过引用访问
? 直接对内存中的对象执行数据操作 ? 减少数据的争用 ? 并行的聚合查询
? 进程内（In-process）的局部缓存 ? 免除了对象-关系映射（ORM）
你是否需要改变对应用和硬件的思维方式，最终取决于你要用它们完成的工作。但似乎公论认为，开发者解决性能和可伸缩性的思路已经到了该变一变的时候。
Amdahl定律和Gustafson定律
这里，我们都以S(n)表示n核系统对具体程序的加速比，K表示串行部分计算时间比例。
Amdahl 定律的加速比：S(n) ＝ 使用1个处理器的串行计算时间 / 使用n个处理器的并行计算时间
S(n) = 1/(K+(1-K)/n) = n/(1+(n-1)K)
Gustafson定律的加速比：S(n) ＝ 使用n个处理器的并行计算量 / 使用1个处理器的串行计算量
S(n) = K+(1-K)n
有点冷是不是？
通俗的讲，Amdahl 定律将工作量看作1，有n核也只能分担1-K的工作量；而Gustafson定律则将单核工作量看作1，有n核，就可以增加n(1-K)的工作量。
这里没有考虑引进分布式带来的开销，比如网络和加锁。成本还是要仔细核算的，不是越分布越好。
控制算法的复杂性在常数范围之内。
万兆以太网
手段篇
一致性哈希
要求分布式架构的发展说起。
http://blog.sina.com.cn/mpl398235717
http://blog.sina.com.cn/mpl398235717
第一阶段
考虑到单服务器不能承载，因此使用了分布式架构，最初的算法为 hash() mod n, hash()通常取用户ID，n为节点数。此方法容易实现且能够满足运营要求。缺点是当单点发生故障时，系统无法自动恢复。
第二阶段
为了解决单点故障，使用 hash() mod (n/2), 这样任意一个用户都有2个服务器备选，可由
client随机选取。由于不同服务器之间的用户需要彼此交互，所以所有的服务器需要确切的知道用户所在的位置。因此用户位置被保存到memcached中。
当一台发生故障，client可以自动切换到对应backup，由于切换前另外1台没有用户的session，因此需要client自行重新登录。
这个阶段的设计存在以下问题
负载不均衡，尤其是单台发生故障后剩下一台会压力过大。 不能动态增删节点
节点发生故障时需要client重新登录
第三阶段
http://blog.sina.com.cn/mpl398235717
http://blog.sina.com.cn/mpl398235717
打算去掉硬编码的hash() mod n 算法，改用一致性哈希(consistent hashing)分布 假如采用Dynamo中的strategy 1
我们把每台server分成v个虚拟节点，再把所有虚拟节点(n*v)随机分配到一致性哈希的圆环上，这样所有的用户从自己圆环上的位置顺时针往下取到第一个vnode就是自己所属节点。当此节点存在故障时，再顺时针取下一个作为替代节点。
优点：发生单点故障时负载会均衡分散到其他所有节点，程序实现也比较优雅。
亚马逊的现状
aw2.0公司的Alan Williamson撰写了一篇报道，主要是关于他在Amazon EC2上的体验的，他抱怨说，Amazon是公司唯一使用的云提供商，看起来它在开始时能够适应得很好，但是有一个临界点：
在开始的日子里Amazon的表现非常棒。实例在几分钟内启动，几乎没有遇到任何问题，即便是他们的小实例（SMALL INSTANCE）也很健壮，足以支持适当使用的MySQL数据库。在20个月内，Amazon云系统一切运转良好，不需要任何的关心和抱怨。 ……
http://blog.sina.com.cn/mpl398235717