まだ階層型DBも終わっていないのにRDBMS終わるとか気が早いｗ

「諸君、私はDL/Iが好きだ！」な現場にいるとどこの世界の話やら、と思うタイトルのエントリを読んだけど、確かにそのとおりかな、と思うことはあります。

RDBMSは、関係代数というきれいな理論をベースにしていて、関係を理解しやすくプログラムも書きやすく、それまで使われていたネットワークDBにとって替わりました。

2008-12-12

階層型DBのIMS-DBやネットワーク型DBのAIM-DBもまだまだ現役です。その理由には信者がいたりレガシーを捨てられない、という事情があることは否めない。古い技術しか持たない人を食わせる手段であったり。しかし、未だにバージョンアップがされ続けている背景には、それなりに有用な場面がある、という事情があります。シーケンシャルアクセスでバッチ処理、みたいな処理はホストのプラットホーム的特性もあいまってやっぱり早い。でもあっちのデータとこっちのデータとみたいなのは苦手だし。データ構造がマッチすれば、つまり特定用途にはまだまだ使えるものですね。

こうして、安心して手軽に使えるデータ永続の仕組みは、RDBMSだけになりました。
そうすると技術がこなれてきて、アプリケーション内で使うデータベースシステムでも使えるようなRDBMSも出てきました。たとえば、今メールクライアントを作るとき、多くの人が組み込みRDBMSを使ってメールデータやアドレス帳を保存するのではないでしょうか。
どこもかしこもRDBMSです

2008-12-12

というよりは、階層型やネットワーク型はアプリケーションがデータ構造に縛られてしまうので、データとアプリを切り離す用途では不適切だったからであって、「手軽に使える〜になりました」というわけではなく、「ようやく手軽に使える永続化手段が登場した」という話。手軽な、という意味ではファイルが確実で、ただ、耐障害性を必要とする用途では使えないし、DBのようなデータの扱い方もできないからね。処理をする、という観点ではファイルベースのSASなんかも選択肢に上がったりします。
ともあれ、データとアプリケーションが切り離されることでオープンシステムでの現実的な選択肢としてRDBMSは使われてきました。

Webアプリケーションでのデータ永続化は、無条件でRDBMSに行うことが多いと思います。
けれど、Webアプリケーションの場合、JOINなどSQLのもっている高度な表結合があまり必要なかったりします。逆に、SQLの検索では使い物にならず、自力で逆引きインデックスを持ったりして検索の仕組みを作ることも多いかもしれません。

2008-12-12

僕がやっていたプロジェクトではとにかくデータの種類が多くて、それを一生懸命SQLでやっつけていました。つーか、O/Rマッパーなにそれ美味しいの？テーブルが多すぎて有用性がわからん、という感じでしたね。
Webアプリケーション、というよりは、整合性命のオンラインアプリケーション＋Webフロントみたいなシステムだったからかもしれません。基幹業務システムとそうでないシステムの違いかもしれませんね。Webアプリかどうかは必ずしも関係なさそう。

SSDを前提にしたプログラムモデルになれば、そもそもシーク時間と戦うこともなく、ストレージを意識せずにプログラムが組めます。そうなったとき、アプリケーションのデータを永続化するためにRDBMSをわざわざ使うことはないでしょう。

2008-12-12

この前のエントリも見たけど、そもそもファイルというデータのモデル化は、人間に理解しやすいようにできたデータの単位でしか過ぎないんだよね。人間が扱う以上は人間が把握できる単位でデータをまとめる必要があるから、「アドレスでいいじゃん」というのはどうにも違和感がある。というか、アドレスでいいならVSAMというかISAM最強？みたいな。違うか。
ちょっとごっちゃになっている気がするのは「アプリケーションデータの永続化」と「データベースの利用」は別の問題だということ。DBを利用する目的は主に「シーケンシャルとは限らないデータへの効率的なアクセス」と「対障害性を持った永続化手段」の二つの側面からなると思うんだ。アプリケーション的な観点から言うと、後者はあまり重要ではない。だから、RDBMSの代わりに何を使うか、という話で「アプリケーションデータの永続化」が目的になるのはちょっと違うなあと。あくまでデータをどのような手段で(アクセス方法で)扱うか、という話にしないといけないはず。

そして、プログラムモデルとしては、すでにRDBMSからの脱却の準備は始まっています。
ORマッピングがそれです。

2008-12-12

O/Rマッピングは単純データ構造しか表現できず(というか、複雑にするにはコストがかかってSQL書いたほうがマシ)、用途が限られるというのが今の僕の考えなんだけど、だから、データモデルのアプローチを変更できるところはO/Rマッピングの恩恵を十分に得られるはず。だから、ある種のアプリケーションはRDBMSからの脱却が図れそう、っていうのは正しいと思う。これは決してすべてのプログラムがそうだというわけではないよね。

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

2008-12-12

ここもちょっとわからないんだけど、SSDとHDDの違いはスピンドルかそうでないかの違いでしかないと思うんだよなあ。そもそもSSDって今のところランダムアクセス苦手だし。キャッシュの話も言ってしまえばメモリ内のデータモデルの話なんじゃないのと思ったり。
と、ここまできて、一つ下の階層の話をしているような気がしてきた。概念データと物理データのマッピングはOSとかDBMSの仕事だからそれによってプログラミングモデルが変わっちゃやばいんじゃない？それこそ順編成ファイルの時代に逆戻りな気がする。

Javaはレガシーで21世紀のコボラーと言われるとかいう話がありましたが、実際のところJavaはC化してJavaVM用高機能アセンブラになるだけです。
レガシーになるのはRDBMSではないかと思います。
いま「大規模バッチはCOBOLじゃないと書けないよ」というのと同じように「業務システムはSQLじゃないと書けないよ」と言われるんじゃないでしょうか。

2008-12-12

Webシステムの話してたのに急に普遍的な結論になっちゃいましたね。「業務システムはSQLじゃないと書けないよ」って言うのは今までの話を総合するとそういう結論になっちゃうんだけど、ここでは否定的なニュアンスだよね(つまり、SQLじゃなくても書けると)。どうも業務アプリがSQL以外で書ける未来があんまり見えない。あ、XMLDBとかはなしね。大して変わらんと思うので。
全体的な話としてはよくわかると思いつつ、どうも納得しがたい感が残るのは、れがしーれがしーと言われているIMSやらがまだまだ現役バリバリの現場にいるからかもしれません。ま、正直コストはかかるんですが、IMS。

とはいえ、コンピュータの進化はデータモデルを変える

ウイングアークテクノロジが出している"Dr.Sum"というBIツールがあります。BIツール、つまりDWH/DMシステムってディメンションだファクタだなんだと良くわからない複雑な多次元データモデリングをしていろいろ気を使ってめんどくさいことをやってようやく分析開始、みたいなイメージがありますね。専用の多次元DBは仕様も公開されてなくて。どうも専門家が必要なイメージ。でも”Dr.Sum"は誰でも簡単にBIの構築ができちゃう。なんでか。必要な業務データをMicrosoft Accessみたいな関係を作るI/Fでちょこちょこ繋げたら分析の元ネタができちゃう。んで、項目を適当に軸に設定してちょちょいのちょい、できれいに分析。簡単。
これ、要は繋げたデータをがっつり非正規化してフラットなレコードにしてしまうんですよね。一昔前なら使い物にならなかったはず。PCのディスクもCPUもメモリも十分に早く、大容量である今こそ可能な仕掛けに思えました。
RDBMS(に限らないけど)の根本であるデータの正規化と関係性の整理は、それを更新するアプリケーション側には必要だけど、参照する側はそんなにいらないんだよね。
更新するアプリケーションは、何かの属性を変えるたびにその属性を使っている全テーブルを更新させられちゃたまらない。

そんなわけで、DBが多様化するだけだと思うよ

そういえば、XMLのデータって階層型データ構造とネットワーク型データ構造とのいいとこ取りみたいな感じ？AIMとかにそのままぶち込めないのかな？なんて思う今日この頃。よくわかっていません。
用途も多様化し、性能も多様化していく中で、適切なDBを選んでいけるようになるというのが現状から近い未来だと思います。
一つ重要だと思うのは「DBっていったらRDBMSだろ常識的に考えて」という思考からは脱却したいなあ、ということ。何せ「DBといったらIMSだろう常考」という人たちがいろんなものを阻害してきたわけですから。IMSが有用な場面は使えばいいけど、「DBといったら」ではないよね。同様に、RDBMSじゃないとねえ…という理由でRDBMSを選ぶ時代はもう終わりなんだろうね。