Enterprise Solution ForumMicrosoft SQL Server Solution Seminar受講記として
インサイドインフォメーションと最適化
秋月巌 AKIZUKI, Iwao
エンジニアによるプロダクトの品質差
ニューテクノロジーの発表ラッシュが一段落して、なんとかアプリケーションを動かすことができるようになり、最近は、最適化のことばかり考えている。ただ動けばいいということばかりではなく、よりよく動くことに注意を払うようになってきたからだろう。
最適化といっても範囲は広い。コーディングの最適化から、ユーザーインターフェイスの最適化まで、すぐれたプログラムを作成するために留意するべきポイントは限りなく考えられる。それだからこそ、同じ仕様書から開発してもエンジニアによって完成するプログラムに大きな差が出てくるのである。
最適化によって失うもの
私は最適化を奨励しているのではない。最適化は余分なコストが発生するものだから、できる限り行なわないというのが私の方針である。大抵の場合、ユーザーは最適化されたプログラムよりも、コストが低く、確実に動作するプログラムを要求しているものだ。最適化は品質の向上につながるが、それが顧客（ユーザー）が要求するものでないならば、エンジニアの自己満足にすぎない。
というのは、以前のようにあらゆる部分で最適化を図るのがユーザーの便宜につながっていた頃とは違い、巨大マシンパワーを安価に利用できる今日では、マシンパワーに依存する方がプログラマのパワーに依存するよりもコストを削減できるからである。たとえば、Visual BasicのようなRADツールの使用は、あくまで十分なマシンパワーが確保できるという前提で使用されるものである。もし、コーディングレベルによる最高レベルの最適化が必要ならば、プログラムはC言語（あるいはアセンブラ）で、オブジェクトもコンポーネントも使うことなく開発することが要求される。つまり、ニューテクノロジーと呼ばれるものの多くは、プログラム実行の最適性を犠牲にしながら、提供されているのである。
新しいテクノロジーの導入を決定する要件
もし、新しいテクノロジーが、次のプロジェクトを展開するのに有効なものならば、それは検討するべきだろう。導入の前には、必ず、十分な調査を実施するか、民間の調査機関（たとえば本誌やPCDN）の報告を参照することが必要になる。だが、十分に調査したつもりでも、開発のスタート後、あるいは運用後に、そのテクノロジーが使いものにならないことが発覚する可能性がある。その場合、既存のテクノロジーで代替えするプランを立てておくことが要求される。もし、実績のあるテクノロジーで置き換えることができないようなケースならば、新しいテクノロジーの導入は見送った方がよい。でないと、あなたのキャリアに傷がつくことになるかもしれない。
つまり、最適化を行なわない場合でも、そのための余地は常に残しておく必要があるということである。システム開発がビジネスである以上、プロダクトの品質と開発コストは常にハカリにかけられる。ユーザーを満足させつつ、どこまでコストの削減をはかれるかが優れたシステムマネージャが追求する用件になる。しかし、もちろん、コストの削減がユーザーの利益を損なうようなことになってはならない。
最適化とスキル
ビジネスサイドからみたとき、実は最適化にはまた別の問題点がある。的確な最適化をはかるためにはシステムの動作原理を十分に理解しなければならない。そのようなスキルの高いエンジニアはコストが高く、育てるのも簡単ではない。また、ある種の資質も要求される。
ビジュアルプログラミングを始めとして、時代の進歩がシステム開発に与えた影響は大きい。昔はどんな形だろうが一丁のハサミで切り抜いていたが、現在は丸を切るハサミや、三角を切るハサミなど用途別の道具がいろいろと用意されている状況だと思えばよい。
ここで、たとえば、少し突起物のある丸を切り抜きたいという要求が発生したとしよう。このような要求が多い場合には、メーカーは“突起物のある丸”型をした刃を備えたハサミを用意してくる。しかし、このハサミは突起物の形状だとか大きさだとかを最初に設定しなければならず、大変使いにくいうえ、よく壊れるのである。ここは、やはり、昔ながらのハサミを使うのが賢明というものだろう。しかし、丸を切るハサミの使い方にばかりなれた職工は、昔のハサミで丸を切ることに慣れていない。
セミナーとインサイドインフォメーション
私は以前、xBaseで大量のプログラムを作成していた。普及しはじめたばかりの、Intel 80286プロセッサを使用した台湾製のコンピュータだ。このマシンはすばらしく高速で動作したが、開発に使用していたソフトウェアであるdBaseVは中間コードにコンパイルする機能すらない完全なインタープリタであった。この状況では1行といえども無駄なコードを記述することは許されない。月日は流れ、伝説的なパフォーマンスを誇ったFoxBase（現在はMicrosoftに買収されたが、当時はFox Software社製）を入手することで、コードの記述法は大きく変わった。中間コードでコンパイルすることにより、圧倒的な実行速度の向上がはかられていたからである。必要なエラーハンドラを記述しても実用性を損なうことはなくなった。しかし、当時の1MBのメモリではインデックスを使わないテーブルの検索速度には限界があり、苦心の最適化をする必要があった。
こんなことを書いているのは、先日、Microsoftが主催するMicrosoft SQL Server Solution Seminarに出席し、Microsoft SQL Serverの最適化に関して多くの啓示をうけたからである。このセミナーは300人ほどの受講者を対象にしたセミナーである。
カンファレンスとセミナーの違い
最近、頻繁に開催されるメーカー系のカンファレンスの類に私はほとんど出席しない。時間を割きコストを割いて新製品の宣伝を聞いてもあまり意味がないし、壇上で話している人が米国のドキュメントの翻訳を棒読みするケースが多いからだ。今回は、セミナーと銘打っていることと対象のプロダクトをMicrosoft SQL Serverに限定していることから出席したのだが、いくつかのセッションは有意義な内容だった。
私自身セミナーの講師を務めている関係で、小人数を対象にしたセミナーには受講者としてよく出席する。そのようなセミナーは大抵、講師も厳選されており、出席する意味のあるコースが多い。それまで見当もつかなかったことに気づかされたりする。
今回のMicrosoft SQL Server Solution Seminarは受講者が300人。もちろん、ひとり一台のマシン環境はないし、後ろの席に座るとプロジェクターの画像も見にくいなど不都合も多い。それはともかく、私が非常に納得したのは、最後のセッションでマイクロソフト株式会社の井口氏が講演した「SQL Serverトラブルシューティング」についてである。氏はマイクロソフト株式会社でコンサルティング業務に従事しているそうだが、さすがにSQL Serverのインサイド情報を熟知している。タイトルは「トラブルシューティング」だが、SQL Serverの内部動作に関する説明には最適化に関する多くのヒントが隠されていた。
公開されていない内部動作に関する情報
たとえば、「RDOなどのレコードセットはtmpdbテーブルを使用する」と聞けば、「RDOを使用する場合にはtmpdbテーブルをメモリ上に作成しよう」とか、あるいは「レコードセットを使用するのはやめよう」だとかいった判断が可能になる。このような知識が最初に与えられていなければ、やみくもにチューニングを施すか、あるいはオーバーヘッドの原因になる部分をひとつひとつつぶしていかなくてはいけない。問題なのは、このようなSQL Serverの内部動作に関する資料が一般には公開されていないことである。
井口氏が用意してきた材料は与えられた時間内で説明するには多すぎたらしく、配布された資料の最後までは説明が進まなかった。説明が割愛された部分にも興味深いポイントがあり、まったく残念である。結局、このセッションは終了時間が制限時間をオーバーしたために、質疑応答の時間も用意されなかった。
オプティマイザの働き
Microsoft SQL Serverのように複雑なアプリケーションになると、システムの内部で判断し、実行する処理の量が膨大になる。ユーザーはそのような内部的な動作を気にせずに、公開されたインターフェイスだけを使用していれば、十分に有益な結果が得られるはずである。
つまり、SQLデータベースのインターフェイスであるSQL文を渡せば、必要な結果が十分なパフォーマンスで得られるのである。しかし、十分なパフォーマンスでは足りず、そのマシンの最大のパフォーマンスが要求されるような場面もある。
Microsoft SQL Serverにはオプティマイザという機能が内蔵されている（Jetデータベースエンジンにもオプティマイザは内蔵されており、その原形はFox Softwareのエンジニアが開発したものだ）。オプティマイザはその名の通り、最適化を実行するプログラムである。ユーザーが発行したSQL文を解析し、どのような検索方法を実行すれば、もっとも効率よく結果を取得できるか判断するプログラムである。
オプティマイザは主にインデックスの使用の有効無効を判断する。つまり、データベースシステムの最適化を行なう際には、オプティマイザがどのような判断するかを考えながらSQL文を記述する必要がある。しかし、オプティマイザの判断の基準はマニュアルには十分に記述されていない。結局、試行したりベンチで計ったりしながらパフォーマンスのチューニングをはからねばならない。
昔と今と...
xBaseのようなISAMのデータベースを使用する方法では、テーブルのリレーションも、インデックスを使用するか否かの選択も、すべてはプログラミングによって行なっていた。現在の高度で複雑化したRDBMSでプログラムを作る場合には、RDBMSが提供するリレーション機能を利用したり、SQL文の記述を工夫することで、それらを実現する。
適切なSQL文を書くためには、RDBMSの内部動作を知ることが不可欠になる。私たち今日の開発者は、それらのインサイドインフォメーションを得るため、積極的に、このようなメーカーが主催するセミナーに出席すべきなのだろうか。
決して安いとはいえない費用を考えると、結論を出すのはむずかしい。
Microsoft SQL Server Solution Seminar セッション概要
ビジネスアプリケーションもしくはシステム開発を担当しているプログラマを対象として、97年10月28・29日の2日間にわたって東京（大東京火災新宿ビル）にて開催された
1日目 SQL Server Enterprise Edition 6.5からSQL Server 7.0へのロードマップ Universal Data Access概説 OLE DB/ADOと既存技術（DAO，ODBC/RDO）との使い分け Visual BasicによるAdvanced SQL Server Programming Visual BasicとRDOの組み合わせでSQL Serverを利用するビジネスアプリケーションを開発する実例解説 Visual Data Toolsによるクエリデザインとストアドプロシージャ開発 開発者向けのデータベース統合開発管理ツールによるデータベースアプリケーションの作成 プログラムからのSQL Server管理技法 DMO（分散処理管理オブジェクト）の利用によるSQL Server管理 SQL Serverパフォーマンス＆チューニング 2日目 IISとSQL Serverの連携による分散アプリケーションの展開 Cluster Serverを利用した堅牢なデータサーバーの構築 データサービス層にCluster Serverを導入した3階層モデルのアプリケーション／システム構築について ビジネスアプリケーション開発事例紹介〜他DBMSからSQL Serverへの移行 株式会社NTCの事例 BackOfficeロゴ取得のためのステップと対応ソフトウェア開発ツールの紹介 Synon Obsydianの紹介 BackOffice Small Bussiness Server 4.0紹介 SQL Serverトラブルシューティング
VB Magazine ライブラリ | Visual Basicコースホームページ
int21 ホームページ | PCDN ホームページ