ここでは(b)仕入データ更新を行うMapReduce処理1が、どこまでスケールアウトするかを調べた。100万件または1000万件のデータを使い、ノード数を変えて性能を測定している。

 結果を図3に示す。データが1000万件の場合、性能はノード数にほぼ比例して増加した。12ノードのときの性能は7万9967件/秒である。1ノード当たりの性能は約7000件/秒でノード数が変化してもほぼ一定だった。

図3●Hadoopの処理性能<br>スレーブノード数を変化させた場合、100万件のデータの場合はノード数を増加させてもスループットがわずかしか向上しなかったが、1000万件のデータの場合はノード数にほぼ比例してスループットが向上した
図3●Hadoopの処理性
スレーブノード数を変化させた場合、100万件のデータの場合はノード数を増加させてもスループットがわずかしか向上しなかったが、1000万件のデータの場合はノード数にほぼ比例してスループットが向上した
[画像のクリックで拡大表示]

 12ノードの場合の性能は、処理時間にすると2分5秒である。実際にはこれにインポートなどの処理時間がかかるが、数分で終わるだろう。筆者らが開発に携わったRDBMSの実システムでは、約100万件の仕入データの買掛計上処理に約1時間を要していた。それに比べると100倍近い性能になる。

 もちろん、検証環境では「実データより性能が得られやすい分布のデータを使用した」「検証用のプログラムは実システムと比べると処理が簡略化されている」などの違いはあるが、ケタ違いの性能が出たことは確かだ。

 また、分散処理システムの中には数ノード程度で性能が頭打ちになるものもあるが、Hadoopは10ノード以上でも性能が向上し、頭打ちになる傾向は全くなかった。

 一方、データ量が100万件の場合はノード数を増やしても、性能がわずかしか向上しなかった。12ノードのときの性能は1万5697件/秒である。

 原因は、テストプログラムを格納したJARファイルの各スレーブノードへのコピー、各ノードでのJava VMの起動、ジョブ自体の初期化といったオーバーヘッドが、1000万件のテストよりも相対的に大きいためと考えられる。

なぜデータ量多いと性能向上するか

 では、データ量が1000万件の場合、なぜノード数にほぼ比例するような性能向上が実現するのだろうか。RDBMSとの比較によって説明しよう。

 RDBMSのシステムで特に性能を考慮せずにバッチを作ると、「必要なデータを取り出して、演算処理を実行し、結果を書き戻す」という一連の処理をデータ件数だけ繰り返すものになりがちだ。これをあまり工夫せずに実行すると、ディスクI/Oなど計算以外の処理に大きなリソースが割かれる。

 一方、Hadoopでは「必要なデータを一括して呼び出し、演算を並列分散処理で実行した後、結果を一括して書き戻す」という処理が基本である。

 誤解を恐れずに言えば、RDBMSのシステムも、オーバーヘッドを減らすように工夫すれば性能は向上する。RDBMSの熟練者から見ると「Hadoopが速いのは、比較したRDBMSのプログラムに問題があるため」にすぎない。

 しかし、RDBMSのプログラムで性能を向上させるには、エンジニアに相当な経験と能力が要求される。

 それに対してHadoopでは、バッチ処理で良好な性能を得るための仕組みを活用して、エンジニアが分散処理プログラムを作成できる利点がある。