搜寻了一下AWS DynamoDB和Dynamo之间的区别

实际上，与Dynamo论文中的实现最接近的AWS服务似乎是S3。Dynamo和DynamoDB在架构和实现上有所不同，有以下几点差别。

构成的差异 de

魔术师

• リーダーレス

クライアントが更新データを複数ノードに書き込む（クライアントサイドでレプリ）

DynamoDB是一个NoSQL数据库服务。

• シングルリーダー（パーティションキーごとの）

Paxosでリーダー選出 / 1.5秒ごとのハートビート 5

イメージ的にはマスタースレーブ形式の同期レプリみたいな

クライアントはリーダー経由で書き込みをリクエスト

是否发生了写入冲突

活力神

• 複数クライアントからの書き込みが衝突するケースがある

→ 書き込みが衝突したら、アプリ側で読み込み時に解決する必要がある（後述の補足参照）
（調整してくれるリーダーはいない…）
（常にスプリットブレインし続けているのをアプリがなんとかし続けるイメージ…）

DynamoDB -> 动态数据库

• 書き込みが衝突しない（リーダーが調整）

→ アプリで特に何か注意する必要はない

非常重要的事物 / 付出了牺牲的事物

活力无限

• 可用性を重視

単一障害点（リーダーノード）がなく、対象ノードのいくつかにアクセスできれば読み書きできる。
Dynamoの論文では可用性をめっちゃアピールしている

always-on, always writable

writes are never rejected
high availability where updates are not rejected even in the wake of network partitions or server failures
no updates are rejected due to failures or concurrent writes

逆にデータの一貫性（アプリからの使いやすさ）は犠牲にしている。

DynamoDB 动态数据库

• データの一貫性（アプリからの使いやすさ）を重視

アプリが書き込みの衝突を解決しないでいい

逆に多少の可用性は犠牲にしている

フェイルオーバーの時間分（リーダーが落ちて最大1.5秒＋Paxosのリーダー選出の時間）は書き込みできない（と思う）。

補充：「应用程序在加载时解决写入冲突」是什么意思？

在Dynamo等软件中，例如以下的写入会发生冲突。6 1

1. クライアントAが次のような更新をします：

  { key = user_id:1234, value = name:Alice }

2. 同時にクライアントBが次のような更新をします：

  { key = user_id:1234, value = name:Bob }

3. このとき、書き込みが衝突して次のようになります：

  { key = user_id:1234, value = name:Bob and/or value = name:Alice }

当应用程序读取数据时，到底是Alice还是Bob是正确的呢？

「通过应用程序解决冲突的写入」意味着必须在应用程序中判断哪个是正确的（或者两者都是正确的）。我认为这很困难（这可能是为什么Dynamo的采用数量很低4）。

Cassandra等遵循最后写入原则，并且无需处理应用程序的写入冲突。然而，这种冲突解决方式是否理想可能因情况而异（例如，Facebook选择了易于理解一致性的HBase，而不是他们自己开发的Cassandra）。