RDBMSとMongoDB - seikoudoku2000のブログ

丁度、MongoDBのことが社内で色々と話題になっている時に、タイムリーにこの記事がでてきて、自分的に凄くささったのでメモ。
Open database life: ムック「データベース徹底攻略」 - MySQL/Redis/MongoDB/Redshift

データベース設計ができない/できなかった/する時間が取れない、といった人たちや、Shardingのためのロジックを書くのがめんどくさい、といった人たちを中心に好まれるデータベースです。Facebookでも、子会社の中にMongoDBを使っているところがあります。
　MongoDBを使うか、RDBMSを使うかという議論は、よく「先に楽をして後で苦労するか、先に苦労して後で楽をするか」という表現にたとえられます。「技術的負債」を語る上で良いモデルケースと言えるでしょう。
　稼働までなら、MongoDBの方が、正規化が必須なRDBMSより楽です。その一方で、設計を放棄したツケは、後々になってデータ整合性問題、(重複値の多発による)データ量増加、それによるコスト増といった様々な負債となって現れます。裏の実装はMyISAMと大して変わらないので、データ量がメモリに乗らないくらいの規模になってくると、InnoDBよりも急激なペースで参照・更新性能とも悪化します。典型的な「技術的負債」のパターンと言えるのではないでしょうか。

英訳 (by Gengo)

The debate about whether to use MongoDB or RDBMS is often described as being analogous to the expression, “To play now and work later, or work now and play later”. I believe that the situation we find here is a suitable model for talking about “technical debt”.
If we were only to consider the matter up to the point of operation, then MongoDB is the easier option because it does not require normalization like RDBMS does. On the other hand, the cost of abandoning design will surface later on in the form of various burdens such as the problem of data consistency, and (due to the frequent occurrence of duplicates) rises in data quantity and cost. The underlying implementation is not much different from MyISAM, so if data cannot fit into memory, both the referencing and updating performances will decline at a pace more rapid than InnoDB. It can be said that this is a classic pattern of “technical debt”.

MongoDBの売りとして、"スキーマレス"によるイニシャルコストの低さという所がフォーカスされているようですが、一方でNoSQL系の誕生の背景としては、Webシステムの拡大に伴う、ストレージの"スケールアウト"の必要性という所があったはずで、自分は後者の印象のほうが強かったので、ユースケースが真逆でチグハグだな〜と感じました。

スキーマレス
- テーブル定義しなくてもデータを格納できる。
  - サービスをさくっと始める所にフォーカス
スケールアウト
- スケーラビリティを維持するためACIDからBASEへ (下に参考スライド有り)
  - サービスがでっかくなった時に必要な概念
  - 一貫性を犠牲にしてもスケーラビリティを手に入れたい時

しかも、スケールアウトという、後で楽するための所に強いプロダクトなのに、スキーマレスの設計によるツケで、後で苦労するプロダクトとされているのも聞いてて残念な感じ。

ただ、一方で、例えば、世界的に使われててボクも大好きなfoursquareはMongoDBを使っていたり、アメーバもMongoの採用事例で色々とスライドを見かけるので、MongoDBがフィットするユースケース/使い方というのも確実に存在していて、そういうユースケースがもうちょっと抽象度を挙げてキャッチーな言葉でまとめられるようになると、違う見え方がするのかな〜と思ったり。
Mongo on Hadoop | Foursquare Engineering Blog
AmebaのMongoDB活用事例

あと、これは自分で色々想像してて気になった所で、スキーマレスでさくっと始められるというのは長所として挙げられますが、運用して2,3年経った時にどんな感じになってるのかな〜？と。スキーマ定義のドキュメントが無いとかはまあよくある話だと思いますが、RDBMSであれば、DDL引っ張ってくれば、最低限の情報とその定義に基づくレコードが格納されているという状態は保証されますが、スキーマレスだと、DDL無いし、Modelクラスがコードに定義されていたとしても、そのModelクラス自体が変遷したりしているわけで、運用の仕方によっては、むかーしの予期しないレコードでバグが出るとか、migrationが超大変とかありそうだな〜と勝手に想像しました。この辺は使ってる人に、どうやってるのか話を聞いてみたい。

ACID, BASE, CAP定理に関しては、この資料が凄くまとまってて勉強になりました。

NoSQLに関するまとめ from Gosuke Miyashita

これ絡みで最近読んだ本