Yakstは、海外の役立つブログ記事などを人力で翻訳して公開するプロジェクトです。
5年以上前投稿 修正あり

MySQLの過去を振り返る Part 6 エンジンは動き出す

長らくMySQLの開発に関わってきたStewart Smith氏が、MySQLの誕生から現在、将来の展望までを駆け足で語る。Part 6は、MySQLの特徴であるプラガブルなストレージエンジンの設計について。

原文
Ghosts of MySQL Past, Part 6: The engine revs (English)
翻訳依頼者
D98ee74ffe0fafbdc83b23907dda3665
翻訳者
D98ee74ffe0fafbdc83b23907dda3665 doublemarket
原著者への翻訳報告
未報告


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について見てみよう。

次の記事
MySQLのALTER TABLEをモニタリングする
前の記事
MySQLの過去を振り返る Part 5 買収の時代

Feed small 記事フィード

新着記事Twitterアカウント

新着翻訳リクエストTwitterアカウント