NoSQL とは — KV / ドキュメント / 列指向 / グラフ
📖 このページのゴール：「NoSQL＝なんだか新しくて速いやつ」というモヤモヤを、4つの種類とその得意・不得意に整理すること。名前（Redis・MongoDB・Cassandra・Neo4j…）を聞いたら「ああ、あの形の仲間ね」と置き場所がイメージできるようになります。 ← 目次・はじめにへもどる
ここまで（02〜06ページ）は、ずっと RDB（かっちりした表） の世界でした。「表に縛らない、もっと自由な置き場所が欲しい」——その答えが NoSQL です。まずは肩の力を抜いて、たとえから入りましょう。
🧺 ひとことのたとえ：中身の形がバラバラでも入る、大きなカゴ
RDB が 「行と列がきっちり決まった表計算＋伝票」 だとすると、NoSQL は 「中身の形がバラバラでも、とりあえずポイポイ入る大きなカゴ」 です。
- 表（RDB）は、列をぜんぶ先に決めてからでないと入れられません（名前・年齢・住所…）。きっちりしている=信頼できる、けれど窮屈。
- カゴ（NoSQL）は、形が違うものでもそのまま入る。あるデータには住所があって、別のデータには無くてもOK。ゆるいぶん、大量・高速・柔軟が得意です。
そのかわり、カゴの中身を 複雑に突き合わせて集計するのは苦手なことが多い——ここが今日いちばん大事な「代償」です（後半で説明）。
🧩 NoSQL＝「Not only SQL」（かっちりスキーマに縛られない）
「NoSQL（ノーエスキューエル）」という名前は、ちょっと誤解されがちです。
❌「No SQL ＝ SQL を完全に否定するもの」ではありません。 ⭕ NoSQL ＝ Not only SQL（SQL だけじゃないよ） の略。「RDB と SQL も使うけど、それ以外の選択肢も持とう」という意味です。
RDB の最大の特徴は、スキーマ（＝表の設計図。列の名前と型をかっちり決めるルール）でした。NoSQL のいちばんの違いは、ここを ゆるめる こと。
- スキーマレス／柔軟なスキーマ：先に列をぜんぶ決めなくてよい。後からデータの形が変わっても入る。
- だから 開発が速く始められるし、形が一定でないデータ（ユーザーごとに項目が違う設定、刻々と増えるログ など）と相性がいい。
🟢 ここだけ覚えれば十分：RDB＝先に設計図ありき／NoSQL＝形がゆるくてもまず入る。
🗂 種類は4つ：KV／ドキュメント／列指向／グラフ
NoSQL は「1つの製品」ではなく、目的のちがう4つの家族の総称です。表で一気につかみましょう。
| 種類（よみ） | ひとことたとえ | データの形 | 得意なこと | 代表サービス |
|---|---|---|---|---|
| KV（キーバリュー） | 名札と中身（コインロッカー） | 「キー → 値」の対だけ | とにかく速い。鍵を渡せば一発で取り出す | Redis / DynamoDB |
| ドキュメント | JSON のかたまりを丸ごと保存 | 1件＝入れ子OKの JSON 風 | アプリのオブジェクトをそのまま保存。形が一定でなくてよい | MongoDB / Firestore |
| 列指向／ワイドカラム | 超巨大な表を列ごとに分けて持つ | 行×ものすごく多い列 | 超大量データの書き込み・集計に強い | Cassandra / Bigtable |
| グラフ | 点と線で「つながり」を持つ | ノード（点）＋エッジ（線） | 「友だちの友だち」などつながりをたどるのが速い | Neo4j |
少しだけ補足（🔧 読み飛ばしOK）：
- 🏷 KV（キーバリュー）＝名札と中身：「
user:123という名札（キー）を渡すと、その中身（値）を返す」だけのシンプルな仕組み。構造がシンプルだからものすごく速い。セッション情報や後述のキャッシュ（09ページ）でよく使われます。 - 📦 ドキュメント＝JSON のかたまり：プログラムで扱う「1人のユーザー」のようなオブジェクトを、バラさず丸ごと1件として保存。RDB のように複数の表に分けなくてよいので直感的。
- 📊 列指向／ワイドカラム＝超大量向け：何十億行・何千列という桁外れの規模を、たくさんのサーバーに分けてさばくための形。IoT のセンサーデータや巨大な時系列ログなどが典型。
- 🕸 グラフ＝つながり重視：SNS の交友関係、商品の「これを買った人はこれも」、不正検知など、関係そのものが主役のときに輝きます。
🌱 なぜ生まれた？（RDB だけでは足りなくなった理由）
NoSQL は「流行りだから」ではなく、RDB が苦手とする場面を埋めるために生まれました。
- 📈 巨大スケール：利用者が世界中に何億人。1台のサーバーでは到底さばけない量を扱いたい。
- ✂️ 水平分割（すいへいぶんかつ＝シャーディング）：データをたくさんのサーバーに分けて載せること。NoSQL はこれを前提に設計されていて、サーバーを足すほどスケールしやすい。
- 🧷 柔軟な構造：データの形が頻繁に変わる／項目がバラバラでも、設計図に縛られず素早く対応したい。
- ⚡ 高速な書き込み：膨大なログやイベントを、止まらずどんどん書き込みたい。
🧭 ことばメモ：スケールには2方向あります。
- 垂直スケール（スケールアップ）＝1台のサーバーを強くする（CPU・メモリ増し）。やがて天井が来る。
- 水平スケール（スケールアウト）＝サーバーの台数を増やす。NoSQL が得意なのはこちら。
⚖️ その代償：複雑な「結合」や「強い整合性」が苦手
いいことばかりではありません。NoSQL は速さ・柔軟さ・大規模と引き換えに、RDB が当たり前に持っていた強みを手放しがちです。ここを知らずに選ぶと後で痛い目を見ます。
- 🔗 結合（けつごう＝JOIN）が苦手：RDB は「注文表」と「ユーザー表」を SQL の JOIN でサッと突き合わせられました。NoSQL（特にカゴをたくさんのサーバーに分けた状態）では、これが難しい・遅い・できないことが多い。だから設計の段階で「よく一緒に使うデータは、最初からまとめて入れておく」という発想が必要になります。
- 🪢 強い整合性が苦手＝「結果整合性」になりがち：データを複数サーバーにコピーして分散させると、書いた直後は全サーバーがまだ揃っていない瞬間が生まれます。
🧭 ことばメモ：結果整合性（けっかせいごうせい） 「今すぐ全員が同じ値を見る」ことは保証しないけれど、「しばらく待てば、いずれ全部が同じ値に揃う」という考え方。 たとえ：遠くの支店に「在庫が1減ったよ」と電話で伝える——伝わるまでの数秒は、支店によって数字がズレる。でも少し待てば必ず揃う。RDB の トランザクション（ぜんぶ成功かぜんぶ取消＝つねに整合） とは、ここが大きく違います。
🆚 RDB との対比でつかむ
最後に、RDB（02ページ）と NoSQL をまっすぐ並べておきます。迷ったときはこの表に戻ってください。
| 観点 | 🗄 RDB（SQL） | 🧺 NoSQL |
|---|---|---|
| データの形 | かっちりした表（先に設計図） | ゆるい・多様（形がバラバラでも入る） |
| クエリ（検索） | SQL で複雑な検索・結合(JOIN)が得意 | 鍵での取り出しは速いが、複雑な結合は苦手 |
| 整合性 | 強整合（トランザクション/ACID） | 結果整合になりがち |
| スケール | おもに垂直（足し算は工夫が要る） | 水平が前提（台数を足して伸ばす） |
| 代表 | PostgreSQL / MySQL | Redis / DynamoDB / MongoDB / Cassandra / Neo4j |
🧭 基本姿勢：まず RDB で、困ってから NoSQL
「新しくてカッコいいから NoSQL」——これが初心者のいちばんの落とし穴です。基本の構えはシンプル。
🟢 まずは PostgreSQL 系の RDB（マネージドなら Supabase / Neon / RDS）で素直に作る。 そして「RDB だと困る具体的な理由」——たとえば ①想像を絶する規模になった ②特定のアクセスの仕方に振り切りたい ③リアルタイム同期がほしい——がはっきり出てきてから、その用途にだけ NoSQL を足す。
SQL は何十年も使われてきた普遍の言語で、移行先も豊富。だから「とりあえず間違いない」のは RDB のほう。NoSQL は“理由があるとき”に効く特殊兵装、と覚えておけば大きく外しません。実際にどの NoSQL を選ぶか（DynamoDB / MongoDB / Firestore の使い分け）は、次の08ページで具体的に見ていきます。
🟢 ひとことで言うと
NoSQL＝「Not only SQL」。表に縛られない大きなカゴで、KV・ドキュメント・列指向・グラフの4種類がある。 大量・高速・柔軟（水平スケール）が得意な反面、複雑な結合や強い整合性は苦手（結果整合になりがち）。だから合言葉は 「まず RDB で、困ってから NoSQL」。
➡️ 次へ
次のページ：DynamoDB / MongoDB / Firestore — 代表3つの使い分け → ← 目次・はじめにへもどる