こんにちは。なにげに収束してしまったみたいで、今更なのですが。

深海水草 <VYG01106@xxxxxxxxxx>さんの
<20040613102738.A294.VYG01106@xxxxxxxxxx>
"[mysql 09622] Re: ACCESS97ODBC接続のパフォーマンス"


> 長谷です
> 
> > 「今のところ問題はない」とは機能や能力的にはMS-Accessで十分、
> > しかし将来の事とかを考慮するとクライアント/サーバに移行したい、
> > という事ではないでしょうか。
> 
> それは大体想像は付きます。．．．けど
> しかし、評価の方法に問題有り、と提起して居るのです

　評価の方法に問題あり、確かにそうです。仮想記憶みたいな貧乏臭いものに頼
るのはいけませんよね（笑）。まあ、話を聞いて(読んで)いると、プラットフォー
ムのパフォーマンス以外にも、多々問題を抱えている様な気がします。


> > MS-Accessの様なシングルユーザを念頭に置いているシステムを
> > 基本的にはマルチユーザなクライアント /サーバ・モデルに置き
> > 換える場合、排他制御をどの様に導入していくかで、その置き
> > 換えが上手く行くかポシャるかが決まるとも言えると思います
> 
> これも同感です。この「排他制御」が Acesss を C/S として使う
> 場合に死ぬほど苦労するので．．．
> ならば RDBMS を使う方がまだマシ、という意見です

　MDB/JETを共有で使ったりすると、DBが壊れる事がありますしね。


> > 多数のスタンドアローン・システムで行われている処理をサーバ
> > にまとめる場合、個々のスタンドアローンでAPが使用する処理
> > 能力の総和がサーバに求められる事になります。
> 
> うぬぬ、それは余裕を見れば、ですよね．．．
> 確かに仰るように月末、年度末、期末などには負荷が集中するとは
> 思います
> 
> でも普段、スタンドアローンな PC で100％そのような DB を操作
> する訳ではなく、メールとかも使うでしょうからね．．．

　能力的な設計は、必要処理能力や重畳度とかを決めて/測って利用/負荷モデル
を作っての統計的(OR的)なものと、必要処理能力が同時に要求される事を想定し
た最悪値設計があるでしょう。この２つの間のどの辺を落としどころにするのか
が難しい訳です。

　見込みが甘い、つまり負荷を過小に評価しての設計は、ユーザの不満程度で済
めば大変結構、実際には深刻なトラブルに発展する事も少なくありません。「大
金をつぎ込んだのに、サーバを使った新システムの方が遅いじゃないか！<以下
略>」と言う様な。


> > 能力的には10万円 PCが10台分位、でしょうか。
> 
> 最初からそこまで用意しなくても、まず DB Server を一台置いて、
> それで負荷が大きいようだったら増やしてクラスタリング、と
> いうのが経済的であるように感じます

　700万するけど、100万相当のPC群と同じ位しかパフォーマンスがないSunのサー
バマシンですが、これはエントリレベルのマシンです。エントリレベルとしては、
ハイスペックですけれどね。サーバに機能を集中するなら、この程度では全然お
話しにならない場合もあるでしょう。

　クライアント/サーバだからジャイアントサーバを導入しなければ、は確かに
ナンセンスではあります。しかし「ではPC程度のコンピュータでクラスタを」は、
ジャイアントサーバ導入よりも技術的な敷居が高いでしょう。

# ボクも趣味としてはクラスタですね。


> > 一般論としては、なんとも言えない、ではないでしょうか。
> 
> 今現在 Access で何とかなって居る場合はそうだろうと思います

　いや、「多数のスタンドアローンとクライアント/サーバでは、どちらがお得
なんでしょう？」の問いに対しての答が「一般論としては、なんとも言えない」
です。


> > クライアント/サーバのモデルの
> > 方が、逆に馬鹿高、 C/P極悪になる場合も多い、だったりします。
> 
> これこそ SE やプログラマの実力次第で大きく変わるだろうと思い
> ますけどね

　総合的にC/P、あるいはパフォーマンス単体でもですが、を維持するのは大変
ですよ。システム構築の立案時にこの手の考察が行われる事は当たり前ですし、
その様な文書は仕様書に含まれるのが普通です。ですが、それは真剣にやられて
いるのでしょうか。後でパフォーマンス的な問題が発生するのは、形だけの検討
が行われた事の証左ではないでしょうか。

　形だけの原因は何でしょうね？



　　　　松枝知直　　　　<tomom@xxxxxxxxxx>
　　　　　　　　　　　　http://www.argus.ne.jp/~tomom/