ＲＤＢＭＳの（ごくごく大局的な）問題点

Grailsに関して、レガシーＤＢとの連携、エンタープライズ適用などをこのところずっと考えていたのですが、ITアーキテクト記事「スケーラブルなO/Rマッピングの実現手法」を読んで非常に感銘を受けることがあったので、考えたことの個人感想メモ書きです。

●ＲＤＢＭＳは何故発展したか。

• (1)性能問題発生
• (2)RDBMSの性能向上がそれを解決
• (3)開発資本集中
• (4)さらなる高機能化・高性能化
• (5)(1)へ

というポジティブループが出来たため。(3)はお金の問題だけではなく、「あまりにもそれが有用である」という理由も含む。

このポジティブスパイラルは本質的に無限であり、かつ猛烈に強力である。なぜなら、性能問題は、データ数の増加、利用者数増大に伴う多重度増加によっておきるので、「全てのプロジェクトが常に将来限界点に到達し問題となる」ということをはらんでいるから。変な風に例えると、地球の端っこがガケになっているとして、みんなそこを車で突っ走ってる（or止まってる)。落ちるのが早いか遅いか(or止まってる)、という種類の問題である。

なお、上記背景により、標準化とかは構造的に期待できない。各製品は、性能問題を個別に回避しそれを自ベンダ製品へのロックインの理由とするから（SQLの言語の文法仕様はむしろ本来あるべき発展を妨げる足カセとして良く機能しているような・・・）。結局のところＤＢ「固有の」性能チューニンのある部分は（少なくともそれが避け得ない袋小路という意味では）バッドノウハウである。バッドである、というと反発があるかもしれないが例えば以下のような状況を考えてもほしい。

• やればやるほどＤＢＭＳ固有機能を使いたくなる（それOra）
• ＳＱＬ実行計画というのはいわばＳＱＬをコンパイルしたマシン語（or中間コード）のようなものだと思うが、それを見てチューニングせざるを得ない状況。Javaで言うとバイトコードを見てデバッグする状況。
• 性能のためにテーブル・レコードを分割するとか、データ構造を表現するためのはずの記述に、性能のための都合が乱入する。

チューニングの努力がおかしいとはいいません。しかしそれが常に、あるいはいつも普段に普通に常に永遠に行われなければならないとしたら、何かがおかしい気がする。スケーラビリティの確立が脆弱で常にシビアに脅かされている。

●ＲＤＢＭＳの本来の債務

ＲＤＢＭＳのかけがえの無いコアコンピタンスは（１）データ整合(２)運用性・可用性として、それは債務の問題としてまったくただしい。ここは押さえる。性能や機能に関しては、本当に（あるいはどの程度まで）そうなのか、というのが論点。

(この点について私は必ずしも確信を持って同意するものではありません。考え方の一つだとは思います。非常に高スケールのときだけに弁別が必要な事柄かも。気弱。）

●何が問題？

ＲＢＭＳの性能・機能が圧倒的に優れているため、「性能にむとんちゃくな一般平均的開発者（orちょっと劣る開発者）」でも、世界最高レベルの性能資本の恩恵を受けることが可能に。また前述の資本集中ループ構造の結果ＲＤＢＭＳには開発資本が投資されすぎ「過剰なほどの強力さ」が生じ、アプリケーションの計算処理の多くまでもＤＢ上で実行してしまう傾向がある。ここに前述のスケーラビリティの脆弱さ・アンバランスさの背景がある。

しかし、過剰機能（債務の不合理的な割り当て）の弊害として、ＤＢＭＳへの過度な依存は、ＴＣＯ的に悪い。かつ、スケールしないという意味で性能的にすら良い解ではない。例えば、強力複雑なSQLを縦横にＤＢサーバ上で実行することで、テンポラリファイルや余分なメモリが必要になりＤＢサーバのコストを増す。あるいはインデックスが容量を圧迫する。いずれもスケールアウトの阻害要因となる。
かたやＣＰＵコスト・ハードディスクコスト、メモリコストは安くなってるのにしかるべき配分でそれが享受できない（運用コストがスケールしない）。

おわりに

私は前記記事の立論について、現時点で必ずしも同意するものではありません（同意しないものでもありません。ようするにわからない）。有効性の程度問題というのはありそうで、秒間数千アクセスといった高負荷環境で言えることとしての限定的な言明・ベストプラクティスなのか、ＯＲマッピングの一般法則として通用する真理が含まれるか、について引き続き興味を持って上記記事の次回分を期待しているところです。

さらに、「ＳＱＬ職人」に拒否されることの多いＯＲマッピングフレームワークの意義というか位置づけにあがいていた私にとって非常に参考になる、光明になるかも、と思わせてくれた記事でした。

少なくとも問題提起としては秀逸だと思います。連載は完結しておらず、６回までに、具体策がほぼその全容を現しつつあり（ＤＢの集合演算処理をＡＰサーバ側に展開して、クロージャを駆使した「オープンＳＱＬライク言語」で柔軟性と高速性を両立させた開放型ＤＢＭＳを作るようです。ラッパにJRuby使うようだが、Ｇｒｏｏｖｙであるべき・・ゴゴゴゴゴ）、次の第７回以降、その実装が提示されていくと思われます。カツモクして待ちます。←なぜか変換できない・・(MSIME)