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

[Makoto Komatsu]

小松＠メディアフロントです。

Sun, 9 Mar 2003 04:23:36 +0900に、Tsukasa Koizumiさんは
<200303090423.FDF21317.VLBBTUT ＠ koiz.com>において、
以下のように書きました：
> 小泉＠コイズコムデジタルワークスです。

ふふふ。
> マシンが非力（single celeron 800MHz）だったので、ハードウェアのアップ
> グレードを提案したが、却下(T_T)。
とか、
> どうせ作り直すなら…と、一応試してみようとは思ってますが、それであれほ
> ど速くなるとはにわかには信じがたく（むしろ遅くなるような気が…）、もし
> かしてJDBCなんかを使ってないか？などと疑ってます。
とか、
なんだか、語るに落ちた感がありますが。

いやこの際、素人なのでしっかり勉強しますって気持ちで取り組むのも大切かと。(^^;

業界で感じるよくある間違いのひとつは、論理的方法と実践的方法のギャップです。
例えば正規形。RDBの理論をちゃんと勉強してきたお利口な学生さんは、必ず最初に
第２正規形で美しいDB設計を展開しようとしますけど、少しテーブル数が増えると
これがなかなかうまく動いてくれない。
その横で、我流でガリガリやってきたつわものは正規形なんか無視してテーブルに
丸ごと放り込んで動かしている。
悲しいけど、えてしてつわものの我流が勝ってしまうんだな。

PostgreSQLも少々クセがあるみたいで、理論どおりではああなんだけど、実際には
こっちがいいよ、みたいなことが多々あるもんですよ。
そのへんは経験と割り切りが肝要。

> ○最初のバージョン（2002年9月）
> ユーザ個々のデータを、
>
>   ・認証
>   ・プロフィール
>   ・ステータス
>   ・フラグ
>   ・金銭系ステータス、ポイント
>   ・決済履歴
>
> の5つのテーブルに分け、リレーショナルな作りにした。

履歴以外の基本情報、属性情報だけはひとつのテーブルにまとめたほうが
良かったでしょうね。ただしプロフィールとかは検索に使わないものかも
しれないし、インデックス設定を行うものはなるべくまとめてひとつに
するとか。そうでないものは別テーブルにしてリレーション張るとか。

履歴はもちろん全ユーザを1個にまとめて。

> PHPのPgsqlモジュールより速いならば、採用の価値はあるかと思ってます。
>
> ＃PHPのPgsqlモジュールは、著しく遅い気がしてます(^^;

PHPからの接続が遅く見えるのはPHPそのものの特性によるものです。
接続オーバヘッドを減らすには持続的接続を使うとか、方法もありますね。
さらに重要なことは、DBネイティブな定型ロジックはPHPにやらせないこと。
PostgreSQLにはPL/pgSQLという組込スクリプトエンジンがあるので、これを
活用しましょう。ユーザの履歴と基本情報から表示用のデータセットを
取り出す等の定型的処理は、組み込みスクリプトを使うとかなり速くなります。
さらにはデータ型の変換にPHPの関数を使っている場合には、それをPostgreSQL
関数でやってみることもおすすめします。日付等、場合によっては嘘みたいに
速くなる場合がありますよ。

うちの場合、PL/pgSQLでやれることはなるべくやらせて、それでも重くなる
コアなコードはCで書いて組み込むこともあります。
PHPは入出力と画面遷移、そしてセッション管理だけに専念してくれれば
いいのではないでしょうか。という発想。

JDBCが速いということはありません。しかたなくJDBCを使っているだけのこと。
もちろん、すでにおわかりでしょうが、PHPからJDBCなんてナンセンスなことは
あり得ません。

提案なんですけど、とりあえず手元にそれなりの（同スペックの）サーバを
用意して、DB部分だけダンプして持ってきたらどうですか？
守秘義務がどうのこうのと言われたら、パフォーマンス上げるためのチューニングを
行うためにシステムを安全に切り分けて検証しますとかなんとか、うまく言いくるめて
ですね、データ丸ごと持ってきてからいろいろ試してはどうでしょうね？

最終的にはシステム運用を一時止めて、データを全てダンプして新しく設計しなおした
DBへ入れなおすことが必要になるだろうと思います。
それを数万件でやるのか、数十万件でやるのかは、勇気の問題かも。