NoSQL

概要

NoSQLは、RDBMSのリレーショナルモデル（行と列の表）以外の方法でデータを管理するデータベースの総称です。キーと値の対で持つキーバリュー型（Redis）、JSONのような構造化ドキュメントで持つドキュメント型（MongoDB）、巨大な疎な表で持つワイドカラム型（Cassandra）、つながりをそのまま持つグラフ型（Neo4j）など、性格の異なる複数のファミリーを一括りにした呼び名です（「Not Only SQL」と読むのが一般的です）。

共通するのは、RDBMSが守り抜いてきた厳密な整合性や固定スキーマを部分的に手放す代わりに、サーバを並べて処理能力を伸ばす水平スケーリングのしやすさや、データ構造の柔軟さを得ている点です。大規模Webサービスのキャッシュ、セッション管理、大量ログの蓄積など、RDBMSが苦手とする領域で広く使われています。

なぜ生まれたか

2000年代半ば、GoogleやAmazonのような超大規模Webサービスは、RDBMSの限界に直面していました。RDBMSは1台の中でACIDを守る設計であり、性能向上は基本的にサーバの増強（垂直スケール）に頼ります。しかし世界中からのアクセスは1台の限界をあっさり超え、データを複数台に分散すればJOINやトランザクションの保証が急激に難しくなります。分散環境では一貫性・可用性・分断耐性を同時に満たせないというCAP定理が示すとおり、「全部を守ったまま無限に分散する」道はなかったのです。

そこで両社は、守るものを絞り込んだ独自の分散データストアを構築しました。Googleは巨大な分散表であるBigtable（2006年発表）、Amazonは高可用キーバリューストアのDynamo（2007年発表）です。これらの論文に触発されてCassandraやMongoDB、Redisなどのオープンソース実装が次々と登場し、2009年頃に「NoSQL」という旗印のもとにムーブメントとしてまとまりました。「厳密な整合性を少し緩めれば、地球規模のスケールと高可用性が手に入る」という発見が、この語彙の原点です。

詳細

4つの主要ファミリー

キーバリュー型（Redis、Memcached、DynamoDB）は「キーを渡すと値が返る」だけの最小のモデルです。構造が単純なぶん圧倒的に高速で、キャッシュやセッションストア、ランキング集計などに使われます。特にRedisはメモリ上で動作し、マイクロ秒単位の応答を実現します。

ドキュメント型（MongoDB、Firestore）は、JSONに似た入れ子構造のドキュメント単位でデータを格納します。事前のスキーマ定義が不要で、ドキュメントごとに構造が違っても構いません。アプリケーションのオブジェクトをほぼそのまま保存でき、正規化で分割する代わりに関連データを1ドキュメントに埋め込む設計が標準です。

ワイドカラム型（Cassandra、HBase）は、行キーごとに数百万の列を持てる巨大で疎な表のモデルです。書き込みの取りこぼしが許されない大量データ——IoTセンサーの計測値、メッセージ履歴、ログ——を、数十〜数百ノードに分散して受け止める用途に向きます。

グラフ型（Neo4j）は、ノードとエッジ（関係）を第一級のデータとして持ちます。「友達の友達」のように関係を何段もたどる問い合わせは、RDBMSではJOINの連鎖になり急激に遅くなりますが、グラフ型なら自然に表現できます。

分散と結果整合性の仕組み

NoSQLの多くは、データをキーのハッシュ値などで複数ノードに自動分割（シャーディング）し、さらに各データを複数ノードに複製（レプリケーション）して耐障害性を確保します。書き込みが全レプリカへ行き渡る前に応答を返す設計では、直後の読み取りが古い値を返すことがあります——これが結果整合性（eventually consistent）で、「いずれ全ノードが一致する」ことだけを保証する緩い整合性です。

書き込みの応答が返った時点では、まだ全レプリカに変更が行き渡っていません。応答の速さと引き換えに、一時的な不一致を許容するのが結果整合性です。

この性質はACIDと対比してBASE（Basically Available, Soft state, Eventually consistent）と呼ばれます。「SNSのいいね数が数秒ずれても問題ないが、口座残高がずれるのは致命的」というように、扱うデータがどちらの保証を必要とするかが選定の分かれ目です。

使いどころと落とし穴

NoSQLはRDBMSの置き換えではなく適材適所です。実務では「本体のデータはPostgreSQL、キャッシュとセッションはRedis、行動ログはワイドカラム型」のように併用（ポリグロット・パーシステンス）するのが定石で、まずRDBMSを既定の選択とし、明確な理由——スキーマが本質的に不定形、書き込み量が1台の限界を超える、応答速度がミリ秒未満で必要——があるときにNoSQLを足すのが健全です。

落とし穴は「クエリから逆算した設計が必須」という点にあります。RDBMSは正規化しておけば後からどんなSQLでも投げられますが、NoSQLの多くはJOINや柔軟な検索を持たないため、「どう読むか」を先に決めてそれに合わせた形でデータを持つ必要があります。要件が固まらないうちにNoSQLを選ぶと、後から「この条件で検索できない」という壁に突き当たりがちです。また「スキーマレス」は「スキーマを考えなくてよい」ではなく「スキーマの整合性管理がアプリケーション側の責任になる」という意味であることも、見落とされやすいポイントです。