PR

 OSSの性能・信頼性評価プロジェクトの裏話,トリは私,日本ヒューレット・パッカードの後藤宏が務めさせていただきます。

動くけどととてつもなく遅い!

 私が担当したのは,ベンチマーク・プログラムDBT-3の,MySQLへの移植です。DBT-3は,The Linux Foundation(旧OSDL)が開発した,インターネット書籍販売サイトを想定したベンチマークです。

 今回の移植作業は結構大変でした。そもそもDBT-3はPostgreSQLに実装されている機能を多分に意識したベンチマーク・テスト・プログラムだったのですね。「動くけどとてつもなく遅い!」と移植担当エンジニアの悲鳴。「これは大変だぞ…」というのが,本プロジェクトの面々の正直な気持ちでした。

 まずはデータを入れなければ始まりません。入れるだけならなんら問題ないのですが,スクリプトを見ていくと索引作成後,データのロードを行っています。基となっているTPC-HTMでは,主キー,外部キーの定義すらありませんが,DBT-3では,例えば最も件数の多い事実表のLineitem表に,以下のように主キー,複合索引含め,10個も索引の作成を指定しているのです。

 索引が多いのは,より実システムに近いベンチマーク・プログラムということですから,取り除くわけにはいかないのです。このこだわりがなければTPC-Hでより性能を出すことに焦点を当てればいいわけですから。技術評価TFでもこのことを踏まえて検討されたわけです。そもそも主キーがないのはもってのほかですが,索引を作成しない実装などお目にかかったことはありません(もしかすると性能重視であるかもしれませんが,であればRDBMSを使わなくてもいいのでは,と考えてしまいます)。

気がつけば深夜

 ところで,索引を先に作成した場合と,データロード後に作成した場合でとても時間が異なります。スケールファクタが2(たったの6GBですよ)で,3時間が30分です。ちなみにPostgreSQLは7分ですね。MySQLの実装によるのでしょうが,ここは他のRDMBSとの比較が問題でDBT-3を「移植」することが大前提。10社を超えるOSSの部会でも侃侃諤諤(決して喧喧囂囂ではありませんので念のため),「そもそも性能を出す手法を提示するのではなく,比較可能なベンチマークを提示することが目的だよね」という,プロジェクトリーダー鈴木友峰氏のもっともなお話で振り出しに戻った次第です。

 なんとこの日は夕方4時に始めた定例会が,気付けば10時を廻っているではありませんか。途中休憩も一度しか取らなかったような…。終始こんな雰囲気の中で行われた移植作業でした。

 この索引問題,データロードのみならず,パワーテストでも影響しているようで,図1が示すようにPostgreSQLと傾向が異なるのです。この図ではバッファの大きさによるMySQLに議論が及んでいますが,両RDBMSを比較しても傾向は異なります。

 なお,この謎解きはさらに分析が必要です。皆さんのお力添えをお願いいたします。

 次回はEXPLAINについてお話しします。

図1●発表会時の資料よりパワーテスト時の結果一覧


[画像のクリックで拡大表示]
図2●発表会時の資料よりロードテストの結果一覧


[画像のクリックで拡大表示]
図3●少ないメンバーとまだまだ蓄積のない情報とを効率よく共有するため,社内にWikiを用意(さすがOSSのお仕事),作業項目と工数を見積もって作業を開始


[画像のクリックで拡大表示]