昔、某ＤＢＭＳのベンダーが、チューニングして、複数のパラメータを弄くり回しては、「速くならないなあ、、、」と言って、いくども、複数のパラメータを弄くり回していました。
　そして、とうとう、僕のクライアントに対して、以下のように言いました。

　　もう、チューニングの限界です。あとは、アプリケーション・プログラムが原因でしょう。

　
　で、クライアントが僕に診断を依頼したので、僕は、或るいくつかの数値を採取してもらったら、どうすれば良いか、という対応が、直ぐに浮かびました。僕は、或る （１つの） パラメータの数値を ５０％にしました。そしたら、「２倍」 速くなりました。
　としたら、ベンダーが言った「もう、チューニングの限界です」というのは、なんだったんでしょうね （謎）。

　複数のパラメータを弄くり回して、数倍のパフォーマンスが出る、というのは、「（環境を設定する） 初期条件が悪かった」のであって、チューニングとは云わない、と僕は思います。パフォーマンスを向上する （internals として用意されている） パラメータは、数少ない。
　（internals として用意されている） パラメータを調整して、パフォーマンスを向上できる程度というのは、せいぜい、１０％ から ２０％ です。

　適切なパフォーマンスを実現するのは、「データ設計 （正当なデータ構造）」です。どうも、この大切な点を、ＤＢＡたちは、無視しているようです （苦笑）。

　ベンダーが、「もう、チューニングの限界です」と言ったら、僕は、かならず、以下のように訊きます。

　　　　　　「限界」という判断は、どのような数値を根拠にしていますか。

　
　この点を、まともに返事できたＳＥは、いなかった（苦笑）。正解は、「ディスクの seek-time ＋α」です。αは、ＤＢＭＳのスループットを考慮します。

　現代のマシーンは、scalability が、単純に、かつ、廉価に、実現できる環境ですから、昔ほど、チューニングの技法が論点になるとは思えないのですが、、、そうであれば、逆に、「データ設計」が論点になるはずなのですが、どうしてか、そうならない （謎）。

　最近、WINDOWS(2000) 上で、10,000,000件のデータを対象にして、曖昧検索 （複合検索条件） をして、１秒以内のレスポンスを、（僕が指導した） 或るエンドユーザが実現したのですが、チューニングしたって、この速さを実現することはできないでしょう。
　僕は自慢しているのではなくて、こんなテクニックは、エンドユーザでも、できる、ということを言いたいのです。とすれば、データ設計のほうが、ますます、重視されても良いはずなのですが、どうしてか、そうならない、、、。

　石炭とダイヤモンドは、構成項目が同じなのですが、石炭を、いくら、擦っても、ダイヤモンドにはならない。粗悪なデータ構造を、そのままにして、ＲＤＢをチューニングしても、実現できるパフォーマンスなど高が知れている。

　

　（2004年12月 1日）