SQLはObsoleteだと言うなら、じゃあ次はどのようなソリューションであらねばならないか、と言うことにもふれないといけなくなるだろう。これには色々なものが考えられる。L.starは、以下のような要素が求められているのではないか、と思っている。

  • Relational Modelに代わる、もっとプログラミングフレンドリーなもの。

リレーショナルモデルは、ご存じの通りデータ表現形式としては完璧である（あるいは、かなり完全を期して設計されている - 以後、この辺の厳密性は考慮しない）。一方で、性能的にわかりやすかったとはとても言えない。正規化はデータの完全性をより高める。しかし、性能面の高さを保証する方法としては完璧ではない。「正規化しない方が性能が良い」とかいうたわごとが流通するのはそのためだ。実際にはRDBMSは進歩するに従って正規化したデータを賢く捌けるようになっているため、現在ではかなりの確率で（特に第一、第二ぐらいは）正規化した方が早い。なにしろそれが見えづらいことがRDBMSと言うシステムを欠点の多いものにしている。いやもちろんそれを扱う人間が本当は問題なのだが。

一方でこれまた、正規化したから常に早くなると言えるような状況も、未だ現れていない。そもそも第四第五正規化など、もはや何がどういいのかもさっぱり分からない。この複雑な正規化のさじ加減のコントロールをいつまで人間にやらせるのか。つまり何が言いたいかというと、適度に最適化されるような正規化状態が組みやすいような性能ドリブンなモデルが求められるのではないか。

  • クエリ言語として持つべきは物理構造に即したもの。Planningを標準でコンピュータ任せにすべきではない。

先の項目と重なるが、RDBMSの性能を維持しづらいのは、なにより論理的構造を記述することしかできないことにある。それゆえ、古いエンジニアのSQLノウハウは、たいていにおいてプランナの進化とともに役に立たなくなる。進化して、人間が任せっきりに出来るレベルになればいいのだが、そこもまだ遠い。複雑な副問い合わせが大量に現れるようなケースではお手上げである。

個人的には、そういう意味で「物理的」なクエリ言語、いきなりプランナ出力を構文木から作るようなものが必要なのではないかと思っている。いや、確かにプランナが介入することによってデータ質の変化に対応できるとか、お題目は素晴らしいのである。しかし一方で、現実にはデータモデルは頻繁に変化したりはしない。物理的な特性を入力できないために性能を損しているケースと、論理的な特性を記述していたために性能を得したケースはどちらが多いのだろうか。L.starは、正直自信をもって後者だと言い切ることは出来ない。というか、この２つは両方とも並立しうるのではないか、とまで思うのである。仮に「物理的」なプラン記述言語をここでQEL(Query Execution Language)とでも名付けると、SQL->QELコンパイラ（Explain表示）、QEL実行機、その両方を一貫して実行できるものを３つ用意すれば、いいとこ取りに出来るのでは無かろうか。あのクエリキャッシュのような、微妙なAPIも用意しなくて済むのだ。

  • 主に多数のCPUコアやマシンでの高性能を実現すべく、より並列性を考慮したトランザクションとストレージモデル

ACID属性を全て実現するためのRDBMSの構造は大変に美しいものであるが、ところどころでやはり難しい部分を抱えている。一貫性の維持、ロック、ロギングによる多大なオーバーヘッド。いずれも一朝一夕には理解しづらい。これを理解して性能を維持するのが非常に難しくなってきている。ある程度の自由度を与える方向には行きつつあるが、どうすればいいかというノウハウも、今の所十分ではない（これは、RDBMS側だけでなく、ユーザ側もそうである）

もちろん、制限を緩めることも大切なのであるが、もっと今後の性能向上を目指せるようなモデルを構築した方が良くないか。例えば具体的にはすぐ思いつかないが「よりパーティショニングしやすい」「より安定させやすい」「よりロックがかからない」と言ったことが挙げられないだろうか。

こうつらつらと書き連ねてきたが、結局のところここまでのはすべて

「今までのSQL-RDBMSは完璧を追求し過ぎて余計大変なことになっている。もっと現実的にいこうよ」

 

という一文に集約されるのではないかという気がしてきた。なにしろ70年代のIBMなどに代表される最先端（SQLもそれだ）は、いかに美しく完璧に、という理想を持って作られているものが多く、その「理想」が結果として間違っていた、あるいは時代とともに間違いになってしまったことが問題なのだろう。

そう考えると、実はそのようなアプローチはOODBにしろ何にしろ、何度も試みられているわけで、未だに効果的な手法は誕生していない。いややはり、また同じ繰り返しになるがGooglefs+MapReduce+BigTable（あるいはそのコピー品であるHadoop+HiveQL)なんかは、ある意味上記の部分を満たしている。BigTableはへんてこなカラムベースの定義だし、分散パーティショニングありきのアーキテクチャだし、おそらくSQLのようなフロントエンドは持たない。おおむねここに書いているようなのを満たしているように思われる。まあ、RDBMSがダメだなぁ、と言うことに今後なって、駆逐されていくとすればWeb2.0もたけなわとなり、SQL-RDBMSだけでは補いきれない大規模アプリケーションを動かすための標準が出てきた頃になるんじゃ無かろうか。それを逸すと、またSQLの天下が10年続くんじゃ無かろうかという気がする。

そのとき、自分が居るのはどっちの側だろうか。SQL側だろうか、破壊する側だろうか。はたまた関係ない道にいるのだろうか。