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

2003年 3月 9日 (日) 18:24:31 JST

小泉＠コイズコムデジタルワークスです。

<1047182405.4293319497 ＠ mediafront.co.jp> の、
   "[pgsql-jp: 29326] Re: パフォーマンス向上策" において、
   "Makoto Komatsu <eurah ＠ mediafront.co.jp>"さんは書きました：

> Sun, 9 Mar 2003 04:23:36 +0900に、Tsukasa Koizumiさんは
> <200303090423.FDF21317.VLBBTUT ＠ koiz.com>において、
> 以下のように書きました：
> > 小泉＠コイズコムデジタルワークスです。
> 
> ふふふ。
> > マシンが非力（single celeron 800MHz）だったので、ハードウェアのアップ
> > グレードを提案したが、却下(T_T)。
> とか、
> > どうせ作り直すなら…と、一応試してみようとは思ってますが、それであれほ
> > ど速くなるとはにわかには信じがたく（むしろ遅くなるような気が…）、もし
> > かしてJDBCなんかを使ってないか？などと疑ってます。
> とか、
> なんだか、語るに落ちた感がありますが。

そんなに恥ずかしい事を言っているつもりはなかったのですが(^^;;;
いや、お恥ずかしい限りです。


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

自分よりスキルの高い人間が身近にいない（というか、諸々のML以外では見た
こともない）というのは、良くないですね。忙しさに甘んじて勉強を怠っては
いかん、ということがよくわかりました。


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

なるほど。
私は我流なので（決してつわものではありませんが）後者のはずなんですけど、
理論やエレガントさに走りがちな傾向がある、と思います(^^;

最初のバージョンでそれが通用しなかったので、邪道に走ったわけですが極端
すぎたんですね。結局、当たり前にやればよかった、ということですね…(T_T)


> > ○最初のバージョン（2002年9月）
> > ユーザ個々のデータを、
> >
> >   ・認証
> >   ・プロフィール
> >   ・ステータス
> >   ・フラグ
> >   ・金銭系ステータス、ポイント
> >   ・決済履歴
> >
> > の5つのテーブルに分け、リレーショナルな作りにした。
> 
> 履歴以外の基本情報、属性情報だけはひとつのテーブルにまとめたほうが
> 良かったでしょうね。ただしプロフィールとかは検索に使わないものかも
> しれないし、インデックス設定を行うものはなるべくまとめてひとつに
> するとか。そうでないものは別テーブルにしてリレーション張るとか。
> 
> 履歴はもちろん全ユーザを1個にまとめて。

はい。


> > PHPのPgsqlモジュールより速いならば、採用の価値はあるかと思ってます。
> >
> > ＃PHPのPgsqlモジュールは、著しく遅い気がしてます(^^;
> 
> PHPからの接続が遅く見えるのはPHPそのものの特性によるものです。
> 接続オーバヘッドを減らすには持続的接続を使うとか、方法もありますね。

持続的接続は、最初のバージョンで使っていました。
が、httpdが落ちまくるので、すぐにやめた経緯があります。

デッドロックとかではないです。
httpdがセグメンテーションフォルトで落ちる現象が多発しました。
原因は追及していませんが、過去、別のシステムでも同じ経験を何度もしてい
るので、使わない方がいいだろうと思ってました。

やめても体感的には変わりなかったので、あまり必要性は感じてないのですが、
もう一度試してみます。

＃が、httpdが落ちる方が重大なので、たぶん使えないと思います…。


> さらに重要なことは、DBネイティブな定型ロジックはPHPにやらせないこと。
> PostgreSQLにはPL/pgSQLという組込スクリプトエンジンがあるので、これを
> 活用しましょう。ユーザの履歴と基本情報から表示用のデータセットを
> 取り出す等の定型的処理は、組み込みスクリプトを使うとかなり速くなります。
> さらにはデータ型の変換にPHPの関数を使っている場合には、それをPostgreSQL
> 関数でやってみることもおすすめします。日付等、場合によっては嘘みたいに
> 速くなる場合がありますよ。
> 
> うちの場合、PL/pgSQLでやれることはなるべくやらせて、それでも重くなる
> コアなコードはCで書いて組み込むこともあります。
> PHPは入出力と画面遷移、そしてセッション管理だけに専念してくれれば
> いいのではないでしょうか。という発想。

これはやってます(^^)

うちの若いプログラマは、「SQLは嫌いだー」といってなんでもPHPでやろうと
するので、SQLでできないことをPHPでするように口を酸っぱくしています(^^;


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

他人の言うことを鵜呑みにしてはいけませんね。反省。


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

うちで用意したテストマシンがありまして、実際のデータのコピーを入れてあ
ります。いろいろ試して万策尽きた感じで、こちらに投稿した次第です。


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

全データが入ってます(^^;
かなりせっぱ詰まってるので、勇気云々などと言ってられなくて…(T_T)

いろいろ、勉強になります。
ありがとうございます。


/*------------------------------------------------------------------*/
/* 小泉 司＠コイズコムデジタルワークス（東京都文京区）              */
/* Desk: mailto:tsukasa ＠ koiz.com / Mobile: mailto:pigtail ＠ pdx.ne.jp */
/* PGP Public Key: http://www.koiz.com/~tsukasa/PGP_KEY/tsukasa.asc */
/*------------------------------------------------------------------*/