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