DB 選定でよく出るのが「RDB でいくか、NoSQL も使うか」。さらに NoSQL にするなら MongoDB / Redis / DynamoDB など、製品も分かれる。
この記事では、RDB と NoSQL の選定基準と、NoSQL 製品の選定基準をざっくり整理する。細かいベンチマークより、「どんな要件のときに寄せるか」を優先する。
RDB 製品同士の比較は ざっくりDB製品の比較と選定のポイント を参照。
先に結論
- 業務の本体（台帳・取引・結合が多いデータ）は、まず RDB
- NoSQL は「RDB の代わり」より、特定のアクセスパターンが強いときの選択肢
- 「RDB が遅いから NoSQL」は、まずクエリ・インデックス・設計を疑う
- NoSQL 製品は種類が違う（文書 / KVS・キャッシュ / ワイドカラム など）。同じ NoSQL でも用途が別
- 選定は データの形・読み方・整合の強さ・運用できる人 から当てる
RDB と NoSQL の選定基準
製品名より先に、「何をしたいか」で分ける。
RDB に寄せるとき
- 表＋結合が中心（注文と明細、顧客と契約など）
- 更新の整合が強い（会計、在庫、請求）
- トランザクション（まとめて成功／失敗）が必要
- アドホックな集計・レポートが多い
- チームが SQL と RDB 運用に慣れている
NoSQL に寄せるとき
- ほぼ「キーで取る／キーで書く」が中心
- スキーマ（項目）が頻繁に変わる文書・イベント
- キャッシュ・セッション・レート制限など、本体台帳の前段
- 超大量の単純アクセスを水平に伸ばしたい（要件がはっきりしている）
- 結果整合でよい（少し遅れても業務が成立する）
早見
| 要件 | 寄せる先 |
|---|
| 取引・台帳・強い整合 | RDB |
| 結合・集計が多い | RDB |
| キーアクセス中心 | NoSQL（KVS など） |
| 文書・JSON をそのまま扱う | NoSQL（文書指向） |
| キャッシュ・セッション | NoSQL（KVS）＋本体は RDB が多い |
| RDB が遅いだけ | まず RDB 側の設計・チューニング |
実務では RDB が本体、NoSQL が脇役（キャッシュや特定機能）のハイブリッドが多い。
NoSQL は種類が違う
「NoSQL」は1製品の名前ではない。ざっくり次の型がある。
| 型 | 向くアクセス | 製品例 |
|---|
| 文書指向 | JSON 風の文書を丸ごと | MongoDB、DocumentDB など |
| KVS / キャッシュ | キーと値、高速・一時 | Redis、Memcached、DynamoDB（用途次第） |
| ワイドカラム | 超大量・分散書き込み | Cassandra、Bigtable 系 |
| 検索エンジン寄り | 全文検索・ログ分析 | Elasticsearch など（DBというより検索基盤） |
型が違うので、「NoSQL 同士の比較」より どの型が要件に合うか が先。
NoSQL 製品の選定基準
先に聞くこと
- アクセスの形 … キーだけか、文書か、検索か、時系列か
- データの寿命 … 永続の本体か、消えてよいキャッシュか
- 整合 … すぐ一貫して見える必要があるか、遅れてもよいか
- サイズと伸び方 … 単機で足りるか、最初から分散が必要か
- クラウド指定 … AWS なら DynamoDB / ElastiCache、Azure なら Cosmos DB など、寄せやすい製品がある
- 習熟・運用 … チームが触れるか、マネージドにするか
- 費用 … リクエスト課金・メモリ課金など、RDB と単価の考え方が違う
製品のざっくり対応
| 寄せたい用途 | よく選ばれる例 | メモ |
|---|
| 文書・柔軟なスキーマ | MongoDB、DocumentDB | 文書指向の定番筋 |
| キャッシュ・セッション | Redis | 本体台帳の代わりにはしにくい |
| AWS でキーアクセス中心 | DynamoDB | マネージド・スケール向き。設計（キー設計）が肝 |
| Azure で複数モデル | Cosmos DB | |
| 超大量の分散書き込み | Cassandra 系 | 運用・設計の難度が高め。新規では比較的選ばれにくいことも |
| 全文検索・ログ | Elasticsearch など | 台帳DBというより検索・分析寄り |
決めてはいけないこと
- 流行だけで NoSQL にする … 整合と結合が必要な本体まで寄せると苦しくなりやすい
- RDB の遅さを製品変更だけで解く … まずインデックス・クエリ・設計
- キャッシュ用 Redis を台帳にする … 用途が違う
- 習熟できる人がいない製品を本番の中核にする … 障害時に止まる
現場でありがちな分け方
- 受注・顧客・請求 → RDB
- ログインセッション・画面の一時データ → Redis など
- 柔軟なイベントログ・ユーザー設定文書 → 文書指向（または RDB の JSON 列で足りるか先に検討）
- 検索ボックスの全文検索 → 検索エンジン寄り（台帳は RDB のまま、が多い）
チェックリスト
- これは本体台帳か、脇役（キャッシュ・検索）か？
- 強い整合・結合が必要か？ → 必要なら RDB
- NoSQL なら、どの型（文書 / KVS / その他）か？
- クラウド指定と、習熟できる人はいるか？
- RDB の JSON 列やマテビューで足りないか、先に検討したか？
まとめ
- 本体は RDB、NoSQL は特定パターン向け、が基本の感覚
- NoSQL は製品より先に型を選ぶ
- 選定はアクセスの形・整合・寿命・クラウド・習熟から当てる
関連記事