MapReduce: A major step backwards
"A major step backwards"は"重大な退化"とでも訳せばいいのかな？"MapReduce: A major step backwards"という記事が話題になっているようだ。続編も出ている。書いた人の1人はIngresやPostgresのmain architectだったらしい。
データベースコミュニティにとって、MapReduceは以下のようなものらしい。
- プログラミングパラダイムの非常に大きな退行である。(A giant step backward in the programming paradigm for large-scale data intensive applications)
- Indexingの代わりに総当たりを使う場合には準最適解である。(A sub-optimal implementation, in that it uses brute force instead of indexing)
- ちっとも革新的な所がない。25年前に開発された技術を実装したものでしかない。(Not novel at all -- it represents a specific implementation of well known techniques developed nearly 25 years ago)
- 現代のDBMSなら当たり前にある機能の多くが欠けている。 (Missing most of the features that are routinely included in current DBMS)
- DBMSユーザが使っている全てのツールと互換性がない。(Incompatible with all of the tools DBMS users have come to depend on)
英語力には自信がないので、原文も括弧内に入れておいた。
MapReduceは使ったことがないし、RDBもあまり使い込んだことはないんだけれど、RDBの便利な機能は構造化されていないデータに対しては大して役に立たないだろうという印象を受ける。そして、自然言語は自明な構造を持たない。
Googleは自然言語を大量に扱う必要があって、そのために並列処理システムが必要だった。しかし、2000年代初頭頃にそこまで高度な並列処理が行えるDBMSはオープンソースでは存在しなかったので、自社で並列処理システムを開発するか、他社から調達する必要があった。この場合、自社で開発した方が良いだろうという判断は納得できるものだろうと思う。
さて、GoogleにとってMapReduceは必然だったとして、我々はHadoop（余談だがHadoopはApache Topプロジェクトへ昇格したそうだ）なりなんなりを使ってMapReduce的なシステムを使うべきだろうか。
もちろん、解くべき問題によるけれど、大規模非構造化データの処理をするという前提で自分が判断を任せられたら、Hadoopを使うだろうと思う。理由としては、
- 機能が少ない分、改造がしやすそう。改造がしやすい方が、問題が起こったときに取り得る選択肢が増える。
- 並列計算をすることだけが目的なので、並列処理の性能はスケールするだろうし、想定以上のスケールで動かそうとして性能が出なかった場合、upstreamに相談したら良い知恵を出してくれそう。
の2つぐらい。結局、問題が起こったときに自分で対処出来そうなのはどっちか、というのが判断基準かしら。
元エントリのコメント欄を見たところ、unstructured/semi-structured dataをどうするんだ、というコメントがいっぱいついてた。しかし今のところ次のエントリにはそれに対する返答はないようだ。
