MapReduceとパラレルRDBでベンチマーク対決、勝者はなんとRDB!

2009年5月 1日はてなブックマーク del.icio.us Twitter

大量のデータを処理する手法として登場したMapReduce。クラウドに対応した分散処理の定番として話題に上ることが増えてきました。

A Comparison of Approaches to Large-Scale Data Analysis(PDF)

MapReduceは、大量のデータを分割し、分割したデータを分散したノードに投げてノードごとに処理を実行、結果を集約して最終的な答えを求める、といった手法です。

しかしMapReduceが登場する以前から商用レベルで使われていた分散処理手法があります。データを分散したデータベースに格納し処理を行うパラレル・リレーショナルデータベース(パラレルRDB)がその1つです。

パラレルRDBは、データを複数のデータベースに分散して配置、データベースごとに処理を行い、結果を求める手法です。中央に共有メモリを配置するなどの方法で分散したデータベース同士の連携を行うことが一般的です。

ではパラレル・リレーショナルデータベースはMapReduceより遅いのか? 劣るのか? 両者を実際にベンチマークを走らせて比較調査したのが、論文「A Comparison of Approaches to Large-Scale Data Analysis」(PDF)です。

比較の結論は、この論文を紹介してくれたSAPのPaul Hofmann氏のブログ「Parallel DBs faster than Google's MapReduce」から引用しましょう。

The good news is, parallel databases are still 3 to 6 times (on the average) faster than MapReduce. RDBMS is better with regards to speed, query automation, less code to implement per task, etc.
良い知らせとして、パラレルデータベースは平均で3倍から6倍、MapReduceよりも高速だった。パラレルデータベースは、速度、問い合わせの自動化、タスクごとに必要な記述も少ないといった点で優れていた。

一方で、MapReduceのほうが優れていた点もあったようです。

The paper also shows that RDBMS has disadvantages compared to MapReduce like lack of ease of setup and slow when importing a lot of data.
論文では、セットアップの難しさ、そして大量のデータのインポートに時間がかかるといった点が、MapReduceと比較してデータベースの課題として指摘している

ベンチマークはさまざまな処理に対して行われましたが、その中の1つのグラフを論文から引用します。

fig

上記のグラフは、1TBのデータからgrep処理で特定の文字列を抜き出す処理にかかった時間を示しています。パラレルRDBMSとして、Verticaと、某ベンダーの商用製品(DBMS-X)が用いられています。また論文によると、パラレル・リレーショナルデータベースではデータ圧縮機能を用いたとのことです(そのほうが約2倍の性能がでるとのこと)。

なぜパラレルRDBの方が速かったのか。論文では、Bツリーのインデックスによる高速化、最新のストレージ機構、圧縮機能、洗練された並列処理などを挙げています。また、「GoogleバージョンのMapReduceはHadoopより高速だと噂されているが、入手はできなかった」とも書いています。

パラレル・リレーショナルデータベースが分散環境でうまく稼働するには、前提条件として各ノードの性能がある程度高く、かつ信頼性が高い場合でしょう。その前提さえ揃えば、業務アプリケーションのプラットフォームとしては、リレーショナルデータベースというのはクラウドのような環境でも十分な競争力を持っている、ということを示しているのではないでしょうか。

またクラウドには実は、ノードごとにそれなりの性能と信頼性を確保しリレーショナルデータベースを走らせるのに向いたクラウドや、低い性能のノードを大量に集めて並列処理を得意としたクラウドなど、それぞれの特徴があるはずです。アプリケーションを実装する場合にはそれにあったアーキテクチャのクラウドを選ぶ、といったことが必要になってくるのでしょう。

関連記事 on Publickey

関連記事on the Web


次の記事≫ いま起きているWeb標準の進化、HTML5、CSS3、JavaScript 2.0
前の記事≪ Google Book Searchの和解について、米司法省が独占禁止法違反の疑いで調査を開始

Loading...

Blogger in Chief

photo of jniino Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。新しいオンラインメディアの可能性を追求しています。
詳しいプロフィール

Publickeyの情報をTwitterでフォローしませんか?: @publickey




アクセスランキング - 過去7日間

  1. Flashがオープンソース化できず、Fire…
  2. Flashは生き残れるか? - Public…
  3. 仮想化エバンジェリスト「タカハシ」氏のショー…
  4. 英MI5、「中国のノベルティにはトロイの木馬…
  5. クラウドアプリをドラッグ&ドロップで開発、セ…
  6. Amazonクラウドの内部アーキテクチャを推…
  7. アドビCTOのケビン・リンチ氏「いつかはHT…
  8. JavaScriptをGPUで高速化する試み…
  9. クラウドとアプリマーケットの組み合わせがソフ…
  10. グーグルの最新のデータセンターは非常識なほど…
  11. 英国政府、独自のクラウドを計画。オープンソー…
  12. JavaScriptが第一級のプログラミング…
  13. 全部見て5つだけ選びました! グーグルが公開…
  14. アイルランド政府はクラウド利用を警告、米空軍…
  15. 2000年のドットコムバブルを除けば、シリコ…

人気エントリ - はてなブックマーク

アーカイブ  (最新記事10)

バックナンバー

2010年2月
2010年1月
2009年12月
2009年11月
2009年10月
2009年9月
2009年8月
2009年7月
2009年6月
2009年5月
2009年4月
2009年3月
2009年2月

Trackbacks (TrackbackURL:http://www.publickey.jp/mt/mt-tb.cgi/104)

  • (トラックバックは承認後に掲載されます)

Comments