昨日(9/30)の夕方、私は「SQLに対するMySQLのように、NoSQLに対するMongoDBにはよくない面がある」とツイートをした。あいにくそのツイートには説明が欠けていた。とはいえ1つのツイートに全ての必要な説明を含むことはできないだろうから、この記事で説明しよう。ツイートへの返事として受け取ったいくつかの疑問に答えられればと思う。
まず最初に、私は多言語永続化の考え方に賛同はするが、NoSQLの熱狂的支持者ではないということを知っておいてほしい。これはNoSQLを「Not only SQL(SQLだけじゃない)」と読んでいる人ならおかしいと思うかもしれない。私は、SQLは最悪でSQLを使わないと考えることから大きな恩恵を受けているNoSQLシステムがあるはずだと信じている。言い換えれば、「not using SQL(SQLを使わない)」をその最大の利点としているということであり、MongoDBはその一つだというのが私の考えだ。
しかし、私がNoSQLが好きではないからと言って、MySQLが好きであるべきだろうか？そうではない。私から見ると、人々がSQLに関して問題だと思っている多くのことが、実はMySQLの問題であるという点で、MySQLはSQLに多大な損害を与えている。一番重大な例としては、nested loop joinしかサポートしていないため、MySQLはジョインが苦手だということだ。他の多くのSQLデータベースは、ハッシュジョインあるいはソート・マージジョインアルゴリズムが実装されており、これらはどちらも小さすぎないデータセットに対してはよいパフォーマンスが出る。MySQLが広く使われていること(「世界で最も人気のあるオープンソースデータベース」)を考えると、多くの人が「ジョインが遅いから」という理由でSQLから離れていっているのは、MySQLの実装上の制限が人々をNoSQLに向かわせている、と言ってしまってもこじつけではないだろう。
ここでMongoDBを見てみよう。MongoDBとMySQLの競合については、「MongoDBはWebスケールだ」という素晴らしいビデオにはっきりと描かれている。一方で、MongoDBは「最高のNoSQLデータベース」であるとすら主張しており、これは「世界で最も人気のあるオープンソースデータベース」と似ていると思わないだろうか？かと思えば、MongoDBはその主張である「Webスケール」をかなえることができずに多くの人をがっかりさせている(例えばバージョン2.2までのGlobal write lock)。
私に先ほどのツイートをさせたもう一つの理由は、Gwen (Chen) Shapira氏(彼女はOracle DBコンサルタントだ)の面白いツイートだ。
#mongoDB : the big data platform that is challenging to scale over 100GB. http://blog.mongodb.org/post/62899600960/scaling-advice-from-mongohq
上のリンク一時的に切れてしまっていた(9月30日に記事が投稿され、それから削除され、10月2日に違うURLでまたオンラインになった)。この記事は、データが100GBを超えた場合のMongoDBの扱いについて書かれたものだ。この記事を読んで私は、その程度のサイズをMongoDBで扱うのが深刻な問題なのか、ということだ。「Webスケール」という言葉に現状は明確な定義がないとしても、多くの人は100GB以上にMongoDBをスケールさせるのは簡単なはずだと考えているのではなかろうか。今日では100GBはビッグデータではない。100GBなんて多くのSQL DBは簡単に管理できるだろう(MySQLのジョインは問題になるかも)。MongoDBのブログでこんな記事を見ることになるとは非常に面白いことだ。Chen氏のツイートはまさにそれだ。
ここで私は、Jack Clark氏の記事「GoogleはSQL F1データベースで未来へ向う」での発言「失われた5年」(ユーザは5年来、NoSQLのデータ永続性やソフトウェア自体の不安定性に悩まされてきたという、記事の冒頭の一文)という言葉についてもう一度考えてしまう。上で言ったように、私は多言語永続性の考え方は好きだ。私は、ある実装が不十分だからという理由でNoSQLがゴミだとは言っていない。同じように、MySQLのジョインがダメだからと言ってSQLがゴミだとも言わない。それどころか、「早すぎるSQLへの回帰」という記事でAlex Popescu氏が激怒しているのを思い出させる。彼の「失われた5年」に対する反応はこうだ。
その失われた5年とやらで我々が得たものを考えてみてほしい。Redis, Cassandra, Riak, プログラム的なデータ処理のための並列処理方法, Cascading, Pig, Cypher, ReQL, その他たくさんのデータ処理のためのツール、言語、APIなどだ。
私はこれらの全部を知っているわけではないが、道具箱に入れておくべき便利なツールであることは分かる。さらに、Alex Popescu氏はNoSQLに対して反省する姿勢も持ち合わせていることが分かるくらいには彼の言動を追ってきた(彼の記事のタイトルは例外だ)。それが、「最高のNoSQLデータベース」が上のリストに含まれているかどうかを確認するために彼の記事を確認した理由だ。このリストにはMongoDBは含まれていない。これは偶然ではないと思っている。
今の時点では、MongoDBが一般的になり、MySQLがSQLデータベースの残念な代表的製品であるように、NoSQLの同じ立場の製品になるのは避けられなそうだ。
Original title and author: “MongoDB is to NoSQL like MySQL to SQL — in the most harmful way” by Markus Winand
