【特集】 NoSQLを知る

MOONGIFTでは技術コンサルティング、Webサイトプロデュース、テクニカルアドバイザリー、ITレポートサービスを承っております。ご用命、ご質問などはinfo@moongift.jpまでお気軽にどうぞ!

ここ1、2年くらいの間に急速に注目を集めているのがKVS(キーバリューストア）です。それまで良く知られていたRDBMS(リレーショナルデータベースシステム）とは異なり、キーと値という単純化された仕組みになっているのが特徴です。単なる二値化でシステムが組めるのかと感じてしまうのですが、その特性を知ればシステムを構築するのはさほど難しくありません。また、Google App Engineの登場によってDataStoreのようなシステムやAmazon SimpleDBにも注目が集まっています。そうしたRDBMSとは違うデータベースシステムは総称としてNoSQLと呼ばれています。

今回はそんな新しいデータベースシステムのあり方と考え方についてまとめてみたいと思います。

RDBMSとは

RDBMSとは現在最も良く知られているデータベースシステムになります。MySQLやPostgreSQLといったオープンソースのデータベース、OracleやSQL ServerもまたRDBMSです。リレーショナルの言葉が意味する通り、テーブルの関連性を意識した仕組みになっています。またそのデータに対してSQLを使ってアクセスするのが特徴です。SQLとは問い合わせ言語であり、厳密にはプログラミング言語ではありません。10年くらい前ではデータベースシステムの導入はコストが高かったため、個人のシステムでは導入するのが難しかったのですが、オープンソースの台頭とハードウェアコストの低価格化によって現在ではごくシンプルなシステムであっても、さらに低価格帯のレンタルサーバレベルであってもデータベースが利用できるケースが殆どです。

利便性と欠点

RDBMSを利用する際の利点としては、データの格納と再利用についてSQLを使えば簡単になることではないでしょうか。そのため、それまでCSVに入れていたようなデータもデータベースを使って簡単に扱えるようになりました。またデータフォーマットがデータベースのソフトウェアによって固定化されつつもSQLによってある程度汎用的にデータが取得できるようになったため、複数のプログラミング言語から同一のデータを扱うのも簡単になりました。

逆にデメリットととしては起動や接続、管理コストがかかってしまうことです。またデータベースには設定がつきもので、そのパラメータいかんでは性能がフルに引き出せなかったり、データベースの特性に合わせて学習する必要があるのもデメリットでした。トランザクションという更新単位に対して更新とその取消（ロールバック）を保証する仕組みが便利ではありますが、そのために大量の更新が遅くなってしまう欠点もあります。SQLによって問い合わせを行うため、SQLに関する知識が不十分であるとパフォーマンスが劣化したり、SQLインジェクションを含む問題につながるケースもあります。

NoSQLとは

そんな中、最近注目を集めているのがNoSQLという概念です。SQLを使わないデータベース、例えばKVSやRESTfulを使ってデータを操作します。特にスケールアウト（サーバの台数を増やすことで並列化処理させる方法）に強いデータベースが注目を集めています。構造や概念がRDBMSとは全く異なるので、一度RDBMS向けに組んだシステムをNoSQL型にするのは相当難しいようですが、予め知っておけば状況に応じて適切な技術選択が出来るようになるのではないでしょうか。

KVS(キーバリューストア）を採用する

そんな中で注目を集めているのがKVSです。KVSはキーと値という二つのデータしか持ち合わせません。プログラミング言語で言う所のハッシュや連想配列と似たような仕組みになっています。データへのアクセスするには様々な手段が使えますが、最も有名なKVSであるmemcachedの場合はtelnetプロトコルを使ってデータを授受できるようになっています。

KVSの最もよく使われる場面はキャッシュシステムになります。ある値をキーにして、そのデータをバリューとして格納します。例えば新着の記事一覧をまるごとキャッシュにしたりします。最近のプログラミング言語およびフレームワークにはmemcachedをサポートしたキャッシュシステムが実装されており、その利用は簡単にできるようになっています。

memcachedはとてもシンプルなシステムになっており、ソースコード自体6,000行程度となっています。とても実装がシンプルであり、すぐに使えるのが利点です。またサイズが小さいのでとても高速に動作します。MySQLのようなデータベースで複数マスター/スレーブ構成にするのは大変ですが、memcachedの場合はスケーリングがとても簡単にできます。ただし逆にシンプルさ故に管理上必要な機能が実装されていないことも多いのが難点です。なおmemcachedは名前の通りメモリー上にデータを格納するので、サービスを起動し直すと消えるのが利点でもあり、欠点でもあります。

その他、Tokyo CabinetもKVSとして知られた存在です。こちらはメモリーではなくファイルに保存するのでサービスを停止してもデータが消えることがありません。その意味で従来のデータベースと同様に利用できるのがメリットです。さらに高速性も売りで、memcachedとそれほど変わらない速度でデータを読み書きできます。mixiの最終ログイン時間の保持などに利用されています。

もう一つ日本製ではROMAが開発されています。これは楽天が開発しているKVSで、全てRubyで開発されているのが特徴です。開発にはRubyの開発者であるまつもと氏も関わっています。ROMAは分散型を強く意識しており、スケーラブルに拡張することができます。こちらはオンメモリーであり、サーバを停止すると全てのデータが消えます。

クラウド型データベースサービス

KVSの他、最近注目を集めているのがクラウド型、またはクラウドのサービスと連携するデータベースです。

Amazon SimpleDB

Amazon SimpleDB は最も最初にリリースされたクラウド型データベースです。Amazon EC2との親和性が高くなっています。その特徴として、RDBMSのようなスキーマ（テーブル定義）が不要であるということが挙げられます。一般的なデータベース開発の場合、テーブルやフィールドの定義をしっかりと行った上で開発を行いますがSimpleDBの場合はスキーマの定義が不要であり、柔軟にデータを格納できます。また型も意味を持たず、ある時には数値、ある時には文字列等自由に組み合わせていれることが可能です。SimpleDBへのアクセスはSOAPまたはRESTful(HTTP)でできます。データのアクセス時にはSQLに似たクエリーを使います。一般的な演算子はありますが、inやnot inがないので工夫する必要があります。

個人的にSimpleDBを使った時の最大の不便な点は、各要素（RDBMSでいう所のカラム）に収められるデータが1024バイトまでに限定されるということです。数字や名前、住所程度のデータであれば問題ありませんが、ブログの本文のようなテキストを収める場所としては不十分になります。この場合、データのキーを使ってAmazon S3上に保存して回避するという手もあります。

DataStore

Google App Engineを利用する際にデータを入れるのがDataStoreと言われるデータベースです。DataStoreの場合もまた、スキーマを定義する必要がありません。DataStoreとPythonとのラッピングを行うモデルにてプロパティの定義を行うことで使えるようになります。ただしプロパティの型は指定可能で、Long/String/Key/Encoding Key Stringが扱えます。元々あまり型数は多くなかったのですが、今は日付や時刻、真偽値、リストなど多様な形式が扱えるようになりました。また関連性の定義をすることができ、モデルを使ってDataStoreを意識することなくデータを取り出したり更新したりすることができます。データのアクセスにはモデルを経由するか、GQL(Google Query Language)を使ってアクセスします。GQLはSQLに似ているとは言われていますが、別物として考えた方が良いかも知れません。

DataStoreは相当特殊なデータベースなので、複数カラムを使って比較演算をしたり、グルーピングのような集合関数は提供されていません。そのようなDataStore上の特性を予め意識したデータ構造を組む必要があります。既存のRDBMSをそのまま移行しようとするとうまくいかないケースが多いようです。例えば大量にあるデータの全件数を得ることはできないため、ページネーションのような仕組みを作るのは難しくなっています。そのため、次のデータ、前のデータがあるかどうかだけ判断してリンクを付けるのが一般的です。

CouchDB

CouchDBはオープンソースのデータベースシステムで、ドキュメント指向という手法をとっています。SQLではなく、全ての通信にHTTPを使います。またスキーマも不要です。結果はJSONベースで返ってきますので、JavaScriptから（ブラウザベースで）利用するのも容易です。分散化（レプリケーション）も考慮されていますので、多数のCouchDBを使って処理を分散化させるのも容易です。HTTPベースなのでコネクション数の増減もしやすく、かつスケーラブルなのがメリットです。

Apache CouchDB: The CouchDB Project
　http://couchdb.apache.org/

Amazon RDS

Amazon RDSはAmazon.comが提供するデータベースシステムですが、そのインタフェースがMySQL互換なのがメリットになります。Amazon RDSはMySQLが予めセットアップされたEC2用のインスタンスと見ることもできます。ですが要領の範囲内であれば自由にデータを扱うことができます。クラウド型に挑戦したいが、スキーマレスなシステムへの移行は時間を要するという時にAmazon RDSが良い選択肢になるのではないかと思います。その他、データ容量に応じてインスタンスを変更したり（変更できる時間帯は決められています）、パッチやバックアップも自動的に行われます。

Amazon Relational Database Service (Amazon RDS)
　http://aws.amazon.com/rds/

Drizzle

DrizzleはMySQLをクラウド時代に対応させた新しいデータベースになります。まだ開発中ですが、期待のできるシステムです。高速性を売りにするため、元々のMySQLから幾つかの機能を排除しています。とはいえ信頼性が落ちる訳ではないようです。各機能をプラグインベースにすることで必要な機能を後から組み込めるようにします。それによって不要な機能を省く選択が出来るようになります。またクラウド化を想定していますので並列性を高められるようにするとのことです。

drizzle.org
　http://drizzle.org/

SQL Azure Database

マイクロソフトが提供するクラウドサービスがAzureです。そこで提供されるデータベースサービスがSQL Azure Databaseになります。SQL Azure DatabaseはSQL Serverの技術を使って構築されています。さらにPHP向け、ADO.NETなどからのアクセスもできるドライバも提供されています。マイクロソフトのIISを使ってクラウド上にシステムを構築する際に良い選択肢になるかも知れません。

SQL Azure — Products — Windows Azure Platform
　http://www.microsoft.com/windowsazure/sqlazure/

NoSQLの選択

NoSQLを選択する必要がある場合として、まずGoogle App Engineを採用したケースが考えられます。これは他の選択肢がない現状では必須になります。そのため既存のシステムをGoogle App Engineへ移行するという選択をした場合、相当な工数がかかる可能性があります。とはいえ、Googleに買収されたマイクロブログサービスJaikuもGoogle App Engine上で動作していますのでスキーマの設計次第で大型Webサービスも不可能ではないということです。

次に予めアクセスが増えるであろうサービスを構築する場合です。データベースはWebサイトの規模が大きくなる中でボトルネックになるケースが多いです。そのため予め解決手段を盛り込んでおけば後々の修正は少なくて済むようになります。その手段としてKVSをキャッシュシステムとして用いたり、一部のデータはNoSQL型データベースに入れることでスケールしやすい構造にしておくといった工夫が考えられます。キャッシュの場合は後から組み込みを考えることも容易ですが、データ構造を変えるのは簡単ではありません。ハードウェアとデータベースのレスポンスの関係を知った上で、ハードウェアの増強をはかるか、並列化するかを考える必要があります。

もしNoSQL型のデータベースを選択する場合、構造を予め考える必要があります。例えば検索条件（WHERE句）として使うか使わないカラムかで判断する必要があります。また並び替えを考えた上でデータの入れ方を考える必要があります。できることが限られるケースが多いので、その解決手段をプログラミングで行ってしまうとパフォーマンスが悪くなります。特性を理解し、データベース上で問題を解決する手法が重要です。

まとめ

今はRDBMSがメジャーになっていますので、シェアの分布から言えばクラウド型データベースはまだまだ少ないのが実情です。ですが、大型なWebサービスを中心に採用されるケースが増えています。またWebアプリケーションのようにAjaxを使ったりロングポーリングのようなこれまでとは違うデータベースのあり方が求められるケースもあります。HTTPベースの分散化であれば（CouchDBのような）DNSのラウンドロビンを使った分散も考えられます。単純にデータベースサーバを立てる、というのに比べると複雑になってしまいますが、その分低コストのハードウェアでも高速化させられる可能性があります。各システムの特性を理解し、サービスでの採用を考えてみてください。

　# 2009年12月28日 誤字修正。

MOONGIFTでは技術コンサルティング、Webサイトプロデュース、テクニカルアドバイザリー、ITレポートサービスを承っております。ご用命、ご質問などはinfo@moongift.jpまでお気軽にどうぞ!