データストレージの3つのかたち
ほとんどのデータベースは3つの系統に分かれます。製品を暗記する必要はありません — 自分の問題にどの かたち が合うかを見分けられればいいのです。
| タイプ | 例 | 最適な用途 | トレードオフ |
|---|---|---|---|
| リレーショナル () | PostgreSQL、MySQL、SQLite | 関係を持つ構造化データ。お金や正確さが重要なものすべて | 先にスキーマを設計しなければならない。書き込みを非常に大きくスケールさせるのは難しい |
| ドキュメント / | MongoDB、Firestore、DynamoDB | 柔軟またはネストしたデータ、速いイテレーション、多様なレコード形状 | 一貫性のないデータを作りやすい。関係性やレポートが扱いにくくなる |
| キーバリュー | Redis、Memcached、Cloudflare KV | キャッシュ、セッション、カウンター、既知のキーによる高速な参照 | 内容による問い合わせができない。通常は信頼できる情報源 (source of truth) ではない |
3つのかたちは、データを本当に異なるやり方で保存します。並べて思い描いてみましょう:
リレーショナル (SQL) ドキュメント (NoSQL) キー・バリュー
行 + 列 自己完結した塊 1キー → 1バリュー
┌────┬───────┬──────┐ ┌──────────────────┐ ┌─────────┬─────────┐
│ id │ email │ name │ │ { │ │ key │ value │
├────┼───────┼──────┤ │ id, email, │ ├─────────┼─────────┤
│ 1 │ a@... │ Ana │ │ name, │ │ session │ "x9f2" │
│ 2 │ b@... │ Bob │ │ posts: [ ... ] │ │ count │ "42" │
└────┴───────┴──────┘ │ } │ └─────────┴─────────┘
テーブルが相互に └──────────────────┘ 中は検索不可 —
参照し合う すべて入れ子 キーで引くだけ
リレーショナルデータベースは、互いを参照し合えるスプレッドシートの集まりだと考えてください。それと対話するときに使う言語が SQL (Structured Query Language、構造化問い合わせ言語) です。90%のプロジェクトに良いデフォルト: リレーショナルデータベース (Postgres) から始めること。 成熟していて、予測可能で、構造を強制し、本物のアプリが必ず育てていく関係性を扱えます。データが本当に形を持たないときはドキュメントストアに手を伸ばし、キーバリューストアは主要なストアではなく 補助的な 層 (キャッシュ) として使います。
避けるべき罠は、雰囲気で選ぶことです。「NoSQL (SQLのテーブルを使わないデータベース — 柔軟で自由な形のレコードを保存する) のほうがスケールする」が真なのは、ほとんどのアプリが決して到達しない狭い問題群においてだけで、しかもその代償は、データを信頼できるものにする一貫性保証を手放すことです。システム設計動画で最も格好よく聞こえるかたちではなく、自分の データ に合うかたちを選びましょう。迷ったらリレーショナルが安全な賭けです — キャッシュやドキュメントストアは後からいつでも足せますが、こんがらがったNoSQLデータモデルをほどくのは苦痛です。