提到这两个系统，他们在核心思路上是非常类似的，但有一些细节性的东西又有所偏重，在分布式系统中也算是独树一帜了，很有代表性的一个系列，这些不一致的地方，最明显的地方就在于一致性上。可见，哪怕是从追求简单为上的工程化实现来说，各种不同的方式实现一致性也都有很大的不同，不过他们也有一些共性和一些独树一帜的概念，下面来做一下分别解说。

    从09年第一次阅读Dynamo论文，到最近阅读Amazon S3的一篇专利，一路过来对论文的理解可以简单归结为两个字

    DYNAMO平台的独门绝技： 利用NWR模型与vector clock解决锁问题 我们知道当系统系统为多用户时，就必须使用文件锁的机制来保护数据的完整性和一致性。举例A用户向数据区D1写了数据1， 那么用户B和C都可以看到D1的数据为1，而当A，B同时在向数据区D1做加1的操作，就需要一个锁，让先发起的用户先操作，后发起的用户就需要在队列里面排队等待前面的用户完成操作，再继续进行。

    比较典型的存储云基础系统有Amazon公司的Dynamo系统与Google公司的Bigtable系统，这两种系统不但已经开始是商用（参见S3 服务和 Google App Engine服务），而且都公开了比较详细的实现论文（尤其dynamo系统论文格外详尽――可见Amazon公司的无私和自信）。它们各自实现架构迥异，存储特性不一，但都结构优美，技术上各有可称道的地方，可谓各有千秋，却又殊途同归。下面我们将针对它们两者存储数据的要求、体系架构、扩容、负载均衡、容错、数据存取及查询等我觉得重要的方面进行一些点到为止分析比较，以辨明良莠。

    NoSQL其实并不是什么妖魔鬼怪，相反的，NoSQL的真谛其实应该是Not Only SQL，其产生是在数据量和访问量的增大下，人为地去添加机器、切分数据到不同的机器，变得越来越困难，人力成本越来越高，于是便开始有了这样的项目，本意是提高数据存储的自动化程度，减少人为干预的时间，让负载更加均匀。在国际上，真正的代表之作有来自Google的 BigTable 和Amazon 的Dynamo，他们分别使用了不同的基本原理。

    在前文《多IDC的数据分布设计(一)》中介绍了多IDC数据一致性的几种实现原理，遗憾的是，目前虽然有不少分布式产品，但几乎都没有开源的产品专门针对IDC来优化。本文从实践的角度分析各种方法优缺点。背景资料 Latency差异 Jeff Dean提到不同数据访问方式latency差异 Numbers Everyone Should Know L1 cache reference 0.5 ns Branch mispredict 5 ns L2 cache reference ...

    在云计算的时代，Dynamo可以说是一本实现分布式存储的红宝书，借鉴Dynamo实现的产品如雨后春笋般冒出。前段时间本人曾在Twitter上戏称这年头，如果一个号称有“海量数据”的互联网公司，不做一个自己的Dynamo, 出去都不好意思跟人打招呼 (http://twitter.com/xmpp/status/8023241449) 另外一方面对于Dynamo设计思想也有不少反对的声音，比如2009/11/1在Hacker News上链接的一篇文章Dynamo: A flawed architecture引起不少争议，最...