[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 メーリングリストの案内