純粋に直感的な言葉で CAP を説明しましょう。まず、C、A、P の意味は次のとおりです。
一貫性: 外部オブザーバーの観点から、各「トランザクション」は完全に完了するか、完全にロールバックされます。たとえば、Amazon で購入する場合、サブシステムへの内部分割に関係なく、購入確認、注文ステータスの更新、在庫削減などはすべて「同期」しているように見える必要があります。
可用性: 100% の要求が正常に完了します。
Partition Tolerance: システム内のノードのサブセットが利用できない場合でも、任意の要求を完了することができます。
これらは、システム設計の観点から何を意味しますか? CAP が定義する張力とは何ですか?
P を達成するには、レプリカが必要です。emがたくさん！保持するレプリカが多いほど、一部のノードがオフラインになっていても、必要なデータを利用できる可能性が高くなります。絶対的な「P」の場合、すべてのデータ項目をシステム内のすべてのノードに複製する必要があります。(明らかに、実生活では 2、3 などで妥協します)
A を達成するために、単一障害点は必要ありません。つまり、マスター/プライマリは単一障害点であるため、「プライマリ/セカンダリ」または「マスター/スレーブ」のレプリケーション構成は有効ではありません。複数のマスター構成を使用する必要があります。絶対的な「A」を達成するには、単一のレプリカが他のレプリカとは独立して読み取りと書き込みを処理できる必要があります。（実際には、非同期、キューベース、クォーラムなどで妥協しています）
C を達成するには、システムに「単一バージョンの真実」が必要です。つまり、ノード A に書き込み、すぐにノード B から読み戻すと、ノード B は最新の値を返す必要があります。明らかに、これは真の分散型マルチマスター システムでは起こり得ません。
それで、あなたの質問に対する解決策は何ですか？おそらく、いくつかの制約を緩め、他の制約を妥協するためです。
たとえば、n 個のレプリカを持つシステムで「完全な書き込み一貫性」を保証するには、読み取り数 + 書き込み数が n : r + w >= n 以上である必要があります。 これは例を使って簡単に説明できます。各アイテムを 3 つのレプリカに保存する場合、一貫性を保証するためのオプションがいくつかあります。
A) アイテムを 3 つのレプリカすべてに書き込んでから、3 つのレプリカのいずれかから読み取ることができ、最新バージョンを取得していると確信できます B) レプリカの 1 つにアイテムを書き込んでから、3 つのレプリカすべてを読み取り、選択することができます3 つの結果の最後 C) 3 つのレプリカのうち 2 つに書き込み、3 つのレプリカのうち 2 つから読み取ることができ、そのうちの 1 つに最新バージョンがあることが保証されています。
もちろん、上記のルールは、その間にノードがダウンしていないことを前提としています。P + Cを確実にするには、さらに妄想的になる必要があります...
また、無限に近い数の「実装」ハックがあります。たとえば、最小クォーラムに書き込めない場合、ストレージ レイヤーは呼び出しに失敗する可能性がありますが、成功を返した後でも追加のノードに更新を伝達し続ける可能性があります。または、セマンティックの保証を緩めて、バージョン管理の競合をマージする責任をビジネス レイヤーに押し上げる可能性があります (これは、Amazon の Dynamo が行ったことです)。
データのサブセットが異なれば保証も異なります (つまり、単一障害点は重要なデータには問題ないかもしれませんし、最小限の数の書き込みレプリカが新しいバージョンの書き込みに成功するまで、書き込み要求をブロックしても問題ないかもしれません)。
話し合うべきことはまだありますが、これが役に立ったかどうかをお知らせください。フォローアップの質問があれば、そこから続けることができます...
【続き…】
90% のケースを解決するためのパターンは既に存在しますが、各 NoSQL ソリューションは異なる構成でそれらを適用します。パターンは、パーティショニング (安定/ハッシュ ベースまたは変数/ルックアップ ベース)、冗長性とレプリケーション、メモリ キャッシュ、map/reduce などの分散アルゴリズムなどです。
これらのパターンを掘り下げると、基礎となるアルゴリズムもかなり普遍的です: バージョン ベクトル、マークル ツリー、DHT、ゴシップ プロトコルなどです。
ほとんどの SQL ソリューションについても同じことが言えます。それらはすべてインデックス (内部で b ツリーを使用) を実装し、既知の CS アルゴリズムに基づく比較的スマートなクエリ オプティマイザーを備えており、すべてメモリ内キャッシュを使用してディスク IO を削減します。違いは主に実装、管理経験、ツールセットのサポートなどにあります
残念ながら、あなたが知る必要があるすべてを含む知恵の中央リポジトリを示すことはできません. 一般に、本当に必要な NoSQL 特性は何かを自問することから始めます。これにより、キー値ストア、ドキュメント ストア、列ストアのいずれかを選択することができます。(これらは、NoSQL 製品の 3 つの主要なカテゴリです)。そこから、さまざまな実装の比較を開始できます。
[2011/4/14 再更新]
OK、これが実際に報奨金を正当化する部分です. NoSQL システムに関する次の 120 ページのホワイトペーパーを見つけました。これは、以前に存在しないと言った「NoSQL バイブル」に非常に近いものです。それを読んで喜んでください:-)
NoSQL データベース、Christof Strauch