やりたいこと
カラム数の多さがどれだけパフォーマンスに影響するのかを確かめたいと思いやってみました。
そこで、PostgreSQLのMAXである1600カラムを作成し、データを1000万件入れました。
##結論から
かなりの差がでます。
select count(*)を行うと致命的
他にもデータ自体を検索してしまうとカラム数が多い場合、実行時間がまともに動作しないレベル。
カラム数はあんまり多くしないようにしましょう。
もちろん、インデックスは使いましょう。
前提
PostgreSQLで使ったのはAWS RDS(t3.micro)です。
以下の2つのテーブルを比べることでパフォーマンスを比較します
■testテーブル
・カラム数は、以下の3つ
1.character varying(256)
2.integer
3.timestamp with time zone
・CSVでインポート。サイズは650MBほど
・1000万件のデータがあります。
・インデックスなし
■test_1600テーブル
・カラム数は、以下の1600個
1.character varying(256)
2.timestamp with time zone
3.integerが1598カラムあります。
・CSVでインポート。サイズは73GB・・(汗 でかい
・1000万件のデータがあります。
・インデックスなし
データ個数確認！
カラムが多いと実行時間が123倍かかるようです。
■testテーブルは1000万件確認
約4秒かかりました。
実行計画を見てみます
■test_1600テーブルも万件確認
約10分かかりました・・これはまずい
実行計画を見てみます
Excustion Timeが実行時間です。10分ほどかかってます。
##インデックスがない状態で1行取得してみる
存在しないデータを取得してみる
カラムが多いと実行時間が78倍かかるようです。
■testテーブル
約4秒
■test_1600テーブル
約314秒
##インデックスがある状態で存在する1行取得してみる
■testテーブル
インデックスはると、データ自体を使わないため、あんまりかわらないですね
約0.038ms
■test_1600テーブル
約0.245秒
##CPU使用率もスパイクしまくる
select count(*)と、インデックスなしでアクセスしたからだと思います。
##読み取り IOPS
