前回までのまとめ

前回までで，RDBMSとNoSQLの比較と，NoSQL（TokyoCabinet/TokyoTyrant)を実際に動作させてみました。また，分散環境（kumofs）と組み合わせることで，アベイラビリティとスケーラビリティに特化したDBシステムを構築できることがわかりました。

しかしその反面，複雑なスキーマに対応できなかったり，正確な結果が求められる会計処理などには向かないこともわかりました。また，データにアクセスするための言語がSQLのように統一されていないため，それぞれのNoSQLでアクセス方法を学習する必要がありました。

RDBMSは現在の主流ですが，課金処理などのビジネスシーンにおいては今後も主流として，開発現場で使用されていくと思われます。反面，厳密なACIDのサポートが必要ではないシーンや，膨大なデータを扱いたいシーンにおいてはNoSQLが本領を発揮するのではないでしょうか。

つまり，NoSQLはRDBMSの次の世代として存在するわけではなく，それぞれの特性を生かしつつシステムに適用されていくと考えられます。

Mixiでの実用例では，ユーザの最終ログイン時間を保持するために使用されているようです。Mixiは膨大な数のユーザを抱えるサービスですが，その中の1機能においてNoSQLを適用することがもっとも適している，という判断の下だと思われます。

SNSに見られる，友達関係といったソーシャルグラフの実装はやはり複雑な関係性を表現できる，RDBMSで動作しているのではないでしょうか。

Why NoSQL?

上でも触れましたが，どこにNoSQLを適用するのか，というのがエンジニアにとって必要な眼となると思います。キーワードとしては，

• 素早い処理が必要
• 一方向に増え続けていく膨大なデータ
• リレーショナルを必要としない単純なデータ構造

といったところでしょうか。

新しいシステムの適用はエンジニアにとって楽しみでもあり，不安な要素でもあります。しかしながら，Mixiなどの大きなシステムで実際に使用されていることを考えると不安要素というのは適用するシーンの選択であるといえます。適切に適用されればこれほどはまるモノもないのではないでしょうか。

というのもRDBMSにとって一方向に増え続けていくデータは弱点と言われています。また，ある程度増え続けた後でRDBMSからNoSQLに置き換えようにも，膨大なデータの移行作業というのは本当に骨の折れる作業です。

DBMSの今後

さて，これまでの中でRDBMSとNoSQLを見てきましたが，新たなDBMSが世の中に出てきています。今年の5月頃にニュースサイトや技術ブログで話題になったVoltDBがその一例です。

簡単にご紹介しますと，

• 非共有型クラスタ構成＋オンメモリの分散DBMS
  DBはメモリ上で展開され，複数のサーバを使って分散環境で動作する
• スケーラビリティが高い
  自動でテーブルをクラスターノードに分割する。
  ノードを増やせば増やした分だけパフォーマンスがアップする。
• SQLを使用するが，いわゆるSQLコンソールがない
  データのアクセスにはSQLを使用するが，インタラクティブなコンソールは存在しない。データのアクセスはjavaのソース内にSQLを記述，コンパイルが必要。クラスライブラリとすることでプログラマブルに動かせる。
• テーブルスキーマもjavaのクラスとして用意し，同時にコンパイルが必要。
• ACID制約をすべて実装している

オンメモリで動作，SQLをjavaのクラスとしてコンパイルなど，なかなか敷居が高そうですが，反面パフォーマンスはものすごく高いようです。

このような一例をもってしてもDBMSは様々な方向に向けて進化を遂げていることがわかります。多くのプロダクトの中から，どれが作りたいシステムにマッチするかという視点は常に必要なようです。

6回にわたって，⁠”縁の下の力持ち，データベース⁠”について書いてきましたが，何気なく使っているサービスの裏側ではこのようなDBMSが動作しています。ブラウザの⁠”送信⁠”ボタンを押したとき，そのデータはインターネットを通じて何かしらのDBMSに登録されるわけです。

感慨深いですね（笑⁠）⁠。