適切な整合性レベルの選択
各整合性モデルは、特定の現実のシナリオに使用できます。 それぞれが正確な可用性とパフォーマンスのトレードオフをもたらすものであり、包括的な SLA によってサポートされます。 次の単純な考慮事項は、多くの一般的なシナリオで最適な選択を行う際に役立ちます。
既定の整合性レベルを構成する
Azure Cosmos DB アカウントの既定の整合性レベルはいつでも構成できます。 自分のアカウントに構成されている既定の整合性レベルは、そのアカウントのすべての Azure Cosmos DB データベースおよびコンテナーに適用されます。 コンテナーまたはデータベースに対して発行されるすべての読み取りとクエリでは、指定された整合性レベルが既定で使用されます。
読み取り整合性は、論理パーティション内をスコープとする 1 つの読み取り操作に適用されます。 読み取り操作はリモート クライアントまたはストアド プロシージャが発行できます。
整合性レベルに関連付けられた保証
Azure Cosmos DB では、読み取り要求の 100 パーセントが、選択した整合性レベルについて整合性の保証を満たすことが保証されます。 TLA+ 仕様言語を使用した Azure Cosmos DB での 5 つの整合性レベルの正確な定義は、azure-cosmos-tla GitHub リポジトリで提供されています。
"強固" 整合性
強力な一貫性は、線形化可能性保証を与えます。 線形化可能性は、要求に同時にサービスを提供することを意味します。 読み取りでは、アイテムの最後にコミットされたバージョンが返ることが保証されています。 クライアントが、コミットされていない書き込みや部分的な書き込みを見ることは決してありません。 ユーザーが最新のコミット済みの書き込みを読み取ることが常に保証されます。
"有界整合性制約" 整合性
有界整合性制約の整合性を確保するために、読み取りでは、整合性のあるプレフィックスの優先が保証されます。 読み取りは、最大でアイテムの "K" 個のバージョン (更新)、あるいは期間 "T" のどちらか早く達した方の分だけ書き込みよりも遅れる場合があります。 つまり、有界整合性制約を選択する場合、"整合性制約" は 2 つの方法で構成できます。
- アイテムのバージョンの数 (K)
- 書き込みに対して読み取りが遅れる可能性がある期間 (T)
単一リージョン アカウントの場合、K と T の最小値は 10 回の書き込み操作または 5 秒です。 複数リージョン アカウントの場合、K と T の最小値は 100,000 回の書き込み操作または 300 秒です。
"セッション" 整合性
セッション整合性での単一のクライアント セッション内の読み取りでは、整合性のあるプレフィックス、単調読み取り、単調書き込み、自己書き込みの読み取り、読み取り後の書き込みの優先が保証されます。 これは、単一の「ライター」セッションを使用するか、複数のライターのセッション トークンを共有することを前提としています。
"一貫性のあるプレフィックス" 整合性
一貫性のあるプレフィックスでは、単一ドキュメントの書き込みとして行われる更新の場合、最終的な整合性が表示されます。 トランザクション内でバッチとして行われた更新は、それがコミットされたトランザクションと一貫性を保って返されます。 複数のドキュメントに対するトランザクション内の書き込み操作は、常に一緒に表示されます。
トランザクション T1 と T2 内で、ドキュメント Doc 1 と Doc 2 に対して 2 つの書き込み操作を行ったとします。 クライアントがいずれかのレプリカ内で読み取りを行った場合、ユーザーには "Doc 1 v1 と Doc 2 v1" または "Doc 1 v2 と Doc 2 v2" のどちらかが表示されますが、同じ読み取りまたはクエリ操作に対して "Doc 1 v1 と Doc 2 v2" または "Doc 1 v2 と Doc 2 v1" が表示されることはありません。
最終的な一貫性
最終的な整合性では、読み取りの順序の保証はありません。 さらに書き込みがない場合、レプリカが最終的に収束します。
クライアントが以前に読み取ったものより古い値を読み取ることがあるため、最終的な整合性は最も弱い形態の整合性です。 最終的整合性は、順序保証がアプリケーションで要求されないときに最適です。 たとえば、リツイート、いいね、スレッド化されていないコメントなどです