きしだのはてな このページをアンテナに追加 RSSフィード

2008-12-12(金) RDBMSの時代の終わりが見えてきた

RDBMSの時代の終わりが見えてきた 17:45 RDBMSの時代の終わりが見えてきたを含むブックマーク

クラウドと一緒にやってきたもの

最近、クラウドが流行ってます。

GoogleのMapResuceから始まって、MicrosoftのAzureまで、大手のクラウド製品が出揃った感じ。

で、そこで、こんなクラウド製品が出ましたというときに、必ずといっていいほどそのクラウド用のデータベースの説明があります。そして、それはRDBMSではありません。

GoogleだとBigTableMicrosoftだと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)

HibernateJBoss Cacheに対応しています。JBoss Cacheのクラウド化はそれほど難しいことではないと思うし、クラウドにならなくてもJBoss Cacheのキャッシュ先がSSDになれば本体のRDBMSは不要か、単なるバックアップストレージになります。

その観点においては、「JPARDBMSの能力を引き出せない」とか「SQLを書いたほうがよい」という批判、この二つは言葉は違うけど同じことですが、これらは実は的外れなのです。

RDBMSこそレガシー、SQL書きこそコボラーになる

Javaはレガシーで21世紀のコボラーと言われるとかいう話がありましたが、実際のところJavaはC化してJavaVM用高機能アセンブラになるだけです。

レガシーになるのはRDBMSではないかと思います。

いま「大規模バッチはCOBOLじゃないと書けないよ」というのと同じように「業務システムはSQLじゃないと書けないよ」と言われるんじゃないでしょうか。

とおりすがりとおりすがり 2008/12/13 03:19 浅いなぁ・・・
次世代DBMSの影もイメージもつかめない内容で、RDBMSが終わりだって・・・
仮に次世代があったとしても次世代と既存が共存する可能性についても言及してないし。
あと、高負荷が必要になるシステムと業務システムの比率にも言及していない。
RDBMSが終わりになるよりも先にクラウドの流行が終わるのが先に1票。

とおりすがり2とおりすがり2 2008/12/13 06:21 面白いんだけど、浅すぎ。

最初に消えるのは組み込みだ、といっているけど、SQL無しにデータハンドリングしたことが無いんですかね。なぜそこに到達してるのかという分析が浅い。

wasisanwasisan 2008/12/13 11:32 釣りだと思うけど、これはさすがに言いすぎ。

オブジェクト分析、表分析それぞれに良さがある。
適材適所だということ。

たしかに、SQLの扱いはもっと改善されてほしいけど。

wasisanwasisan 2008/12/13 12:46 すみません、勢いで反応してしまって駄目でしたね。よく読めばそれほど無茶なことを言っているのではなさそうです。

でも、「時代の終わり」ではなく「独占時代の終わり」くらいにしてほしかったかもしれませんが。

でも、SQLみたいな言語がまったく使われなくなるということは明らかに退化だと思います。関数・オブジェクトからのデータへのアクセスは手続き的すぎるということにもっと注目してください。

ki2nekoki2neko 2008/12/13 15:02 いろいろ見て回ったけど、だいたいSQL書けない人ってそういう結論になっちゃうよね。

>Webアプリケーションの場合、JOINなどSQLのもっている高度な表結合があまり必要なかったりします。

どんな低レベルなウェブアプリだよw と煽ってみる

kanohkanoh 2008/12/13 16:14 組み込みSQLiteが無くなる根拠が薄弱だと思います。SQLite使う場合は、そもそも安いから使うのであって、SSDなんて高価な部品は使わないのでは。良くてHDDでしょ。

むーむー 2008/12/13 17:31 時代を完全に読み損なった可哀相なjava信者が
最後のトピックをただ言いたいが為に
スケープゴートとしてRDBMSを引っ張り出して書きましたってだけの記事だと思った。

ってか、釣りかギャグかネタなんだよな、これ?

bbbb 2008/12/13 18:26 Ingres, PostgreSQLなどを作ったStonebraker先生も似たようなことを仰ってます。
http://db.cs.yale.edu/vldb07hstore.pdf
25年前(OLTP時代)の古臭いアーキテクチャを引きずったRDBMSを捨てて、新しいエンジンを一から再設計するべきだ、と。

wasisanwasisan 2008/12/13 20:26 すみません、また言葉遊び的な、しょうもないコメント失礼いたします(この辺りの技術には興味があるので)。

>>bbさん
現在のDBMSシステムやSQL言語が古臭いことは確かだと思います。

しかし、この記事では「オブジェクトデータ(O-Rマップ)」と「テーブルデータ」を二項対立させて考えてしまっているのが、結構な批判を受けている理由だと思います。

むしろ、持ち出すべきなのは、演繹データベースや、Prolog的モデル(表に入るデータ値が構造を持つ)だと思います。そして、これはおそらく、一般に流通している概念としての「オブジェクト」とは無関係なような(断言はできませんが)。オブジェクトとは単なる隠蔽・抽象化手段であって、クエリ検索の動作に関わることではない気がします。
http://en.wikipedia.org/wiki/Datalog
が面白そうなので、私もいつかじっくり読みたいと思うのですが。

もちろん、オブジェクトもデータとして構造を持つ(例:メンバ変数)ので、それをもって現在のRDBの進化系とする見方もあるのでしょうが、それにしてもオブジェクト指向では、"述語・関係"への視点が薄すぎると思います。
これは、
dbm: http://en.wikipedia.org/wiki/Dbm
のような単なるハッシュベースな、さらに古臭いDBを扱う時代に戻ってしまいそうで危険な感じがします。

wasisanwasisan 2008/12/13 20:32 ×DBMSシステム
○DBMS
全体的に、乱文ですね。失礼しました。

wasisanwasisan 2008/12/13 22:21 はい。見落としていたので、しつこいですがコメントします。

> JPAでJPQLなどを書けば勝手にCoherenceにアクセスしてくれるようです。

JPQL = SQL
SQLと等価なものを使っているじゃないですか!

nowokaynowokay 2008/12/14 10:06 構文が似てるから等価というのはどうでしょう?CとJavaが等価というようなものにも思えます。
扱うデータがリレーションかオブジェクトかというのは大きい違いだと思います。
Google BigTableもGQLというSQLのような言語使いますし。

wasisanwasisan 2008/12/14 10:46 返信ありがとうございます。はい、等価と言うのは言い過ぎました。
これは、構造体とタプル(配列)が等価だというのと同じようなものですね
(しかし、実装から離れた場合、同じような直積集合データだと言える気がしますが)。

JPQL、GQL、他LINQとか、どれも多分SQLと同じ考え方に基づいて使用されるものだと思います。

「考え方」が問題なのです。
「オブジェクト」を中心としてデータを扱うのと、「関係性」を中心にしてデータを扱うのはかなり異なったことだと思います。

JavaがC言語の代替となるというのとはまた話は別だと思います。JavaはC言語的な手続き型指向の系列ですから(これはCobolも同じ)。要するに、「オブジェクト指向」と、「関数・論理指向」は少し視点が異なる、相性が悪いということです。

お互いにDBをよく理解していないまま、ここで議論するのは不毛なような気がするので、もう止めた方がいいと思います。
それ以前に、実装の話と概念的な話も混ぜこぜになっていますし。
多分、この記事では、実装面のことだけでDBMSをレガシーだと称していたのでしょうね。私も混乱して誤解してしまいました。
実装としては仕組みは古いのだとは思います。しかし、別に現在のRDBMSがすべて配列で実装されていると思っているわけではないですよね?(最適化のためにハッシュ・インデクス化などはされているはず)。C++言語をC言語コードに落としてコンパイルするのはださいから、C言語はもういらないよ、という程度の話であるならば、それはそれでOKです。

しかし、「学習・理解」のためにはこの隠蔽は危険に思えます。最低限の低級な知識は必要だと思います。

それにしても、SQLは言語としては、あまりにも構文などがダサい(これはC言語も同じですが)ので、これはなんとかしてほしいという気持ちは私も強いです。

----
すみません。乱文失礼いたしました。読み直すとかなり悪意があるように感じてひどいですね(ただぶっきらぼうなだけと思って欲しいのですが)、反省しています。あまり気にせず、これからも技術記事の執筆頑張ってください。

はぶあきひろはぶあきひろ 2008/12/15 07:31 んー。データモデルの話(リレーショナルとか階層型とか)とDBMSの話(トランザクションとか耐障害性とか)とクエリ言語の話(RDBMSでもSQLだけじゃないから)と物理的なストレージの話(HDDとかSSD)の話が、まだらに混ざってるように見えます。それぞれ個別に論じるべき話だと思います。
あと、RDBMSについては「データ構造とアルゴリズムの分離」が肝で、プログラミングの延長としての永続化って話であれば、それこそ70年代の構造化技法(ジャクソン法とか)に戻っちゃうと思うのです。ある特定のWebアプリケーションがあって、それにdependしたデータ構造であればそれでいいのだ、という話であればそれはそれでわからないではないのですけど、それを持ってして一般論としてデータ構造の部品化・再利用性向上という論点が無用だとまではいかないのだろうと。
RDBMSがそもそもは富豪的アプローチですから、ハードウェアが潤沢になることでもっと違うデータモデルを成立させられるでしょ、というのは間違いなくあると思います。ただ、それがハッシュマップかというとどうなんでしょうか。少なくともGAEで普通に販売管理とかやってみると意外と面倒です。RDBMS脳に侵されているからかもしれないですけど、関係ががちがちになっちゃうのは割と設計にかかる負担が増えてる気がします。
多分クラウド云々ではなくて、今期待すべきは、あるいは考えて作るべきは、今のハードウェア(クラウドも含むのでしょう)を有効に活用することを前提とした新しいデータモデルの提示なのではないかと考えます。せっかくなのでそういう方向での提言を期待したいです。

nowokaynowokay 2008/12/15 10:08 ちょっとだけ触れてますが、販売管理みたいな事務処理はRDBMSが向いてるでしょうね。

habuakihirohabuakihiro 2008/12/15 10:38 ショッピングサイトで在庫引き当てや出荷のトラッキングまできちんと連動させようとすると、もう十分に販売管理というか基幹系レベルになると思っています。
従来型の基幹系をMVCのMとして、サイトをVとした上でのそのVを構成するMVCのMがサイト構造と言語にdependしたnon-RDBMSでいんじゃねってのは気分としては理解できます。ただそうすると、アプリケーションライフサイクルがスケールしないんじゃないの? っていうのが別途出てくると思うんですよね。あとは構造変換の手間ですよね。
highトラフィックに対する性能問題を指摘するのであれば、ストレージの問題であってそれは「R」DBMSの問題じゃない気がしますし、アプリケーションの組みやすさって話だと、上述したアプリケーションライフサイクルの話とのトレードオフって話になると思うんですよね。
想定しているWebアプリってのがtwitterみたいな単機能で高トラフィックだっていうのであれば趣旨理解するんですが、そういうので成功するってのはもう言語とかRDBMSとか以前のアイディアとかセンスの問題のような気がしたりして、それらが多数量産される図式ってのがあんまりイメージ出来ないんですよね。
別にRDBMSである必要はないよねってのは了解で、じゃあどういうのがいいのかな、とかRDBMSが出たことで解決された諸問題についてはどうなるのか、とかその辺には触れて欲しいなとは思います。それは私の希望でしかないので、スルーでもいいのだけど、せっかくのお題なので期待しちゃいます(^^)

otsuneotsune 2008/12/15 14:46 s/MapResuce/MapReduce/

nowokaynowokay 2008/12/16 04:38 最近はぶさん会ってないですねぇ。
土曜日長崎にいければよかったんですが、あいにく用事があっていけないんですよねぇ。残念

habuakihirohabuakihiro 2008/12/16 10:22 日曜日の夜に橋本さんと一緒に長崎から福岡入りしますです〜。タイミングが合えば是非(^^)

nowokaynowokay 2008/12/16 10:35 日曜はだいじょぶです。

具体的なDBの仕組みではないけど、クラウドDBの開発が進むという話がありました。
http://www.itmedia.co.jp/enterprise/articles/0812/15/news009.html

habuakihirohabuakihiro 2008/12/16 14:12 あ、んじゃ日曜日に福岡で飲みましょ(^^)

色々と考えてみたんだけど、次世代DBMSってのを考えると二点かな、と。
1.トランザクションに対する割り切り
2.データ構造の汎用性獲得
2.がRDBMSの登場の背景にあるわけですけど、今だとEAI/SOA的なアプローチによる一元化はあるよなと思えますし、thrift的な今風のORB的なアプローチの先にも何か考えられるかなとは思います。
1.が結構大きいのかなとか思ってて、これは非同期処理の話と裏表のような気はするんですよね。MQ的なアプローチなのかもしれない。そうするとDBMSというよりももう一段上のレイヤのFW的な話になるのかな、と。
GAEのDatastoreはexpandoとか結構萌えるんですけど、実際に設計していくと結構トランザクションの括りと関係構造をくっつけて考えないといけないところとかあって、意外とこれ難しいぞと。アプリの構造に密にくっついちゃう感じがするんですよね。あと、CouchDBは個人的に面白いと思ってて、集約関数をJSでゴリることを面倒くさいと思わないなら、結構いいんじゃないかなとか思ったりします。でも、だったらLuceneで良くね? とか思ったりもするんですよね(w
型の緩さってのがポイントになるかと思っていて、GAEのDatastoreなりCouchDBなりはそのあたりの良さってのはあるんだけど、そこをクリアしたとしても多分スキーマ横断的にデータを取りまとめて扱いたいってときにSQL的な集合操作ができる利便性ってすごく大きくて、じゃあ汎用的なスキーマ構成ってどういうものですか? ってしたときにリレーショナルモデルの有用性ってのが出てくる。あと、言語非依存にしたのも大きいと思うんですよね。等しくSQLの苦行を分かち合える(w
で、そういうことを考えたときにプログラミング効率を優先してapplication dependなデータ構造で突き進んで行き詰まった結果に対して生まれたリレーショナルモデルというものを超えるモデルってのを考えると、mumpsヒャッホー!みたいな感じしか私には浮かばないんですよ(^^; もっと要素をバラバラにする方向ですね。ハードのパワーが上がってるんだから富豪的なアプローチはありなわけで。動的に要素を組み合わせてレコードにするくらいの勢い。ハッシュとかタプルとかそういう「組」単位で扱うのが既に古い、みたいな。そうすると多分トランザクションってのももっと割り切れるだろうし。こうやって書いてて思ったのは「型? 型って何よ?」ってことなのかな。動的に型を決められるってのが、実は重要なのかも。

gdgd書きましたけど、とりあえず日曜日に飲みながら続きを(^^)

habuakihirohabuakihiro 2008/12/21 18:16 今、西中洲の東横インにいます。携帯かメールに連絡くださいましm(__)m

nowokaynowokay 2008/12/22 08:24 また体調がいいときにリベンジですね