SQLとNoSQLの選択
SQL or NoSQL
整合性・複雑なクエリ・成熟度が要るならSQL、柔軟なスキーマ・超大規模・超高スループットが要るならNoSQL。用途で使い分ける(両方併用も普通)。
判断の早見表
| 観点 | SQL向き | NoSQL向き |
|---|---|---|
| データ構造 | 構造化・スキーマ固定 | 半構造化・柔軟スキーマ |
| 関係性 | 複雑なJOINが必要 | JOIN不要・独立した塊 |
| トランザクション | 必須 | 不要/弱くてよい |
| 規模 | 中〜大 | TB〜PB級の超大規模 |
| スループット | 通常 | 超高IOPSが必要 |
| 成熟度 | 高い(ツール・人材豊富) | 用途特化 |
図を描画中...
NoSQLが特に輝くデータの例
System Design Primerが挙げる典型例:
- クリックストリーム/ログ: 大量に高速で書き込む。あとで分析。
- リーダーボード/スコア: 頻繁に更新される順位。
- 一時データ: ショッピングカートのような短命データ。
- hotテーブル: アクセスが集中する頻出データ。
- メタデータ/lookupテーブル: 単純なキー引き。
これらは『複雑な関係よりも、速さ・量・柔軟さ』が大事なデータです。
つまずきポイント
- 『SQL vs NoSQL』は宗教戦争ではなく適材適所。1つのサービスで、ユーザー情報はSQL・セッションはRedis(KV)・ログはNoSQL、と併用するのが普通。
- 『流行っているからNoSQL』は危険。トランザクションが本質的に必要なのにNoSQLにすると、整合性を自前で実装する地獄になる。
- 逆に『慣れているからSQL』に固執して、超大規模・高スループットで限界を迎えるのも避けたい。データの性質で選ぶ。
📊 図解
図解: 構造化度 × スケール特性で見るSQL/NoSQL
横軸=規模(中規模〜超大規模)、縦軸=スキーマの構造化度。構造化・中規模なら左上のRDBMS、柔軟・超大規模なら右下のNoSQL寄り、と位置づけで使い分ける。
図を描画中...