はじめに

NoSQL（Not Only SQL）という言葉が注目を集めています。これは「RDBMSが得意なことはRDBMSで，不得意なところにはRDBMSにこだわらず，用途に合ったデータストアを使いましょう』という考え方です。最近では，いわゆるNoSQLデータベース （⁠key-valueストアや各種データベース⁠）⁠ が次々と登場してきています。

そこで今回から数回に渡り，それぞれのNoSQLデータベースの特徴や具体的な使い方について紹介していきます。

RDBMSの強みとは

そもそも，MySQLやPostgreSQLなどのRDBMSの弱みを補うため，様々なNoSQLデータベースが登場してきたわけですが，RDBMSにはたくさんの強みがあることも忘れてはいけません。

RDBMSの強み

• データの一貫性 （⁠トランザクション）
• 更新時のコストが少ない（JOINが前提でテーブルが正規化されている）
• SQLによる複雑な条件での検索や集計
• 実績，ノウハウがある

この中でもデータの一貫性が保証されているというのは大きいです。データの一貫性が厳しく求められるようなケースでは，RDBMSを利用するのがベストでしょう。ですが，ここで挙げたような強みを必要としない，もしくはNoSQLデータベースでも対応可能であるような場合は，RDBMSにこだわる必要はないのかもしれません。

RDBMSの弱みとは

一方，RDBMSの弱みとはいったい何なのでしょうか。ある程度データ量が多い場合に問題になるものですが，以下のようなものが挙げられます。

RDBMSの弱み

• スケーラビリティ（特に書き込み部分）
• インデックス作成コスト

RDBMSの場合，データの読み込み部分についてはマスタースレーブ構成にして（レプリケーション⁠）⁠ ，スレーブを増やすことで比較的簡単にスケールさせることが可能です。

しかし，データの書き込み部分をスケールさせるのは簡単ではありません。お互いにレプリケーションし合うデュアルマスタ構成が考えられますが，更新処理が競合する可能性があります。テーブル毎にクエリの発行先を振り分けるなどの対応が必要になるため，導入するのが簡単だとは言い難いです。

DB分割してサーバを分けるという選択肢も考えられます。ディスクIOを減らしてインメモリで高速に処理するためにも，データサイズが減らせるDB分割は効果的です。ただし，別々のサーバに置かれたテーブル同士ではJOINができないため，それを考慮してDB分割する必要があります。

また，RDBMSの場合，インデックスを作成して検索速度を向上させることが必須ですが，データ量が多いとインデックスの追加によってテーブルが長時間ロックされてしまう点も注意が必要です。

様々なNoSQLデータベースの登場

このようなRDBMSの弱みを補うため，様々なNoSQLデータベースが登場しました。「⁠NoSQL Databases」というWebサイトにまとめられています（※1⁠）⁠。

※1

FlareやROMAなど，国内で作られたものの一部は載っていないようです

タイプ毎に代表的なものを挙げると，以下のようになります（詳細は後の回で説明します⁠）⁠。

揮発性key-valueストア

• memcached

永続性key-valueストア

• TokyoTyrant
• Flare
• ROMA
• Redis

ドキュメント指向型データベース

• MongoDB
• CouchDB

列指向データベース

• Cassandra
• HBase
• HyperTable

NoSQLデータベースって何が嬉しいの？

NoSQLデータベースの最大のメリットは，何といっても，サーバ台数を増やすことで簡単にスケールさせられることと言えるでしょう。分散処理のフレームワークであるHadoopなどもそうですが，今後データ量が爆発的に増えていくことを考えると『いかに簡単にスケールさせられるか』というのは非常に重要なポイントです。

また，他にもメリットとしては処理が高速なこと，デメリットとしてはデータの一貫性がRDBMSに比べ緩いことなどが挙げられます。

結局どれを使ったらいいの？

様々なNoSQLデータベースが登場してきていますが，「⁠名前は知ってるけど具体的な違いがわからない」「⁠何となく良さそうだけど，どれを使ったらいいのだろう」「⁠どんなケースで使うのかわからない」などと思っている方も少なくないのではないでしょうか？

次回以降は，タイプ毎に代表的なNoSQLデータベースに注目し，それぞれの特徴やどんなときに利用できるのか，具体的な利用方法（検証環境はCentOS5.4, Rails2.3.5）などを紹介していきたいと思います。