tom__bo’s Blog

えんじにゃ〜 @tom__bo

MySQL Casual Talks #11で話してきた

CREATE TABLE文のParserを作って、parseしたテーブル定義からテーブルのディスクサイズを見積もるツールを作ったので、発表してきた。

table-size-estimatorという名前で、Githubに上げている

github.com

ツールの骨組みとREADMEにあるサブセットのパースまではできた状態なので、使ってみてissueやPRを貰えると嬉しい。

発表時のスライドはここ

speakerdeck.com

柔軟に利用できるSQLのパーサが欲しいけど、良さそうなものがないので、コンパイラのフロントエンドの勉強がてらに作ってみた。
今回作ってみた結果、自作でSQLのsyntaxをカバーするのは骨が折れるので、サブセットを定義してやるか他の方法を探そうという感じ。コンパイラのフロントエンド、特にLALR(1)による構文解析の仕組みとbisonでやって見るところまではできたので、今後既存のパーサを読むにもだいぶハードルが下がりそう。

勉強には以下の本を読んでいて、

手を動かしやすいサンプルとして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回くらいほしい...)