NoSQL

NoSQLとは

NoSQL(Not only SQL)は、[[リレーショナルデータベース]] の表形式以外のデータモデルを持つデータベースの総称です。柔軟なデータ構造と水平スケール(サーバーを増やして性能を上げる)を得意とします。

主な種類

種類	データモデル	代表例	向いている用途
ドキュメント型	[[JSON]] 形式の文書	MongoDB, Firestore	スキーマが変わりやすいアプリ
キーバリュー型	キーと値のペア	Redis, DynamoDB	キャッシュ、セッション管理
ワイドカラム型	列指向の大規模表	Cassandra	書き込みが膨大なログ・IoT
グラフ型	ノードとエッジ	Neo4j	SNSの友人関係、推薦、相関図

なぜ生まれたか — 増やせる方向が違う

RDB を速くする基本は、CPU とメモリを積んだより強い1台に載せ替えることです(垂直スケール)。ただし1台の上限はいつか来ますし、値段は性能に比例せず跳ね上がります。

NoSQL の多くは逆に、普通の性能のサーバーを何十台も並べる前提(水平スケール)で作られました。そのために、RDB が当然のように持っていたものをいくつか意図的に手放しています。

テーブルをまたぐ [[テーブル結合(JOIN)]] — 相手のデータが別のサーバーにあると成立しにくい
「書いた瞬間から全員が同じ値を読める」保証 — 台数が増えるほど、そろえるための待ち時間になる

つまり NoSQL は「RDB の上位互換」ではなく、捨てたものと引き換えに台数で伸びるという取引です。何を捨てているかを知らずに選ぶと、後から取り返すのが最も高くつきます。

設計の順番が逆になる

RDB では [[正規化]] で「1つの事実は1か所だけ」に整えてから、必要に応じて JOIN で組み立てます。NoSQL では順番が逆で、先に「どんな問い合わせをするか」を決め、その形に合わせて保存します。

たとえば注文履歴の画面で毎回「注文+商品名+配送先」を表示するなら、ドキュメント型ではその3つを最初から1件のドキュメントに入れて持ちます。読むときに組み立てる作業が要らないので、1回のアクセスで画面が作れます。

代償は重複です。商品名を変更したら、その商品を含むすべての注文ドキュメントを書き換えることになります。RDB なら商品テーブルの1行を直せば済んだ場所です。「読みは速いが、更新の整合は自分で取る」— これが NoSQL の設計判断の中心にあります。

スキーマレスは「設計不要」ではない

事前のテーブル定義が要らないことは、構造の管理がなくなることではありません。管理する場所がデータベースからアプリケーションへ移っただけです。初学者がよく踏むのは次のような失敗です。

途中で項目名を zipCode から postal_code に変えた結果、古いデータは旧名のまま残り、集計が半分の件数しか拾わない
電話番号をあるときは文字列 "0312345678"、あるときは数値 312345678 で保存してしまい、先頭の 0 が消える
必須のはずの項目が欠けたデータが混ざっても、保存の時点では誰も止めてくれない

RDB なら型や NOT NULL が弾いた事故が、そのまま保存されます。対策はアプリ側のバリデーションや [[JSON Schema]] のような形の定義を自分たちで用意することで、既存データの形をそろえ直す作業も [[スキーママイグレーション]] と同じく計画的に行う仕事になります。

初学者向けポイント

「NoSQLはRDBの上位互換」ではない。トランザクションや JOIN の強さではRDBに分がある
スキーマレス = 事前にテーブル定義をしなくてよい。ただし「構造の管理をアプリ側が背負う」ことの裏返し
このアプリのような「ナレッジのつながり」はグラフ型DBのデータモデル(ノードとエッジ)そのもの
名前に反して、SQL によく似た問い合わせ言語を持つ NoSQL 製品も多い。「Not only SQL」= SQL も使う、という読み方が実態に近い

使い分けの目安

迷ったらまず [[リレーショナルデータベース]]。データの整合性が最優先の場面はRDB一択
キャッシュや一時データはキーバリュー型、柔軟な文書データはドキュメント型を検討

次に読むための地図

NoSQL は特定の製品ではなく分類名なので、「NoSQL を学ぶ」と決めても次の一歩で手が止まりがちです。目的別に4つの入口があります。上から順に読む必要はありません。

代表的な製品で手を動かす

[[MongoDB]] はドキュメント型の代表で、アプリのオブジェクトをほぼそのまま保存する感覚を最短で体験できます。[[Redis]] はキーバリュー型の定番で、[[キャッシュ戦略]] やセッションの置き場として、RDB の置き換えではなく相棒として使われます。この2つで「表以外の持ち方」を体感するのが早道です。

用途特化型を知る

関係を何段もたどるなら [[グラフデータベース]]、意味の近い文章を探すなら [[ベクトルデータベース]]、文章の中身をキーワードで探すなら [[全文検索]] の検索エンジンが担当します。いずれも「万能をやめて1つの問いに特化する」という、NoSQL に共通する発想の延長線上にあります。

分散の原理を押さえる

台数を増やしたときに何が起きるかを決めるのが [[CAP定理と分散データベース]] です。データをどう振り分けるかは [[シャーディングとパーティショニング]]、同じデータの複製を持つ話は [[レプリケーション]]、そもそもの増やし方の段階論は [[スケーリング]] にあります。製品カタログを読む前にここを押さえると、並んだ用語がつながります。

データ基盤の一部として使う

大量のログや非構造データの受け皿として、NoSQL は [[データパイプライン・ETL]] の途中に置かれます。集めたデータを分析する側の話は [[OLTPとOLAP]] と [[データウェアハウス]] が扱います。

関連技術とのつながり

[[リレーショナルデータベース]] — 比較の基準となる存在
[[SQL]] — NoSQLという言葉の由来。今は「Not only SQL」と読むのが一般的
[[JSON]] — ドキュメント型DBの保存形式
[[シャーディングとパーティショニング]] — 水平スケールを支えるデータ分割の手法
[[トランザクションとACID]] — NoSQLが部分的に手放した保証の中身

Q: NoSQL の多くが前提としているスケールの方向はどれ?
- [ ] より強い1台に載せ替える垂直スケール
- [x] 普通の性能のサーバーを何十台も並べる水平スケール
- [ ] サーバーを増やさず1台を使い切る
解説: NoSQL は台数を増やして伸ばす前提で作られており、その代わりに JOIN や厳密な一貫性を部分的に手放しています。

Q: ドキュメント型で「注文+商品名+配送先」を1件にまとめて保存する設計の代償はどれ?
- [ ] 画面を表示するたびに JOIN が必要になる
- [x] 商品名を変えたとき、それを含むすべてのドキュメントを書き換える必要がある
- [ ] 1件に保存できる項目数が固定される
解説: 読むときに組み立てずに済む代わりに、重複したデータの整合はアプリ側で取ることになります。

Q: 本文が述べるスキーマレスの実態として正しいのはどれ?
- [ ] データの構造を管理する必要がなくなる
- [x] 構造を管理する場所がデータベースからアプリケーション側へ移る
- [ ] 項目名や型がデータベースによって自動でそろえられる
解説: 事前定義が不要になるだけで、項目名の不統一や型の混在を防ぐ責任はアプリ側に移ります。