さて、分散データベースがあると想像してみましょう。オレゴンにノードがあり、カリフォルニアにノードがあるとしましょう。CAP理論では、このタイプのデータベースをセットアップすると問題が発生すると言われています。
たとえば、あるデータベースのデータをクエリする場合、他のデータベースのデータと同じである必要があります。これにより、1つのデータベースにある値が他のデータベースにあることが保証されます(CAP理論の一貫性)。これにより、1つのデータベースのデータを更新し、別のデータベースに照会して、同じ結果を得ることができます。
オレゴンノードのデータを更新すると、データがカリフォルニアノードに送信され、データベースの一貫性が保たれます。真に一貫性を維持するために、どちらかがデータを真に保存する前に両方のデータベースが更新を取得することを保証する必要があります(分散トランザクションを使用した2フェーズコミット)。言い換えると、カリフォルニアのデータベースが何らかの理由(ハードドライブの障害など)でデータを保存できない場合、オレゴンのデータベースはデータを保存せず、トランザクションに失敗します。
上記のような分散トランザクションの問題は、高可用性が必要な場合に発生します。上記のシナリオでは、両方のデータベースを同期させようとするプロセスは、非常に遅いプロセスです。(想像してみてください。オレゴンからカリフォルニアにデータを送信し、そこに到着したことを確認し、両方のデータベースがデータをロックしていることを確認するなど)。これにより、高速で応答性の高いシステムが必要な場合に大きな問題が発生します高需要の時代。(これはCAP定理の可用性です。)
通常、高可用性を確保するために行うことは、分散トランザクションではなくレプリケーションを使用することです。したがって、カリフォルニアがデータを受け入れることを保証する代わりに、先に進み、オレゴンノードにデータを保存し、データに到達したらカリフォルニアにデータを送信します。これにより、カリフォルニアでデータを保存する準備ができているかどうかに関係なく、常にデータを保存できることが保証されます。
これにより可用性が向上しますが、一貫性が犠牲になります。誰かがオレゴンのデータを更新し、その後誰かが(同時に)カリフォルニアのデータを読み取った場合、新しいデータを取得していないことを確認してください。データベースはもはや一貫していません。実際、オレゴンがカリフォルニアにデータを送信するまで、それらは一貫していません!
したがって、それは可用性-一貫性のトレードオフです。
パーティション許容値は、CAP理論の3番目の側面です。このコンテキストでは、パーティション化とは、データベース(または他の分散システム)が個別のセクションに分割され、依然として正しく機能するという考え方です。
問題は、両方のデータベースが正しく実行されているときに何が起こるかということですが、オレゴンからカリフォルニアへのリンクは切断されていますか?
オレゴンのデータベースを更新する場合、何らかの方法でデータをカリフォルニアに取得する必要があります(分散トランザクションまたはレプリケーション)。ただし、2つの間のリンクが切断された場合、システムはパーティション分割され、データベースは相互にリンクされなくなります。
これが発生した場合、選択肢は、可用性を犠牲にして更新の許可を停止する(整合性を維持する)か、一貫性を犠牲にして更新を許可する(可用性を維持する)ことです。
ご覧のとおり、パーティションの許容値は、一貫性と可用性の間の直接的なトレードオフを作成します。
明らかにそれ以上のものがありますが、これらは、分散システムのこれらの3つの主要な側面が相互に機能し、相互に機能する方法に関するいくつかの例です。 CAP理論に関するジュリアンブラウンの説明は、詳細を学ぶのに最適な場所です。