[pgsql-jp: 29323] Re: パフォーマンス向上策

[SAITO Masaru]

齋藤＠横浜です。

202003/03/09 8:02:38 ごろ
Shigekazu Aoyagi <aoyagi ＠ ss.iij4u.or.jp> wrote:さんは以下のように書きました
> 青柳と申します。
> 
> On Sun, 9 Mar 2003 04:23:36 +0900
> Tsukasa Koizumi <tsukasa ＠ koiz.com> wrote:
> 
> 
> データ量は2倍になりますが、少なくとも検索ごとに2万のテーブルを結合する
> コストは削減できます。
> 
> > ○現行バージョン（2002年2月）
> > ユーザーが2万を超えた当たりから、動作が著しく遅くなる。
> > その上、全ユーザの決済履歴を検索、一覧したいとの要望。
> > 
> > 高速化に四苦八苦している間に、日々会員数は増え続け、現在に至る（涙）
> 
> PostgreSQL のソースを読んでないのであてずっぽですが、PostgreSQL 内部で
> テーブル自体を探し出すのに時間が掛かっているのではないでしょうか。
> 
> PostgreSQL の開発者の気持ちになってみると、普通はせいぜい数十程度の
> テーブルしかないでしょうから、テーブル名検索にそれほど高度なアルゴリズム
> は使用しないのではないかと思います。だとしたら、全ユーザの決済履歴どころ
> かあらゆる処理が遅くなってもおかしくありません。
> 

PostgreSQL内部では1テーブル1ファイルになっているものと思われます。
# $PG/data/base/[DB名]/ 以下をのぞいてみただけですので、
# これを別のところで管理しているとしたら外しています。
でもって、同じディレクトリの中に数万ものファイルがあると
各ファイルにアクセスするのにものすごく時間がかかります。
たぶん、indexを張るのも無駄だと思います。

もし、mysqlに変えるとしても、ここらへんの仕組みは同じですので、
パフォーマンスが劇的に改善するとは考えにくいです。
# 改善すると思いますが「劇的」とまではいかないのでは？と思います。


> いっそ、ユーザIDの末尾桁などでユーザをグループ分けして、グループごとに
> DB を分けてしまうというのはどうでしょうか。そうすれば、各DBに収容される
> ユーザは今より1桁は少なくなりますので、しばらくは持つだろうと思います。
> # もちろん、そうやって時間を稼いでいる間に更に抜本的な改善の予算と時間を
> # 提案するとして。
> 
> 変更部分も各スクリプトの DB 名を指定している部分だけですので、処理の
> 方法などはいじらなくて済むので比較的楽に修正できると思います。

という方法と、

> > ○2番目のバージョン（2002年12月）
> > ユーザ毎に決済履歴テーブルを作るように変更。
> > ユーザ毎の決済履歴検索を速くするには、これしかない…という苦肉の策。
> 
> 全ユーザの決済履歴を保存するテーブルを"追加"して、決済時には
> 個別ユーザごとのテーブルと両方を更新するようにしてはどうでしょうか。

この方法で「とりあえず」は何とかなると思います。が
同じディレクトリの中に数万のディレクトリがあってもやっぱり
遅くなりそうな予感。。。($PG/data/base の中に各DBが作られる)
結局やってみる価値はあるけど効果はやって見なきゃわからない
ということですね。。


---
SAITO Masaru <daisaito ＠ lares.dti.ne.jp>