CREATE TABLE文のParserを作って、parseしたテーブル定義からテーブルのディスクサイズを見積もるツールを作ったので、発表してきた。
table-size-estimatorという名前で、Githubに上げている
ツールの骨組みとREADMEにあるサブセットのパースまではできた状態なので、使ってみてissueやPRを貰えると嬉しい。
発表時のスライドはここ
柔軟に利用できるSQLのパーサが欲しいけど、良さそうなものがないので、コンパイラのフロントエンドの勉強がてらに作ってみた。
今回作ってみた結果、自作でSQLのsyntaxをカバーするのは骨が折れるので、サブセットを定義してやるか他の方法を探そうという感じ。コンパイラのフロントエンド、特にLALR(1)による構文解析の仕組みとbisonでやって見るところまではできたので、今後既存のパーサを読むにもだいぶハードルが下がりそう。
勉強には以下の本を読んでいて、
- コンパイラ―原理・技法・ツール (Information & Computing)
- コンパイラの構成と最適化
- コンパイラ入門―構文解析の原理とlex/yacc、C言語による実装 (Computer Science Library)
手を動かしやすいサンプルとして3冊目のSL1というC言語のサブセットのような言語を本に沿って作ってみて、LLVMのバックエンドにつなぎこもうかという辺りで飽きてしまった。
そこで、本来の目的に戻って比較的に着地点が近いCREATE TABLE
文をパースしてみた。
ときどきDeveloperの方とサービスの初期構築時に、テーブル定義(設計)をどうするのか、その定義でどのくらいのディスクになるのかという話をするので、それに使えそうという発想。
発表中はこの定義だと可変長のカラムや運用中のフラグメンテーションによって見積もりと大きくずれるので、どうやったら正確になるかアイディアがほしいです。みたいなことを何回か話してしまったので、正確に見積もることがゴールだと勘違いされてしまったかもしれない。
発表中の話し方や、構成には改善の余地が大いにある。
他にも
- タイトルは「~~ディスクサイズの見積もり」ではなく.ibdファイルのサイズといったほうが良かった(Twitterで見た気がする)
- そもそもInnoDBが前提, innodb_file_per_tableもそう。(まあここらへんは割とデフォだけど、省くと正確ではない)
あたりは気をつけたほうが良かった
とても参考になったアドバイスとしては、
- Large objectの構成が抜けてる(聞いたときの単語は違った、、、Large objectは下のリンクの表現)
- サイズを見積もるというよりはアドバイザーにしたらどうか
- PKがないテーブルを作ろうとしているか
NOT NULL
をつけないで定義しようとしていないか
- ibdファイルをパースするほうが(僕に)向いているのでは
などがあって、書いてみるとエースや素人()な人のアドバイスなので、やはりすごい(語彙力)。
まさしくという感じなので、アドバイザーとしての機能をつけて、可変長のデータの構成見てみたらツールとしては一旦終わりかなと言う感じ。
(partition句の対応をどうするか、、、)
次はibdかbinlogをパースしてみます。
質疑応答、懇親会含めいろいろなアドバイスを頂けて、とても嬉しかったし、発表させてもらえる場を作ってくださった方々に感謝です。 (MySQL Casual, 2か月に1回くらいほしい...)