Visual Basic Magazine 2001年11月号
『新SQL Server解体新書』原稿
〜SQL Server2000とMSDE2000のパフォーマンスの違い〜
Microsoftのマーケティングとエンジニアの未来
プログラマの将来価値を左右するもの
今日のビジネスシーンにおいて、マーケティングが重要だということに異論を唱える人はいないだろう。ソフトウェア業界でもそれは変わらない。というより、ソフトウェア業界は、他の一般的な業界以上にマーケティングが重要だと言っていい。Microsoftのマーケティングに、以前のような凄みがなくなりつつあることは、前回指摘したとおりである。
プロフェッショナルなプログラマが、次にどのような技術を習得するのかを考えるのも、労働市場におけるマーケティングのひとつである。新しく習得した技術が、将来使われなくなった場合、そのプログラマの市場での価値は下落する。つまり、Microsoftのテクノロジーをサポートするエンジニアの場合、Microsoftの技術が使用されなくなると、その技術の需要は減る。結局、Microsoftのマーケティング力の衰えは、技術者の価値を落とすことになるので、他人ごとではない。
Javaか.NETか
そのような理由で、今後、Javaをやっていくか、.NETにすべきかで悩んでいる人も多いのではないだろうか?
この質問にはっきりと答えることは、非常に難しい。「サーバーはJava、クライアントはMicrosoft」という流れは、ある程度はっきりしている。しかし、Windowsクライアントアプリケーション開発の本命が、.NETに移行するのか、あるいは現在のままWin32ネイティブで行われるかどうかは、まだよくわからない。携帯電話や他のモバイル機器の台頭もあるので、これらも考慮する必要があるだろう。
そして今後、当分の間大きなマーケットとして期待できるのは、サーバー側のプログラミングである。もし。プログラムを作ってお金をもらうのならば、サーバーサイドのJavaを習得するのが、最善の方法なのではないかと思う。というのは、Windows系のサーバーよりもUNIX系のサーバーの方が平均的に単価が高いし、需要も十分にあるからである。
ユーザーからみた.NETの利点
しかし、信頼できるJavaのランタイムモジュールが高価なのに対して、.NETのランタイムがOSに組み込まれることを考えれば、.NETを選択するユーザーも必ず出てくるだろう。もちろん、Windows系のサーバーの場合、サーバーOSの価格にランタイムの価格が含まれているだけで、無料ということではない。しかし、それを考えても価格差はある。
また、データベースエンジンのコストもシステムを構築する上では無視できないだろう。この点においても、Windows系のサーバーにはMSDEがあるということが.NETを選択する理由になるだろう。
今回は、MSDE2000をテストしてSQL
Server2000と比較する。クライアントアプリケーションがデータベースサーバーにADO経由でアクセスする通常のタイプのデータベースアプリケーションでは、同時使用ユーザー(同時接続ユーザーではない)が増加するとパフォーマンスで水を開けられたものの、Webアプリケーションにおいては、MSDE2000はSQL
Server2000と同等の性能を示した。前回指摘したように、SQL
Server7.0や旧バージョンのMSDEにあった、「データベースファイルの破壊後、ログのバックアップができず、最後のバックアップまでしかデータベースの復旧ができない」という問題が修正されたことも考えても、MSDE2000を利用する意味は大きい。
もちろん、Linux用の無償のデータベースサーバーを知らないわけでないが、最近のMicrosoft製品の品質の高さを評価している私としては、有償のデータベースへの移行の容易さも考えて、MSDE2000という選択肢は考慮に値すると思う。
.NETを使用するユーザーは必ずいる。しかし、それは普及の確証にはならない
しかし、利点や機能だけで、今後の動向を予測できるわけではない。あくまで、「…という利点があるのだから、使う人がいなくなることはないだろう」と予測できるだけである。第一、利点や機能だけで市場を動向を掴めるのであれば、マーケティングなど必要ないし、Microsoftが今日まで生き残っている理由もない。良い製品を安く提供すればいいだけである。
一方、良い製品を作ると、「良いものだから売れるに違いない」という奢りが生じてマーケティングがおろそかになり、失敗することが多い。逆に言うと、製品に問題があると、それをカバーするような努力をして売ることになり、結果的に成功したりするのである。このことを、私はマクドナルドと全盛期の角川映画とMicrosoftから学んだ。
だから最近のMicrosoftの、製品の品質の高さとマーケティング面での衰退は、直接的な関係があると私は考えている。
マーケッティングと人間心理
マーケティングとは?
ところで、マーケティングと簡単にいっても、マーケティングとは何かをひと言で説明するのは難しい。日常的に自然に使っている言葉だが、中学生に「マーケティングって何?」と質問されたとして、何と答えたらいいだろうか? あえて言うならば「ものやサービスを売れるようにすること」なのだが、この説明で具体的にイメージできる中学生(それに大人も)は少ないだろう。
実際のマーケティングとは、多分に心理的、確率的、推測的なものである。つまり、消費者の心理を検討し、確率を考慮し、消費者の行動を推測することがマーケティングの要だということができる。
しかし、心理も確率も推測も、すべて曖昧なものである。だから、大企業が高価なコンサルタントを雇っても、大きな失敗をすることが多いのだ。
人間ほどあてにならないものはない〜三囚人問題より〜
推測と確率に関して、人間の認知構造が脆弱であることを示す問題として、「三囚人問題」という数学の問題がある。短いものなので、内容を次に記す。
ビル,スティーブ,ラリーの3人の囚人のうち2人は死刑になるが1人は助かる(ビルが助かる確率は1/3)。
ビルは看守に向かって「(自分以外の)残り2人のうち、1人は確実に死刑になるのだから、どちらが死刑になるかを教えてくれ」と頼んだ。
すべてを知っている看守は、正直に「スティーブが死刑になる」と教えた。
その結果、残りの(スティーブ以外の)ビルとラリーのうち、1人は助かるのだから、ビルの助かる確率は1/2に上がったというのは事実だろうか?
■答え■
看守が告げた後も、ビルが助かる確率は1/3で変らないというのが答えである。つまり、ラリーの助かる確率は2/3である。
この答えを知ったとき、私は呆然としてしまったのだが、次のように考えると少しわかりやすくなるだろう。もし、ビルが看守に向かって「3人のうち死刑になる1人を教えてくれ」ときいて「スティーブが死刑になる」と答えたならば、確かにビルの助かる確率は1/2に上がる。しかし、看守はスティーブとラリーの二人のうちから、死刑になる囚人を選んだのである。ここにビルとラリーの違いがある。しかし、この問題の記述からは、ニ者のそのような差を簡単に見つけることはできない。そのため、推測に間違いが生じるのである。
この数学の問題は有名なので「三囚人問題」というキーワードでインターネットのサーチエンジンで検索すれば、かなりの数がヒットする。数学的に納得したい人は試す価値があるだろう。
.NETにおけるMicrosoftのマーケティングは、果たして・・・？
どの言語でも使えるというのは便利だ。しかし、だからだめな場合もある
Microsoftは.NET構想を推進するにあたって、コモンランゲージランタイム(Common Language Runtime)という概念を適用した。つまり、.NETアプリケーションは、対応する言語エンジンさえあれば、どのような言語を使って開発することできるというものである。Microsoftの(Windows用)開発製品ユーザーには、Visual
Basic、C、C++、VBS、VBAなどの言語を使用する。
だから、それらのユーザーが少ない学習コストで移行できれば、.NET用のアプリケーションを書く人が増えるはずだ、とMicrosoftの担当者が推測したことは容易に想像できる。ごぞんじのようにMicrosoftは、対応アプリケーションをたくさん作ってもらうことで地歩を築いてきた会社である。開発者をおざなりにすることはない。
しかし、Microsoftが忘れているのは、移行のコストのうちで言語の占める割合は決して大きくないということである。つまり、言語の移行という意味では、Javaへの移行だって決して難しくないのである。
.NETを扱うのに、VB.NETにするか、C#にするか、C++にするか、私はずっと考えあぐねている。こんなことで悩むのならば、全部、Javaで片付けた方がいいのではないかと思うことも多い。何といっても、現在のトレンドはJavaなのである。もし、.NETのためにC#が必須だったならば、私は迷わずC#で.NETのプログラムを書いただろう。
もちろん、Microsoftのメッセージは「Visual
Basicができるならば、VB.NETで…」ということになる。しかし、Microsoftの中途半端にC#に肩入れしているのを見ていると、VB.NETで大丈夫なのかという不安は拭えない。一方、その中途半端さは、C#に対する不信感にもつながる。C#は現時点でまったく使用されていない言語である。裁判問題には巻き込まれないとしても、普及の見込みが立たず、Visual
J++のように、あっさりと切り捨てられたりするのではないかと考えても不思議ではない。このようにフォーカスを喪失したどっちつかずのメッセージは、マーケティングには禁物である。
どこでも動くというのは便利だ。しかし、だからだめな場合もある
フォーカスの喪失は、どこでも動くはずだったJavaが失敗した理由の一つでもある。Javaも結局は自分のサーバーだけで動けばいいという条件を得ることで高性能と安定性が向上し、初めてサーバーサイドで成功したのである。
Microsoftもコモンランゲージランタイムを採用せずにC#に注力し、とにかく優れたものを早く出荷した方が賢明だったように思える。そして最後に次のようなメッセージを追加すればいい。「C#を習得すれば、Javaをおぼえるのも簡単です」あるいは「Javaを習得すれば、C#Javaをおぼえるのも簡単です」。Visual
BasicやVisual C++の開発者は、必然性さえあれば、迷わずにC#へ移行するのだから。
SQL Server2000とMSDE2000のパフォーマンスの違い
ひっそりとたたずむMSDE2000
私はMSDE2000というプロダクトがあるのを最近まで知らなかった。ちなみにSQL
Server 7と同等のエンジンを持つMSDE(以降、MSDE7)はMicrosoft Database Engineの略語だが、MSDE2000の方はMicrosoft
SQL Server 2000 Desktop Engineの略である。
MSDE2000がOffice XP Developerに付属し、再配布が可能だという情報を得たので、アップグレードしようかと、Office
XPの価格(オープン)をインターネットで調べていたら、MSDE2000はSQL Server 2000にも付属しており、しかもこちらも再配布可能であるということがわかった。
Office XP Developerは高価だが、Microsoftの開発製品のユーザーはアップグレード価格で購入することができる。MSDE2000が配布できるメリットは大きいので、SQL
Server2000を持っていないユーザーにはおすすめである。
SQL Server 2000のユーザーでもMSDE2000の存在に気づいていない人は多いのではないだろうか?
SQL Server2000の2枚組みCDROMのSQL Server 2000 Personal EditionのCDROMに収録されているのだが、自動的に起動するセットアップ画面からインストールすることはできない。しかし、\MSDEというフォルダにひっそりと納められている。
MSDE7がコマンドプロンプトベースのインストーラしかなかったのに対して、GUIのインストーラが用意されている。ただし、インストールフォルダをGUIベースで変更することはできない。
MSDE2000はワークロードガバナーによって、6つ以上のバッチが同時に実行された場合に、性能に制限が加えられる。6接続以上ではなく、6以上の同時バッチ処理であることに注意が必要である。
MSDE2000をSQL Server2000と比較する
繰り返して書くが、SQL Serverなど多くのデータベースサーバーは仕様許諾によって、ベンチマークの公開が禁止されている。そのため、計測結果はあくまで指標としてしか公開することができない。以前、SQL
Server 7とMSDE7を比較試験した状況とは、テストするコンピュータもOSも異なる。前回は、テスト用のクライアントアプリケーションとデータベースサーバーを同じコンピュータで実行していた。今回も同様にテストを開始したのだが、終盤になって試しに「WindowsでのSQL
Serverでの優先度を上げる」チェックボックスをチェックしたところ、SQL ServerとMSDE2000で極端に値が変ってしまった。あるテストでは、MSDEの方が100倍近く高速な結果になったのである。これは、MSDE2000が100倍高速になったわけではなくトリックがある。MSDE2000の方が優先度を上げた場合の優先割合が高いらしく、テスト用のクライアントアプリケーションの速度が極端に低下したのである。テスト結果は、各クライアントの待ち時間を測定するものだったため、クライアントアプリケーションの処理が低下することで、データベースサーバーへの負荷が減り、結果としてレスポンスが向上したのである。そのため、待ち時間は少ないが、処理件数も少ないという結果になってしまった。その反省をふまえて、今回のテストでは、クライアントとサーバーをネットワークで接続し、また、待ち時間だけでなく、処理件数も取り上げることにした。
待ち時間は処理件数か
実際の現場において、ユーザーが気にするのは負荷がかかった場合の処理件数ではなくて、待ち時間である。処理件数と待ち時間の関係は反比例の関係にあるように思えるが、それほどシンプルではない。たとえば、100人のユーザーが同時にアクセスし、1秒後に同時に結果を得た場合、1秒間の処理件数は100、待ち時間の合計は100秒、一人の平均待ち時間は1秒である。次に1/100ごとに100人のユーザーがアクセスし、1秒間で処理が終了した場合、1秒間の処理件数は100、待ち時間の合計は1秒、一人の平均待ち時間は1/100秒である。つまり、同じ、処理件数なのに、待ち時間は100倍変ってしまうのである。
テストツール
テストについては、前回使用したテストツールをそのまま使用した。一つはADOクライアントアプリケーションのテストをするADO多端末シミュレータ、もう一つはWebデータベースシステムの測定を行なうWeb多端末シミュレータである。Web多端末シミュレータでは、データベースへのアクセスはActve
Server PagesとADOを利用している。両方とも指定したクライアントの台数のActiveX.EXEコンポーネントをマルチスレッドで起動して、サーバーにアクセスし、多数接続を実現する。Webクライアントテストツールは、本誌2000,年6月号に収録しているので、ぜひ、追試をおこなってほしい。
これらのツールはクエリー実行時に各端末ごとに違う引数を自動的に指定する他、クエリーを実行するごとに引数の値をインクリメントする仕様になっている。これはデータベースサーバーのキャッシュを無効にするための配慮である。ただ、キャッシュに関しては同じ引数で同じテストを2回繰り返しても速くなることはないので、あまり、神経質になる必要はないのかもしれない。というか、傾向としては同じ引数でテストした2回目の方が遅いことも多かった。通常の中小企業の一年分程度のデータ量は用意しているのだが、この程度のレコード数ならば、キャッシュをを利用するよりも、正規に検索した方が速いのかもしれない。
テスト条件
一処理は4回のSELECT文の実行と各1回のUPDATE、INSERT、DELETE文の実行から構成されている。これらの処理は検索が必要なものは、すべてインデックスが使用されるようにデータベースを設計している。テストデータのようにレコード数が多く、また性能の評価が必要になるような場面ではすべてインデックスが使われるはずだと考えるからである。ゆえに、検索が瞬時に終了するような極少値の場合、グラフで差があるように見えても、それは微小な差であり、計測誤差の範囲である場合が多いことを前提に読んでいただきたい。もちろん、そのようなケースでは注釈を加える。
前述のように1台のコンピュータにクライアントテストツールをインストールし、別のコンピュータではデータベースサーバーのみ、WebのテストではさらにIIS5.0を使用してテストを行なった。他のコンピュータのネットワークトラフィックの影響を避けるため、2台のコンピュータはクロスケーブルで直結した。
また、確認のため、頻繁にSQL Server2000とMSDE2000のインストールとアンインストールを繰り返す必要があったたので、テストの効率から両者ともサービスバックは適用していない。
2つのテストパターン
テストパターンには次の2通りを用意した。
パターン1
指定したクライアント数をデータベースサーバーに接続し、同時に初回の処理を依頼し、結果が帰ってきたら、すぐに次の処理を要求する。テスト結果は各クライアントの一回の処理の平均待ち時間と処理件数を記録する。
パターン2
指定したクライアント数をデータベースサーバーに接続し、各クライアントが0.5秒の間隔を開けて最初の処理を依頼する。2度目以降の処理は1分間隔でおこなう。テスト結果は各クライアントの一回の処理の平均待ち時間を記録する。処理件数は接続数に応じて固定なので、記録する必要はない。
内容を読めばわかるように、パターン1は多数のクライアントを接続し、最大の負荷を与えるテストである。このテストでは負荷によるデータベースの性能の変化を知ることができる。ほとんどのテストがこのテスト方法で行なわれている。パターン2は、現実の使用状況を再現するためのものである。一分間に一回の処理(4回のSELECT文とUPDATE、INSERT、DELETE文を各一回)でもアクセスの頻度としては高めだが、これ以下だとテストにならないのでこのように設定した。この場合、例えば128接続のテストでは、128人のユーザーがいるモデルに近い結果になるが、同時に128の処理依頼があるとは限らないことに注意していただきたい。
ADOクライアントでは16接続以上でワークロードガバナの効果が確認できる
まず、パターン1のテスト結果を示す図1-A、図1-Bでは、MSDE2000のワークロードガバナの効果が16接続以上で、はっきりとあらわれている。
パターン2でのテストを示す図2では、結果は逆転してMSDE2000の方が高速な結果となったが、これは図1と比較して図2はスケールが1/10以下であり計測の誤差が大きく見えるからである。また、前述のように一分おきの処理依頼のため、必ずしも128のバッチ処理が同時に行なわれているとは限らず、ワークロードガバナの動作が限定されるからだと想像される。実際の結果は両方がほとんど瞬時に終了しているが、何回かの計測を繰り返しても常にMSDE2000がやや有利な結果になった。
Webクライアントでは128接続でも差がない
図3はWebクライアントでパターン1のテストを実行したものである。見ればわかるように差はほとんど見られない。図2のように処理時間が極少なわけでもなく、また同時アクセス数も接続数に応じて大きいはずなのに、どうしてワークロードガバナが動作しないのだろうか?
それはIISのコネクションプール機能がコネクション数を制限することで同時実行数が抑制し、ワークロードガバナを無効化していることが考えられる。Webクライアントのケースでは、データベースサーバーに接続するクライアントは、COMコンポーネントであるADOのホストアプリケーションであるIISである。IISはWebクライアントからの接続があるごとに、データベースサーバーに接続するのではなく、Webクライアントが接続を切断しても、データベースへの接続ほ確保しておき、それを次のWebクライアントのために確保しておく。これがコネクションプールである。接続してデータベースサーバーにログインするという作業は、必ずしも負荷の小さな処理ではないので、それをIISが最適化するわけである。
IISのコネクションプール機能がワークロードガバナをキャンセルする
結果的に、例えばWebクライアントが同時に10のバッチ処理を依頼しても、IISは、それを同時に10の要求をデータベースサーバーに送るのではなく、2つずつ5回に分割して送るような処理をしていることが考えられる。このように最適化されれば、ワークロードガバナは動作することなく、処理を実行できることになる。、
図1-Bを見るとわかるように、ワークロードガバナは処理の同時実行数が増えることで、データベースエンジン自体の能力を制限している。しかし、IISを経由してWebアプリケーションを使用することで、そのような制限が回避できるのである。同時実行数が減っても、処理に使用されるCPUなどのリソースの能力は変らないから、性能が大きく変ることはない。作業をする人が1人の受付で、窓口の数が5つでも10でも大差はないのと同様である。ただ、窓口の数が少ないと、たまたま全部の窓口に処理に時間のかかる人がならんだ場合、その後ろで待っている処理に時間のかからない人も、その間待たされることになるので、不公平が発生し待ち時間の合計が大きくなる。しかし、それはWebクライアントとADOクライアントを比較した場合の話であって、Webクライアントの場合、SQL
Server2000もMSDE2000も同じ窓口の数に限定されるのだから、二者の間に差が出るわけではない。
ただ、同時に128処理ならばMSDE2000はSQL Server2000と同等の性能が確保できているが、例えば1000処理だったら、IISはコネクションプールを増やすだろうから、二者に差が出ることは想像できる。しかし、同時に128処理とは、同時に同じWebサイトを閲覧している人が数百人はいる勘定になる。それは、かなりの大規模サイトだということができる。
MSDE2000の場合、同時実行数が64を超えるとWebアプリケーションの方が性能がいい
WebクライアントではSQL Server 2000とMSDE2000の差がでないという図3のグラフを、図1のグラフに重ね合わせることで面白い事実を発見することができる(図4)。信じられないことに、64接続以上では、待ち時間、処理件数ともWebクライアントの結果がADOクライアントの結果を上回るのである。この結果の意外性を際立たせるために、SQL
Server 2000の結果を重ね合わせたものを図5として紹介する。
通常、図5のようにWebクライアントはADOクライアントと比較すると、すべての接続数においてなり劣るものである。これは、Webクライアントの場合、途中に無駄な接続が入るのだから当然である。しかし、図4のMSDEのWebクライアントのケースでは、接続数が増えてもワークロードガバナによる制限が抑制されるため、性能の劣化しているADOクライアント以上のパフォーマンスが出るのである。
ならばスレッド数を制限すれば、ADOクライアントだって…?
ならば、バッチの同時実行数を制限することで、ADOクライアントの場合も多数接続時の性能も確保できるはずである。MSDE2000のmax
worker threadsオプションを小さく設定すれば、同時に実行されるバッチの数が制限され、現在よりは良好な結果が期待できるはずである。max
worker threadsオプションの設定可能最小値は、ドキュメントによって差がある。ある資料では10になっているが、別の資料では32である。実際に試してみたところ、Enetrprise
ManagerでもTransact SQLでも32以下に設定することはできなかった。そして32に設定した状態で、図1のテストをおこなってみたが、結果は改善されなかった。このあたりについては、いい方法もあるように思えるが、今回は時間に追われていて、それ以上の追求はできなかった。何か、いい方法が見つかったら報告したい。
まとめ
ADOを使用した通常のクライアントサーバーアプリケーションの場合、アクセス頻度にもよるが、最大同時実行数が16でユーザー数的には100人くらいまでならば、再配布が可能なMSDE2000でもSQL
Server2000と遜色ない結果を出せるだろう。
Webアプリケーションならば、最大同時実行数が128でも、MSDE2000はSQL
Server2000と同等のパフォーマンスが確保できる。これもアクセス頻度によるが、1人のユーザーが1分に1度程度の処理(4回のSELECT文とUPDATE 、INSERT、DELETE文をそれぞれ1回ずつ)ならば、数百人規模のユーザーまでMSDE2000とSQL
Server2000の差が出ないことを期待できるだろう。ただ、あくまでもSQL Server2000とMSDE2000の間に差がないだけであって、それが十分な性能かどうかは、別途、判断する必要があるのは、言うまでもない。