データベースの融解
2008年11月24日
数年前、プログラミング言語関係者から、Javaによって引き起こされた言語における「核の冬」について話を聞きました。Javaの計算モデルに皆が収斂し(その時点ではC#は単なる模倣と見なされていた)、プログラミング言語における創造性が失われたという感覚でした。その感覚は現在弱まっていますが、おそらくより重要な融解が始まっているかもしれません。それは、データベースに関する思考における、長く深い凍結です。
私がソフトウェア開発の仕事に就き始めた頃、リレーショナルデータベースを熱心に推進していた何人かの人々と働きました。私はオブジェクト指向の世界で彼らに出会いました。当時多くの人が、OOデータベースがデータベースの次の進化段階になると予想していました。しかし、ご存知の通り、それは起こりませんでした。今日では、リレーショナルデータベースは非常に深く組み込まれているため、ほとんどのプロジェクトが最初からRDBMSを前提としています。
先週のQConでは、この前提に疑問を呈する講演が数多くありました。特に私が感銘を受けたのはティム・ブレイの基調講演で、データ管理のいくつかの側面を巡る旅でした。その中で、彼は多くの興味深いプロジェクトを紹介しました。
- Drizzleはリレーショナルデータベースの一種ですが、現代のリレーショナル製品の多くの仕組みを省いています。私はこれをRISC RDBMSと考えています。リレーショナル機能セットの基礎部分のみをサポートしています。
- Couch DBは、分散型キーバリューペアモデルへの多くの試みの1つです。非常に単純なデータモデル(実際にはハッシュマップ以上のものはない)ですが、この種のアプローチは、高トラフィックのウェブサイトで非常に人気があります。
- Gemstoneはオブジェクトデータベース陣営の1つであり、私はGemstone-Smalltalkの組み合わせを非常に強力な開発環境(その後のほとんどの後継者よりも優れている)だと感じました。Gemstoneはニッチなプレーヤーとしてまだ存在していますが、Maglev(データベースと仮想マシンの融合であるアプローチをRubyの世界にもたらすプロジェクト)を通じて、より多くの牽引力を得る可能性があります。
この講演に加えて、Kresten Krab Thorupが主催する代替データベースに関するトラック全体がありました。そこで言及された追加ツールにはNeo4J(グラフ(ネットワーク)データベースツール)があり、ジム・ウェバーから稀有な賞賛を得ています。
これらの製品について尋ねるべき自然な疑問は、ODBMSが失敗したのに、なぜこれらが成功する可能性があるのかということです。リレーショナルデータベースの支配力を解凍する可能性のある環境に何が変化したのでしょうか?リレーショナルデータベースがこれほどまでに支配的であった理由については多くの仮説がありますが、私の意見では、その支配力はデータ管理における役割よりも、統合における役割によるものです。
今日の多くの組織にとって、統合の主要なパターンは共有データベース統合です。複数のアプリケーションが共通のデータベースを使用して統合されます。これらの統合データベースがある場合、これらのアプリケーションがすべてこの共有データに簡単にアクセスできることが重要です。そのため、SQLの役割が非常に重要になります。主に標準的なクエリ言語としてのSQLの役割は、リレーショナルデータベースの支配に不可欠でした。
データベース領域の加熱は、統合の代替手段、特にWebサービスの台頭によるものです。さまざまなバナーの下で、HTTPを介してテキスト(主にXML)ドキュメントをやり取りすることにより、アプリケーションがお互いに通信するための動きが拡大しています。インターネットとイントラネットの両方におけるWebにより、この統合モードはSQLよりもさらに普及しています。これは良いことです。私は、共通のデータベースを通じて密接に結合された複数のアプリケーションのアプローチがずっと好きではありませんでした。それ以上にカプセル化の違反はありません。
統合プロトコルをSQLからHTTPに変更すると、データベースを統合データベースからアプリケーションデータベースに変更できるようになります。この変化は非常に重要です。まず、Ruby on Railsが採用しているような、オブジェクトリレーショナルマッピングへのはるかに単純なアプローチをサポートします。さらに、リレーショナルデータモデルの締め付けを打ち破ります。HTTPを介して統合する場合、アプリケーションが独自のデータをどのように保存するかは問題ではなくなり、アプリケーションは独自のニーズに合ったデータモデルを選択できます。
これはリレーショナルデータベースが消滅することを意味するとは思いません。結局のところ、それらは多くの状況で正しい選択肢です。しかし、これは、アプリケーション開発者が自分のニーズに合った正しいオプションについて考える必要があることを意味します。非リレーショナルプロジェクトの人気が高まり、成熟するにつれて、ますます多くのプロジェクトが他のオプションを選択するでしょう。