created: 2021-06-30T07:43:48.000Z

CAP定理のメモ

CAP定理とは有名な3つの特性があり、これらをすべて満たすDBを作ることは出来ないというもの。

3つと書いてあるが、実際には分断耐性は「分散DBか否か」ということであり、CAP定理が登場する文脈はだいたい分散DBの話なので「分散DBでは一貫性と可用性どちらかを諦める必要があるよ」という話である。

書き込みがアトミックに行われるという意味で、レコードを書き込んだ直後にそのレコードを参照しても書き込んだ値が読めることをいう。

DynamoDBは「結果整合性(弱い整合性)」というモードを使うことが出来る。これを使う場合はレコードを書いた後の数百msはreadしたときに書き込み以前の値が取れる場合がある。

クエリを投げたらきちんと結果が帰ってくること。

DynamoDBの「弱い整合性」の例では一貫性を犠牲にして可用性を優先していることになる。逆にいうと一貫性(強い整合性)を担保しようとするDBではクエリが返すのが遅くなるということ。

データを分散して格納すること。これを諦めると一貫性と可用性を両方満たせる。 MySQLなどのRDBMSはこの特性を持っていないのでデータを更新した直後も正しいデータが素早く返ってくる。

参考

こちらで引用されてるビヨンセのアルバム数の例はとても役にたった