何
- DynamoDBの参照はデフォルトが結果整合性なのでCAP定理のAP型(一貫性を犠牲にして可用性をとった設計)と紹介されていた。では「強力な整合性のある読み込み」オプションをどう考えたら良いのか？
- AP型のDynamoDBで、強力な・・・を選べば(+Cで)CAP定理の限界を超えた！な訳はないはず。
CAP定理とは(wikipediaより)
- ノード間のデータ複製において、同時に次の3つの保証を提供することはできない
- 一貫性 (Consistency)：すべてのデータ読み込みにおいて、最新の書き込みデータもしくはエラーのどちらかを受け取ること
- 可用性 (Availability)：単一障害点が存在しないこと
- 分断耐性 (Partition-tolerance)：通信可能なサーバーが複数のグループに分断されないこと
考えるヒント1
- 強力な整合性のある読み込みは、ネットワークの遅延または停止があった場合には利用できなくなる可能性があります。
考えるヒント2
- https://aws.amazon.com/jp/dynamodb/faqs/
- 結果整合性のあるオプションを選択すると、読み込みスループットが最大限に向上します。
考えるヒント３
- http://dev.classmethod.jp/cloud/aws/dynamodb-new-parameter-consistent-read/
- 強力な整合性のある読み込みは)書き込まれている3箇所より2箇所の値を読み取り、一致すればその値を、一致しなければもう1箇所の値を読んで2箇所に書き込まれている値を返す、という仕組みになります。
現時点のアイデア
- 「強力な整合性」は、分散ノードの値を複数みて比較しないといけないため、値を参照するまでの時間が伸びているという意味で「可用性が落ちている(CP型)」と考える。
- ネットワークの問題がないときにCA型、ネットワークの問題があるときにAP型になる、と考える。
別の方向から考える
- MySQLでレプリケーション遅延が起きれば、一貫性が損なわれるのでAP型になっている。(スレーブはCを捨ててAを実現している)
- 思考実験１）マスターとスレーブの値をすべて取得して、一致したときだけ値を返すようにラップすれば、CP型になる？(一致するまでは結果を返せないのでAを捨てている)
- 思考実験２）遅延したスレーブは切り捨てて、マスターと遅延していないスレーブだけが値を返すようにラップすれば、CA型になる？(ネットワークの問題により故障していないノードが使えなくなるのでPを捨てている)
その他
- Dynamoの論文が読めるらしいので読んでみよう
- http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf