NoSQLとRDBMS — カチッとした表か、何でも入る段ボールか

データベースには大きく2つの性格があります。1つはRDBMS(MySQL、PostgreSQLなど)。列の名前と型が決まったカチッとしたエクセルの表で、決まった形のデータしか受け付けません。もう1つはNoSQL、なかでもドキュメントDB(MongoDBなど)。こちらは何でも入る段ボールで、形がバラバラでも黙って受け取ります。

どちらが優れているかではなく、違いは「データの形を、いつ確かめるか」にあります。下の図1で、形の違う5人分の会員データを表と段ボールに同時に入れて、そのあと読み出してみてください。

RDBMS — 入口で検品する

RDBMSでは、データを入れる前にスキーマ(列の名前・型・必須かどうか)を決めておきます。図1の表なら「name と email は必須、age は整数」。この約束に合わないデータは、書き込みの時点でエラーになります。年齢に「二十歳」と書いてきても、name を nmae と打ち間違えても、入口で止まる。

これは面倒に見えて、実は大きな安心です。表に入っている時点で形が正しいことが保証されているので、読む側は何も疑わずに平均を出したり、名前で並べたりできる。複数の表を JOIN でつなぐ、残高をトランザクションで守る、といった「データの正しさ」が大事な仕事が得意なのもこのためです。

代わりに、形を変えるのが重い。電話番号を持たせたくなったら ALTER TABLE で列を足し、既存の全行にも空欄(NULL)ができます。図1では一瞬ですが、何億行もある本番の表では、慎重な計画が要る作業になります。

ドキュメントDB — 何でも受け取り、出口で困る

ドキュメントDBは、1件ごとに好きな形のまましまえます。ある人だけ電話番号がある、住所を入れ子のまま1枚に持たせる――どれも準備なしで入ります。仕様がどんどん変わる開発初期や、項目が人によってバラバラなデータ(商品ごとに違うスペック、ログ、設定など)と相性が良いのはこのためです。

ただし「形の決まりがない」は、形を確かめる仕事が消えたという意味ではありません。読む側に移っただけです。図1で年齢の平均を出すと、文字の「二十歳」で計算が止まり、名前の一覧には nmae のせいで名前のない人が混ざります。これをスキーマオンリード(読むときに形を解釈する)と呼び、RDBMSのやり方はスキーマオンライト(書くときに形を確かめる)と呼ばれます。

まとめ

RDBMSは入口で検品するカチッとした表、ドキュメントDBは何でも受け取る段ボールです。検品の手間は、どちらを選んでもなくなりません。書くときに一度だけ払うか、読むたびに払うかの違いです。形がはっきりしていて正しさが大事なデータ(会員、注文、お金)は表に、形がバラバラで変わりやすいデータは段ボールに。実際のサービスでは、両方を使い分けていることも珍しくありません。