[pgsql-jp: 32969] Re: 問い合わせの速度低下

[田中 正幸]

こんにちは田中です。

一日144000レコード増えていきますと
356日で51264000レコードになります。

3年程度で1億5千万程度のデータ量になりますが、その時点のパフォーマンスは大丈夫でしょうか？
CHECK_IDごとにテーブルを分けるとか、他の方法を取ったほうがよろしいのでしょうか？

http://www.nttdata.co.jp/rd/topic/oss/
PostgresForest

以上のツールなどを利用してみるとか。。。（未検証）

1日ごとの固定長ファイルに書き出すとか、MySQLなど他のDBを選択してみるとか
最低限データ分割をしないと難しいと思います。

手元の環境ですと１００万件の全件カウントだけでも３秒以上かかっていますので
データ件数は抑えるように作ったほうがいいとは思いますよ。

田中

> -----Original Message-----
> From: pgsql-jp-admin ＠ ml.postgresql.jp
> [mailto:pgsql-jp-admin ＠ ml.postgresql.jp]On Behalf Of Mao Morimoto
> Sent: Tuesday, May 18, 2004 11:59 AM
> To: pgsql-jp ＠ ml.postgresql.jp
> Subject: [pgsql-jp: 32966] 問い合わせの速度低下
> 
> 
> たびたびお世話になってます。もりもとです。
> 
> PostgreSQL7.4.2を利用しているのですが、
> パフォーマンス面で悩んでいまして・・
> 
> 毎日２４時間、５分おきに５００レコードずつどんどん追加されていくテーブルがあ
> ります。
> 
> TABLE T_RESULT
>   TIME_SMPL   TIMESTAMP
>   CHECK_ID    INTEGER
>   CHECK_SUB   INTEGER
>   以下、データフィールド
> 　　　：
> 
> このようなテーブルで、TIME_SMPL、CHECK_ID、CHECK_SUBの三つのフィールドが
> 重複キーのようになっていて、
> TIME_SMPL の重複インデックス I_RESULT_1
> CHECK_ID ＋ CHECK_SUB の複合重複インデックス I_RESULT_2
> TIME_SMPL ＋ CHECK_ID ＋ CHECK_SUB の複合重複インデックス I_RESULT_3
> この、三つのインデックスを念のため設定してあります。
> 
> なぜインデックスが三つかというと、VACUUMした後におなじSELECT文をEXPLAINする
> と、インデックスがどれか一つだけだと、時々シーケンシャルスキャンになってしま
> うのです。三つあると、必ずどれか一つを使ってくれるようです。
> （主に使われるのは、I_RESULT_1+Filterのパターンと、I_RESULT_3だけのパターン
> のようです）
> 
> そこで、問題なのですが・・ CHECK_IDとCHECK_SUBとTIME_SMPLを条件としてレコー
> ドを取り出すだけの簡単なSELECT文の実行時間が、データがたまるとどんどん遅く
> なってしまうのです。（１日動かすと144000レコード増えて、SELECTの問い合わせに
> かかる時間は20倍くらいになってしまいます）
> 
> 遅くなったときに VACUUM ANALYZE するとまた元通り早くなるのですが、またしばら
> くすると遅くなってきますし、データがたまってくるとVACUUM自体がとんでもなく時
> 間かかってしまうので、こまめに実行できる状況ではありません。。
> 
> もしかして、追加されたレコードについてはVACUUMするまでインデックスが有効にな
> らないのでしょうか。。？
> また、このような場合の何かいいパフォーマンス対策はありますでしょうか。。？
> 
> - Mao Morimoto
> http://blog.yamamaya.com/
> 
>