読者です 読者をやめる 読者になる 読者になる

uehaj's blog

Grな日々 - GroovyとかGrailsとかElmとかRustとかHaskellとかFregeとかJavaとか -

RDBMSの(ごくごく大局的な)問題点

SQL RDBMS Groovy

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

●RDBMSは何故発展したか。

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

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

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

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

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

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

●RDBMSの本来の債務

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

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

●何が問題?

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

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

おわりに

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

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

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

広告を非表示にする