Re URLを扱うテーブルを作るときにどうすべきか
数日前、
pathtraqの事例を詳しく知りたい
URLを扱うテーブルを作るときにどうすべきか - 金利0無利息キャッシング – キャッシングできます - subtech
に対し、
pathtraq は前方一致検索が必要だから算術系圧縮して varbinary(767) だけど、順序の維持が不要ならハッシュのが速いはず
はてなブックマーク - kazuhookuのブックマーク / 2009年3月11日
と書いた件について。
ハッシュ値を使えるべきケースでは使うべきってのは、まあ間違いではないけれども、常にそうかというと微妙だなと思わないわけでもないわけであり。mala さんに対しては今更言うまでもないような気がするけど、なんか自分の頭の中がもやもやしてるので、まとめてみる。
気になる点としては、まず、disk I/O の回数。RSS リーダーのようなケースでは、「あるフィードの、特定時点以降の全エントリを読み出す」というような動作が頻発するだろう。となると、InnoDB のようなクラスターインデックス方式のデータベースを使っている場合は、それに最適化したスキーマ設計が重要なのかなぁとか。
あと、Bツリー系のデータベースで、固定長フィールドを使った方が検索速度が速い実装ってあるのかなぁ、ってのが疑問*1。となると、ハッシュ値より圧縮データのが平均長が短くなる場合は、そっちを使うべきって議論もありうるかなぁ、と。
そんなことを思ったりしました。
