« 回線速度の計測 | トップページ | JJTree 構文木を作るツール »

2009年2月19日 (木)

「更新系」はどこへ?

正直、何を根拠にAPサーバで処理した方が良いなどと言ってるのか、いまだに分かりません。私がアホなんでしょうが、口汚く罵って煽ってみても、そういう主張の方のコメントが得られなかったのは残念です。炎上もさせられなかった(笑)。

炎上までいかなかったけれど、たくさんのご意見ありがとうございました(ベンチャー社長で技術者で)

私も「APサーバで処理した方が良い」という話はよくわからないのですが。

一連のお話を読んでいて、少し思ったのは。

ユーザーインターフェイスに必要なパラメータと戻りはダミーのストアドプロシージャの中に含まれています。更新系では、画面側の項目と、セッションIDやログインIDなどが必要になるかもしれませんが、戻りはエラーコードやエラーメッセージを返せば済みます。

更新系に必要なものは、システムの共通仕様として、あらかじめ、まとめておけばよいことです。

テーブル設計は実装の後に! (ベンチャー社長で技術者で)

と、当初は「更新系」、OLTP系の話が少し出ているのですけど。

当たり前ですが、

(クライアントへ)データ転送 > データスキャン >>>> 四則演算

つまり、DBで1回テーブルスキャンするのと、そのときに集計処理をついでに行うのはパフォーマンスには差が出ませんから、DBサーバにとって四則演算をどこかで肩代わりしても意味がないのです。

SQLを使うとスケーラビリティの問題が起きる? それはエコじゃないね (ベンチャー社長で技術者で)

後半では、完全に集計処理、OLAP系だけの話になってしまっている、というところです。

大量のユーザが、大量の更新をかけるような、OLTP系のシステムの場合、 DBサーバをスケール・アウトしたい、ということはあるのではないですかね。

Article_20090218

こんな感じで、OLTP系処理に対しては、DBサーバを複数台用意して、DBサーバ1台あたりの書き込み負荷を下げる。OLAP系処理に対しては、もう一台、集計用のDBサーバを用意して、そこで集計をすると。

まあ、別にOLTP系処理で、 テーブルを直接書きにいかずに、ストアド・プロシージャー経由でも、全く問題ない と思います。ですので、別に結論は変わらないのですけどね。

ただ、OLTP系の場合は、「スケーラビリティをあげるために、処理は極力DBサーバで行うべき」は言いすぎかもしれません。当たり前ですが、 DBのデータ使わない処理まで、DBサーバでやる必要はないですから ね。 「生の入力データ」(例えば、HTML)を、そのまま DBサーバに渡して、DBサーバで解析・バリデートとか。

結局のところ、 データに対する処理は、そのデータのある場所に近いところで行なうのが良い、という話でしょう。昔から言われていることですが。

|

« 回線速度の計測 | トップページ | JJTree 構文木を作るツール »

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック

この記事のトラックバックURL:
http://app.f.cocolog-nifty.com/t/trackback/80472/28199530

この記事へのトラックバック一覧です: 「更新系」はどこへ?:

« 回線速度の計測 | トップページ | JJTree 構文木を作るツール »