クラウドと一緒にやってきたもの
最近、クラウドが流行ってます。
GoogleのMapResuceから始まって、MicrosoftのAzureまで、大手のクラウド製品が出揃った感じ。
で、そこで、こんなクラウド製品が出ましたというときに、必ずといっていいほどそのクラウド用のデータベースの説明があります。そして、それはRDBMSではありません。
GoogleだとBigTable、MicrosoftだとSQL Data Services、あとはAmazonのSimpleDB。どれも、基本的にはひとつのテーブルにハッシュコードでアクセスするようになっています。
ほかのクラウド製品も、Oracle Coherenceだったり、楽天のRomaだったり、非RDBMSのデータストレージを提供します。
クラウドというわけではないけど、mixiのTokyo TyrantやApache CouchDBも、RDBMSではないデータストレージです。
RDBMSのいいところ
RDBMSは、関係代数というきれいな理論をベースにしていて、関係を理解しやすくプログラムも書きやすく、それまで使われていたネットワークDBにとって替わりました。
ちなみに、なんで「関係データベース」かというと、そのころ米中関係が問題になっていて「関係」という言葉が流行っていたからというのは豆知識。
RDBMSは言語から独立していて、また扱いやすい理論だったため排他制御やアトミック処理、分散も考えやすく、どんどん発達しました。
その過程で、データの保存先がハードディスクという円盤ベースの媒体であることを前提としたチューニングも行われてきました。RDBMSは、シークタイムやデータの置き場所を考えてチューニングすると速さが一桁かわったりします。
RDBMSは使われすぎている
こうやって、RDBMSが進化し、また、RDBMSのみが進化してきました。
RDBMSは事務データを扱うことに向いていることと、これまでデータベースを使うようなシステムは事務データを扱うものだけだったということが背景にあると思います。
こうして、安心して手軽に使えるデータ永続の仕組みは、RDBMSだけになりました。
そうすると技術がこなれてきて、アプリケーション内で使うデータベースシステムでも使えるようなRDBMSも出てきました。たとえば、今メールクライアントを作るとき、多くの人が組み込みRDBMSを使ってメールデータやアドレス帳を保存するのではないでしょうか。
どこもかしこもRDBMSです
Webアプリでのデータベース
Webアプリケーションでのデータ永続化は、無条件でRDBMSに行うことが多いと思います。
けれど、Webアプリケーションの場合、JOINなどSQLのもっている高度な表結合があまり必要なかったりします。逆に、SQLの検索では使い物にならず、自力で逆引きインデックスを持ったりして検索の仕組みを作ることも多いかもしれません。
また、ホスト言語にSQLを埋め込むというのは学習コストやコーディングの手間が大きく、いまではORマッピングを使うことが少なくありません。Webアプリケーション、というか非業務システムでは、RDBMSの「R」の部分がまったく生かせておらず、単に「DBMS」として使っているという状況です。
それはRDBMS以外ではパフォーマンスが出ず信頼性が低くプログラムの組み方が難しいからという理由もあります。
おそらくそういう状況から、Webアプリケーションで扱いやすいDBとして冒頭であげたようなクラウド用データベースが開発されてきたのではないかと思います。
また、RDBMSのいろいろな仕組みが重過ぎて、Webでの高負荷に耐えれないということもあります。
mixiでも、ログイン時間記録のような単純で超高負荷なデータはmemcached+Tokyo Tyrantになっているようです。
mixi engineer blog
最初に消えるのは組み込みRDBMS
クラウド用データベースが現れてきたとはいえ、プライベートクラウドが持てるような規模であればまだしも、一介のWebサイトではそのようなクラウド化は難しいと思います。Webサイトの場合はクラウドホスティングが使えるとしても、デスクトップアプリケーションの組み込みDBとしては使えません。
そこで、昨日書いたSSDの時代の到来です。
ハードディスクもオンボードになるのかな？そうするとプログラムモデルも変わる。
SSDを前提にしたプログラムモデルになれば、そもそもシーク時間と戦うこともなく、ストレージを意識せずにプログラムが組めます。そうなったとき、アプリケーションのデータを永続化するためにRDBMSをわざわざ使うことはないでしょう。
RDBMSが最初に消えるのは、ローエンドの、SQLiteやDerbyなどが使われている分野だと思います。
ORマッピングでのシームレスな移行
そして、プログラムモデルとしては、すでにRDBMSからの脱却の準備は始まっています。
ORマッピングがそれです。
JPAが大切だと思っているのは、永続パラダイムの転換に、コーディングを変えることなく対応できるからです。もちろんJPA+RDBMSのシステムをJPA+非RDBMSに切り替えれるという話ではなく、プログラマのコードの書き方の対応の話です。
そして、仕組みとしてもそれは始まっていて、たとえばTopLink Gridでは、Coherence対応に対応していて、JPAでJPQLなどを書けば勝手にCoherenceにアクセスしてくれるようです。
Oracle TopLink 11g リリース / TopLink Grid (w/ Coherence) - S/N Ratio (by SATO Naoki)
HibernateはJBoss Cacheに対応しています。JBoss Cacheのクラウド化はそれほど難しいことではないと思うし、クラウドにならなくてもJBoss Cacheのキャッシュ先がSSDになれば本体のRDBMSは不要か、単なるバックアップストレージになります。
その観点においては、「JPAはRDBMSの能力を引き出せない」とか「SQLを書いたほうがよい」という批判、この二つは言葉は違うけど同じことですが、これらは実は的外れなのです。
