カラム数が増えるとDB性能が劣化する？
テーブルのカラム数が増えていくと、DB性能が悪くなる気がする。
そんなメンバーの声を聴いて、そういえば自分も実体験として、100カラムほどあるテーブルの性能問題にぶつかったことがあったことを思い出した。やたらとSELECTが重い。とは言え、その原因がカラム数にあるというのは眉唾。
実際に手元にあった PostgreSQL8.1 で試してみることにした。
10カラム、20カラム…と、100カラムのテーブルまで、カラムを10ずつ増やしながら10テーブルを用意。データは、主キーとなるIDにのみシリアル値を設定したレコードを、各テーブルに100万件だけ用意してみた。さっそく、それぞれにSELECT文を投げてみる。
この結果を見る限り、カラム数による影響はなし。
はて、では何が原因で劣化を感じたのだろうか。カラム数に比例して増えるのは、データである。そこで今度は、10カラムのテーブルで、1カラムずつデータを挿入していったときの性能比較。対象レコード数は100万件。各テーブルにSELECT文を投げてみる。
データ量が増えるにしたがって検索性能が落ちている。落ちているとは言っても、100万レコードに値を入れて、それで100ミリ秒遅くなっている程度だけど。
ということで、カラム数が増えることで性能が落ちるのではなく、カラムが多いテーブルではデータ量も多くなるので性能が落ちる、というのが本当のところか。カラム数が1000とかになったら激しく性能劣化する可能性もあるから、断定はできないけど、100カラム程度であれば、カラム数の影響はないようだ。
データ量の増加にともなって検索速度が落ちる点についても、ちゃんと VACUUM FULL や REINDEX していくことで、影響は最小限に抑えられる。これらを計画的に行うような設計にしておけば、数百万件レベルなら臆することでもない。
ただし。
カラム数が膨大なテーブルは、保守の面から考えると、決して便利とは言えない。設計はラクかもしれないけど、個人的にオススメはできない。
自分が設計するときに、テーブルのカラム数が40～50を大きく超える場合は、派生させたテーブルを作って分割管理することを検討する。結合のコストがかかるとは言うものの、実はそういった横長テーブルのうち、よくSELECTされるのは30程度だったりする。それならば、結合コストを犠牲することも、やぶさかではないと思う。ま、でも基本は正規化ですけどね！
以上、お疲れさまでした。
Posted by dT by 16:28
トラックバック
このエントリーのトラックバックURL
コメント
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29