キャッチーなタイトルを付けるのは難しいな、と思いつつASTの"Linux is obsolete"をぱくって見る。
もうSQLと出会ってからすでに10年近くが経過している。非常に良くできたもので、知れば知るほど感心したものである。が、同時に業界の変化から取り残されていき、ダメになっているなと思われる部分もいっぱいある。ここに書かれているようなのは、もう昔から言われているようなことばかりだが、L.starなりに実体験をふまえてまとめてみた。
SQLは、論理的に以下にデータを取り出すか、と言うことに着目して記述する言語である。これはデータのやりとりの記述を実にシンプルにした、という利点がある。代わりに、実際の検索に必要な物理的な部分はプランナにより、自動的に最適化されるというのが売りである。この最適化が100%完璧に働くなら何の文句はない。実際にも、90%位はうまくいっていると言っていいだろう。
ところが、残り10%のうまくいかない部分が問題になる。それをなんとかするため、論理構造だけではなく、物理構造つまりSQL個別実装に特有の要素を加味して書かなければいけないということになる。しかも、標準SQLは、すでに相当複雑になっているにもかかわらず、個別実装に特有な部分を全て吸収できるほどの柔軟さを有していない。勢い、独自拡張に頼らざるを得ない部分が出てくる。これは文法的なSQLがどれだけ標準化によって統一されようとも、その奥にあるずっと実用的な側面は、OracleなりPostgreSQLなりDerbyなり何でも良いが、個別実装依存になることを意味する。
Joel on softwareのJoel氏は、「漏れのある抽象化の法則」という言い方でこれを説明している。リレーショナルモデルは完璧かもしれないが、SQLとその実装はその完璧さには及ぶべくもない。30年以上の並々ならぬ努力がこれを解決できていない。それどころが、どのくらいで解決できるかすら分からない。そのことからしても、問題の大きさはしれるだろう。はたして、これを解決するほどの労力は本当に必要なのだろうか。
SQLと他の言語のマッピングほど、頭を悩まし続けている問題も少ないだろう。よく言われるのはO-R Mappingというオブジェクト指向言語とのマッピングだ。たくさんのフレームワークが内製商品OSS合わせて提案されている。L.starが知っているのは以下のようなものが挙げられる。
いろいろあるが、正直決定版というものを見たことがない。いや、むろん実装として素晴らしいものも普及しているものもたくさんある。
しかし元々すりあわしづらいものを無理矢理くっつけるそのアプローチは、第三者視点から見ると醜悪である。L.starもJava屋としていろんなのを見たり書いたりしたことがある。が、はっきりOO側からこれは！と言うアプローチは見たことがない。逆に、SQL屋になってみて、しっくり来るアプローチも少ない。非常に大きなギャップを抱えているのだ。最近の挑戦はLINQだが、これもなんというかせっかくのC#言語の美しさを損ねている感がある。
SQLデータベースの高機能さと言ったらない。例えばdbmのような単機能ハッシュだけなら、RDBMSよりずっと高速なハッシュDBはいくらでもあろう。また、大量データの解析のようなものの場合、RDBMSなど使わずにCSVとかを直読みするようなexecutor部分だけ引っ張ってきて書いた方が高速になる。しかし、この２つのアプローチの両方に対応でき、なおかつその中間のギャップを埋められるようなソリューションとして、SQLデータベースより普及しているものはない。これはSQL実装の美点の一つである。
しかし、欠点はすでに述べたとおり、あらゆるアプローチにおいてSQLが最良というわけでは決してないのだ。むしろ「SQLでできる」というがためにあらゆるものをキッチンシンク式に詰め込まれたアプリケーションはプログラムとしての自由意志よりもとにかくSQLを使うと言うところに主眼が置かれた実装である。それはもはやSQLに支配された奴隷という感すら受ける。例えば以下は個人的に「なんでこんなのにSQLデータベース使うの？」と思った例である
あと最悪なのはトランザクションである。もちろんbegin-commit(abort)で表せるトランザクションは、非常にありがたい便利なものである。しかし、それを実装することによる、性能面やロック競合などの部分はより物事を面倒にする。個人的にはこれらをサポートしない故に早いMyISAMを大変評価していたのだが。
このように、結構大きな問題が昔から知られている。今後もSQLは使われ続けるのだろうが、解決される見込みはどれもなさそうなものである。しかし逆に言うと、こういう部分をきっちり解決しつつ、より大きなスケールや性能を出せるアプローチは、今後普及を見込めるのでは無かろうか。個人的にはGoogleのMapReduce+BigTable、Apache Hadoop+HiveQLなどはそれに値する、非常に興味深いものだと思うのだが。
もうSQLと出会ってからすでに10年近くが経過している。非常に良くできたもので、知れば知るほど感心したものである。が、同時に業界の変化から取り残されていき、ダメになっているなと思われる部分もいっぱいある。ここに書かれているようなのは、もう昔から言われているようなことばかりだが、L.starなりに実体験をふまえてまとめてみた。
論理構造しか記述できないこと
SQLは、論理的に以下にデータを取り出すか、と言うことに着目して記述する言語である。これはデータのやりとりの記述を実にシンプルにした、という利点がある。代わりに、実際の検索に必要な物理的な部分はプランナにより、自動的に最適化されるというのが売りである。この最適化が100%完璧に働くなら何の文句はない。実際にも、90%位はうまくいっていると言っていいだろう。
ところが、残り10%のうまくいかない部分が問題になる。それをなんとかするため、論理構造だけではなく、物理構造つまりSQL個別実装に特有の要素を加味して書かなければいけないということになる。しかも、標準SQLは、すでに相当複雑になっているにもかかわらず、個別実装に特有な部分を全て吸収できるほどの柔軟さを有していない。勢い、独自拡張に頼らざるを得ない部分が出てくる。これは文法的なSQLがどれだけ標準化によって統一されようとも、その奥にあるずっと実用的な側面は、OracleなりPostgreSQLなりDerbyなり何でも良いが、個別実装依存になることを意味する。
Joel on softwareのJoel氏は、「漏れのある抽象化の法則」という言い方でこれを説明している。リレーショナルモデルは完璧かもしれないが、SQLとその実装はその完璧さには及ぶべくもない。30年以上の並々ならぬ努力がこれを解決できていない。それどころが、どのくらいで解決できるかすら分からない。そのことからしても、問題の大きさはしれるだろう。はたして、これを解決するほどの労力は本当に必要なのだろうか。
既存言語との致命的なミスマッチを抱え続けている
SQLと他の言語のマッピングほど、頭を悩まし続けている問題も少ないだろう。よく言われるのはO-R Mappingというオブジェクト指向言語とのマッピングだ。たくさんのフレームワークが内製商品OSS合わせて提案されている。L.starが知っているのは以下のようなものが挙げられる。
- Pro*C,epcg,SQLjなどに挙げられる、SQL構文をソースコードに直接書き込めるもの
- 昔のRoguewaveとかにあった、構文木を自作することで多数のDBに対応できるもの
- iBATISのように、SQLテンプレートを用意し、それからオブジェクトを生成するようなもの
- Hibernateのように、テーブル/オブジェクトを対応させて作るもの
いろいろあるが、正直決定版というものを見たことがない。いや、むろん実装として素晴らしいものも普及しているものもたくさんある。
しかし元々すりあわしづらいものを無理矢理くっつけるそのアプローチは、第三者視点から見ると醜悪である。L.starもJava屋としていろんなのを見たり書いたりしたことがある。が、はっきりOO側からこれは！と言うアプローチは見たことがない。逆に、SQL屋になってみて、しっくり来るアプローチも少ない。非常に大きなギャップを抱えているのだ。最近の挑戦はLINQだが、これもなんというかせっかくのC#言語の美しさを損ねている感がある。
OLAPとOLTPという、性能指標が異なる方式を統合しているなど、高機能すぎる
SQLデータベースの高機能さと言ったらない。例えばdbmのような単機能ハッシュだけなら、RDBMSよりずっと高速なハッシュDBはいくらでもあろう。また、大量データの解析のようなものの場合、RDBMSなど使わずにCSVとかを直読みするようなexecutor部分だけ引っ張ってきて書いた方が高速になる。しかし、この２つのアプローチの両方に対応でき、なおかつその中間のギャップを埋められるようなソリューションとして、SQLデータベースより普及しているものはない。これはSQL実装の美点の一つである。
しかし、欠点はすでに述べたとおり、あらゆるアプローチにおいてSQLが最良というわけでは決してないのだ。むしろ「SQLでできる」というがためにあらゆるものをキッチンシンク式に詰め込まれたアプリケーションはプログラムとしての自由意志よりもとにかくSQLを使うと言うところに主眼が置かれた実装である。それはもはやSQLに支配された奴隷という感すら受ける。例えば以下は個人的に「なんでこんなのにSQLデータベース使うの？」と思った例である
- ログを格納するだけなら、検索しないのでログファイル+grepで十分ではないですか
- 単なる銀行口座ならdbmで十分じゃないですか
- 大規模解析はOLAP専用ツールに任せた方が高速じゃないですか
あと最悪なのはトランザクションである。もちろんbegin-commit(abort)で表せるトランザクションは、非常にありがたい便利なものである。しかし、それを実装することによる、性能面やロック競合などの部分はより物事を面倒にする。個人的にはこれらをサポートしない故に早いMyISAMを大変評価していたのだが。
このように、結構大きな問題が昔から知られている。今後もSQLは使われ続けるのだろうが、解決される見込みはどれもなさそうなものである。しかし逆に言うと、こういう部分をきっちり解決しつつ、より大きなスケールや性能を出せるアプローチは、今後普及を見込めるのでは無かろうか。個人的にはGoogleのMapReduce+BigTable、Apache Hadoop+HiveQLなどはそれに値する、非常に興味深いものだと思うのだが。
