MongoDB、っていうかスキーマレスDB

RDBMSとスキーマレスDBの対比が理解出来ていない。
MongoDBとかをどういう局面で使うと有効で、どういうときは素直にRDBMSを使うべきなのか。

最近それに興味を持ってちょっとずつ調べている。

昨日までに調べて判ったことがいくつかある。

MongoDBにはトランザクションと排他制御がない。
MongoDBはテーブルのJOINとかできない。
MongoDBはRDBじゃないので集合ベースの思考が向かない。
Cassandraは列のカウントアップもできない。MonogoDBができないかはわからない。
MongoDBはRDBMSと違って、最初から型や制約を定義することがない。だからエンティティに属性を増やすたびにALTER文を発行する必要がない。つまり、頻繁にテーブル定義を変えたくなる場合に作業が楽。

型や制約を定義しない

http://gihyo.jp/dev/serial/01/various-nosql/0004

カラムを固定できない場合に有効です。あらかじめたくさんのカラムを用意しておくことでも対応は可能ですが，マジックナンバーのようなカラムが増えてしまうと，運用しづらくなってしまいます。

また，RDBMSで開発を行っている場合，テーブルのスキーマが変更になるたびにデータベース側とアプリ側で修正を行わなければいけません。そういった場合，MongoDBであればスキーマレスなのでアプリ側のプログラムのみ修正すれば良いです。

列のカウントアップもできない

カウントアップできないというのはこういうSQLが発行できないということ。

update person set age = age + 1 where id = 10;

RDBだったらこういうものは排他制御をDBがちゃんとやってくれるので、
もともとage=2のデータを二つのトランザクションからカウントアップしたとき、

(transaction1) age = 2 + 1 = 3;
(transaction2) age = 3 + 1 = 4;

って、ちゃんとやってくれる。
でもCassandraはこれができない（厳密に言うと、できなかった、らしい）。

DBとアプリの関係性を見直す？

http://www.ustream.tv/recorded/16328557
このUstなんだけど、「DBとアプリの関係性を見直す」っていうのはたしかにうまいことを言っていると思うんだ。
でも、鵜呑みにするのはまだまだ危ないかな〜なんて思う。

スキーマレスなDBを使うことで、DBの型や制約に頼らない、
アプリケーションの方でそういう部分をきちんとやるという考えは尤もらしいのだけど、そう簡単でもないかなと今は思っている。

RDBの型や制約のおかげでアプリケーションの考慮漏れに気付かされるっていうことも大いにあると思う。
しっかりバリデーションを組んでテストまで書いてOKが出ているのに、
処理終了まで進めると一意制約違反で落ちるとか。

実装者・設計者がちゃんと考えていたのに気づかなかった部分をRDB側のチェック機能のお陰で事前に発覚して助かったなんてことは結構あるんじゃないかなと思うんだ。

とはいえ、まだまだ全然知らないことばかりなので引き続きこの分野は調べていく。