3秒でわかる
表形式にこだわらずデータを保存するデータベースの総称。文書型やキーバリュー型などがあり、形の揃わないデータや大量の書き込みを扱うときに選びます。
もう少し詳しく
どういうものか
NoSQL は、行と列の表にデータを収める従来のリレーショナルデータベース以外の保存方式をまとめた呼び名です。中身は 1 種類ではなく、JSON に近い文書をそのまま入れるドキュメント型、キーと値だけを高速に出し入れするキーバリュー型、列単位で持つワイドカラム型、点と線でつながりを表すグラフ型に大きく分かれます。名前は「SQL を使わない」ではなく「SQL だけではない」という意味で使われます。
なぜ必要か
リレーショナルデータベースは、事前に列を決めておく前提で強い一貫性を守ります。この前提が合わない場面があります。商品ごとに属性がまったく違うカタログ、1 秒あたり数万件届くセンサーのログ、ユーザーごとに形の違う設定データなどです。列を足すたびにテーブル定義を変えるより、文書ごと入れて読むときに解釈するほうが速く回ります。書き込みを複数台へ分散させやすい設計になっている点も選ばれる理由です。
具体例
// MongoDB のドキュメント。同じコレクションに形の違う文書を入れられる
db.products.insertOne({
name: "浅煎りブレンド",
price: 1200,
tags: ["coffee", "light"],
roast: { level: 2, date: "2026-08-01" }
});
db.products.find({ tags: "coffee", price: { $lt: 1500 } });同じことをリレーショナルデータベースでやるなら、商品テーブルとタグテーブルを分けて JOIN する設計になります。
つまずきやすいところ
「NoSQL は速い」という理解だけで選ぶと失敗します。速いのは、あらかじめ決めた読み方に合わせて形を作った場合だけで、あとから別の切り口で集計したくなると総なめが必要になります。設計の順番が逆で、リレーショナルでは先にデータの形を決めますが、NoSQL では先に画面と検索条件を決めてから保存形式を決めます。結合が無いぶん、重複を持つ設計になる点も最初は違和感があります。
似た用語との違い
| 種類 | 得意なこと | 代表例 |
|---|---|---|
| ドキュメント型 | 形が揃わないデータの保存 | MongoDB |
| キーバリュー型 | キー指定の高速な読み書き | Redis |
| ワイドカラム型 | 大量書き込みと時系列 | Cassandra |
| リレーショナル | 結合と厳密な整合性 | MySQL |
覚え方
リレーショナルは正しさを守る作りで、NoSQL は形と量に合わせて割り切る作りです。どちらが上ということはなく、扱うデータの形が先に決まるかどうかで選び分けます。