近年、Facebookに代表されるSNS（ソーシャル・ネットワーキング・サービス）やAmazonのような世界で運営されるEC（電子商取引）サイトの普及に伴って、「NoSQL」という新しいデータベースが注目を集めています。
　NoSQLとは問い合わせ言語であるSQLを使用したRDBMS（リレーショナルデータベースシステム）の弱点を補完するもので、ウィキペディアによると「広い意味での非関係モデルに属するデータストアを利用した技術である」と定義されています。つまり、「SQLは不要だ」という意味ではなく、SQLを使わないRDBMS以外のデータベースの総称なのです。ちなみに、データストアとは、データを決められた形式で記憶装置などに永続的に保存・蓄積するソフトウェアやそのような機能・処理を指しています。
　RDBMSはシステム開発において標準的に使われる関係データベースシステムで、大規模なシステムではOracle社の「Oracle Database」から、小規模なシステムではMicrosoft社の「Access」まで、幅広いシステムで使われています。ところが、Webが社会のインフラとなったいま、世界規模で運営するWebサイトのデータ量や同時アクセス数は天文学的な単位に膨れ上がり、拡張性に制約があるRDBMSでは処理が困難な状況となってきました。

　従来、一般的なインターネットのシステムはWeb3階層が主流でした。これはWebブラウザを用いたインターフェイスを司るプレゼンテーション（PL）層、アプリケーションを実装するビジネスロジック（BL)層、データを格納するデータベース（DB)層と、3段階に分けてシステム構成することで、柔軟なシステム提供を可能にしたものです。しかし、このアーキテクチャもインターネットをベースとしたクラウド等の出現によるサービス規模の急拡大によって、限界が近づいています。

　サーバの数を増やして処理性能の向上を図る手法を「スケールアウト」と呼びますが、PL層、BL層ではWebサーバやAPサーバを増やしてこのスケールアウトが可能なのに対し、DB層はRDBMS（リレーショナルデータベースマネジメントシステム）を主体に作られており、基本的にスケールアウトが困難だからです。
　RDBMSの処理性能を上げるには、サーバをより高性能なものに換えるか、メモリやプロセッサを増設することでサーバ本体の性能を高めるのが一般的で、この手法を「スケールアップ」と言います。スケールアップは１台のサーバで管理できる利点がありますが、たとえ世界で一番高性能のサーバを導入したとしても、そのサーバの処理速度以上に性能を上げることができません。一方、スケールアウトは、論理的にはサーバの台数を増やせば増やすだけ、性能が上がることになります。
　RDBMSでもOracle社のRACのようにスケールアウト構成が組めるものもありますが、数倍程度の性能向上が限界です。そのため、Amazon、Google、Facebookを始めとする大規模なサービス事業者が、RDBMSとは概念の異なるスケーラビリティのあるデータベースシステムを独自に開発して自社サービスに適用するようになり、これをオープンソースとして公開しています。これがNoSQLムーブメントの発端となったのです。

　NoSQLは確かにRDBMSが不得手とするスケーラビリティを備えていますが、RDBMSの方が得意な領域もあり、すべての要件を満たすデータベースは今のところ存在しないのです。
　エリック・ブリュワー／Eric Brewer氏が2000年に提唱した「CAP定理」（The CAP Theorem）と呼ばれる概念があります。この定理は、ネットワーク上の分散システムは、
「Consistency（整合性）」「Availability（可用性）」「Partition Tolerance（ネットワーク分割耐性）」という3つの要件のうち、同時に2つしか保証できないというシステムデザイン上のトレードオフを論じたものです。
整合性というのは、各クライアントが同時に同じデータを読み出すと必ず同じ値が返されること、可用性はサービスが停止しないこと、ネットワーク分割耐性は、分散システム内のネットワークが分断された場合もサービスを継続できることを意味しています。
　RDBMSはデータの整合性と可用性を満たしているので、銀行口座での入出金処理などのデータの矛盾が許さなく、サービスが止められないリアルタイム処理を要求するシステムに適していますが、その分、サーバが１つなのでネットワーク分割耐性に弱点をもっています。逆にNoSQLはサーバが複数あるので、拡張性（スケーラビリティ）や耐障害性には強いのですが、1つのクライアントから書き込まれた変更を複数のサーバに同期するため、すべてのクライアントから参照できるようになるまでに時間がかかる可能性があり、整合性が弱いのが特徴です。
　このように、NoSQLとRDBMSは各々整合性、可用性、ネットワーク分割性のうち2つしか条件を満たしていないため、システムのニーズを考慮して、選択的に使い分ける必要があります。データ量（拡張性）、もしくは処理性能がそれ程大きく（高く）ない場合には、従来どおりRDBMSでもいいのですが、一定のデータ量（拡張性）、もしくは処理性能を超える場合には、NoSQLを検討すべきです。検討のポイントは、結果整合（Eventual Consistency)が許容できるかどうかという点にあります。

　具体例として、NRIで検証したWebメールでのメッセージの送受信を例に挙げてみましょう。

　Webメールでのメッセージの送受信を概念モデル化すると、その構成要素は「送信者」、「メッセージ＋状態」、「受信者」となり、図2のA）のようになります。この送信者や受信者が社内やある特定のグループのユーザに限られ、使用頻度が限定されるのであれば、RDBMSで充分かもしれません。サーバを増やせば、1台ごとに新しくソフトウェアをインストールしなければならず、増えれば増えるほど管理が面倒でコストもかかります。しかし、Google社のGmailとかMicrosoft社のHotmailのように、不特定多数に公開するクラウド上のWebメールであった場合には、ユーザ数の増加や利用頻度の増加が完全に予測できないため、NoSQLの適用を考える必要があります。
　メールシステムは必ずしもリアルタイムで瞬時に整合性がとれる必要はありませんが、かといって送信者が送信して受信者が受け取るまでに5分、10分とタイムラグがあるようでは問題です。そのため、NoSQLの適用を検討する場合には、予め適合性の検証をする必要があります。具体的にはB）のように、Query(問い合わせ）ベース設計と言う手法で、敢えてRDBMSでの正規化を崩し(非正規化)にし、送信者から見た送信Query（送信者＋メッセージ＋状態）と受信者から見た受信Query（受信者＋メッセージ＋状態）に分割します。これに対して、概念モデルで作成したU)ユースケースで、非正規化によって2つのQueryに分割されたデータ（メッセージ＋状態）が結果整合（Eventual Consistency)で問題ないかの確認をします。
　今回のWebメールでは、メール送信者側によるメッセージ状態変更（W１によるメッセージ状態の『登録』への変更や、W2によるメッセージ状態の『送信』への変更）が結果整合でよく、さらに受信者側の状態変更である、W3、W4も結果整合でよいため、NoSQLの適用が可能であるとの結論となりました。　又、その検証結果として、NoSQL(Apache Cassandra)を使う事で、その特長である拡張性があるWebメールシステムができる事がわかりました。

　今回はNoSQLに焦点を当てて紹介しましたが、実はここへきてデータベース研究の大御所であり、Ingres※1やPostgreSQL※2の生みの親であるMichael Stonebraker氏がVoltDBというSQLベースのインメモリデータベースを発表したことで、流れが変わろうとしています。
　インメモリデータベースとは、通常のデータベースのようにデータをハードディスク上に保存するのではなく、メモリ上に常駐させておくデータベースの総称です。VoltDBはインメモリにすることでディスクアクセスに伴うオーバーヘッド(余計な時間）を劇的に減少させ、さらにACID※2によるデータ一貫性を維持しつつ、約50倍という大きな性能向上とスケーラビリティを実現しています。
　余談ですが、このVoltDBはAKB48の総選挙に使われたことで話題になりました。その際に要求された処理速度は「毎秒１万アクセス、1秒につき1万投票」というもので、システムを手掛けたのはB社ですが、アクセステストにはNRIセキュアテクノロジーズ株式会社が所有する専門の機器が使用されました。これが成功したことで、VoltDBの日本での注目度は一気にあがったのです。
　VoltDBの長所は、性能、拡張性に加えて、やはりSQLという標準インターフェイスをベースに設計されていることです。前述したように、NoSQLには様々な種類がある為、例えば、その代表的なOSSであるApache Cassandraを導入した場合、その何年後かにもっと性能のよいNoSQL系のOSSが登場し乗り換えたいと思っても、インターフェイスが標準化されていないので、互換性も無い為大変難しいです。その点、VoltDBのようなNewSQLと呼ばれる製品であれば、従来どおりの開発手法やツールを使いつつ、クラウド時代のスケーラブルで高速処理が可能なDBを手にできます。
　このようにDBの世界でもクラウド時代の到来と共に、新しい技術が次々と登場しています。我々は、今後益々重要度を増すであろうNewSQL、NoSQL関連の技術動向を注意深くウォッチ、技術検証をし、NRIでのSI、サービス提供で活用していく方針です。

※1 Ingres
商用サポートのあるオープンソースのリレーショナルデータベースマネージメントシステムである。Ingres は 1970年代初めから1980年代初めにかけて、カリフォルニア大学バークレー校で、当時教授であったMichael Stonebraker氏が率いる研究プロジェクトで開発された。オリジナルのコードは、バークレーの他のプロジェクトと同様、BSDライセンス（Berkeley Software Distribution License）により最小限のコストで入手可能である。1980年代中ごろから生まれたSybase、Microsoft SQL Server、NonStop SQLなどの商用データベース製品はすべてIngresが基になっている。

※2 PostgreSQL
BSDライセンスに類似するライセンスにより配布されているオープンソースのオブジェクト関係データベース管理システム (ORDBMS) である。その名称は Ingres の後継を意味する「Post-Ingres」に由来している。単純に「Postgres」や「ポスグレ」と呼称されることも多い。 問い合わせ言語には SQL を用いており、SQL92、 99の大部分と、2003、 2008の一部をサポートしている。

※3 ACID
ACIDは、Atomicity, Consistency, Isolation, Durabilityから合成された頭字語である。
これ以上分解すると意味のないものとなる最小の処理単位という意味の原子性（Atomicity:アトミック性）、一貫性(Consistency)、独立性(Isolation)、および永続性(Durability)は、トランザクション処理を行うにあたって不可欠な機能であると考えられている。もしACIDがなければデータベースの完全な状態は保証されない。ISO/IEC 10026-1:1992 Section 4に詳述されている。
(「ウィキペディア (Wikipedia): フリー百科事典」より　http://ja.wikipedia.org/ ACID (コンピュータ科学)）（最終更新 2011年11月18日 (金) 06:45）