CAPの定理-可用性とパーティションの許容範囲

CAPの「可用性」（A）と「パーティションの許容度」（P）を理解しようとしましたが、さまざまな記事の説明を理解するのが困難でした。

私はAとPが一緒に行くことができると感じます（これはそうではないことを知っているので、私は理解できません！）。

簡単に説明すると、AとPの違いとそれらの違いは何ですか？

整合性とは、データがクラスター全体で同じであることを意味します。そのため、任意のノードとの間で読み書きを行い、同じデータを取得できます。

可用性とは、クラスター内のノードがダウンした場合でもクラスターにアクセスできることを意味します。

パーティショントレランスとは、2つのノードの間に「パーティション」（通信の中断）があったとしても、クラスターが機能し続けることを意味します（両方のノードは稼働していますが、通信できません）。

可用性とパーティション許容度の両方を実現するには、一貫性をあきらめる必要があります。マスターとマスターのセットアップに2つのノードXとYがあるかどうかを検討します。現在、XとYの間のネットワーク通信は中断されているため、更新を同期できません。この時点で、次のいずれかを実行できます。

A）ノードが同期しないようにする（一貫性を放棄する）、または

B）クラスタが「ダウン」している（可用性をあきらめている）と考える

利用可能なすべての組み合わせは次のとおりです。

• CA-すべてのノードがオンラインである限り、データはすべてのノード間で一貫しており、どのノードからでも読み取り/書き込みができ、データが同じであることを確認できますが、ノード間にパーティションを作成した場合、データは同期していません（パーティションが解決されると再同期しません）。
• CP-データはすべてのノード間で一貫しており、ノードがダウンしたときに使用できなくなることにより、パーティションの許容範囲を維持し（データの非同期化を防ぎます）。
• AP-ノードは相互に通信できなくてもオンラインのままであり、パーティションが解決されるとデータを再同期しますが、すべてのノードが同じデータを持っていることは保証されません（パーティション中またはパーティション後）。

CAシステムは実際には存在しないことに注意してください（一部のシステムがそうであると主張している場合でも）。

PをCおよびAと同等に考えることは少し誤りです。むしろ、C、A、Pの間の「2のうち3」の概念は誤解を招くものです。CAPの定理を説明する簡潔な方法は、「分散データストアでは、ネットワークパーティション時に、整合性または可用性のいずれかを選択する必要があり、両方を取得することはできない」というものです。新しいNoSQLシステムは可用性に重点を置いていますが、従来のACIDデータベースは一貫性に重点を置いていました。

CAを実際に選択することはできません。ネットワークパーティションは誰もが望むものではありません。それは、分散システムの望ましくない現実であり、ネットワークが失敗する可能性があります。問題は、それが起こったときにアプリケーションに対してどのトレードオフを選ぶかです。その用語を最初に作成した人からのこの記事は、これを非常に明確に説明しているようです。

ここでは、特にPに関して、CAPについて説明します。

CAは、モノリシックな単一サーバーデータベースに問題がない場合にのみ可能です（多分レプリケーションは可能ですが、すべてのデータが1つの「障害ブロック」にあります-サーバーは部分的に障害とは見なされません）。

問題がスケールアウト、分散、およびマルチサーバーを必要とする場合---ネットワークパーティションが発生する可能性があります。あなたはすでにPを必要としています。私がアプローチするいくつかの問題は、常に単一サーバー常時パラダイム（または、Stonebrakerが言ったように、「分散型はテーブルステークス」）の影響を受けます。CAの問題を見つけることができる場合、従来の非スケールアウトRDBMSのようなソリューションは多くの利点を提供します。

私にとっては珍しいので、APとCPについて説明します。

パーティションがある場合にのみ、APとCPのどちらかの操作を選択します。ネットワークとハードウェアが正しく動作している場合は、ケーキを手に入れて食べます。

AP / CPの違いについて説明しましょう。

AP-ネットワークパーティションがある場合、独立したパーツが自由に動作できるようにします。

CP-ネットワークパーティションがある場合は、ノードをシャットダウンするか、読み取りと書き込みを許可しないため、確定的なエラーが発生します。

APとCPの問題があるため、両方を実行できるアーキテクチャが好きです。データベースによっては、両方を実行できるものもあります。CPおよびAPソリューションの中には、微妙な点もあります。

たとえば、APデータセットでは、読み取りの不整合と書き込みの競合の両方が発生する可能性があります。これらは2つの異なるAPモードの可能性があります。読み取りの可用性が高く、書き込みの競合を許可しないAP用にシステムを構成できますか？または、強力で柔軟な解決システムを使用して、APシステムで書き込みの競合を受け入れることができますか？最終的に両方が必要になるのでしょうか、それともどちらか一方だけを行うシステムを選ぶことができるのでしょうか。

CPシステムでは、小さなパーティション（単一サーバー）がある場合、どれくらいの可用性が得られませんか？レプリケーションを大きくすると、CPシステムの可用性が向上する可能性があります。システムはこれらのトレードオフをどのように処理しますか？

これらはすべて、CPとAPで尋ねる質問です。

この分野で今すぐ読むのは、Brewerの「12年後」の投稿です。これはCAPの議論を明確に進めるものであり、強くお勧めします。

http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed

一貫性：

読み取りは、指定されたクライアントの最新の書き込み（ACIDなど）を返すことが保証されています。その間に要求があった場合、ノード全体またはノード内でデータ同期が完了するまで待機する必要があります。

可用性：

すべてのノード（失敗していない場合）は常にクエリを実行し、常に要求に応答する必要があります。最新のコピーを返すかどうかは関係ありません。

パーティション許容度：

システムは、ネットワークパーティションが発生しても機能し続けます。

APに関しては、可用性（常にアクセス可能）は、パーティション許容値の有無（Cassendra）またはなし（RDBMS）で存在できます。

picソース

パーティションの許容範囲はどの回答でもうまく説明されていないように思うので、CAPの定理の意味をさらに詳しく説明するだけです。

C：（線形化可能性または強い一貫性）はおおよその意味

操作Aが正常に完了した後に操作Bが開始した場合、操作Bは、操作Aの完了時と同じ状態、または新しい状態（ただし、古い状態ではない）のシステムを表示する必要があります。

A：

「システム内の障害のない[データベース]ノードが受け取ったすべての要求は、[非エラー]応答になるはずです。」一部のノードが要求を処理できるだけでは不十分です。障害のないノードは、それを処理できる必要があります。多くのいわゆる「高可用性」（つまり、ダウンタイムが短い）システムは、実際にはこの可用性の定義を満たしていません。

P：

パーティショントレランス（ひどく誤った名前）とは、基本的に、非同期ネットワークを介して通信していることを意味し、メッセージを遅延またはドロップする可能性があります。インターネットとすべてのデータセンターがこの特性を持っているので、あなたはこの問題について本当に選択の余地はありません。

出典：Awesome Martin kleppmannの作品

いくつか例を挙げると、Cassandraは最大でAPシステムにすることができます。ただし、Quorumに基づいて読み取りまたは書き込みを行うように構成した場合、CAPは利用できず（CAPの定理の定義に従って利用可能）、Pシステムのみになります。

単純なCAP定理では、分散システムが3つすべての保証を同時に提供することは不可能であると述べています。

一貫性

すべてのノードに同じデータが同時に含まれている

可用性

毎回データを提供するには、少なくとも1つのノードが利用可能である必要があります

パーティション許容差

システムの障害は非常にまれです

ほとんどすべてのシステムは、CA、AP、またはCPの少なくとも2つの機能しか保証できません。

一貫性–読み取りリクエストを送信しているときに、結果が返されている場合は、クライアントリクエストで指定された最新の書き込みを返す必要があります。可用性–読み取り/書き込みのリクエストは常に成功するはずです。パーティションの許容度–ネットワークパーティション（一部のマシンが相互に通信する際の問題）が発生しても、システムは引き続き機能します。

分散型では、ネットワークパーティションが発生する可能性があり、CAPの「P」を回避できません。したがって、「一貫性」と「可用性」のどちらかを選択します。

http://bigdatadose.com/understanding-cap-theorem/

CAPの定理を理解する簡単な方法：

ネットワークパーティションの場合、完全な可用性と完全な一貫性のどちらかを選択する必要があります。

システムは最新の書き込みを返すことを保証できないため、一貫性を選択すると、クライアントのクエリに応答できなくなります。これは可用性を犠牲にします。

可用性の選択は、クライアントの要求に応答できることを意味しますが、システムは一貫性、つまり書き込まれた最新の値を保証できません。利用可能なシステムは、与えられた状況下で最良の答えを提供します。

この説明は、この優れた記事からです。お役に立てば幸いです。

私はたくさんのリンクを調べてきましたが、1つを除いて、どれも私に満足のいく答えを与えることができませんでした。

したがって、私はCAPを非常に単純な表現で説明しています。

• 一貫性：どのノードから来たかに関係なく、同じDataを返す必要があります。

• 可用性：ノードは応答する必要があります（利用可能でなければなりません）。

• パーティションの許容度：ノード間にパーティション（ネットワーク障害など）がある場合でも、クラスターは応答する必要があります（利用可能でなければなりません）。

（また、それはより多くの混乱1個の主な理由は、それの悪い命名規則である場合、私は右、私が与えられている場合がありますしていた。DNCの代わりに定理を：データの一貫性、ノードの可用性、クラスタの可用性にそれぞれ対応し、一貫性、可用性と分割耐性はそれぞれ）

CPデータベース： CPデータベースは、可用性を犠牲にして一貫性とパーティションの許容範囲を提供します。2つのノード間でパーティションが発生すると、システムは、パーティションが解決されるまで、一貫性のないノードをシャットダウンする（つまり、ノードを使用不可にする）必要があります。

APデータベース： APデータベースは、一貫性を犠牲にして可用性とパーティションの許容範囲を提供します。パーティションが発生しても、すべてのノードは使用可能なままですが、パーティションの誤った端にあるノードは、他のノードより古いバージョンのデータを返す可能性があります。（パーティションが解決されると、通常、APデータベースはノードを再同期して、システム内のすべての不整合を修復します。）

CAデータベース： CAデータベースは、すべてのノードに一貫性と可用性を提供します。ただし、システム内の任意の2つのノード間にパーティションがある場合はこれを実行できないため、フォールトトレランスを提供できません。分散システムでは、パーティションは避けられません。したがって、理論的にはCA分散データベースについて説明できますが、実際には、CA分散データベースは存在できますが、存在してはなりません。

したがって、これは、必要な場合に分散アプリケーション用のCAデータベースを用意できないことを意味するものではありません。PostgreSQLなどの多くのリレーショナルデータベースは、一貫性と可用性を提供し、レプリケーションを使用して複数のノードに展開できます。

出典：https : //www.ibm.com/cloud/learn/cap-theorem