前編では，OSS推進フォーラム・開発WGの立上げ時を中心にお話をしてきました。後編では実際にデータベースの評価がどうなったのかについてお話したいと思います。

DBTとの格闘

　OSDL DBT-1を利用するようになった経緯は前編でお話しましたが，さて実際に使ってみると・・・コンパイルエラーが続出，必要なファイルが足りないなど，波乱含みの展開になりました。さすがオープンソースと当初は軽く考えていましたが，始めてみると意外と深みにはまっていきました。

　DBT-1は元々SAP-DB（現在のMySQL MAX-DB）用にストアドプロシージャベースで開発されていましたが，PostgreSQL用に移植された際にいくつかのファイルが落ちた状態でした。フェーズ１では，何とかこれをMAX-DB最新版とPostgreSQL最新版に対応させました。

　次に問題と思われたのはストアドプロシージャです。DBMSへの依存性が高く，ストアドプロシージャの性能測定を行っているのでは？といった意見も出ましたので，これを無くすることにしました。

　フェーズ２では，トランザクションロジックをＣで書き換え，MySQLとPostgreSQL版を作成しました。

　DBMSのインターフェースはODBCを利用しています。ODBCは遅いと言った意見もありますが，ODBCであれば接続できるDBMSが広がると思い，敢えてこれを取り入れています。他のDBMSでも比較的移植がし易くなっているはずです。逆に，スピード狂の方はぜひDBMS固有のネイティブ接続にトライしてください。

　実際に測定を行ってみると，DBMSのチューニングが非常に効果があることが判ります。

　図はMySQLの例ですが，遅いクエリを特定し（ここでは検索）これに対してバッファサイズを拡張した場合の結果を示しています。評価基準があってどれくらい効果があるのかがハッキリ示せた例です。もちろんこれだけがチューニングではありませんし，測定環境に影響を受けることも忘れてはなりません。ただ，これから利用しようとする環境が果たしてどれくらいの潜在力があるのかは推測できると思います。

MySQLでの遅いクエリのチューニング前と後