- MySQLの過去を振り返る Part 1
- MySQLの過去を振り返る Part 2
- MySQLの過去を振り返る Part 3
- MySQLの過去を振り返る Part 4
- MySQLの過去を振り返る Part 5
Netfrastructureは、データベースエンジンだけでなく色々なものを持っていたが、MySQLにとって興味深いものの一つはやはりストレージエンジンだろう。Netfrastructureの面白いところの一つとしては、組み込みのJava VMがあった。これにより、データのすぐそばで色々な巧妙な仕掛けをすることができた。JimとAnnは機能が一通りそろったデータベースを携えてきたので、MySQLのいくつかの部分はショックを受けたものだ。
Falconエンジン自体にはいくらかやり残したことがあったが、それは完成されることはなかった。おそらく皆さんは「今年の後半には完成するでしょう」と聞いたかもしれないが。
他にもMySQLが他人に所有されているわけではないストレージエンジンを手に入れようとする試みはあった。Geminiを復活させることだ。思い出してみて欲しい。Geminiはその時にはGPL対応になっており、ことによると最新のMySQLにアップデートされるかもしれなかった。LaunchpadのAmiraプロジェクトのコードを見てみるといい。しかし最終的には、このプロジェクトはどうなることもなかったが、もっとリソースを使えていたらどうなったかは興味深いところだ。結局のところ、Falconは興味を惹きつけたのだ。
何年もの間、プレゼンテーションやマーケティング資料で大々的に宣伝されてきたように、これがプラガブルなストレージエンジンアーキテクチャの完璧な勝利になるはずだった。それで何が起きたかというと？NDB(今のMySQL Cluster)が安定し、「明らかな」バグや意図しない挙動から解放されるまでに、2年から4年もの歳月がかかったわけだ。Falconはそうではなかっただろうか？
実際のところ、Falconプロジェクトは、ストレージエンジンインタフェースの欠点を全て暴露してくれた。そこには「本当にこれでいいんだっけ？」「ああ、うん、そうなんだ、悪いね」というたくさんのやりとりがあった。
ストレージエンジンとデータベース間をつなぐAPI(ここでは広い意味で使う)は、元々ISAM、それからMyISAMを接続するために使われていたものだ。そして最初のトランザクション対応ストレージエンジン(InnoDB)のためにたくさんの改造が必要になり、それらが今もきれいにされないままだ。分散ストレージエンジンでもあり、3番目のトランザクション対応エンジン(MySQL Cluster)が登場した時にも、APIには根本的な改善はされないままで、むしろ同種の回避策やずるいやり方が増えただけだった。そうしてFalconが登場する頃までに、ラッキーだったらAPIはまだあなたの期待する機能はないという状態だ。オフィシャルなドキュメントが正確でないという状況は多くあったが、トランザクション対応データベースが動作するために必要な基本的な何かを実装するために、階層化の意味を失わせるような気持ちの悪いコミットをしなければならないのは間違いなかっただろう。
ほぼ間違いなく最悪だったのは外部キーで、これはFalconプロジェクトの必須条件だった。外部キーの情報を取り出すときは、自分でSQLパーサを書かなければならないのだ。auto_incrementから始めるのもやめよう。正しい動作は全くもってドキュメントに書かれてなどいないのだから。
次はPBXTについて見てみよう。
