RDB、NoSQL、時系列DB などの違いと代表例
アプリやサービスを作ろうとすると、どこかで「どのデータベースを使うべきか」を考えることになります。
ただ、最初のうちは次のような状態になりがちです。
- DBの種類が多すぎる
- MySQL や PostgreSQL は聞いたことがあるけれど、何が違うのか分からない
- Redis や MongoDB も名前は知っているが、どういう用途なのか曖昧
この記事では、データベースを大まかに分類しつつ、代表的なDB名とその概要、メリット・デメリット、何に向いているかをざっくり整理します。
この記事の目的
この記事は、次のような方向けです。
- DBの種類を大まかに整理したい
- 代表的な製品名をざっくり知りたい
- 「どのDBが何に向いているか」を俯瞰したい
細かな内部実装やベンチマーク比較というよりは、まず全体像を掴むための整理記事です。
まずは大分類
データベースは細かく分けるといろいろありますが、まずは次のように整理すると分かりやすいです。
- リレーショナルデータベース（RDB）
- キーバリューストア
- ドキュメントデータベース
- 分析系データベース（列指向・DWH寄り）
- グラフデータベース
- 時系列データベース
- インメモリデータベース
- 検索エンジン系データストア
「NoSQL」は、RDB以外をまとめて呼ぶことが多いですが、実際にはその中にさらにいくつかの系統があります。
1. リレーショナルデータベース（RDB）
もっとも定番のデータベースです。
表（テーブル）形式でデータを管理し、行と列で整理します。
SQL を使って操作するものが一般的です。
代表例
- MySQL
- PostgreSQL
- MariaDB
- SQLite
- Oracle Database
- Microsoft SQL Server
概要
たとえば、
- ユーザー一覧
- 注文一覧
- 商品一覧
のような形でテーブルを作り、テーブル同士を関連付けて管理します。
メリット
- 構造が明確で分かりやすい
- SQLが使える
- 整合性を保ちやすい
- 実務での採用例が非常に多い
- 取引データや業務データに強い
デメリット
- スキーマ変更がやや重いことがある
- 柔軟なデータ構造にはやや向かない
- 大規模分散を前提とした設計は製品次第
向いている用途
- 会員管理
- ECサイト
- 予約システム
- 会計・業務システム
- 管理画面系のアプリ全般
ざっくり印象
まず迷ったら RDB を検討する、で大きくは外しにくいです。
特に Webアプリや業務系システムでは今でも中心的な存在です。
2. キーバリューストア
key -> value の形でデータを保存する、シンプルなデータベースです。
代表例
- Redis
- Amazon DynamoDB
- Riak
概要
たとえば、
session:12345 -> ユーザーのセッション情報cache:top_page -> キャッシュ済みデータ
のような形です。
メリット
- 高速
- 構造がシンプル
- キャッシュ用途に強い
- スケールしやすい製品が多い
デメリット
- 複雑な検索や結合には向かない
- データ構造の関係性を扱うのが苦手
- RDBのような柔軟な問い合わせは難しい
向いている用途
- キャッシュ
- セッション管理
- 一時データ保存
- ランキング
- 高速参照が必要なデータ
補足
DynamoDB はキーバリュー型としてよく紹介されますが、ドキュメント的な使い方もできます。
ざっくり印象
「本番DBの主役」というより、補助役として非常に強いです。
特に Redis は、キャッシュやセッション保存でよく使われます。
3. ドキュメントデータベース
JSONのようなドキュメント単位でデータを保存するDBです。
代表例
- MongoDB
- Couchbase
- Firestore
概要
RDBのように厳密な表形式ではなく、1件ごとに少し構造が違っても扱いやすいのが特徴です。
例:
{
"name": "Yamada",
"email": "[test@example.com](mailto:test@example.com)",
"tags": ["vip", "tokyo"]
}
メリット
- 柔軟なデータ構造
- JSONライクで扱いやすい
- アプリケーションとの相性が良い
- スキーマ変更に強い
デメリット
- データ整合性の管理は設計に依存しやすい
- 複雑な関連データ管理はRDBの方が得意なことが多い
- JOIN前提の設計とは相性が悪い
向いている用途
- コンテンツ管理
- プロフィール情報
- 可変項目が多いデータ
- プロトタイプ
- モバイル / Webアプリの一部バックエンド
ざっくり印象
「項目が増減しやすい」「JSONっぽく扱いたい」という時に便利です。
ただし、業務システムのような厳密な整合性が必要な場面では慎重に選ぶべきです。
4. 分析系データベース（列指向・DWH寄り）
大量データの集計や分析に強いタイプのデータベースです。
列単位で効率よく扱う仕組みを持つものが多く、分析用途で強みを発揮します。
代表例
- ClickHouse
- BigQuery
- Amazon Redshift
概要
通常のRDBが「1行単位」で読むイメージなのに対し、分析系データベースは「必要な列だけを大量に効率よく読む」のが得意です。
メリット
- 大量データの集計に強い
- 分析クエリが速い
- ログやイベント分析に向く
デメリット
- 更新中心の処理には向かないことがある
- 業務アプリの通常トランザクションには不向きな場合が多い
- 学習コストが少し高い
向いている用途
- アクセスログ分析
- BI
- 大量イベントデータ
- 分析基盤
- データウェアハウス
補足
Cassandra や HBase も「カラム系」として語られることがありますが、これらはワイドカラムストアと呼ばれることが多く、ここで扱っている分析寄りの列指向DBとは少し性格が異なります。
ざっくり印象
日々の業務処理より、集計・分析・可視化向けです。
5. グラフデータベース
「ノード」と「関係」を重視してデータを管理するDBです。
代表例
- Neo4j
- Amazon Neptune
- JanusGraph
概要
人と人のつながり、経路、依存関係のような「関係そのもの」が重要なデータを扱いやすいです。
メリット
- 関係性の探索に強い
- ネットワーク構造の表現が得意
- 経路探索や推薦ロジックに向く
デメリット
- 一般的なCRUD中心の業務システムには過剰なことが多い
- 学習コストがある
- RDBほど広く使われてはいない
向いている用途
- SNSの関係性分析
- 推薦システム
- 組織図や依存関係
- 経路探索
- 不正検知の関係分析
ざっくり印象
「関係性」が主役のときに真価を発揮します。
普通の業務テーブル管理とは発想がかなり違います。
6. 時系列データベース
時間の流れに沿って増えるデータを扱うのに特化したDBです。
代表例
- InfluxDB
- TimescaleDB
- OpenTSDB
概要
CPU使用率、センサーデータ、株価、アクセス数など、時刻とセットで増えていくデータを保存・集計しやすい設計です。
メリット
- 時系列データの保存と集計に強い
- 一定期間ごとの集計がしやすい
- 監視やメトリクス用途と相性が良い
デメリット
- 一般的な業務データ管理には向かない
- 汎用DBとしては使いづらい
- 用途がかなり明確
向いている用途
- サーバー監視
- IoT
- メトリクス収集
- ログの時系列分析
- センサーデータ保存
補足
TimescaleDB は PostgreSQL をベースにした時系列向け拡張として知られています。
ざっくり印象
「時間が主軸」のデータなら非常に強いですが、万能型ではありません。
7. インメモリデータベース
主にメモリ上でデータを扱い、高速処理を重視するDBです。
代表例
- Redis
- Memcached
- SAP HANA
概要
ディスクよりも高速なメモリを中心に使うことで、高速な読み書きを実現します。
メリット
- とにかく速い
- キャッシュや一時保存に強い
- リアルタイム性が高い処理と相性が良い
デメリット
- メモリ容量に制約がある
- 永続化や障害時の扱いに注意が必要
- 大量の本番主データをそのまま置くには設計が必要
向いている用途
- キャッシュ
- セッション管理
- 一時キュー
- リアルタイムランキング
補足
2で紹介した Redis も、このインメモリデータベースの代表例です。
ざっくり印象
「主データベース」より、高速化担当として採用されることが多いです。
8. 検索エンジン系データストア
厳密には一般的なDBと少し性格が違いますが、検索用途では非常に重要です。
代表例
- Elasticsearch
- OpenSearch
- Solr
概要
全文検索、あいまい検索、ログ検索、集計付き検索などが得意です。
メリット
- 全文検索に強い
- ログ検索に強い
- 検索UIとの相性が良い
- 集計やフィルタも比較的得意
デメリット
- 主DBとしては扱いづらい
- 整合性管理は工夫が必要
- 運用コストがかかることがある
向いている用途
- サイト内検索
- ログ基盤
- 商品検索
- 監視ログ分析
ざっくり印象
「保存」より検索が主役です。
RDBや他DBと組み合わせることが多いです。
最近は境界線が曖昧になってきている
最近のデータベースは、1つの製品が複数の性質を持つことも珍しくありません。
たとえば、PostgreSQL でも JSON を扱えますし、DynamoDB もキーバリュー型とドキュメント型の両方の側面があります。
そのため、分類は「完全に別物」というより、何を得意としているかを理解するための目安として捉えるのが実務的です。
では、最初に何を選べばよいか
迷ったときは、まず次の考え方で良いと思います。
まずはRDBを第一候補にする
ユーザー、予約、注文、顧客、商品など、一般的な業務データはRDBが扱いやすいです。
キャッシュが必要なら Redis を足す
高速化やセッション管理が必要なら Redis は非常に有力です。
JSONっぽく柔軟に持ちたいならドキュメントDBを検討する
項目の変化が多いなら MongoDB や Firestore のような選択肢もあります。
分析やログなら専用DBを検討する
大量ログ分析や全文検索は、RDBだけで無理に頑張るより専用の仕組みが向いています。
よくある構成の例
実際には、1種類だけで完結しないことも多いです。
例1: 一般的なWebアプリ
- PostgreSQL / MySQL: 本番データ
- Redis: キャッシュ・セッション
例2: コンテンツ多めのサービス
- MongoDB / Firestore: 柔軟なデータ
- Redis: キャッシュ
例3: ログ分析基盤
- RDB: 管理情報
- Elasticsearch / OpenSearch: 検索
- ClickHouse / BigQuery: 分析
例4: 監視やメトリクス
- InfluxDB / TimescaleDB: 時系列データ
- Grafana: 可視化
まとめ
データベースは「有名なものを選ぶ」だけではなく、何を保存したいか、どう取り出したいか、どれぐらい整合性が必要かで選ぶのが重要です。
ざっくり整理すると、こんなイメージです。
- 業務データなら RDB
- 高速キャッシュなら Redis などのキーバリュー / インメモリDB
- 柔軟なJSONデータなら ドキュメントDB
- 大量分析なら 分析系データベース
- 関係性の探索なら グラフDB
- 時間ベースのデータなら 時系列DB
- 全文検索なら 検索エンジン系
最初は全部を覚える必要はなく、
「まずRDB」「必要に応じて別のDBを足す」
くらいの理解でもかなり実務的です。
おわりに
私自身、最初は DB の名前が多すぎて混乱しましたが、
「何を得意にしているDBなのか」という観点で見ると、かなり整理しやすくなりました。
これから学ぶ方や、技術選定をざっくり整理したい方の参考になれば幸いです。