RDB以外のDB入門

RDB が第一候補であることは変わりませんが、要件によっては別タイプのDBの方が適している場面があります。ここでは代表的な6種類を、用途と代表製品を対応させて整理します。

なぜRDB以外を知るか

データをテーブルではなくオブジェクトとして保存するDBです。クラス構造との親和性が高い一方、標準SQLベースの運用文化とは相性差があります。

観点	特徴
得意	複雑なオブジェクト構造の永続化
注意	運用人材・エコシステムが限定されやすい

代表製品: ObjectDB, db4o（旧）, GemStone/S

key -> value の単純な構造で超高速アクセスを重視するDBです。Redis などが代表例です。

観点	特徴
得意	キャッシュ、セッション、レート制御、ランキング
注意	複雑な結合・分析には向かない

代表製品: Redis, Memcached, DynamoDB（Key-Value用途）

実運用の逸話として、Google では Bigtable 系の「キー中心アクセス」モデルが大規模サービスのデータ基盤で活用されてきました。Amazon でも Dynamo 系の設計思想が高可用・低遅延な分散KVSの代表例になっています。

重要なのは「なんでもKVSに入れる」ことではなく、アクセスパターンが キーで即時参照 に寄るデータに絞って使うことです。

ノード（点）とエッジ（関係）でデータを表現します。関係の辿り方自体が重要な要件で強みを発揮します。

観点	特徴
得意	推薦、経路探索、不正検知、依存関係解析
注意	帳票系集計や厳密トランザクション中心業務はRDBが安定

代表製品: Neo4j, Amazon Neptune, JanusGraph

埋め込みベクトルの近傍探索に特化したDBです。RAGや意味検索など、LLM活用システムで採用が増えています。

観点	特徴
得意	類似検索、推薦、意味検索、RAG
注意	業務トランザクションの整合性管理はRDB併用が基本

代表製品: Pinecone, Weaviate, Milvus, Qdrant

JSONドキュメントを中心に扱うDBです。項目変化が多いデータに対応しやすい一方、整合性ルールは設計で明示する必要があります。

観点	特徴
得意	柔軟スキーマ、アプリ寄りデータ構造
注意	RDBのような厳密制約を前提にしない設計では破綻しやすい

代表製品: MongoDB, Couchbase, Firestore

時間軸データの保存・圧縮・集計に強いDBです。監視メトリクスやIoT計測値などで使われます。

観点	特徴
得意	時間窓集計、保持期間管理、書き込み最適化
注意	複雑トランザクション中心の基幹業務には不向き

代表製品: InfluxDB, TimescaleDB, QuestDB

選定の基本は「要件に最も自然なデータモデルは何か」です。流行よりも、整合性・運用性・チームスキルを優先して決めます。

実務では「RDB + KVS」の併用が多く、必要に応じてグラフDBを補助的に使う構成が一般的です。