NoSQL
関係モデル以外のデータベースの総称。 「SQL を使わない」ではなく「Not Only SQL」。
種類#
| 種類 | データの形 | 例 | 適する用途 |
|---|---|---|---|
| キーバリュー | キー → 値 | Redis、DynamoDB | キャッシュ、セッション |
| ドキュメント | JSON 的な文書 | MongoDB、Firestore | 構造が可変なデータ |
| ワイドカラム | 行キー + 列族 | Cassandra、HBase | 大量の時系列 |
| グラフ | 節点と辺 | Neo4j | 関係の探索 |
| 時系列 | 時刻 + 値 | InfluxDB | 監視、センサ |
なぜ生まれたか#
2000 年代、Web サービスの規模が 1 台の RDB で扱える限界を超えた。
| 要求 | RDB の限界 |
|---|---|
| 水平スケール | 結合とトランザクションが分散を難しくする |
| 可用性 | 強い一貫性は分断時に可用性を犠牲にする |
| スキーマの柔軟性 | 変更にロックがかかる |
| 書き込み速度 | B木の更新コスト |
捨てるものを決めることで、 別の性質を得たというのが本質。
トレードオフ#
| 得るもの | 失うもの |
|---|---|
| 水平スケール | 結合(アプリで行うことになる) |
| 書き込み性能 | 強い一貫性 |
| スキーマの自由 | DB による検証 |
| 単純なデータモデル | 複雑な問い合わせ |
スキーマレスは「スキーマが無い」のではなく、 スキーマがアプリケーション側に移っただけ。 読むコードすべてが形式を想定することになる。
選び方#
関係が複雑・整合性が重要 → RDB
単純なキー参照が超高速に必要 → キーバリュー
構造が案件ごとに違う → ドキュメント
書き込みが膨大・分散前提 → ワイドカラム
関係そのものを辿る → グラフまず RDB を検討するのが実務的な既定。 PostgreSQL は JSON 型も持ち、 多くの用途をカバーできる。
参考文献#
- Martin Kleppmann. Designing Data-Intensive Applications. O’Reilly, 2017.
- Giuseppe DeCandia et al. Dynamo: Amazon's Highly Available Key-value Store. SOSP, 2007. https://doi.org/10.1145/1294261.1294281
- Fay Chang et al. Bigtable: A Distributed Storage System for Structured Data. ACM TOCS 26(2), 2008. https://doi.org/10.1145/1365815.1365816