DBとかパフォーマンスとか
チラ裏です。
そのカラムにインデックスを張るべきか否か、そしてそれはどう判断すべきなのか
- かなり頻繁に where 句として使われる
- カーディナリティは極端に小さい(現状2パターンしか無い。直近増える予定もない)
…というカラムがあった。時間が無いなりに調べた結果、このカラムには index 不要だと思い貼らないことにした。 これを、理論からだけじゃなくて実際の測定値から判断したかったなと。
とはいえ、開発環境のテストデータで測定してもあまり意味ないだろうし、どうやるのが良いかわからなかった。本番に投入して様子見するしかないのかなー。
migration でしくじったがどうするのが良かったんだろう
インデックスを張るか悩んだカラムだが、最初はインデックス張る方向で進めておりその設定を書いた migration ファイルを push していた。さらに、試験環境に rake db:migrate していた。
しょうがないので、index を削除する migration ファイルを push したわけだが、これ大丈夫なんかな…。 rake db:migrate すると、index 作ってまたすぐ削除することになると思われるので、本番環境の DB に実行した時にどのくらい影響あるんだろってのが少し気になってる。
Rails とパフォーマンス
Rails…、というか ActiveRecord。 コールバックとか関連とか、ウェッブアプリ開発で最高便利な機能をたくさん持つ代わりに、用途によってはパフォーマンスが出にくいというのが今回の開発で思ったこと。
知らないだけってのもあるだろうけど、特に書き込みが多いアプリケーションと ActiveRecord って相性悪いんじゃないかと思った。大量の INSERT を1クエリにまとめる activerecord-import や、UPDATE 句をまとめる update_all、DELETE 句をまとめる delete_all などはあるものの、それなりに制約があった。ActiveRecord の機能が十分に使えなくなってしまう。
実際、その制約が理由でこれらの機能をうまく導入できなかったりもした。 大量書き込みって時点で Rails way 外れてんのかなぁ〜