データ保存方法選定ガイド
データ保存方法選定ガイド
このドキュメントは、プロジェクトでデータを保存する方法を選定する際の検討事項をまとめたものです。テキストファイルから始まり、データベース技術がどのように進化してきたかを理解することで、各技術の本質的な特徴と適切な用途が見えてきます。
データ保存方法の進化の歴史
各技術は、前世代の技術が抱えていた課題を解決するために生まれてきました。単純なテキストファイルから始まり、構造化、整合性、スケーラビリティ、運用性へと進化してきました。
第一世代：テキストファイルによるデータ保存（1970年代〜）
CSV / プレーンテキスト
生まれた背景: プログラムが扱う最も原始的なデータ形式。シンプルで人間が読み書き可能。
解決した課題:
- データの永続化（プログラム終了後もデータを保持）
- 人間が直接編集可能
- 異なるシステム間でのデータ交換
- 実装のシンプルさ
残された課題:
- データの整合性保証がない（重複、不整合が発生しやすい）
- 検索・更新が非効率（全件走査が必要）
- 同時アクセス制御がない（複数プロセスからのアクセスで不整合）
- データ型の制約がない
- リレーションの表現が困難
影響: データ保存の基礎。現在でも小規模データの交換形式として広く使用される。
JSON / YAML / XML
生まれた背景: CSVでは表現できない階層構造や複雑なデータを扱うため。
解決した課題:
- 階層構造データの表現
- データ型の表現（文字列、数値、真偽値、配列、オブジェクト）
- 構造化されたデータの読み書き
- 人間が読みやすい形式（特にYAML）
残された課題:
- データの整合性保証がない（スキーマ検証が必要）
- 検索・更新が非効率（全件走査が必要）
- 同時アクセス制御がない
- 大規模データには不向き
- リレーションの表現が困難
影響: 設定ファイル、APIのデータ交換形式として標準化。現代のWeb開発の基盤。
第二世代：ファイルベースデータベース（1980年代〜）
SQLite (2000年)
生まれた背景: アプリケーションに組み込める軽量なデータベース。サーバー不要で、ファイルベースながらSQLを実行可能。
解決した課題:
- SQLによるクエリ: 効率的な検索・更新
- ACID特性: トランザクションによる整合性保証
- 型システム: データ型の制約
- サーバー不要: 単一ファイルで完結
- 同時アクセス制御: ロック機構による整合性
残された課題:
- 同時書き込みが限定的（読み取りは複数、書き込みは1つのみ）
- 大規模データには不向き（数GB以上）
- ネットワーク経由でのアクセスが困難
- 分散処理ができない
影響: モバイルアプリ、デスクトップアプリ、小規模Webアプリケーションで広く採用。最も使用されているデータベースの一つ。
第三世代：リレーショナルデータベース（1970年代〜、1990年代に標準化）
MySQL / PostgreSQL
生まれた背景: 複数のアプリケーションから同時にアクセスし、大規模なデータを効率的に管理するため。リレーショナルモデルによるデータの正規化と整合性保証。
解決した課題:
- リレーショナルモデル: データの正規化、重複排除
- 複数ユーザー同時アクセス: 高並行性
- ACID特性: トランザクションによる強固な整合性保証
- SQL標準: 統一的なクエリ言語
- インデックス: 高速な検索
- 外部キー制約: リレーションの整合性保証
残された課題:
- 水平スケーリングが困難（シャーディングは複雑）
- スキーマ変更が大変（マイグレーションが必要）
- 柔軟なスキーマ変更に対応しにくい
- 大量の非構造化データには不向き
- 運用・管理の専門知識が必要
影響: エンタープライズアプリケーションの標準。現代のWebアプリケーションの大部分で使用されている。
MySQL (1995年):
- 軽量で高速、Webアプリケーション向け
- オープンソースで広く採用
PostgreSQL (1996年):
- 高機能で標準SQL準拠
- 拡張性が高く、エンタープライズ向け
第四世代：NoSQLデータベース（2000年代後半〜）
生まれた背景: Web 2.0の台頭により、リレーショナルDBでは対応困難な要件（大規模スケーリング、柔軟なスキーマ、高速な読み書き）が求められた。
MongoDB (2009年)
解決した課題:
- ドキュメント指向: JSONライクな柔軟なスキーマ
- 水平スケーリング: シャーディングによる分散処理
- スキーマ変更が容易: マイグレーション不要
- 非構造化データの扱い: 多様なデータ形式に対応
残された課題:
- ACID特性が限定的（複数ドキュメントのトランザクションは制限あり）
- 結合（JOIN）ができない
- 整合性保証が弱い
- メモリ消費が大きい
影響: 非構造化データや柔軟なスキーマが必要なアプリケーションで広く採用。
Redis (2009年)
解決した課題:
- インメモリデータベース: 極めて高速な読み書き
- 多様なデータ構造: 文字列、リスト、セット、ハッシュ等
- キャッシュ用途: 頻繁にアクセスするデータの高速化
- Pub/Sub: リアルタイム通信
残された課題:
- 永続化がオプション（メモリ主体）
- データ容量が限定的（メモリサイズに依存）
- ACID特性が限定的
- リレーションの表現が困難
影響: キャッシュ、セッション管理、リアルタイムアプリケーションで標準的に使用。
その他のNoSQL
Cassandra: 大規模分散環境での高可用性、書き込み性能重視
Elasticsearch: 全文検索、ログ分析、可視化
第五世代：クラウドデータベース・BaaS（2010年代〜）
Firebase Realtime Database / Firestore (2011年)
生まれた背景: バックエンドの運用負荷を削減し、開発者がフロントエンド開発に集中できるように。
解決した課題:
- サーバーレス: インフラ運用が不要
- リアルタイム同期: クライアント間での自動データ同期
- 認証・セキュリティ: 組み込みの認証システム
- スケーリング: 自動的なスケーリング
- マルチプラットフォーム: Web、モバイル、サーバーから同一API
残された課題:
- ベンダーロックイン（特定クラウドへの依存）
- クエリ機能が限定的（リレーショナルDBほど柔軟ではない）
- コストが高い（大規模利用時）
- 細かい制御ができない
影響: モバイルアプリ、リアルタイムアプリケーション、スタートアップで広く採用。
Supabase (2020年)
生まれた背景: Firebaseの代替として、オープンソースでPostgreSQLベースのBaaS。
解決した課題:
- PostgreSQLベース: リレーショナルDBの強力な機能を活用
- オープンソース: ベンダーロックインの回避
- リアルタイム機能: Firebaseと同様のリアルタイム同期
- 標準SQL: 既存のSQL知識を活用可能
残された課題:
- 比較的新しい（エコシステムが成長中）
- Firebaseほど成熟していない
- 企業での採用事例が限定的
影響: Firebaseのオープンソース代替として注目。PostgreSQLを活用したい開発者に支持。
第六世代：分散データベース・NewSQL（2010年代後半〜）
Google Spanner (2012年公開、2017年一般提供)
生まれた背景: グローバル規模での分散処理とACID特性を両立。リレーショナルDBの整合性とNoSQLのスケーラビリティを統合。
解決した課題:
- グローバル分散: 複数のリージョンにまたがるデータ配置
- ACID特性: 分散環境でも強固な整合性保証
- 水平スケーリング: 大規模データの処理
- 一貫性: グローバルな一貫性保証
残された課題:
- コストが高い（エンタープライズ向け）
- 複雑な運用
- オープンソース版は限定的（CockroachDB等が代替）
影響: グローバルスケールのアプリケーションで採用。分散DBの新しいパラダイムを示した。
CockroachDB (2015年)
生まれた背景: Spannerのオープンソース代替。PostgreSQL互換で、グローバル分散とACID特性を両立。
解決した課題:
- PostgreSQL互換: 既存のSQL知識を活用
- グローバル分散: 複数リージョンでのデータ配置
- ACID特性: 分散環境でも整合性保証
- オープンソース: ベンダーロックインの回避
残された課題:
- エコシステムが限定的
- 運用が複雑
- 企業での採用事例が少ない
影響: Spannerのオープンソース代替として注目。グローバル分散が必要なアプリケーションで採用。
技術の系譜と選択の指針
シンプルさ重視の系譜
CSV/テキスト → JSON/YAML → SQLite選択の指針: 小規模データ、組み込み用途、シンプルな要件の場合は、この系譜を検討。
整合性重視の系譜
ファイル → SQLite → MySQL/PostgreSQL → Spanner/CockroachDB選択の指針: データの整合性が最重要の場合、リレーショナルDBを選択。グローバル分散が必要な場合はNewSQL。
スケーラビリティ重視の系譜
MySQL/PostgreSQL → MongoDB → Spanner/CockroachDB選択の指針: 大規模データ、高トラフィックが必要な場合。水平スケーリングが必要な場合はNoSQLまたはNewSQL。
運用性重視の系譜
自前運用DB → Firebase → Supabase選択の指針: 運用負荷を削減したい場合、BaaSを検討。PostgreSQLが必要な場合はSupabase、リアルタイム機能が重要な場合はFirebase。
パフォーマンス重視の系譜
ファイル → SQLite → MySQL/PostgreSQL → Redis → インメモリDB選択の指針: 速度が最優先の場合、インメモリDB（Redis）を検討。ただし、永続化要件を考慮。
現在の主要技術の比較
SQLite (2000年)
強み:
- サーバー不要（ファイルベース）
- 軽量で高速
- SQLによるクエリ
- ACID特性
- 組み込みが容易
弱み:
- 同時書き込みが限定的
- 大規模データには不向き
- ネットワーク経由アクセスが困難
適している用途: モバイルアプリ、デスクトップアプリ、小規模Webアプリケーション、組み込みシステム
選ぶべき場合:
- サーバー運用を避けたい
- 単一アプリケーションでの使用
- 小〜中規模のデータ（数GB以下）
- 組み込み用途
PostgreSQL / MySQL
強み:
- 強固なACID特性
- 標準SQL対応
- 豊富な機能とエコシステム
- 高い信頼性
- 多くの採用事例
弱み:
- 水平スケーリングが困難
- スキーマ変更が大変
- 運用・管理の専門知識が必要
- 柔軟なスキーマ変更に対応しにくい
適している用途: エンタープライズアプリケーション、Webアプリケーション、トランザクション処理が必要なシステム
選ぶべき場合:
- データの整合性が最重要
- リレーショナルデータが中心
- 標準SQLが必要
- 複数のアプリケーションからアクセス
- エンタープライズ要件（セキュリティ、監査等）
PostgreSQL vs MySQL:
- PostgreSQL: 高機能、標準SQL準拠、拡張性が高い、エンタープライズ向け
- MySQL: 軽量で高速、Webアプリケーション向け、シンプル
MongoDB (2009年)
強み:
- 柔軟なスキーマ（ドキュメント指向）
- 水平スケーリング
- スキーマ変更が容易
- 非構造化データの扱い
- JSONライクなデータ形式
弱み:
- ACID特性が限定的
- 結合（JOIN）ができない
- 整合性保証が弱い
- メモリ消費が大きい
- クエリ機能が限定的
適している用途: 非構造化データ、柔軟なスキーマが必要なアプリケーション、大規模スケーリングが必要な場合
選ぶべき場合:
- スキーマが頻繁に変更される
- 非構造化データが多い
- 水平スケーリングが必要
- リレーションが複雑でない
- 高速な読み書きが重要
Redis (2009年)
強み:
- 極めて高速（インメモリ）
- 多様なデータ構造
- キャッシュ用途に最適
- Pub/Subによるリアルタイム通信
- セッション管理に適している
弱み:
- 永続化がオプション（メモリ主体）
- データ容量が限定的
- ACID特性が限定的
- リレーションの表現が困難
適している用途: キャッシュ、セッション管理、リアルタイムアプリケーション、キュー処理
選ぶべき場合:
- キャッシュが必要
- セッション管理が必要
- リアルタイム通信が必要
- 極めて高速な読み書きが必要
- 永続化は重要ではない、または補助的な用途
Firebase / Firestore (2011年)
強み:
- サーバーレス（インフラ運用が不要）
- リアルタイム同期
- 認証・セキュリティが組み込み
- 自動スケーリング
- マルチプラットフォーム対応
弱み:
- ベンダーロックイン
- クエリ機能が限定的
- コストが高い（大規模利用時）
- 細かい制御ができない
適している用途: モバイルアプリ、リアルタイムアプリケーション、スタートアップ、プロトタイプ開発
選ぶべき場合:
- バックエンド運用を避けたい
- リアルタイム同期が必要
- モバイルアプリが中心
- 迅速な開発が必要
- ベンダーロックインを許容できる
Supabase (2020年)
強み:
- PostgreSQLベース（強力な機能）
- オープンソース（ベンダーロックイン回避）
- リアルタイム機能
- 標準SQLが使用可能
- Firebaseの代替
弱み:
- 比較的新しい（エコシステムが成長中）
- Firebaseほど成熟していない
- 企業での採用事例が限定的
適している用途: PostgreSQLを活用したいBaaS、オープンソース重視のプロジェクト、Firebaseの代替
選ぶべき場合:
- PostgreSQLが必要
- オープンソースを重視
- ベンダーロックインを避けたい
- リアルタイム機能が必要
- Firebaseの代替を検討
Spanner / CockroachDB
強み:
- グローバル分散
- ACID特性（分散環境でも）
- 水平スケーリング
- グローバルな一貫性保証
弱み:
- コストが高い
- 複雑な運用
- エコシステムが限定的
- 企業での採用事例が少ない
適している用途: グローバルスケールのアプリケーション、複数リージョンでの一貫性が必要な場合
選ぶべき場合:
- グローバル分散が必要
- 複数リージョンでの一貫性が必要
- 大規模スケーリングが必要
- ACID特性が最重要
- コストを許容できる
選定時の実践的な検討事項
技術の進化の流れを理解した上で、プロジェクトの要件に合わせて選定します。
1. データの特性
データの規模
- 小規模（数MB〜数GB）: ファイル、SQLite、PostgreSQL/MySQL
- 中規模（数GB〜数TB）: PostgreSQL/MySQL、MongoDB
- 大規模（数TB以上）: MongoDB、Spanner/CockroachDB、分散DB
データの構造
- 構造化データ（リレーショナル）: PostgreSQL/MySQL、CockroachDB
- 非構造化データ: MongoDB、Firebase/Firestore
- 半構造化データ: MongoDB、PostgreSQL（JSON型対応）
データの整合性要件
- 最重要（金融取引等）: PostgreSQL/MySQL、Spanner/CockroachDB
- 重要: PostgreSQL/MySQL、SQLite
- やや重要: MongoDB、Firebase/Firestore
- 重要ではない: Redis、ファイル
2. アプリケーションの要件
スケーラビリティ要件
- 垂直スケーリングで十分: PostgreSQL/MySQL、SQLite
- 水平スケーリングが必要: MongoDB、Spanner/CockroachDB、分散DB
同時アクセス要件
- 単一アプリケーション: SQLite、ファイル
- 複数アプリケーション（読み取り中心）: PostgreSQL/MySQL、SQLite
- 高並行書き込み: PostgreSQL/MySQL、MongoDB、Spanner/CockroachDB
リアルタイム要件
- 必要: Firebase/Firestore、Supabase、Redis Pub/Sub
- 不要: PostgreSQL/MySQL、MongoDB（ポーリング等で対応可能）
3. 運用・開発要件
運用負荷
- 最小化したい: Firebase/Firestore、Supabase、BaaS
- 許容できる: PostgreSQL/MySQL、MongoDB（自前運用）
- 完全にコントロールしたい: 自前運用DB
開発速度
- 迅速な開発が必要: Firebase/Firestore、Supabase、BaaS
- 標準的な速度: PostgreSQL/MySQL、MongoDB
- 最適化が重要: 自前運用DB
チームのスキル
- SQL経験あり: PostgreSQL/MySQL、SQLite
- NoSQL経験あり: MongoDB、Firebase/Firestore
- 未経験: Firebase/Firestore、Supabase（学習コストが低い）
4. コスト要件
初期コスト
- 最小化したい: オープンソース（PostgreSQL/MySQL、MongoDB、SQLite）
- 許容できる: BaaS（Firebase/Firestore、Supabase）
- 高額でも良い: エンタープライズDB、Spanner
運用コスト
- 最小化したい: BaaS（Firebase/Firestore、Supabase）
- 許容できる: オープンソース（自前運用）
- 高額でも良い: マネージドサービス、エンタープライズDB
選定チェックリスト
選定時に確認すべき項目をチェックリスト形式でまとめます。
データの特性
- データの規模（小規模/中規模/大規模）
- データの構造（構造化/非構造化/半構造化）
- データの整合性要件（最重要/重要/やや重要/重要ではない）
アプリケーション要件
- スケーラビリティ要件（垂直/水平）
- 同時アクセス要件（単一/複数/高並行）
- リアルタイム要件（必要/不要）
運用・開発要件
- 運用負荷（最小化/許容/完全コントロール）
- 開発速度（迅速/標準/最適化）
- チームのスキル（SQL/NoSQL/未経験）
コスト要件
- 初期コスト（最小化/許容/高額可）
- 運用コスト（最小化/許容/高額可）
- 長期的なコスト（ライセンス、スケーリング）
その他
- ベンダーロックインの許容
- オープンソースの要件
- セキュリティ要件
- 監査要件
- バックアップ・災害復旧要件