実はDynamo論文1 の実装に一番近いAWSサービスはS3らしい 2 です。DynamoとDynamoDBはアーキテクチャ/実装が違っていて3 4下記のような違いがあるようです。
| 可用性 | アプリからの使いやすさ | |
|---|---|---|
| Dynamo | ◎ | △？ |
| DynamoDB | ○ | ◎ |
構成の違い
Dynamo
- リーダーレス
- クライアントが更新データを複数ノードに書き込む（クライアントサイドでレプリ）
DynamoDB
- シングルリーダー（パーティションキーごとの）
- Paxosでリーダー選出 / 1.5秒ごとのハートビート 5
- イメージ的にはマスタースレーブ形式の同期レプリみたいな
- クライアントはリーダー経由で書き込みをリクエスト
書き込みの衝突の有無
Dynamo
- 複数クライアントからの書き込みが衝突するケースがある
- → 書き込みが衝突したら、アプリ側で読み込み時に解決する必要がある（後述の補足参照）
- （調整してくれるリーダーはいない...）
- （常にスプリットブレインし続けているのをアプリがなんとかし続けるイメージ...）
DynamoDB
- 書き込みが衝突しない（リーダーが調整）
- → アプリで特に何か注意する必要はない
重要視しているもの / 犠牲にしているもの
Dynamo
- 可用性を重視
- 単一障害点（リーダーノード）がなく、対象ノードのいくつかにアクセスできれば読み書きできる。
- Dynamoの論文では可用性をめっちゃアピールしている
-
always-on,always writable writes are never rejectedhigh availability where updates are not rejected even in the wake of network partitions or server failuresno 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のどちらが正しいのでしょうか？
「アプリによる書き込みの衝突の解決」とは、このどちらが正しいか（or どちらも正しい）をアプリで判断しなければならないということです。これは大変だと思います（そのためかDynamoは adoption lagged らしいです 4）。
Last Write WinsであるCassandraなどはアプリで書き込みの衝突を解決しなくても済むようになっています。ただそれが好ましい衝突の解決方法なのかは別かもしれません(Facebookが自身で作ったCassandraではなくデータの一貫性がわかりやすいHBaseを採用した例7 など)