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のお仕事),作業項目と工数を見積もって作業を開始 |
[画像のクリックで拡大表示] |