Loading article…
結果的一貫性は、分散コンピューティングで高可用性を実現するために使用される一貫性モデルであり、特定のデータ項目に新しい更新が行われない場合、最終的にはその項目へのすべてのアクセスで最後に更新された値が返されることを非公式に保証します。[1]結果的一貫性は楽観的レプリケーションとも呼ばれ、[2]分散システムで広く導入されており、初期のモバイルコンピューティングプロジェクトに起源があります。[3]結果的一貫性を実現したシステムは、多くの場合、収束した、またはレプリカ収束を達成したと言われます。[4]結果的一貫性は弱い保証であり、線形化可能性などのほとんどの強力なモデルは、当然のことながら結果的に一貫しています。
最終的に一貫性のあるサービスは、従来のACID（原子性、一貫性、独立性、耐久性）とは対照的に、BASEセマンティクス（基本的に利用可能、ソフトステート、最終的な一貫性）を提供するものとして分類されることが多い。[5] [6]化学では、塩基は酸の反対語であり、頭字語を覚えるのに役立ちます。[7] 同じリソースによると、これらはBASEの各用語の大まかな定義です。
- 基本的に利用可能: 読み取りおよび書き込み操作は可能な限り利用可能 (データベース クラスターのすべてのノードを使用) ですが、一貫性がない可能性があります (競合が調整された後も書き込みが持続しない可能性があり、読み取りで最新の書き込みが取得されない可能性があります)。
- ソフトステート: 一貫性の保証がなければ、ある程度の時間が経過すると、まだ収束していない可能性があるため、状態を知ることができる確率は限られる。
- 結果的に一貫性がある: 書き込みをいくつか実行し、システムが十分に機能すると、データの状態を知ることができます。そのデータ項目のそれ以降の読み取りでは、同じ値が返されます。
結果的一貫性は、分散ソフトウェアアプリケーションの複雑さを増大させると批判されることがあります[8] 。これは、結果的一貫性が純粋に生存性の保証（読み取りは最終的に同じ値を返す）であり、安全性を保証するものではないためです。結果的一貫性のあるシステムは、収束する前に任意の値を返す可能性があります。
紛争解決
レプリカの収束を確実にするために、システムは分散データの複数のコピー間の相違点を調整する必要があります。これは次の 2 つの部分で構成されます。
- サーバー間でデータのバージョンや更新を交換すること（反エントロピーと呼ばれることが多い）[9]
- 同時更新が発生したときに適切な最終状態を選択することを「調整」と呼びます。
最も適切な調整方法はアプリケーションによって異なります。広く普及している方法は「最後の書き込みが勝つ」です。[1] もう 1 つは、ユーザー指定の競合ハンドラーを呼び出すことです。[4] タイムスタンプとベクター クロックは、更新間の同時実行を検出するためによく使用されます。「最後の書き込みが勝つ」が受け入れられない状況では、「最初の書き込みが勝つ」を使用する人もいます。[10]
同時書き込みの調整は、次の読み取りの前に行われる必要があり、異なるタイミングでスケジュールすることができます。[3] [11]
- 読み取り修復: 読み取り時に不整合が見つかった場合に修正が行われます。これにより、読み取り操作が遅くなります。
- 書き込み修復: 修正は書き込み操作中に行われるため、書き込み操作が遅くなります。
- 非同期修復: 修正は読み取りまたは書き込み操作の一部ではありません。
強い結果整合性
結果的一貫性は、活性保証（更新は最終的に観察される）のみであるのに対し、強い結果的一貫性（SEC）は、同じ（順序なしの）更新セットを受信した任意の2つのノードが同じ状態になるという安全性の保証を追加します。さらに、システムが単調であれば、アプリケーションがロールバックを受けることはありません。SECを保証する一般的なアプローチは、競合のない複製されたデータ型です。[12]
参照
参考文献
- ^ ab Vogels, W. (2009). 「最終的に一貫性がある」. Communications of the ACM . 52 : 40–44. doi : 10.1145/1435417.1435432 .
- ^ Vogels, W. (2008). 「最終的に一貫性がある」.キュー. 6 (6): 14–19. doi : 10.1145/1466443.1466448 .
- ^ ab Terry, DB; Theimer, MM; Petersen, K.; Demers, AJ; Spreitzer, MJ; Hauser, CH (1995). 「Bayou における更新競合の管理、弱く接続された複製ストレージ システム」。第15回ACM オペレーティング システム プリンシプル シンポジウムの議事録 - SOSP '95。p. 172。CiteSeerX 10.1.1.12.7323。doi :10.1145 / 224056.224070。ISBN 978-0897917155. S2CID 7834967。
- ^ ab Petersen, K.; Spreitzer, MJ; Terry, DB; Theimer, MM; Demers, AJ (1997). 「弱一貫性レプリケーションのための柔軟な更新伝播」ACM SIGOPS オペレーティング システム レビュー. 31 (5): 288. CiteSeerX 10.1.1.17.555 . doi :10.1145/269005.266711.
- ^ Pritchett, D. (2008). 「塩基：酸の代替」.キュー. 6 (3): 48–55. doi : 10.1145/1394127.1394128 .
- ^ Bailis, P.; Ghodsi, A. (2013). 「今日の最終的な一貫性：限界、拡張、そしてその先」. Queue . 11 (3): 20. doi : 10.1145/2460276.2462076 .
- ^ Roe, Charles (2012 年 3 月)。「ACID vs. BASE: データベース トランザクション処理の pH の変化」。DATAVERSITY。DATAVERSITY Education , LLC。2019年8 月 29 日閲覧。
- ^ H Yaniv Pessach (2013)、分散ストレージ(分散ストレージ: 概念、アルゴリズム、実装編)、Amazon、OL 25423189M、
結果整合性を使用するシステムは、システム負荷の軽減とシステム可用性の向上をもたらしますが、ユーザーと開発者の認知的複雑さが増します。
- ^ Demers, A.; Greene, D.; Hauser, C.; Irish, W.; Larson, J. (1987). 「複製データベース保守のためのエピデミックアルゴリズム」。第 6 回 ACM 分散コンピューティングの原理に関するシンポジウム議事録 - PODC '87。p. 1。doi : 10.1145 / 41840.41841。ISBN 978-0-89791-239-6. S2CID 1889203。
- ^ Rockford Lhotka. 「並行処理テクニック」Wayback Machineで 2018 年 5 月 11 日にアーカイブ。2003 年。
- ^ Olivier Mallassi (2010-06-09). 「Cassandra で遊ぼう… (パート 1/3)」. OCTO Talks! . 2011-03-23取得。
もちろん、特定の時点では、各ノードが独自のデータ バージョンを持っている可能性が高くなります。競合の解決は読み取り要求時に行われます (読み取り修復と呼ばれます)。現在のバージョンの Cassandra では、ベクター クロック競合解決メカニズム [sic] が提供されていません (バージョン 0.7 で利用可能になるはずです)。競合の解決はタイムスタンプ (行または列を挿入するときに設定されるもの) に基づいて行われます。タイムスタンプが大きい方が勝ち、データを読み取っているノードがその責任を負います。これは重要なポイントです。なぜなら、タイムスタンプは列が挿入された時点でクライアントによって指定されるからです。したがって、すべての Cassandra クライアントの [sic] を同期させる必要があります...
- ^ Shapiro, Marc; Preguiça, Nuno; Baquero, Carlos; Zawirski, Marek (2011-10-10). 「競合のない複製されたデータ型」。SSS'11 Proceedings of the 13th International Conference on Stabilization, Safety, and the Security of Distributed Systems。Springer-Verlag Berlin、ハイデルベルク: 386–400。