整合性モデルを理解する
分散データベース システムで、ユーザーの可用性を向上させたり、読み取りの待機時間が短縮するために、ワイド エリア ネットワーク経由で他のリージョンにデータをレプリケートしている場合、データは他のリージョンに同期的にコミットされるため、データベース全体のデータの完全な一貫性、または書き込みの待機時間を長さをトレードオフさせる必要があります。
Azure Cosmos DB には整合性のスライディング スケールが用意されており、他のデータ ストレージ ソリューションによって提供される従来の強のオプションと弱のオプションの間の多数のオプションがあります。
5 つの各整合性レベルは、互いに比べた場合にトレードオフがはっきりするように明確に定義されています。
| 整合性レベル | 説明 |
|---|---|
| 厳密 | 線形整合性。 データは、すべての構成済みリージョンにレプリケートおよびコミットされてから、すべてのクライアントにコミットされ、表示されます。 |
| 有界整合性制約 | 読み取りが、構成されたしきい値 (時間または項目数) まで書き込みよりも遅れます。 |
| セッション | 特定のセッション (SDK インスタンス) 内で、ユーザーは自己の書き込みを読み取ることができます。 |
| 一貫性のあるプレフィックス | 読み取りが書き込みよりも遅れる可能性がありますが、読み取りの順序が合わなくなることはありません。 |
| 最終的 | 読み取りは最終的には書き込みと一致します。 |
"強固" 整合性
"強固" 整合性では、すべての読み取り操作で項目の最新バージョンが返されることが保証されます。 待機時間や不整合のために、クライアント アプリケーションが古い項目を読み取ることはありません。 書き込み操作が完全にコミットされるのは、他のすべてのリージョンで準備が整ってからです。
この特性が原因で、"強固" 整合性では待機時間が最も長くなります。地理的に遠い距離までコミットがレプリケートされるのを待つ必要があるためです。
"有界整合性制約" 整合性
"有界整合性制約" は "強固" 整合性に似ていますが、読み取りが定義済みのしきい値まで書き込みよりも遅れる点が異なります。 そのしきい値は、次のように定義できます。
- 書き込みよりも遅れる項目のバージョン数 (K)
- 書き込みよりも遅れる時間間隔 (T)
"有界整合性制約" は、書き込み待機時間を短くしたいが、適切なしきい値までは整合性を保つ必要があるアプリケーションのための優れた妥協点です。
ヒント
有界整合性制約は、データが書き込まれるリージョンに強力な一貫性を保証します。
"セッション" 整合性
セッションの整合性では、単一のクライアント セッション内、または SDK とクライアント間でセッション トークンが渡される場合に、自己の書き込みの読み取りが保証されます。 これ以外は、"一貫性のあるプレフィックス" または "最終的" 整合性のいずれかに整合性の保証は緩和されています。
"セッション" 整合性は、エンド ユーザーが自分で行ったトランザクションをすぐに確認できない場合に混乱する可能性があるアプリケーションにとって最適なオプションです。
"一貫性のあるプレフィックス" 整合性
"一貫性のあるプレフィックス" 整合性では、一貫性は低下しますがパフォーマンスは向上します。これでは、書き込みが遅れる読み取りが、書き込まれた順序で表示されることを保証します。
"一貫性のあるプレフィックス" 整合性は、読み取り操作の順序が待機時間よりも重要なアプリケーションに最適です。
最終的な一貫性
"最終的" 整合性は、最も弱い整合性の形式です。読み取りは書き込みよりも遅れ、読み取りが順序に合わない可能性があります。 ただし、"最終的" 整合性では、書き込み待機時間は最も短く、可用性は最も高くなり、他のオプションと比較して読み取りスケーラビリティが最も大きくなる可能性があります。
"最終的" 整合性は、線形または整合性の保証が必要ないアプリケーションに適したオプションです。