在云盘算 的时期 ，Dynamo可以说是一本完成 散布 式存储的红宝书，自创 Dynamo完成 的产物 如雨后春笋般冒出。前段工夫 自己 曾在Twitter上戏称

这岁首 ，假如 一个号称有“海量数据”的互联网公司，不做一个本人 的Dynamo,出去都欠好 意思跟人打召唤
(http://twitter.com/xmpp/status/8023241449)

别的 一方面临 于Dynamo设计思惟 也有很多 否决 的声响 ，好比 2009/11/1在Hacker News上链接的一篇文章Dynamo: A flawed architecture引发 很多 争议，最初 竟引发 Amazon CTO Werner Vogels在Twitter上回应

Darn, someone figured out that Dynamo is a flawed architecture. Luckily its only use is storing hundreds of millions of shopping carts 
(http://twitter.com/Werner/statuses/5345892061)
汗，有人发明 Dynamo是一个缺点 的架构，侥幸 的是，咱们 只用它来存储了成百上亿的购物篮数据。:-)

以下是这篇批评 Dynamo文章大局部 中间 概念 ，所翻译的概念 其实不 代表Tim立场。

–译文入手下手 –

Dynamo: A flawed architecture

在宣布 此文章之前，我也争辩 过Dynamo是不是 合适 咱们 的体系 。然而 我很清晰 这篇论文充斥 缺点 ，它将毛病 的引诱 了读者让人人 信任 其设计，它的良多 设计前后自相抵触 。下文会具体 引见 这些缺点 。

Dynamo的终究 分歧 性

起首 ，终究 分歧 性对开辟 者意味甚么 呢？

1. 写入的数据不克不及 在后续的读操作中获得 到。
    
2. 写入的数据也有能够 在后续的读操作中获得 到，但读到后能够 下一次又读不到。
    
3. 因而 对写操作前面 的读取没有SLA(Service Level Agreement)包管 。

举例申明 ，因为 Dynamo是一个key value存储，咱们 假定 value中存储的是一个list, 当list写入数据以后 别的 一个client却未读取到，这时候 候它需求 写入数据的话只能从头 构建一个新的list，添加要存的值并将新list存入，这就会招致 老的list数据丧失 。

(Update: 服装论坛 上一些人指出，因为 Vector Clock机制，数据丧失 的场景不成 能呈现 ，我赞同 ，不外 我再提出几个其他成绩 。)

1. Cassandra未用vector clock, 而只用client timestamps也到达 了一样 后果 。
    
2. Dynamo依附 兼并 抵触 来处理 此成绩 ，一些场所 下抵触 很难处理 。好比 从list中毛病 的截取操作。(if deletion from the list is a valid operation – then how would one reconcile after mistaken truncation?)
    
3. 别的 一个场景，读取到脏数据后能够 会影响后续的写入。(a stale read may end up affecting writes to other keys)

普通 的知识 是读取脏数据是需求 防止 的，然而 Dynamo中无任何办法 来防止 读取脏数据和 防止 读取脏数据的客户端再次写入，这个在单IDC情况 实际上是 完整 可以免 的。

Quorum分歧 性

(译者注：Quorum是Dynamo的一个中心 特征 ，次要 思惟 是 写最大节 点数W + 读最大节 点数R > 一切 节点数N)
Dynamo 入手下手 就提到体系 按终究 分歧 性设计，然而 在4.5中却提出用Quorum的办法 来完成 必定 水平 的分歧 性，意思是假如 R+W>N, 则读操作就具有 (强)分歧 性了。分明 是误导。因为 节点会呈现 不成 用的情形 ，特别 在跨IDC情形 下，任一节点随时都有能够 分开 quorum组，当它分开 再到场 的时分 ，R个节点前往 的数据就是纷歧 致的，由于 毛病 节点的数据只具有 “终究 分歧 性”，而在事先 前往 的只能是脏数据。

这就带来一个分明 的成绩 ，为何 要让未同步到最新数据的节点到场 组？谜底 是Dynamo中无任何办法 来判别 一个节点是不是 数据同步，也没法 判别 有哪些数据分歧 步。因而 只能做一个完整 数据对照 才干 判别 ，Dynamo顶用 一种叫Merkle Tree的办法 来完成 ，这个固然 是一个价值 昂贵且不天真 的操作，由于 为了不影响Dynamo正常的读写营业 ，同步需求 在后台履行 。

完成 强分歧 性也能够 用读取一切 节点(R=N)的体例 来到达 ，不外 有2个成绩 。

1. 一旦有一个节点未同步，读取就会掉 败。
    
2. 读取的价值 极高。

我并非 第一个发明 这些成绩 的人，好比 另外一 著名 的Cassandra产物 Cassandra-225中就提到用一个中间 commit log的办法 来处理 此成绩 。

WAN considerations 跨IDC的成绩

值得指出的是，假如 将Dynamo安排 到多个机房，节点的断续情形 会很轻易 产生 。当一个节点毗连 不到，Dynamo的”hinted handoff”战略 会利用 分歧 性哈希算法将数据放入下一个节点。在多IDC情况 下，下一节点凡是 在另外一 机房，因而 会形成 异地数据传输增添 。当异地全部 IDC都连不上彀 络决裂 情形 产生 时，数据需求 很长工夫 才干 完整 恢复。

Disaster Recovery 灾害 恢复

Dynamo终究 分歧 性及同步的设计关于 是节点毛病 是有价值的，然而 却没法 预算 有几何 数据未同步。假如 改用惯例 的commit log体例 的话，很轻易 就可以 完成 毛病 恢复而且 盘算 未同步的数据量。

未利用 工夫 分歧 性(译者：基于timestamp的兼并 ？)在某些场所 下很难兼并 抵触 。

分歧 性仍是 可用性 Consistency versus Availability

普通 以为 Dynamo选择了CAP实际 中的AP，而BigTable选择了CA。不幸的是，Dynamo并没有弄 清甚么 是 A(availability)和P(Partition Tolerance)。读者被误导只能在C和P中做一个弃取 ，这个固然 是错的。咱们 很轻易 在单IDC完成 分歧 性及高可用性。大局部 贸易 数据库就是如斯 ，HBase/HDFS也是如斯 。

良多 人误觉得 即便 在单IDC架构中，Dynamo体例 比BigTable/GFS架构更公道 。但Dynamo的优势实际上是 在多IDC。

中间 化仍是 去中间 化

Dynamo中提到

In the past, centralized control has resulted in outages and the goal is to avoid it as much as possible. This leads to a simpler, more scalable, and more available system.
曩昔 ，中间 化设计招致 了良多 灾害 ，咱们 意想到 要阔别 中间 化。去中间 化后，体系 会更简约 ，更具有可扩大 性及高可用性。

中间 化的确 会构成 瓶颈，然而 没有证听说 明中间 化就低可用性。大局部 专业的存储体系 经由过程 双机热备的体例 都具有 高可用性。复杂 的说，只需求 一切 中间 模块(电源，主板，RAID，互换 机等)都按双份的体例 来设计，只需求 额定 增添 一点硬件本钱 ，这些体系 根基 可以到达 5个9的可用性。

值得取笑 的是Dynamo其其实 局部 情形 下仍是 一个中间 化的系统 ，如互换 机毛病 产生 了收集 分片，办事 器分红 2个自力 的小网，这时候 候Dynamo对客户端是不成 用的，虽然 客户端可以毗连 上Dynamo。

更取笑 的是咱们 看到Dynamo良多 分歧 性成绩 都是去中间 化设计所招致 。

–译文完–

此文的会商 也十分 出色 ，关于 想深切 懂得 Dynamo的伴侣 是车载斗量 的材料 。