MLを購読してもすぐに未読メールが溜まるのであまり購読しないのですが、諸般の事情でsqliteのMLを購読しています。 想像以上に流量が多く、あっと言う間に未読メールが溜まりました。やれやれ。

そんなわけで、一ヶ月前のメールを今ごろ読んでいるのですが、少し面白いメールなので紹介します。

• http://www.mail-archive.com/sqlite-users%40sqlite.org/msg40777.html

話の発端はsqliteが遅いという報告で、結論としてvacuumしたら速くなったという話です。vacuumは面倒だし時間もかかって面倒、という愚痴に対する、DRH(Dr. Richard Hipp)のコメントが上のメールです。

ちなみに、 AirOne もsqliteが原因で表示速度が徐々に遅くなっていきます。遅いと感じたらスタートメニューの「表示用データの最適化」を実行してみてください。「表示用データの最適化」は、内部的にはsqliteのvacuum(ついでにanalyze)を実行しています。人によっては、驚くほど表示速度が速くなります。

上のメールによると、vacuumが内部的に行うことで実行速度に効くのはb-treeの再構築のようです。

DRHによれば、最初にsqliteが大目のディスク領域を確保する設計にすればb-treeのフラグメンテーションをかなり防ぐことはできるだろう、とのことです。今のsqliteは必要に応じてファイルサイズを広げていくので、b-treeのフラグメンテーションが避けられません。なぜならb-treeの拡張のたびに、ファイルサイズを伸ばして追記するからです。結局、sqliteでは定期的なvacuumは必須、という結論です。

sqliteは個人ユースのツールなどにもそれなりに使われている気がしますが、みんな定期的なvacuumはどう実現しているのでしょう。 AirOne もスタートメニューに「表示用データの最適化」を追加しましたが、まあ、存在に気づく人が数%、実行までしてみる人が更に数%と言ったところでしょう。

auto_vacuumや頻繁なvacuumは却って(おそらく空き領域のコンパクションにより)空き要領がなくなり、b-treeのフラグメンテーションが進む(b-treeを拡張する時、ファイルに空き領域がなければファイル長を伸ばして追記するのでb-treeが分断されるという理屈)、という話です。auto_vacuumは一見魅力的に見えますが、sqliteに限れば使うのは危険なオプションです。