ACID原理とCAP定理 ~ NewSQLへの道 ~

データベースはそもそも、なぜ作られたのでしょうか？

システム設計上の概念から言えば、変数に入るさまざまな値をプログラムから切り離して、別の場所に保管したほうが便利だったから、なのでしょう。そんな初期のデータベースは、大勢の人が一斉にアクセスするわけでもなく、パフォーマンスや可用性は二の次で、正確性と整合性が何よりも重要でした。

おそらく、パフォーマンスにこだわり出したのは、インターネットが普及してからで、可用性にこだわり出したのはクラウドが普及してからではないでしょうか。

パフォーマンスや可用性が今ほど重要でなかった時代は、データがどんどん増えて容量が足りなくなれば、「縦方向に拡張する」のみでした（Scale UP vs. Scale Outの記事参照）。クーラーの利いたサーバー室にデータベース専用ホストがあって、バックアップのスクリプトを夜中に自動実行されるように設定して、「週7日24時間稼働！」なんてプレッシャーもなく、古き良きのんびりした時代でした…（遠い目でつぶやく）。

インターネット時代は、オンライン トランザクション処理（OLTP）をサポートすることが最重要課題になりました。いつどこで誰がデータを更新するかわからないし、AさんとBさんが同時にアクセスするかもしれません。トランザクションは一度始めたら、誰にも邪魔されずに完結してもらわなければならないし、もし途中で失敗したらロールバックして、元の状態に戻さなければなりません。何事も中途半端はいけません。できないことはできないとはっきり言うのが、データベースでも人間関係でも「整合性」を保ついちばんの秘訣です。

少し話が逸れましたが、つまりACIDがデータベース設計の基本原理です。ACIDとは、「Scale UP vs. Scale Out」の記事でも触れたとおり、A（atomicity=原子性／不可分性）C（consistency＝一貫性／整合性）I（isolation＝独立性／隔離性）D（durability=耐久性／永続性）のことです。

クラウドが普及すると、パフォーマンスと可用性が重視されるのはもちろんのこと、データの量も桁違いに増加して、ビッグデータ時代に入りました。データの急増には縦方向の拡張（Scale Up）では対応しきれず、横方向の拡張（Scale Out）が必要になります。

横方向の拡張とは、すなわちシステムの分散のことで、そこではCAP定理が考慮されなければなりません。CAP定理とは、

『ノード間のデータ複製に関しては、Consistency（一貫性）、Availability （可用性）、Partition-tolerance （分断耐性）の3つの保証を提供することは不可能である』

とブリュワーさんが言い出したから、「ブリュワーの定理」とも呼ばれます。

仮に、データベースが2つのノードにまたがる場合、ノードAとノードBのデータを常に一致させるのがConsistency、ノードAがダウンしてもノードBがサービスを提供し続けるのがAvailability、ノードAとノードBが分断されてもサービスを提供するのがPartition-toleranceです。

ビッグデータの用途はOLTPではなく、OLAP（オンライン アナリティクス処理）が中心で、リレーショナル データベースのような整合性を重視する必要がなかったためにスケールアウトが実現したのであり、ブリュワーさんが言うところの「Consistency」を犠牲にしています。リレーショナル データベース＝SQLデータベースとすれば、スケールアウトの実現はNoSQLデータベースだからこそ達成されたAP （CAP定理のCを外した）システムです。

ちなみに、ブリュワーさんは、昔、日ハムにいた外人助っ人のブリューワさんとは別人です。カタカナは異なりますが、どちらもBrewerで、ビール醸造職人という意味です。だから、ブリュワーの定理（Brewer’s Theorem）は一見したらビールの作り方の法則みたいで、それだったら、もっと便利な気が…

また話が逸れましたが、要するに、スケールアウトされた分散型データベースはACID原理に準拠しておらず、OLTPはサポートできない、ということになります。

では、OLTPをサポートして、なおかつ分散するにはどうすればよいのでしょうか？

そこで考え出されたのがNewSQLデータベースで、リレーショナル データベースを水平パーティションで分割（sharding）して、レプリケーションと二次インデックスで複数ノードに分散するしくみです。クラウド時代がクラウド ネイティブ時代に進化して、何でもコンテナに箱詰めしなきゃ気が済まない、いや、コンテナ化できる便利な時代になったので、OLTPサポートのリレーショナル  データベースも複数ノードに分散するのは自然な流れと言えます。

では一体、このNewSQLはどうやってCAP定理の壁を乗り越えたのでしょうか？少し話が長くなってしまったので、次回につづきます。

関連したトピックス

• CAP定理の壁 ～NewSQLへの道～
• スケールアップ とスケールアウト [データベース]
• PostgreSQLがエンタープライズレベルのデータベースの選択しであるかどうか？
• 分散ノードの整合性 ～NewSQLへの道～
• ドキュメント・データベースは何か？
• データレプリケーションソリューションに求められる9つのポイント
• データウェアハウスの利点とヒント
• SAP HANAで空間(Spatial)データサイエンスを強化する仕組み
• Oracle Exadataのパフォーマンス　Part3： 更なるモニターとクエリーによるチューニング
• 排他制御について【リアルタイムレプリケーションツールDBMoto】