[pgsql-jp: 30567] Re: レンタルBBS テーブル構成

斎見 浩平 saimi @ oliver.co.jp
2003年 7月 24日 (木) 03:33:03 JST


なるほど、冷静に考えたらそうですね。

実際、100万レコード単位のテーブルをPentium100程度のマシンで集計関数
を呼ぶと、4〜5分帰って来なかった経験があるので、前の発言になりました。

分類キーによる単純な絞込みクエリーなら、今の3GHzクラスのCPUで1000万
レコードぐらい瞬時に結果が出そうですね。
負荷が高くなって、サーバーを分割するとしても、1テーブルだからといっ
て手間が増えるわけでもないし。

もし、1%の掲示板に99%のアクセスがあるとしたって、ログ数がアクセス
に比例して格納されているのであれば、問題はなさそう。

ただ気になるのは、更新アクセスの集中ですね。多数のウェブサーバーのバッ
クエンドとして動いてる場合などは、100件の更新アクセスと100件の検索ア
クセスが1つのテーブルに同時にやってくるなんて事もありそうですけど。
この件は最後に質問させてもらいます。

で、いくつか識者に質問:

> コネクションキャッシュなんか使った日にゃどんな
> ことになるやら…

1.schemaの場合でも、コネクションキャッシュは再利用されないのでしょ
うか?

2.同時に多数の更新アクセスが集中した場合、更新時の内部ロックや、
MVCCのことなんか考えると、1テーブルに集中するより、それぞれ別のテー
ブルにアクセスされたほうが、処理が早いと思われますが、PostgreSQLは例
えばMySQLなどのまともにマルチスレッド化されているDBと比較して、「1テー
ブルに同時更新要求」と「独立したテーブルに同時更新要求」の処理時間の
差は小さいと見込まれるのでしょうか?

-- 
斎見 浩平 <saimi @ oliver.co.jp>




pgsql-jp メーリングリストの案内