CAP定理とは？
CAP定理について話す前に、分散システムについて、そしてなぜそれが必要なのかを知る必要があります。
ご存知のように、モバイル時代において、リクエストとデータの量は指数関数的に増加しています。
この状況に伴い、データベース環境においても、容易に拡張でき、データを迅速に配信しなければならないという要件が存在します。
これらの要件を解決するために、分散システム環境が考案されました。
CAP定理は、2000年に行われた分散コンピューティングに関する講演でエリック・A・ブリュワー教授によって最初に提唱されたため、ブリュワーの定理とも呼ばれます。
2年後、MITのセス・ギルバート教授とナンシー・リンチ教授が「ブリュワーの予想」の証明を発表しました。
CAP定理
CAP定理が言及する3つの分散システムの特性を見てみましょう。
Consistency（一貫性）
これは、すべてのクライアントが同時に同じデータを見ることを意味します。
この言葉はいくつかの意味で解釈できます。ACIDの一貫性と混同しないようにしてください。
データベースの観点から
それは `transaction`（トランザクション）を意味します。トランザクションは、そのようなデータベースシステムにおける相互作用の単位です。実際に、データベースにおいてトランザクションはACID特性を持っています。
アトミック（原子的）な観点から
単一のリクエスト/レスポンス操作シーケンス。
すべてのクライアントが同時に同じデータを見る。
Availability（可用性）
これは、1つ以上のノードがダウンしていても、データを要求するすべてのクライアントが応答を得られることを意味します。
別の言い方をすれば、分散システム内のすべての稼働中のノードは、例外なく、あらゆるリクエストに対して有効な応答を返します。
Partition tolerance（分断耐性）
パーティション（分断）とは、分散システム内での通信の途絶、つまり2つのノード間の接続が失われたり一時的に遅延したりすることです。分断耐性とは、システム内のノード間で通信障害がいくつ発生しても、クラスターが機能し続けなければならないことを意味します。
CAP定理とNoSQLデータベースの種類
最近のNoSQL（非リレーショナル）データベースは、垂直方向だけでなく水平方向のスケールも考慮しています。また、相互接続された複数のノードで構成される成長するネットワーク全体で急速に拡張できます。
2つのCAP特性に基づいて、いくつかのタイプがあります。
-
CP データベース : CPデータベースは、可用性を犠牲にして一貫性と分断耐性を提供します。任意の2つのノード間で分断が発生した場合、システムは分断が解決されるまで、一貫性のないノードをシャットダウン（つまり、使用不可に）する必要があります。
-
AP データベース : APデータベースは、一貫性を犠牲にして可用性と分断耐性を提供します。分断が発生した場合、すべてのノードは利用可能なままですが、分断された側の間違った端にあるノードは、他のノードよりも古いバージョンのデータを返す可能性があります。（分断が解決されると、APデータベースは通常、ノードを再同期してシステム内のすべての不整合を修復します）
-
CA データベース : CAデータベースは、すべてのノードにわたって一貫性と可用性を提供します。しかし、システム内の任意の2つのノード間で分断がある場合、これを行うことはできず、したがってフォールトトレランス（耐障害性）を提供できません。（フォールトトレランスとは、一部のコンポーネントに障害が発生した場合でもシステムが適切に動作し続けることを可能にする特性です。）
ご存知のように、分散システムでは分断を避けることはできません。したがって、CA分散データベースは存在できません。しかし、これは、必要であれば分散アプリケーション用にCAデータベースを持てないという意味ではありません。PostgreSQLなどの多くのリレーショナルデータベースは、一貫性と可用性を提供し、レプリケーションを使用して複数のノードにデプロイできます。また、シャーディングも可能です。
MongoDBとCAP定理 ( CP )
MongoDBは、データをBSON（バイナリJSON）ドキュメントとして保存する人気のあるNoSQLデータベース管理システムです。ビッグデータや、複数の異なる場所で実行されるリアルタイムアプリケーションによく使用されます。CAP定理に関しては、MongoDBはCPデータストアです。つまり、可用性を妥協しながら一貫性を維持することで、ネットワーク分断を解決します。
MongoDBはシングルマスターシステムです。各レプリカセットには、すべての書き込み操作を受け取るプライマリノードを1つだけ持つことができます。同じレプリカセット内の他のすべてのノードは、プライマリノードの操作ログを複製し、それを独自のデータセットに適用するセカンダリノードです。デフォルトでは、クライアントはプライマリノードからも読み取りますが、セカンダリノードから読み取ることを許可する読み取り設定を指定することもできます。
プライマリノードが使用できなくなると、最新の操作ログを持つセカンダリノードが新しいプライマリノードとして選出されます。他のすべてのセカンダリノードが新しいマスターに追いつくと、クラスターは再び利用可能になります。この間、クライアントは書き込みリクエストを行うことができないため、データはネットワーク全体で一貫性が保たれます。
Cassandra ( AP )
Apache Cassandraは、Apache Software Foundationによって維持されているオープンソースのNoSQLデータベースです。これは、分散ネットワーク上にデータを保存できるワイドカラムデータベースです。ただし、MongoDBとは異なり、Cassandraはマスターレスアーキテクチャを採用しており、その結果、単一障害点ではなく複数の障害点があります。
CAP定理に関しては、CassandraはAPデータベースです。つまり、可用性と分断耐性を提供しますが、常に一貫性を提供できるわけではありません。Cassandraにはマスターノードがないため、すべてのノードが継続的に利用可能である必要があります。ただし、Cassandraは、クライアントがいつでも任意のノードに書き込みできるようにし、不整合をできるだけ早く調整することで、結果整合性（Eventual Consistency）を提供します。
データはネットワーク分断の場合にのみ不整合になり、不整合は迅速に解決されるため、Cassandraはノードがピアに追いつくのを助ける「修復」機能を提供します。ただし、継続的な可用性は、多くの場合、トレードオフに値する可能性のある高パフォーマンスなシステムをもたらします。
結論
分散システムにおけるCAP理論に基づいたデータベースを見ることで、各データベースの利点をよりよく理解できました。最後に、CAP理論、分散処理システム、およびデータベースを体系化してくれたIBMに感謝の意を表したいと思います。
Stay Hunger, Stay Foolish