結果整合性 とは？

データを複数のレプリカにコピーする構成を考えよう。更新が届くまでの間は、新しい値を返すレプリカと古い値を返すレプリカがあり得る。追加の更新が止まり、通信などが回復して更新を伝播できれば、最終的に同じ値を読めるようになるんだ。必ず数秒で揃うという保証ではないよ。

用途ごとに判断するよ。たとえば「いいね数の表示」は遅れを許容する設計も考えられる。一方、残高や在庫に基づく処理の確定では、同時更新や二重処理も考えて整合性やトランザクションを設計する必要がある。同じサービス内でも、表示と確定処理で必要な保証は違い得るんだ。

製品や操作によって違うよ。DynamoDBのテーブルとローカルセカンダリインデックスでは、結果整合性の読み取りと強い整合性の読み取りを選べる。一方、グローバルセカンダリインデックスなどは強い整合性の読み取りに対応しない。サービス名だけでなく、対象と設定を見る必要があるんだ。

現在のS3は、オブジェクトのPUTやDELETEに対して強い整合性を提供しているよ。成功した書き込みの後の読み取りで、その更新を確認できる。すべての分散ストレージを結果整合性として説明するのは不正確なので、そのサービスが今どの操作にどんな保証を提供するかを確かめよう。

単純な値の多数決ではないよ。Cassandraでは必要数のレプリカから応答を集め、タイムスタンプなどの規則で新旧の値を扱う。読み取り数Rと書き込み数Wがレプリカ数RFに対してR＋W＞RFなら応答集合が重なる、という考え方を使うんだ。競合解決やレプリカの修復も別に必要になるよ。