判断: SQL か NoSQL か (どのデータベースファミリーか)?

適切なデータベースファミリーの選択は、データモデルの形状、一貫性とスケールの優先度、クエリの複雑さによって決まる。「NoSQL のほうが新しい」といった一般論は誤解を招く。各ファミリーは特定のアクセスパターン向けに設計されている。このツリーは、データの構造を起点に、リレーショナル、ドキュメント、キーバリュー、検索エンジンの中から適切なツールに導き、必要に応じてポリグロットなアプローチを想起させる。

データの性質と主なアクセスパターンは?

最も決定的な質問から始める: データは強い関連を持つ構造化レコードか、柔軟/可変なスキーマのドキュメントか、単純なキーバリューの検索か、それともテキスト検索のような特殊なニーズか? データの形状とクエリの方法がファミリーをほぼ決定する。

• リレーショナル、構造化レコードと複雑なクエリ
• 柔軟/可変なスキーマを持つネストしたドキュメント
• 単純なキーバリュー、極めて低いレイテンシ/キャッシュ
• 全文検索 / ファセット検索、ログ分析

強い一貫性 (ACID) と水平スケールのどちらが優先か?

データはリレーショナルに見えるが、優先度は何か? 複数テーブルの結合、トランザクションの整合性、強い一貫性 (ACID) が不可欠か、それとも単一ノードに収まらない膨大な量を水平スケールすることか? リレーショナルモデルはほとんどのワークロードにとって適切なデフォルトであり、限界に達するのはスケールが実際に単一ノードを超える場合のみ。

• ACID、結合、複雑なクエリの整合性が最優先
• 何よりもスケール。関連/結合は弱い

推奨: リレーショナルデータベース (RDBMS)

構造化され強く関連したデータを持ち、トランザクションの整合性を必要とするワークロードにとって適切なデフォルト。ACID 保証、成熟した SQL クエリエンジン、結合により、複雑な問いに確実に答えられる。

推奨: ドキュメントデータベース

スキーマが頻繁に変化する柔軟でネストしたデータを、自然な形 (JSON 形式のドキュメント) で保存する。主に単一ドキュメント単位で読み書きし、結合が少なく、水平スケールが必要なアプリケーションに適する。

推奨: キーバリューストア / キャッシュ

キーによる非常に高速な読み書きが必要で、複雑なクエリを必要としないワークロード向けに設計されている。通常はメモリ上で動作し、マイクロ秒/ミリ秒単位のレイテンシを提供する。キャッシュ、セッション、カウンタなどの用途に最適。

推奨: 検索 / 分析エンジン

全文検索、関連度ランキング、ファセットフィルタリング、大量のログ/テキスト分析に特化した転置インデックスベースのエンジン。リレーショナルの LIKE クエリでは実現できない検索体験を提供する。