NoSQL登場の背景、CAP定理、データモデルの分類
海外のブログをチェックしていると、ここ最近でNoSQLに関する話題が劇的に増えてきていることを感じます。
アジャイルソフトウェア開発手法やデザインパターンなど、ソフトウェア開発の分野の先進的な取り組みで知られるKent Beck氏も先日、自身のブログ「Three Rivers Institute」でNoSQLについての考察を記したエントリ「Stuck with “NoSQL”?」をポストしました。
Kent Beck氏はNoSQLが普及し始めた背景、そして今後の課題について触れています。
10年前はSQLで要件が満たせていた
Beck氏は、10年前は当時のアプリケーションの要件のほとんどすべてをリレーショナルデータベースのSQLで満たすことができたと図示しました。
しかし最近になって、アプリケーションの要件が広がり、SQLでは満たせなくなってきたと指摘。
その例としてBeck氏自身が過去に取り組んできた生命保険会社のアプリケーションを例に挙げます。そのアプリケーションでは毎日のようにスキーマが変化するため、SQLとORM(Object-Relational Mapping）では対応できず、オブジェクトデータベースのGemstoneを利用することで対応できたと述べています。
こうしたSQLだけでは満たせないさまざまな要件、上記の図にあるようにスキーマの可塑性、スケーラブルなデータ読み込み、書き込み、処理の柔軟性などを満たすために、リレーショナルデータベース以外のNoSQLな製品が開発された。これがNoSQLの登場の背景にあるとBeck氏は解説します。一方で、こうしたさまざまなNoSQLを、NoSQLという言葉で表すのは適当ではないという憂慮も示しています。
Here is where the futility of defining NoSQL as anything but a negative space becomes apparent to me.
NoSQLのことを、単純に「SQLと正反対のもの」と定義してはいけないことがこの図からすぐにわかります。
この図によって、NoSQLという「～ではない」というネガティブな用語による定義が用をなさないものだろうと私は思い始めている（訳注：もう少し適切な訳がありそうな気がします…、うまい訳が思いついた方はぜひコメント欄などでお知らせを。追記：コメントいただきました、ありがとうございます！ 反映させました）
「NoSQL」ではなく、もっとそれぞれの用途を示すような命名があってしかるべきだろう、というのは、Kent Beck氏だけではなく多くのNoSQL関係者のあいだでも議論されてきたことです。しかしこれまでなかなかいい命名の提案はありません。
ちなみにNoSQLというのは「Not Only SQL」の略です。その命名の過程と議論については昨年11月の以下の記事に詳しく書きましたのでご参照ください。
NoSQLをCAP定理＋データモデルで分類
そのNoSQLをうまく分類することにある程度成功しているのではないか？ という記事を見つけたので、あわせて紹介します。それがブログ「Nathan Hurst’s Blog」にポストされたエントリ「Visual Guide to NoSQL Systems」です。
このエントリでは、Eric Brewer氏が提唱したCAP定理を基にデータベースを分類しています。CAP定理とは、分散システムにおいては以下の3つの要素のうち2つしか満たすことができない、という定理です。
- C：Consistency（一貫性）
- A：Availability（可用性）
- P：Tolerance to network Paritions（ネットワーク分断への耐性）
例えばリレーショナルデータベースでは、一貫性（C）と可用性（A）をできるだけ保証する代わりに、ネットワーク分断への耐性（P）を犠牲にしています。つまりリレーショナルデータベースを構成するネットワークが途中で切れたり大きく遅延した場合、そのシステムとしては動作が保証されなくなってしまいます。
一方で、NoSQLデータベースの1つ、アマゾンのSimpleDBを例に挙げると、SimpleDBを構成するネットワークが万が一分断されたり大きく遅延した場合でも、SimpleDBは動作し続けることができるようになっており、ネットワーク分断への耐性（P）や可用性（A）は非常に強力な一方で、データの一貫性（C）についてEventual Consistency（結果整合性）を採用しているために厳密な保証はありません（ただし最近、一貫性を保証するオプション機能が追加されました）。
こうしたCとAとPの要素を基にリレーショナルデータベースおよびNoSQLを分類して図示したものを、Visual Guide to NoSQL Systemsでは示しています。
この図では、C（一貫性）、A（可用性）、P（ネットワーク分断への耐性）に加えて、以下の分類を組み合わせています。
- Relational
- Key-Value
- Column-Oriented
- Document-Oriented
この分類は非常に合理的で分かりやすいものではないでしょうか。
SQL、NoSQLという代わりに、一貫性と可用性を重視した「CAリレーショナル」とか、可用性とネットワーク分断耐性を重視した「APキーバリュー」などの分類は、それぞれのデータベースの特長を表し、理解しやすくなるのではないかと思います。
ただし、この分類が広く普及するにはまだ少し複雑過ぎるでしょう。しかしいままで見たNoSQLの分類としてはいちばん合理的な方法であるとも思います。このあたりを足がかりにして、なにかうまいキーワードが出てこないかと期待します。
関連記事
CAP定理については、以下のエントリで詳しく解説しているのでご参照ください。
また、CAP定理に関連したEventual Consistencyについては以下の記事で紹介しています。
アマゾンのSimpleDBに追加された一貫性オプションについては以下の記事で紹介しています。
また、NoSQLについて知りたい方は、Publickeyでこれまで多くの記事を公開しているので、ぜひ「NoSQL」タグから記事一覧をどうぞ。
