Introduction

Eric Brewerによって提案されたよく知られたコンピュータサイエンスの定理があります。

• Consistency
• Availability
• Partition tolerance

これは非常に抽象的であり、用語は正確に直感的ではないので、この記事ではこの理論を打破するために最善を尽くします抽象的なものから、より現実世界の話や例まで。 この定理は、アプリケーションが本当に必要とするものと、それを達成するために犠牲を払う必要があるかもしれないという点で、データベースアーキテク

CAP用語の定義

この定理について話しているのと同じページにいることができるように、いくつかの基本的な定義を手に入れましょう。

CAP–一貫性、可用性、パーティション許容値

• 一貫性–すべてのデータサーバーに同じデータがあるため、システム内の任意のサーバーを照会してまったく同じデー
• 可用性–データサーバーへのすべての要求が応答を取得します。 あるサーバーがビジー状態の場合、応答できる別のサーバーにルーティングされます。
• Partition Tolerance–ネットワーク障害が発生し、一部のサーバーが通信できない場合でも、システムが動作を継続する機能。

基礎となる仮定–Pは不可能です

分散データベースシステムでは、データは異なるサーバー上で分割され、それらのサーバーはネットワーク上で互いに 問題は、ネットワークが壊れているため、常に通信すると想定していること、つまり完璧なネットワークを持つことができないことです。 この理論の面では、現実の世界ではパーティションの許容誤差を犠牲にする必要があることを意味します。 完璧な尽きることのないネットワークが存在していた場合、我々は一貫性と可用性を達成する問題を持っていないだろうが、これは失敗した物理的な Pが不可能な場合、私たちの選択肢は何ですか？

パーティションの許容誤差をあきらめたので、定理は今、一貫性と可用性のどちらかを選択する必要があると言います。

アプリケーションがすべての着信要求を満たすことができる可用性を選択できますが、データが最新であることを保証することはできません。

あなたのアプリケーションには何が必要ですか？

アプリケーションがソーシャルメディアサイトであり、常に最新のデータを持つ必要がない場合は、可用性を選択することができます。 あなたのユーザーが30秒の遅れの後に投稿を見ることは重要ですか？ そうでない場合は、最新のデータではなくてもユーザーがデータにアクセスできるように優先順位を付けるため、可用性を優先することができます。一方、アプリケーションでデータベースへのすべての読み取りが絶対的な最新データである必要がある場合は、可用性を犠牲にして一貫性を選択する必要が 情報が絶対的な最新であることを保証できないため、一部の要求ではエラーが発生する必要があります。

リレーショナルとNoSQLによって行われた選択

SQLやACIDで設計された他のリレーショナルデータベースシステムのようなデータベース技術は、一貫性を優先 一方、ほとんどのNoSQLデータベースは可用性を優先します。

結論

アプリケーションの観点からこの定理を調べることは優れた練習であり、アプリケーションの優先順位を評価するのに役立ちます。 分散データシステムがある場合は、アーキテクチャを調べ、どの犠牲を払っているかを理解してください。

MongoDB、CockroachDB、Postgresは、今日のデータベースアーキテクチャを非常に堅牢にする優れたデータベース技術ですが、説明したように、完璧ではありません。 私たちは完璧なネットワークを持っておらず、常に”ユーザーエラー”があります。 本番環境に移行しており、アプリケーションに最適なオプションについて議論したい場合は、Object Rocketまでお気軽にお問い合わせください。