または「データウェアハウスをCPまたはAPとして特徴付けることをやめる」



ジェフ・ホッジスは、優れた投稿「初心者向け分散システムに関するノート」で 、見つかったソリューションを批判するためにCAP定理を使用することを推奨しています。 多くの人は、このアドバイスを心に留めすぎており、システムを「SR」（データの一貫性はあるが、ネットワーク配信で一定の可用性はない）、「AR」（ネットワーク配信で一貫した状態のない可用性）、または「CA」と表現しています（つまり、 5年前にCoda Haleの記事をまだ読んでいません。 ）



SAR定理を除く記事のすべての点に同意します。 それはすべてを単純化しすぎ、システムの特性を判断するためにそれを使用するために多くの人々がそれを誤解します。 ですから、SAR定理への言及をやめ、それについて話し、すでに冷静に引退させてください。 代わりに、より正確な用語を使用して、さまざまなトレードオフを議論する必要があります。



（はい、私は他の人にまったく書かないことを勧めるトピックに関する記事全体を書くことの皮肉を理解します。しかし、少なくとも私はCAP定理の議論を承認しない理由を尋ねるときに興味がある人に与えることができるリンクを持っていますまた、記事があなたにとってあまりにも気前が悪いと思われる場合は謝罪したいのですが、この威厳は多くのリンクに依存しています。）

ATSの使用する定義が狭すぎる

CAPを（データベースのマーケティング資料の曖昧な概念ではなく） 定理として参照する場合は、正確でなければなりません。 数学には精度が必要です。 プルーフは、プルーフで使用されたのと同じ意味の言葉で入力した場合にのみ保存されます。 そして、それは非常に正確な定義に依存しています。

• CAPの一貫性とは、実際には線形化可能 性を意味し、これは一貫性の （そして非常に強力な）原則です。 特に、これはACIDの「C」とは関係ありません。たとえそのCが「一貫性」を意味していてもです。 線形化可能性については、後で少し説明します。
• CAPの可用性は、「システム内の作業ノード[データベース]が受信するすべての要求が応答[エラーなし]につながる必要がある」と定義されています。 一部のノードがリクエストを処理できるだけでは十分ではありません。動作中のノードはリクエストを処理できる必要があります。 いわゆる「高可用性」、つまり ダウンタイムが短いため、実際のシステムは可用性の定義を満たしていません。
• パーティション トレランスはひどい名前です。一般に、通信に非同期ネットワークを使用することを意味します。これは、メッセージを失ったり遅延させたりすることがあります。 インターネットおよびすべてのデータセンターにはこのプロパティがあります 。したがって、実際には、このコンテキストでは選択肢がありません。

また、CAP定理は、古いシステムだけでなく、非常に具体的なモデルのシステムを記述することにも注意してください。

• CAP空間のシステムモデルは、単一の読み取り/書き込みノード\カウンター（レジスタ）です-それだけです。 たとえば、複数のエンティティに影響するトランザクションについては何も言われていません。 それらは、何らかの方法でそれらのオブジェクトを単一のオブジェクトに把握するまで、定理の範囲外にあります。
• CAP定理で言及されている唯一のタイプの障害は、ネットワークの分離です。 ノードはアクティブのままですが、それらの間のネットワークはダウンしています。 この種のエラーは何らかの方法で発生しますが 、これが問題になる可能性があるのはこれだけではありません：ノードが壊れたり、再起動したり、ディスク容量が不足したり、ソフトウェアのバグをキャッチしたりすることができます。 分散システムの作成プロセスでは、発生する可能性のあるエラーとトレードオフの範囲がはるかに広いことに留意する必要があります。 CAP定理に集中しすぎると、他の重要な問題が無視されます。
• さらに、CAP定理は待ち時間については何も述べておらず、 ほとんどの開発者はアクセシビリティよりもはるかに心配しています。 実際、CAP互換のシステムは任意に遅くても、「手頃な価格」と呼ばれることがあります。 すべてを極限までとらえた場合、Webページを取得するのに約2分かかっても、ユーザーがシステムを「アクセス可能」と呼ぶことはないでしょう。

定義がCAP定理の用語の正式な意味と一致する場合、それはあなたに合っています。 しかし、一貫性とアクセシビリティの用語に別の定義を与えると、CAP定理が適用されるとは期待できません。 もちろん、これは、値を再定義することで、突然不可能なことを行えるという意味ではありません！ SAR定理に導かれず、あなたの視点を支持する議論にそれを使用することはできません。

線形化可能性

（ATSのコンテキストでの「整合性」という意味で）線形化可能性に慣れていない場合は、これについて簡単に説明します。 正式な定義はそれほど明確ではありませんが、重要なアイデアは、簡単な方法であれば次のとおりです。



操作Aが正常に完了した後に操作Bが開始された場合、操作Bは、Aの完了時または新しい状態のシステムの状態を確認する必要があります。



より明確にするために、システムが線形化できない次の状況を想像できます。 下の図を参照してください（私の未発表の本のプレビューの一種）：







この図は、次の状況を示しています。ボブとアリスは同じ部屋にいて、両方とも2014年ワールドカップでの最終試合の結果を確認するために携帯電話をチェックしています。 請求書が発表された直後に、アリスはページを更新し、勝者を見て、それについてボブに喜んで知らせます。 彼はすぐに電話でUpdateを押しますが、彼の要求は複製されたデータベースに届き、それはわずかに遅れるため、彼の電話はゲームがまだ進行中であると言います。



アリスとボブが電話で同時にページを更新した場合、リクエストがいつ処理されたかわからないため、異なる結果を受け取ったことは驚くことではありません。 ただし、ボブは、最終スコアに関するアリスの感嘆符を聞いた後 、ページを更新する（要求を開始する）ことを知っているため、データが少なくともアリスと同じ年齢になると予想しています。 彼が不正なクエリ結果を受け取ったという事実は、線形化の違反です。



ボブのリクエストがアリスのリクエストの後に厳密に発生したということは（同時ではないということです）、ボブが別の通信チャネルを介してアリスからリクエストの結果を聞いたという事実に基づいています。 ボブがゲームが終わったというアリスからの結果を聞いていなかったなら、彼は彼の結果が古いことを知らなかっただろう。



データベースを設計するとき、クライアントがどのタイプの通信チャネルを持つかを知ることはできません。 データベースで線形化（CAP一貫性）を提供したい場合、さまざまな場所に多くのデータ（複製データ、キャッシュ）がある場合でも、データのコピーは1つだけだと全員に思わせる必要があることがわかります。 。



多数の調整操作が必要になるため、線形化可能性を保証することは非常に高価で問題があります。 コンピューターのCPUでさえ、 RAMへの線形アクセスを提供しません ！ 最新のCPUで線形化を実現するには、 メモリバリア命令を使用する必要があります。 そして、システムの線形化可能性をテストすることさえ非常に困難です。

ATSの可用性

ネットワーク分離の場合に線形性またはアクセシビリティを犠牲にするかどうかについて少し話しましょう。



2つの異なるデータセンターにデータベースのコピーがあるとします。 この場合の特定のレプリケーション方法は重要ではありません。シングルリーダー（マスター/スレーブ）、マルチリーダー（マスター/マスター）、またはクォーラムベースのレプリケーション（ Dynamoスタイル ）にすることができます。 レプリケーションの一般的な目的は、あるデータセンターでデータが変更されると、別のデータセンターで表示されることです。 クライアントが1つのデータセンターにのみ関連付けられており、データ複製のためにデータセンター間にもう1つの接続が必要であると想像してください。



次に、DC間の接続を中断します。これが、ネットワークの分離という意味です。 それでは何が起こるでしょうか？







明らかに、次の2つのオプションのいずれかを選択できます。

1. アプリケーションは引き続き動作し、データベースへの書き込みを許可します。両方のデータセンターから完全にアクセスできます。 ただし、DC間の接続が中断されるため、あるDCでのすべての変更は別のDCで使用できなくなります。 これは線形化に違反します（前の例では、AliceをDC1に、BobをDC2に割り当てることができます）。
2. 線形化を失いたくない場合は、必ず1つのデータセンターで読み取りと書き込みを行い、 リーダーと呼ぶことができます。 接続が失われたためにデータを最新にできない別のDCでは、同期が復元されるまで、データベースは読み取りと書き込みのためのクライアントのサービスを停止する必要があります。 2番目のデータセンターの依存データベースは要求を処理できないため、CAPアクセスできません。

ちなみに、これは本質的にSAR定理の証明です。 この例では、2つのDCが使用されていますが、ネットワークの問題も内部にある可能性があるため、すべてを1つのDCに適用できます。 2つのDCを使用した例の方がシンプルで視覚的だと思いました。



第２の実施形態における条件付きの「アクセスできない」状況では、ＤＣの１つで要求を非常にうまく処理できることに留意されたい。 したがって、システムが線形化可能性に重点を置いて構築されている（つまり、CAPにアクセスできない）場合、これは必ずしもネットワーク分離が自動的に単純なアプリケーションにつながることを意味するわけではありません。 主要なDCを使用するようにすべての顧客を転送できる場合、顧客はまったく落下に気付かないでしょう。



実際の可用性は 、CAPのアクセシビリティのみを指すものではありません 。 アプリケーションの可用性はほとんどの場合SLAで測定されます（たとえば、正しいリクエストの99.9％が1秒以内に結果を返す必要があります）が、このような合意はCAPアクセス可能およびCAPアクセス不可能なシステムで実装できます。



実際には、多くのDCにあるシステムは、非同期複製を念頭に置いて設計されていることが多く、非直線化されていることがわかります。 ただし、この選択の理由はほとんどの場合、ネットワーク自体の遅延であり、データセンターの安定性の向上とネットワークの延性だけではありません。

多くのシステムは、線形化もCAPアクセスもできません。

整合性（線形化）とアクセシビリティのCAP定理で厳密な定義を持つシステムを作成する方法は？



たとえば、レプリケーションと単一のリーダーを備えたデータベースを使用します。これは、ほとんどのリレーショナルデータベースのデフォルト設定です。 この構成では、クライアントがマスターから分離されている場合、クライアントはデータベースに書き込むことができません。 クライアントがコピー（読み取り専用のレプリカ）から読み取ることができたとしても、彼がデータを書き込むことができないという事実は、単一のマスターの設定がCAPでアクセスできないことを意味します。 そして、そのようなシステムがしばしば「高可用性システム」として位置付けられることは問題ではありません。



1つのマスターでのレプリケーションがCAPアクセス可能でない場合、「CP」を実行しますか？ 待って、それほど速くない！ アプリケーションがレプリカから読み取ることを許可し、レプリカが非同期である場合（ほとんどのデータベースではデフォルト）、読み取り中に依存データベースが少し古くなる場合があります。 この場合、読み取り値は線形化されません。 CAP一貫性がありません。



さらに、 スナップショット / MVCC 分離レベルを持つデータベースは、線形化を必要とすることで同時実行操作の数が減るため、意図的に非線形化されます。 たとえば、 PostgreSQL SSIはOracleと同じ状況で直列化可能性を提供しますが、線形化可能性は提供しません。 データベースがACIDとしてマークされているからといって、データベースがCAP定理の一貫性/一貫性の定義を満たすことを意味するわけではありません。



これらのシステムは、CAP準拠でもCAPアクセス可能でもありません。 それらは「SR」でも「AR」でもなく、単に「P」でもあります。 はい、「3つのうち2つ」という文言を使用すると、3つのうち1つのオプションのみを選択できます。



NoSQLはどうですか？ たとえば、MongoDBを使用できます。シャードにつながるものがあります（少なくとも、これがスプリットブレインモードでない場合は想定されます）。したがって、上記のすべてを考慮すると、CAPアクセシビリティはもうありません。 そして、カイルは最近 、これにより最高レベルの一貫性設定でも非直線化された読み取りが可能になることを示したため、CAP一貫性もありません。



Riak、Cassandra、VoldemortなどのDynamoデリバティブは、高可用性向けに最適化されているため、「AR」と呼ばれますか？ まあ、それはあなたの設定に依存します。 レプリカでデータを読み書きできる場合（R = W = 1）-レプリカは実際にCAPで利用可能です。 ただし、読み取りと書き込みがクォーラム（R + W> N）で実行され、ネットワークが分離されている場合、少数派側のクライアントはクォーラムに到達できません。操作のクォーラムもCAPアクセスできません（少なくとも一時的に、ベースデータはマイノリティ側で追加の発言をしません）。



クォーラムに基づいた読み取りと書き込みが線形化を保証すると主張する人に会うこともありますが、それに依存することはそれほど賢明ではないと思います-ずさんなクォーラムと読み取り修復などの脆弱な機能の組み合わせは、 壊れやすい顔 、 死者が回復するとき、削除されたレコードが復元されるとき、またはレプリカの数がライターの元の数より少なくなる（定足数条件の違反）、またはレプリカの数が元のNを超える（再び定足数条件の違反） これはすべて、非線形化されたデータ収集につながります。



言及されているシステムはすべて悪くはありません。人々は戦闘環境でそれらをうまく使用しています。 ただし、特定の操作または構成に依存するため、またはシステムがCAP定理の一貫性またはアクセシビリティの厳密な定義を満たさないためなど、「AP」または「CP」として厳密に定義することはできません。

実際の例：ZooKeeper

ZooKeeperはどうですか？ このシステムは合意アルゴリズムを使用しているため、多くの人がこれがアクセシビリティよりも一貫性を優先することの純粋な例であることに同意しています （つまり、「CPシステム」）。



ただし、 ドキュメントを見ると、ZooKeeper はデフォルトで線形読み取りを提供していないことが明確に示されています。 各クライアントはいずれかのノードに接続されており、読み取りを開始したい場合、隣接ノードに更新されたデータがある場合でも、ノードからのデータのみが表示されます。 これにより、クォーラムを収集したり、読み取りごとにリーダーに問い合わせたりする必要がある場合よりもはるかに高速にデータを読み取ることができますが、ZooKeeperはデフォルトでCAP整合性定理の要件を満たしていません。



一般に、readコマンドの前にsyncを使用してZooKeeperで線形化された読み取りを行うことができます。 パフォーマンスが低下するため、これはデフォルトの動作ではありません。 syncコマンドが使用されますが、常に使用されるわけではありません。



ZooKeeperの可用性についてはどうですか？ さて、ZKはデータを記録する合意に達するために多数決を必要とします。 過半数と少数のノードに分割されている場合、過半数は以前のように機能しますが、少数の残りのノードは、すべてが機能しているにもかかわらず、書き込み要求を処理できません。 ZKの書き込み機能は、パーティションモードの操作ではCAPアクセスできません（ほとんどのノードがデータを書き込むことができるという事実を考慮しても）。



さらに楽しくするために、ZooKeeper 3.4.0では、少数ノードが読み取り要求を処理し続けることができる読み取り専用モードを追加しました 。クォーラムは不要です。 つまり 読み取りモードは CAPアクセス可能です。 したがって、デフォルトでは、ZKはCAP一貫性（「CP」）でもCAPアクセス可能（「AP」）でもありません-実際には単なる「P」です。 ただし、同期オプションを使用してCPシステムを作成できます。正しいオプションを有効にした場合、読み取り操作に対してのみAPシステムを作成できます。



しかし、面倒なのは、ZooKeeperを「一貫性のない」システムと呼ぶことは、単にデフォルトで線形化できないという理由だけで、機能の非常にひどい解釈です。 ZKは実際に非常に高い一貫性を提供します！ アトミックブロードキャストとカジュアルな一貫性の保証をサポートします。これは、 書き込み、単調な読み取り 、 一貫したプレフィックス読み取りを組み合わせた読み取りよりも強い条件です。 このドキュメントでは、システムは一貫した一貫性を提供すると述べていますが、ZooKeeperは順次一貫性よりも強力な定義を保証しているため、これは私たち自身の過小評価です。

SR / AR：誤った二分法

1つのストレージでも「AR」または「SR」として明確に分類できなかったという事実は、特定の考えにつながるはずです。これらは、説明されたシステムにとって不適切な定義です。



次の理由により、「AR」または「SR」のカテゴリの異なるリポジトリを特定しようとするのをやめる必要があると確信しています。

• 1つのアプリケーション内で、 データの一貫性が異なる複数の異なる操作が存在する場合があります。
• 多くのシステムは、CAP定理の枠組み内で一貫性とアクセシビリティの定義を満たしていません。 しかし、システムが単に「P」と呼ばれるのを聞いたことはありません。 しかし、これは悪くはありません-CP / ARカテゴリーに分類されない、完全に計画されたアーキテクチャである可能性があります。
• ほとんどのソフトウェアが上記のカテゴリに正確に分類されていなくても、人々はそれをカテゴリの1つに絞り込もうとしますが、理解したいことに対する「一貫性」または「アクセシビリティ」の意味は必然的に変化します。 残念ながら、単語の意味が変わると、CAP定理は適用できなくなり、CP / ARへの分割は問題になりません。
• システムを2つのカテゴリのいずれかに絞り込もうとすると、膨大な数のニュアンスが失われます。 分散システムの設計で使用できるフォールトトレランス、待機時間、プログラミングモデルの単純さ、相互作用などに関して、非常に多くの側面があります。 これらすべてのニュアンスを1ビットの情報にエンコードすることは物理的に不可能です。 たとえば、ZooKeeperでも読み取り専用モードで「AP」をサポートしており、このモードにより、記録された順序でレコードを読み取ることができます。RiakやCassandraなどのシステムの「AP」よりもはるかに強力です。それらを一緒に積み重ねることはばかげているでしょう。
• エリック・ブリューワーでさえ、CAPが誤解を招きやすく、物事を単純化しすぎていることを認めています。 2000年には、分散システムのトレードオフの議論を開始することが重要でしたが、うまくいきました。 ある種の画期的な正式文書やデータウェアハウスのスキームの厳密な分類を作成する意図はありませんでした。 15年後、データの整合性とエラー保護を確保するためのさまざまなアプローチを備えたはるかに豊富なツールセットを入手しました。 ATSはその役割を果たし、今が先に進む時です。

自分で考えることを学ぶ。

「SR」と「AR」がシステムの説明と批判に適していない場合、見返りに何を使用すべきですか？ 正しい答えしかないと思います。 多くの人々は、分散システムの問題について一生懸命考え、多くの時間を費やして、問題を理解するのに役立つ用語とモデルを提案しました。 これらのアイデアについて多くを学ぶには、自分で文献を掘り下げる必要があります。

• 良い出発点は、ダグテリーによる記事です。そこでは、例として野球を使用して、部分的コヒーレンスの異なるレベル間の違いを説明しています 。 あなたは（私のように）アメリカ人ではなく、野球のことは何も理解していなくても、読みやすく理解しやすいです。
• トランザクション分離モデル（分散レプリカの整合性とは異なりますが、近い）について詳しく知りたい場合は、私の小さなHermitageプロジェクトが役立ちます。
• レプリカの一貫性、トランザクション、および可用性の間の関係は、 Peter Bailis によって調査されました。 また、ドキュメントはカイルキングスベリーが示すのが好きな一貫性のレベルの階層の重要性を説明します 。
• これをすべて読むと、さらに深く掘り下げる準備が整います。 この投稿のためにたくさんのリンクとドキュメントをシャベルで作りました-それらを読んでください、専門家はすでにあなたのために多くのことを完全に説明しています。
• 最後の議論として、もしあなたがソースを読むことができないなら、私はあなたに私の本を見てみることをお勧めします。 ご存知のように、私は投稿から広告スピーチを行わないように非常に努力しました 。
• ZooKeeperのテーマに興味があり、それをさらに詳しく調べたい場合は、 Flavio JunqueiraとBenjamin Reedが良い本を書いています。

どの学習パスを選択しても、好奇心と忍耐を保つよう強くお勧めします。これは簡単なことではありません。 しかし、妥協の理由を理解し、特定のケースでどのタイプのアーキテクチャが必要かを判断できるため、報酬が得られます。 しかし、何をするにしても、「SR」と「AR」について話すのはやめましょう。それは意味をなさないからです。