CAP定理について知らなかったすべて

分散システムでの最初の経験の間に、私は常に特定のCAP定理に出くわしました。すべての側面からそれを研究し理解するためにかなりの量を掘らなければなりませんでした。 私はデータベースウィザードではありませんが、分散システムの世界を少し探検することが、一般の開発者にとって役立つことを願っています。 この記事では、CAPとは何か、その問題と代替案について説明し、CAPプリズムを介した一般的なデータベースシステムについても検討します。

CAP定理

この定理は、2000年のEric Brewerによる分散コンピューティングの原則に関するシンポジウムで発表されました。 2002年、セスギルバートとマンシーナンシーリンチは、ビール醸造家の仮説の公式な証拠を公開し、定理としました。



Brewer氏によると、彼はコミュニティに分散システムの侵害についての議論を開始してほしいと考えており、数年後、彼はそれに対して修正と予約をし始めました。

CAPの背後にあるもの

CAPは、分散システムでは3つのプロパティのうち2つしか選択できないと述べています。

• C（一貫性）-一貫性。 各測定値は、最新のエントリを提供します。
• A（可用性）-可用性。 各ノード（立ち下がりではない）は常に（読み取りおよび書き込みの）要求を正常に実行します。
• P（パーティション許容値）-分布許容値。 ノード間に接続がなくても、それらは互いに独立して機能し続けます。

すでにこの定理の十分な明確な証拠があるので、私はバウマン大学へのリンクとサービス「コール、私は思い出させます！」の形で証明を提供します。

基本的にはすべて三角形です

多くの記事は、このような単純な三角形に帰着します。

実践する

CAP定理を実際に適用するために、私の意見では、3つの最も適切で非常に人気のあるデータベースシステムを選択しました。Postgresql、MongoDB、Cassandraです。

Postgresqlをご覧ください

次の項目は、抽象分散Postgresqlデータベースに関連しています。

• マスタースレーブレプリケーションは、1つの一般的なソリューションです。
• 非同期/同期モードでのマスターとの同期
• トランザクションシステムは、一貫性を確保するために2フェーズコミットを使用します。
• パーティションが発生した場合、システムと対話できません（主な場合）

したがって、パーティションの場合、システムは動作を継続できませんが、強力な一貫性と可用性を提供します。 これはCAシステムです！

MongoDBを見てみましょう

以下の項目は、MongoDB抽象分散データベースに関連しています。

• MongoDBは1つのマスターノードを持つシステムであり、デフォルトですべてのエントリがそこに移動するため、強力な一貫性を提供します。
• 他のノードから分離する場合のマスターの自動変更。
• ネットワークが分離した場合、システムはレコードを安全に完了することができるまで、レコードの受け入れを停止します。

したがって、システムはネットワーク分離の場合でも動作を継続できますが、すべてのノードのCAP可用性は失われます。 これはCPシステムです！

Cassandraをご覧ください

Cassandraはマスター/マスターレプリケーションスキームを使用します。これは、実際には、ネットワーク分離によりすべてのノードが自給自足で機能するAPシステムを意味します。



それは簡単に思えます...しかし、そうではありません。

CAPの問題

ここでHabréのCAP定理の問題に関する多くの詳細で興味深い記事が書かれているので、 CAPへのリンクはもう関係がなく 、CAP定理に関する神話は残しておきます。 必ず読んでください。しかし、各記事を新しい外観のように扱い、あなたの心に近づきすぎないようにしてください。 私自身はあまり深くなりませんが、必要な編集をいくつか行ってください。



したがって、CAP定理の問題は次のとおりです。

• 現実世界から遠く離れた定義
• 開発の一環として、主にCPとAPを選択します
• 多くのシステムは単なるP
• 純粋なAPおよびCPシステムは期待したものではない場合があります

定義の何が問題になっていますか？

CAPの一貫性は、実際には線形化可能性を意味します（そして、達成するのは本当に難しいです）。 線形化可能性とは何かを説明するために、次の図を見てみましょう。







説明した場合、審判はゲームを終了しましたが、すべてのクライアントが同じ結果を得るわけではありません。 システムを線形化するには、レフリーが他のデータソースと即座にデータを同期し、レフリーがゲームを終了したときに各クライアントが正しい情報を受け取るようにする必要があります。



定義上、CAPの可用性には2つの重大な問題があります。 1つ目-部分的な可用性の概念はなく、ある程度の割合（たとえば、パーセンテージ）がありますが、完全な可用性しかありません。 2番目の問題は、無制限の応答時間です。 システムが1時間応答したとしても、利用可能です。



分布への抵抗には倒れたノードは含まれません。その理由は次のとおりです。

1. 定義によります。 可用性では、「...（すべてのノード（失敗していない場合）常に...）」
2. 証拠に基づいています。 CAP定理の証明は、ノードでいくつかのコードを実行する必要があることを示しています。
3. さて、私の推測のいくつか（そしてそれだけではない）。 ノードがクラッシュした場合、システムは回復し、他のノードと通信し、何も起こらなかったかのように動作を継続できます。 ネットワーク分離の場合、接続が復元されるまで待つ必要があります。

したがって、システムの回復能力を覚えておく必要がありますが、CAP定理の範囲を超えています。

AP / CPの選択

通常、ノード間の通信は、メッセージを遅延または削除する可能性のある非同期ネットワークを介して行われます。 インターネットおよびすべてのデータセンターにこの特性があり、これらはありそうもない出来事ではないので、CAシステムは開発フレームワークでほとんど考慮されません。

多くのシステムは単なるP

2つのノード（マスター、スレーブ）とクライアントからなるシステムを想像してください。 マスターとの接続が突然失われた場合、クライアントはスレーブから読み取ることはできますが、書き込むことはできません-CAPが利用できません。



わかりました。CPシステムと同様ですが、マスターとスレーブが非同期で同期する場合、クライアントは同期が成功する前にスレーブからデータを要求できます-CAPの整合性が失われます。

純粋なAPおよびCPシステム

純粋なAPシステムには、単純に2つの番号ジェネレーターを含めることができます。 純粋なCPシステムは、 私は合意された状態に到達しようとしますが、私たちには答えません。 さらに進んで、CPシステムは強い一貫性ではなく、最終的な一貫性を提供します。 彼については少し後で話しましょう。

それと一緒に暮らす方法

結局のところ、これは抽象的なものを分類するための試みに過ぎないため、車輪を再発明する必要はありません。 分散データベースを使用する場合は、次のアプローチを使用することをお勧めします。

• CAP定義とその制限に注意してください。
• CAPの代わりにPACELC定理を使用すると、別の角度からシステムを見ることができます。
• ACID / BASEの原則と、それらがシステムにどのように適用されるかを覚えておいてください。
• あなたが取り組んでいるプロジェクトを考えると、体の動きをする必要があります。

パセルク

PACELCの定理は、2012年にイェール大学のダニエルJ.アバディによって最初に記述され、形式化されました。 PACELC定理はCAPに基づいているため、その定義も使用します。



定理全体はIF P->（CまたはA）、ELSE（CまたはL）になります。



待ち時間-これは、クライアントが応答を受信する時間であり、一定レベルの一貫性によって規制されます。 レイテンシー（レイテンシー）は、ある意味で、可用性の程度を表します。

BASEについて

BASEはACIDの独特なコントラストであり、現実の世界では真の一貫性を実現できず、高度にスケーラブルなシステムでモデル化できないことを示しています。



BASEの背後にあるもの：

• 基本的な可用性。 システムはすべての要求に応答しますが、この回答にはエラーまたは矛盾したデータが含まれる場合があります。
• ソフト状態 最終的な一貫性の変化により、システムの状態は時間とともに変化する場合があります。
• 最終的な一貫性。 システムは最終的には一貫したものになります。 彼女は引き続きデータを受け入れ、すべてのトランザクションの一貫性をチェックしません。

私はACIDやBASEよりも優れているものについて何度も尋ねられました-それはあなたのプロジェクトに依存します。 たとえば、データが重要ではなく、ユーザーがインタラクションの速度を本当に重視している場合、BASEが最適なオプションです。 反対の場合、ACIDはデータに関してシステムの信頼性を可能な限り高めるのに役立ちます。

新鮮な表情

落とし穴のほとんどについてわかったので、得られた知識のプリズムを通して同じ人気のあるデータベースシステムを見てみましょう。

Postgresql

Postgresqlは多くの異なるシステム構成を許可しているため、それらを説明することは非常に困難です。 Slonyを介して実装する従来のマスタースレーブレプリケーションを見てみましょう。

• システムはACIDに従って動作します（2フェーズコミットにはいくつかの問題がありますが、これは記事の範囲外です）。
• 接続が切断された場合、Slonyは新しいマスターに切り替えようとし、一貫性のある新しいマスターが作成されます。
• システムが正常に動作している場合、Slonyは強力な一貫性を実現するためにあらゆることを行います。 実際、ACIDがこのシステムの大きな遅延の原因です。
• システム分類-PC / EC（A）。

モンゴッド

MongoDBについて何か新しいことを見つけましょう。

• これは、ドキュメントレベルでの限定的な意味でのACIDです。
• 分散システムの場合-それはすべてそのBASEです。
• ネットワークパーティションがない場合、システムは読み取りと書き込みの一貫性を保証します。
• マスターノードが落ちたり、システムの残りの部分との接続を失ったりした場合、一部のデータは複製されません。 システムは、新しいウィザードを選択して、読み取りおよび書き込みに使用可能なままにします。 （新しいマスターと古いマスターは矛盾しています）。
• システムはPA / EC（A）と見なされます。これは、ほとんどのノードが中断した場合にCAPが利用可能なままになるためです。 CAPでは、MongoDBは通常CPと見なされることに注意してください。 PACELCの作成者であるダニエルJ.アバディは、アクセシビリティよりも一貫性に関してはるかに多くの問題があると言います。

カサンドラ

• 「高速」インタラクション（低遅延インタラクション）用に設計されています。
• レコードレベルのACID。
• 分散システムの場合-それはすべてそのBASEです。
• 切断が発生した場合、残りのノードは機能し続けます。
• 通常の動作の場合、システムは一貫性のレベルを使用して遅延を削減します。
• システムはPA / EL（A）と見なされます。

結論

• 分散システムのトレードオフは、設計プロセスを開始する場所です。
• 抽象システムを分類するのは十分に困難です。まず、技術仕様に基づいて要件を策定し、その後で目的のデータベースシステムを正しく構成することをお勧めします。
• 気にしないでください、私たちは好奇心developers盛な開発者です。疑問がある場合は、専門家にお問い合わせください。

ご清聴ありがとうございました！