データストレージの3つのかたち
ほとんどのデータベースは3つの系統に分かれます。製品を暗記する必要はありません — 自分の問題にどの かたち が合うかを見分けられればいいのです。
| タイプ | 例 | 最適な用途 | トレードオフ |
|---|---|---|---|
| リレーショナル (SQL) | PostgreSQL、MySQL、SQLite | 関係を持つ構造化データ。お金や正確さが重要なものすべて | 先にスキーマを設計しなければならない。書き込みを非常に大きくスケールさせるのは難しい |
| ドキュメント / NoSQL | MongoDB、Firestore、DynamoDB | 柔軟またはネストしたデータ、速いイテレーション、多様なレコード形状 | 一貫性のないデータを作りやすい。関係性やレポートが扱いにくくなる |
| キーバリュー | Redis、Memcached、Cloudflare KV | キャッシュ、セッション、カウンター、既知のキーによる高速な参照 | 内容による問い合わせができない。通常は信頼できる情報源 (source of truth) ではない |
90%のプロジェクトに良いデフォルト: リレーショナルデータベース (Postgres) から始めること。 成熟していて、予測可能で、構造を強制し、本物のアプリが必ず育てていく関係性を扱えます。データが本当に形を持たないときはドキュメントストアに手を伸ばし、キーバリューストアは主要なストアではなく 補助的な 層 (キャッシュ) として使います。
避けるべき罠は、雰囲気で選ぶことです。「NoSQLのほうがスケールする」が真なのは、ほとんどのアプリが決して到達しない狭い問題群においてだけで、しかもその代償は、データを信頼できるものにする一貫性保証を手放すことです。システム設計動画で最も格好よく聞こえるかたちではなく、自分の データ に合うかたちを選びましょう。迷ったらリレーショナルが安全な賭けです — キャッシュやドキュメントストアは後からいつでも足せますが、こんがらがったNoSQLデータモデルをほどくのは苦痛です。