我阅读了有关数据存储一致性和Amazon Dynamo论文的考察

最近推出的Azure Cosmos DB似乎可以选择与5种一致性级别相匹配的选项进行部署。虽然有点陈旧，但当Facebook在考虑一致性时选择采用HBase而不是他们自己开发的Cassandra时，我感到非常惊讶。

在这种感觉下，“一致性”似乎是重要的。 zhè xià, “” shì de.)

我对数据存储的兴趣是在经历了分布式数据库管理系统（DBMS）的开发后产生的，最近我也对”一致性”进行了一些调查研究，并想整理一下写下来。另外，我觉得掌握基础知识非常重要（虽然这篇论文已经是10年前的文章了），所以我也想谈谈亚马逊Dynamo的论文《Dynamo: 亚马逊高可用键值存储》。

我不太了解 CAP 的 C 和 ACID 的 C。

在公钥的”为什么云上的关系型数据库很难？与BASE和CAP理论有关”这篇文章中，有人似乎混淆了CAP的C和ACID的C，产生了修改线（误解了Consistency的用法）。

根据 http://d.hatena.ne.jp/winplus/20091023/1256305279 的描述，内容如下所述。

• ACID的C：在从账户A进行转账时，不能发送使得A账户余额变为负数的金额。
• CAP的C：确认从账户A进行转账后，该账户余额总是转账后的金额。

这个网页还对CAP的C和ACID的C进行了讨论，除了这个网页还有其他网页也有相关内容。
– 令人困惑的CAP和ACID的术语
– yohei-y:weblog: CAP的C和ACID的C
– 支持云时代分布式数据库的技术应用和进步- kuenishi的博客

ACID中的C在银行账户中很容易理解，但CAP中的C表示“能否正确地阅读其他客户的写入（是否有一致性）”=“是否满足某种一致性模型”这样来理解。

最终一致性

顺便提一句，Eventual Consistency似乎与这些有所不同。

经常可以看到这样的解释：“在由多个节点组成的系统中，每个节点最终都会拥有相同的副本。”但这只是关于内部运行的描述，没有提及对外部可见的行为，导致客户端不知道该如何连接。

这是不是意味着在Eventual Consistency中，节点之间的数据复制不仅缺乏一致性，而且在客户端可见的行为上也缺乏一致性？我在后面的”当读取最新数据再次读取时出现数据回滚的情况（Quorum版本）”中考虑了这一点。

我喜爱的一致性模型

听说将并行系统和分布式系统的读写行为建模的东西称为一致性模型。

通过意识到现有的一致性模型，可以避免做出难以理解的解释而被责骂，或者陷入复杂而难以理解的个人一致性模型中（例如，在应用程序中使用分布式数据库或为应用程序提供分布式系统时）。

因此，我想要稍微介绍一下我喜欢的一致性模型。

Strict Consistency

いつ読んでも最新の値が読める（直前に書かれた値が読める）というものです。シンプルです。
1ノードだけのシステムや分散システムでもマスターノードが存在する（選出される）＋同期レプリの場合にStrict Consistencyの場合が多そうです。

Causal Consistency

書き込み直後に最新のデータが読めるとは限りませんが、どのクライアントから見てもデータの変遷は同じというものです。
Message QueueなどのPersistent Communication機能をもつ場合、このConsistencyをみたすと思います
（メッセージを書いた直後だと最新データは読めませんがメッセージがデータノードに反映されれば読めるため）。

Read-your-writes Consistency

例えばSNSに自分の近況を書いていつまでも自分のタイムラインに表示されないと不安ですが、このConsistencyなら自分の投稿がすぐ読めるので不安になって連投してしまうことがありません。安心です。

多余的部分

根据谷歌云数据存储（Google Cloud Datastore）的基于 Megastore 的研究论文，它通过将读写主节点分割为实体组（Entity Group）并将读写操作落到本地事务中，以确保严格一致性。

在Global Index中，似乎在更新表格记录时，会将索引更新消息暂时写入消息队列，然后执行索引更新。

我曾思考使用索引的讀取在Causal Consistency下會是怎樣的情況，但我理解索引所指向的記錄數據與之不一致（實體群組不同），因此導致了Eventual Consistency：https://cloud.google.com/datastore/docs/articles/balancing-strong-and-eventual-consistency-with-google-cloud-datastore/?hl=ja#h.4xdytk3hj44

我的理解是：使用索引進行讀取時，由於索引指向的記錄數據與其不一致（實體群組不同），因此達到的一致性是Eventual Consistency。

在阅读最新数据后再次读取时，出现了回到旧数据的情况（Quorum版本）。

我希望在这里写下自己对于最终一致性行为理解不够清楚的方面。

根据https://docs.microsoft.com/ja-jp/azure/cosmos-db/consistency-levels#a-nameconsistency-levelsa一致性级别，”Eventual Consistency”表示客户端可能获取比之前获知的值更旧的值，这可能导致获取的值的新旧程度不一致的情况（至少在Azure的定义中是如此）。

在Dynamo系列数据存储中，仅在一个节点上进行读写操作的模式下，当然会出现数值新旧的差异。但即使在这里设置了Quorum，也想考虑一下数据是否可能回滚的情况（可能是错误的）。

想要设置的数据存储系统

我們假設這個數據存儲具有以下可能存在於許多Dynamic系統數據存儲中的功能。

Quorum

ここではデータのレプリカを2つ持つとして、3ノード中2ノードに書き込めたら書き込み成功、2ノードから同じデータが読み込めたら読み込み成功とします。
この場合、障害さえ発生しなければ書き込み完了後に読めばStrict Consistencyな気がします（3ノード中2ノードに書き込めば3ノード中2ノードから読めるので）。

Read Repair

データを読んだときに各ノード間でデータの不整合を検知した場合に修復をおこないます。

Hinted Handoff

担当ノードにデータが書き込めなかった場合、別ノードにとりあえず書いておいて、後から書き込めなかったノードを修復します。

当数据发生回滚时的行为

假设有3个服务器节点和3个客户端来存储数据。其中一个客户端正在尝试写入数据，而另外两个客户端正在尝试读取数据。

我认为这种情况在现实中几乎不会发生/已实施了许多功能以减少不一致。例如，Dynamo的论文中写道：“在我们的下一个实验中，我们针对一个时间段为24小时的购物车服务返回的版本数量进行了分析。在此期间，99.94%的请求仅看到一个版本；0.00057%的请求看到了2个版本；0.00047%的请求看到了3个版本；0.00009%的请求看到了4个版本。这表明不一致的版本很少被创建。”这证明了几乎没有不一致存在。

但是，当只写着”Eventual Consistency”这样的字样时，我感到功能变得非常复杂，行为也变得难以理解。

为什么Dynamo能够引领NoSQL的潮流（诗篇）

我觉得NoSQL的流行可能是从Dynamo的论文开始的（需要出处）。

像HBase这样的CP型数据存储系统从写入阶段开始就考虑了一致性问题，而像Dynamo这样的AP型数据存储系统虽然在读取阶段需要一些技巧，但有以下优点：
– 不会阻塞写入（也包括读取）操作（具有高可用性）
– 易于横向扩展
– 易于进行故障恢复
– 几乎没有不一致性的概率

在这一点上能够吸引人们的注意力可能是非常重要的，不是吗？

在以前看来，数据存储中的一致性被认为是必不可少的，但现在我们可以宣称“没有也没问题”，这具有很大的影响力。我认为，在允许最终一致性的服务中，AP型的数据存储可以完全占据有利地位，与竞争对手的数据存储相对立。

高度可用性

論文中一再三強調了高可用性的重要性，即使在网络分割或服务器故障的情况下，也能实现高可用性更新，永不拒绝写入（即使无法使用一些节点时，只要能够将数据写入可写节点，从可读节点读取数据，可用性就非常高，为此会牺牲一定程度的一致性）。

由于这个原因，在数据读取时，文章中还提到了一些需要应用程序端进行某种冲突解决的情况。例如，当多个客户端同时写入并乱序排列数据时，在读取时需要确定哪些数据是有效的。在论文中，提到了一些解决冲突的方法，例如合并每个节点读取的数据（适用于购物车）以及根据时间戳确定写入时间最晚的数据为有效数据的方法。

Dynamo和DynamoDB之间的区别是什么？

尽管DynamoDB的公共服务细节没有公开（可能与Dynamo类似），但相较于Dynamo而言，它给人一种可靠的感觉（因为有Strong Consistency的描述）。

注意：凡配有到公共关服务的国际信息，描述语陈以“不觉漏察”加暗示注意事项。这不是该描述中的真实情况，而只是设法根据问题提供一种假设情况。

在DynamoDB中，可能不需要应用程序层的冲突解决，因为我看到DynamoDB提到它在3个可用区之间进行同步复制，所以它与Dynamo可能有很大的不同。

我对Stack Overflow上关于Cassandra实现的答案进行了思考，对其实现方式产生了浓厚的兴趣。

https://stackoverflow.com/questions/20544518/dynamodb-conditional-writes-vs-the-cap-theorem

以下是我参考的文献。

• Cosmos DB

https://docs.microsoft.com/ja-jp/azure/cosmos-db/consistency-levels

FacebookのHBase利用

http://www.publickey1.jp/blog/10/facebookmysqlcassandrahbase.html

Dynamo: Amazon’s Highly Available Key-value Store

http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html
( http://docs.basho.com/riak/kv/2.2.3/learn/dynamo/ )

CAP/ACID

http://blog.thislongrun.com/2015/03/the-confusing-cap-and-acid-wording.html
http://yohei-y.blogspot.jp/2009/03/capcacidc.html

https://en.wikipedia.org/wiki/CAP_theorem

Consistency Model

https://en.wikipedia.org/wiki/Consistency_model
http://www-higashi.ist.osaka-u.ac.jp/~nakata/mobile-cp/chap-06j-1.pdf

Google Cloud Datastore

https://cloud.google.com/datastore/docs/articles/balancing-strong-and-eventual-consistency-with-google-cloud-datastore/?hl=ja
Megastore: http://cidrdb.org/cidr2011/Papers/CIDR11_Paper32.pdf

Bigtable : http://static.googleusercontent.com/media/research.google.com/en/us/archive/bigtable-osdi06.pdf

DynamoDBの同期レプリ

https://aws.amazon.com/jp/dynamodb/faqs/
( https://forums.aws.amazon.com/message.jspa?messageID=466349 )
( https://www.slideshare.net/shimy_net/amazon-dynamodb-23315068/6 )

Data loss

https://aphyr.com/posts/285-call-me-maybe-riak
https://aphyr.com/posts/294-call-me-maybe-cassandra/