データストアの配置方針 ― RDBMS/NoSQL/キャッシュ/検索の組合せ ― 生成AI時代のアーキテクチャ超入門

本記事について

当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「システムアーキテクチャ」カテゴリ第6弾として、データストアの全体配置方針について解説する記事です。

2026年は RDBMS・KVS・検索エンジン・時系列DB・ベクトルDB・オブジェクトストレージを用途特化で組み合わせるのがデフォルト。「何をどこに置くか」の設計が運用コストとレイテンシを決めます。本記事はシステム全体の配置方針に特化し、各カテゴリ概要・Polyglot Persistence・スケール戦略・バックアップ設計まで扱います（個別アプリの詳細選定は別カテゴリ「データアーキテクチャ」へ）。

このカテゴリの他の記事

本記事の守備範囲

データストア選定は「システムアーキテクチャ段階の全体方針」と「個別アプリケーションアーキテクチャでの詳細選定」の2段階で決まります。本記事は前者、つまりシステム全体として何をどう配置するかに特化します。

記事	扱う範囲
本記事（システムアーキテクチャの全体方針）	システム全体の配置方針 / 各カテゴリの概要 / Polyglot Persistence / スケール戦略
個別アプリの詳細選定（別カテゴリ）	個別アプリの詳細選定 / 判定フロー / データ量別の段階選び
データモデリング（別カテゴリ）	テーブル設計・正規化・主キー・インデックス
データ基盤（別カテゴリ）	DWH / データレイク / BI 連携

本記事の立場は「システムアーキテクチャ設計時にRDBMS / NoSQL / キャッシュ / 検索 / オブジェクトストレージをどう組み合わせるか」の全体地図です。データ量や機能要件に基づく具体の選定フローは別カテゴリ「データアーキテクチャ」の記事で扱います。

本記事の問いは「どのデータストア種を組み合わせるか」です。個別の選定フローは別カテゴリで深掘りします。

一番引き返せない決定

データストアの選定は、システムアーキテクチャの中で最も後戻りが困難な判断です。アプリのコードは書き直せても、スキーマと大量データが積み上がった後のDB移行は桁違いに重く、数日〜数週間のダウンタイムが避けられないこともあります。

馴染みのある RDBMS（リレーショナルデータベース）だけで全部を賄うのは、もう現代的なやり方ではありません。現在は RDBMS・NoSQL・キャッシュ・検索エンジン・オブジェクトストレージを組み合わせるのが本命です。ここで「何を選んだか」は、そのまま向こう5〜10年を左右します。

「後から考える」が通用しない領域です。最初の判断が重要になります。

主な4カテゴリ

データストアは用途別に4つのカテゴリに大別できます。それぞれ得意な用途が異なるため、1つのシステム内で複数を組み合わせるのが現代の主流です。

カテゴリ	用途	代表例
RDBMS	構造化データ・整合性重視	PostgreSQL・MySQL
NoSQL	スケール重視・柔軟スキーマ	DynamoDB・MongoDB
キャッシュ	高速アクセス・一時データ	Redis・Memcached
検索エンジン	全文検索・集計	Elasticsearch・OpenSearch

加えてオブジェクトストレージ（S3等）が画像・動画・添付ファイルの保管先として使われます。どのデータをどこに置くかの設計センスが、アプリ全体のパフォーマンスと運用コストを決めます。

RDBMS（リレーショナルデータベース）

RDBMS は、データを表（テーブル）形式で管理し、SQLで操作する伝統的なデータベースです。ACIDトランザクション（Atomicity 原子性・Consistency 一貫性・Isolation 独立性・Durability 永続性）による強整合性を保証し、金融・業務アプリなどデータの正確性が絶対に必要な領域で圧倒的な実績があります。

製品	特徴	使いどころ
PostgreSQL	OSS決定版・JSON/全文検索/GIS対応	新規開発の第一候補
MySQL	普及度・軽快・情報量	Webサービス・既存互換
MariaDB	MySQLフォーク・完全OSS	MySQL代替・商用回避
Oracle Database	エンタープライズ・高機能	金融・基幹系
SQL Server	Microsoft系と密結合	.NET・Windows環境
Amazon Aurora	MySQL/PG互換・クラウド最適化	AWS上の新規構築

新規案件で特別な理由がない限り、PostgreSQLを選ぶのが鉄板です。JSON型・全文検索・GIS（位置情報）など多機能さがOSSの中で突出しており、拡張性でも他を引き離しています。MySQLは古くからのWebサービスに多く、今も現役で戦えますが、新規選定では PostgreSQL に軍配が上がる場面がほとんどです。

新規の第一候補はPostgreSQLです。迷ったらここから疑います。

NoSQLの4系統

NoSQL は「Not Only SQL」の略で、RDBMS以外のデータベース全般を指します。スケール性と柔軟なデータ構造が特徴で、用途により4つの系統に分かれます。

系統	代表	得意領域
KVS（キーバリュー）	Redis / DynamoDB / Memcached	キャッシュ・セッション
ドキュメント	MongoDB / DocumentDB / Firestore	JSON形式・階層データ
ワイドカラム	Cassandra / HBase / BigTable	時系列・大量書き込み
グラフ	Neo4j / Neptune	ソーシャル・関連分析

NoSQLの基本思想は「RDBMSの整合性を犠牲にしてでもスケールさせたい」です。ECの商品カタログ・SNSの投稿履歴・IoTログのような「大量データを高速に書き込みたい」ケースで本領を発揮します。逆に整合性が命の業務アプリで選ぶのは筋が悪いです。

DynamoDB と Redis

DynamoDB（AWS製）とRedisは、NoSQLの中でも特に実務でよく使われる2大製品です。似たKVSですが、得意領域がはっきり違います。

DynamoDBはフルマネージドの分散KVSで、「スケールを意識せず書き込める」のが最大の利点です。理論上無限にスケールし、サーバーレスアーキテクチャと相性が良いため、高トラフィックAPIで選ばれます。ただしJoin・集計が苦手で、RDBMSと逆に「先にアクセスパターンを決めてテーブル設計する」発想が必要です。

Redisはインメモリキャッシュ用途のデファクトスタンダードです。メモリ上にデータを置くためミリ秒未満のレスポンスを実現し、セッション管理・ページキャッシュ・レート制限・ランキング（ZSET）・Pub/Sub など用途が幅広いです。

用途	推奨
固定アクセスパターンの大規模書き込み	DynamoDB
セッション・ページキャッシュ	Redis / ElastiCache
リアルタイムランキング・リーダーボード	Redis（ZSET）

DynamoDBはスケール特化、Redisはキャッシュ特化。役割が違います。

検索エンジン

検索エンジンは、文章や商品説明などのテキストの中身を素早く検索する専用DBです。RDBMSでも LIKE '%キーワード%' は可能ですが、数万件を超えると遅すぎて実用にならないため、専用の検索エンジンを別に用意するのが定石です。

製品	特徴	使いどころ
Elasticsearch / OpenSearch	全文検索のデファクト・ログ分析も可	本格的な検索・ログ集約
Meilisearch / Typesense	軽量・モダン・セットアップ容易	中小規模アプリ
PostgreSQL全文検索	追加DB不要・pg_bigm等	小規模・手軽に始める
Algolia	マネージドSaaS・UI充実	スピード重視のサービス

日本語全文検索では、形態素解析（Kuromoji）の設定が鍵を握ります。日本語は単語の切れ目が明確でないため、適切な辞書を使わないと「東京都」が「東京」と「都」に分解される、といった検索漏れが連発します。

オブジェクトストレージ

オブジェクトストレージは、画像・動画・PDFなどのファイルを保管するための専用ストレージです。RDBMSに画像を直接入れるとDBが肥大化して性能が落ちるので、「メタデータはRDBMS、実体はオブジェクトストレージ」という分離が基本です。ここを守らないのは典型的な地雷踏みです。

サービス	提供元	特徴
Amazon S3	AWS	業界デファクト・豊富な統合
Azure Blob Storage	Azure	階層ストレージ充実
Google Cloud Storage	GCP	BigQuery連携が強力
Cloudflare R2	Cloudflare	Egress無料で低コスト

CDN（CloudFront等）と組み合わせると、配信の高速化とトラフィックコスト削減が同時に効きます。Cloudflare R2 は S3互換で帯域課金がないため、動画配信など帯域が支配的な用途で注目されています。

用途別の選び方

複数のデータストアを役割ごとに使い分けるのが現代の主流です。典型的な構成は以下の通りです。

用途	推奨データストア
トランザクション主体のアプリ	PostgreSQL / Aurora
高速セッション・キャッシュ	Redis / ElastiCache
固定キーの超スケール書き込み	DynamoDB
商品検索・ログ集計	OpenSearch / Elasticsearch
時系列メトリクス	Timestream / InfluxDB
画像・動画・添付ファイル	S3 / R2（オブジェクトストレージ）
データ分析・BI（Business Intelligence、業務データを分析・可視化する領域）	BigQuery / Redshift / Snowflake

用途ごとに最適なDBを組み合わせる考え方を Polyglot Persistence（多言語永続化）と呼びます。

Polyglot Persistence

Polyglot Persistence は、1つのシステムで複数のデータストアを組み合わせて使う設計思想です。「1つのDBで全部」は設計的には綺麗に見えても、用途ごとに最適なDBを選ぶ方が性能・コスト・運用性のバランスで勝ちます。

flowchart LR
    APP([アプリ])
    PG[(PostgreSQL<br/>マスタ・注文・ユーザー)]
    RD[(Redis<br/>セッション・キャッシュ)]
    OS[(OpenSearch<br/>商品検索・ログ集計)]
    S3[(S3<br/>画像・動画・添付)]
    DDB[(DynamoDB<br/>高スループットログ)]
    APP -->|RDB| PG
    APP -->|KVS| RD
    APP -->|全文検索| OS
    APP -->|ファイル| S3
    APP -->|時系列| DDB
    classDef app fill:#fef3c7,stroke:#d97706;
    classDef rdb fill:#dbeafe,stroke:#2563eb;
    classDef kvs fill:#fee2e2,stroke:#dc2626;
    classDef search fill:#fae8ff,stroke:#a21caf;
    classDef obj fill:#f0f9ff,stroke:#0369a1;
    class APP app;
    class PG rdb;
    class RD kvs;
    class OS search;
    class S3,DDB obj;

ECサイト・SaaSプロダクトでは、この種の分業構成がほぼ標準です。各データストアは同期的に連携せず、非同期メッセージキュー（SQS/Kafka等）でつなぐのが障害耐性の観点でも筋がいい設計です。同期で繋いでしまうと、1つのDBが落ちた瞬間に連鎖停止が起きます。

「1DBで全部」は過去の話。役割ごとに最適な道具を使うのが現代流です。

スケールとレプリケーション

データ量やアクセス数が増えると、DBは単一サーバーで処理しきれなくなります。レプリケーションとシャーディングでスケールさせるのが基本戦略です。

方式	仕組み	用途
リードレプリカ	読み取り専用のコピーを増やす	読み取り重視のアプリ
シャーディング	データを複数サーバーに分散	書き込みも分散したい
マルチAZ	可用性ゾーン冗長化	高可用性要件
マルチリージョン	地理的冗長・DR対策	災害対策・グローバル配信

クラウドマネージドDB（Aurora・Cloud SQL・Cosmos DB）を使うと、これらの複雑な構成をスイッチひとつで有効化できます。自前構築との運用コスト差は圧倒的で、「自前でシャーディングを組むのは相応の体力がないと手を出さない方がいい」というのが実務的な結論です。

バックアップとリストア

データストアのバックアップ戦略は、障害・誤操作・ランサムウェア対策の最後の砦です。肝心なのは「取っているか」ではなく「戻せるか」リストア訓練を定期実施しないと、いざという時に復旧できない事例が今でも繰り返し発生しています。

観点	内容
RPO（Recovery Point Objective）	何分前まで戻せるか（データ損失の許容量）
RTO（Recovery Time Objective）	何分で復旧するか（停止時間の許容量）
PITR（Point-in-Time Recovery、任意時点復元）	過去の任意時点への復元機能
クロスリージョンバックアップ	別リージョンに保管し災害対策
保管期間	法的要件（税務は7年等）を満たす

クラウドマネージドDBはPITRが標準機能で、過去5〜35日の任意の時点に戻せます。年次・月次の長期保管は別途エクスポートが必要なケースが多いです。

データ量・トラフィック別のDB選定

「なんとなくPostgreSQL」は正解率が高いですが、データ量とトラフィックの段で選ぶ最適解が変わります。下記は2026年4月時点の目安です。

データ量	書き込み RPS	読み取り RPS	推奨メインDB	補助の典型構成
〜10万行	〜10	〜100	PostgreSQL（単一インスタンス）	なし
〜1000万行	〜100	〜1,000	PostgreSQL + リードレプリカ1本	Redis（セッション）
〜10億行	〜1,000	〜10,000	Aurora / Cloud SQL + レプリカ複数	Redis + OpenSearch
〜100億行	〜10,000	〜100,000	Aurora + シャーディング or DynamoDB	Redis + Kafka + ClickHouse
100億行〜	10,000〜	100,000〜	DynamoDB / Spanner / Cassandra	Kafka + データレイク

データ量が1テーブル1,000万行を超えたらインデックス設計とパーティション検討、1億行でシャーディング検討、10億行でNoSQL選択肢が現実的。というのが経験則です。先にキャッシュ（Redis）を足すのが効く場面は多く、DBを替える前にキャッシュで済む検証を先にすべきです。

悩んだらPostgreSQL単一 → キャッシュ追加 → レプリカ追加 → シャーディングの順。いきなりNoSQLは筋が悪いです。

スキーマ変更・マイグレーションの鬼門

「DBは後から変えられない」の本番を決めるのがスキーマ変更です。ここで事故ると本番が数時間止まるので、禁じ手を徹底回避します。

禁じ手	なぜダメか
列のリネームを1回のマイグレーションで実施	旧コードが動いているインスタンスが即死。expand/contract（列追加→両方書き込み→切替→旧列削除）で3回に分ける
1,000万行以上のテーブルに NOT NULL 列を即時追加	既存レコードで制約違反、マイグレーションが何時間も戻らない
インデックス追加を通常の CREATE INDEX で実行	テーブル全体がロックされ、本番が書き込み不能に。PostgreSQLなら CREATE INDEX CONCURRENTLY、MySQLなら pt-online-schema-change / gh-ost
マイグレーション前のバックアップを取らずに本番適用	ミスった瞬間にリストアの道が消える
DBAがGUIで直接本番DDLを実行	変更履歴が残らず、監査・再現・ロールバックが全て不可能になる
マイグレーションとコードデプロイを同一トランザクション化	ロールバック時にスキーマだけ戻せない／戻せるが新旧コード共存で壊れる
マイグレーションツール（Flyway / Liquibase / Prisma Migrate）を使わずSQL手書き運用	バージョン管理・再現・CI検証ができず、本番と開発のスキーマが乖離

2017年1月31日の GitLab DB削除事件（エンジニアが本番と開発を取り違えて rm -rf、5種類のバックアップが全滅）は、バックアップ戦略だけでなくDB操作の権限管理・二重確認の重要性を示す事例です。

スキーマ変更は「マイグレーションツール + PR レビュー + 段階適用」の3点セットを省略すると必ず事故ります。

AI時代の視点

AI駆動開発が前提になると、データストアの選定軸は「スキーマをコードで管理できるか」「AIがクエリ・マイグレーションを正確に書けるか」が決定打になります。

PostgreSQL + Prisma/Drizzle のような ORM（Object-Relational Mapping、DBの行をプログラムのオブジェクトとして扱う層）+ マイグレーションツール（スキーマ変更を版管理する仕組み）の組み合わせは、AIがスキーマ定義からマイグレーションSQLまで一気通貫で生成でき、設計と実装の距離が劇的に縮まります。独自クエリ言語のNoSQLやマネージドSaaSは、AIの学習データが薄く生成精度が落ちる傾向があります。

AI時代に有利	AI時代に不利
PostgreSQL + ORM（Prisma/Drizzle/TypeORM）	独自クエリのNoSQL（AIが不慣れ）
SQLベース・標準規格に近い	ベンダー独自のGUIデータ操作
マイグレーションをコードで管理	スキーマがコード外にある
Infrastructure as CodeでDB構成も管理	コンソール手作業でのDB設定

スキーマ設計の本質的な難しさ（RDBMSの非正規化・DynamoDBのアクセスパターン先決め）は、AIでも解決できません。丸投げするとアンチパターンを量産するので、人間が設計方針を決め、AIに実装させるのが正解です。

AI時代でもPostgreSQLの優位性は継続します。スキーマをコードで管理する仕組みが決定的に重要です。

よくある勘違い

データストア選定で非専門家・若手エンジニアが引っかかるパターンです。

• NoSQLはRDBMSの上位互換 → 本当はこう：NoSQLはスケール性のためにJoin・整合性を犠牲にした設計。業務アプリで「後からJoinが欲しい」になると設計をやり直す羽目になります。「流行っているから」で選ぶのは甘い選択
• バックアップさえ取っておけば安心 → 本当はこう：取るのは簡単、戻せるかは別問題。リストア訓練をしていないバックアップは、取っていないのと同義。定期的に実戻しするところまでが運用
• マネージドDBは高いから自前のほうが安い → 本当はこう：時間単価を含めるとほぼ常にマネージドの方が安いです。フェイルオーバー・バックアップ・パッチ・監視を自前で組むコストを無視した比較は、あとで必ずしっぺ返しが来ます
• 画像もDBに入れた方が一貫性がある → 本当はこう：DBが肥大化してバックアップ時間とI/Oが爆発します。画像はオブジェクトストレージ、URL参照だけDBに持つのが鉄則

MongoDB の「なんとなく」事件（業界事例）

スタートアップで「スキーマを自由に変えたいから」という理由だけで MongoDB を選び、半年後にECの注文履歴から売上レポートを集計するフェーズに入った瞬間に、Join もトランザクションもほしい仕様が次々に出てきて現場が止まった。という事例は一度ならず聞かれます。結局 PostgreSQL に移行し、移行作業そのものに3ヶ月を溶かしたチームもあるといいます。

2018年頃、似たような流れで MongoDB 採用のスタートアップを見ていたことがありますが、注文集計の要件が出た瞬間にクエリが書けず、結局BIツールに回すためにPostgreSQLへの日次同期を入れる羽目になったと聞きました。

教訓は、「DB選定は今の楽さではなく、1年後の要件で決める」ということです。特にトランザクションが絡むアプリは、悩んだらRDBMSから始める。必要になったときだけNoSQLを足す、の順序を逆にすると痛い目を見ます。

「スキーマレスが楽」は、集計が始まるまでの話です。

決めるべきこと — あなたのプロジェクトでの答えは？

以下の項目について、あなたのプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。

• メインDB（PostgreSQL / MySQL / Aurora / DynamoDB）
• キャッシュ戦略（Redis / Memcached / アプリ内 / CDN）
• 検索基盤（OpenSearch / PostgreSQL全文検索 / SaaS）
• ファイルストア（S3 / R2 / Blob Storage）
• バックアップ方針（RPO / RTO / 保管期間）
• 暗号化（保存時・転送時・鍵管理）
• スケール戦略（レプリカ / シャーディング / マルチリージョン）

よくある失敗

• 「なんとなく」でMongoDBを選ぶ → Join多発でパフォーマンス崩壊。トランザクションアプリにNoSQLは向かない
• DynamoDBを選んだが後で複雑なクエリが必要に ― 設計し直しで数週間の後戻り
• バックアップは取っているがリストア未検証 ― 本番障害時に「戻せない」ことが判明
• 画像をDBに直接格納 → DBが肥大化して性能劣化。S3に移行する大工事に発展
• Redisをデフォルト設定で本番投入 ― 永続化設定を忘れて再起動でデータ全消失。2017年初頭には、MongoDB・Elasticsearch・Redis の「デフォルト認証なし・インターネット公開」構成を狙ったランサムウェア攻撃が世界規模で発生し、数万台が暗号化・削除される事件があった。デフォルト設定を疑わず本番に上げるのは、今でも最大級の事故入口

最終的な判断の仕方

データストア選定は最も後戻りできない決定なので、最初に問うべきは「何を優先するか」です。強整合性なのか、スケール性なのか、スキーマの柔軟性なのか。この優先順位を決めずに「NoSQLが流行だから」で選ぶと、数年後にJoinが必要になって再設計の大工事になります。

原則は強整合・リレーショナルの要件があるならRDBMSで、それで困る場面だけ他のカテゴリを足します。

現実解は、PostgreSQLを中心に、用途特化のDBを必要最小限で足す構成（Polyglot Persistence）です。「1つのDBで全部」でも「全部別々」でもなく、役割分担の粒度を運用体制に合わせて決める。

AI時代の観点でも、SQL + ORM の組み合わせが生成精度で圧倒的に有利で、独自クエリ言語のNoSQLは信頼性が落ちます。

選定の優先順位をまとめると次の通りです。

1. データの性質（強整合／結果整合／キャッシュ）でカテゴリを絞る
2. 規模とアクセスパターンから用途別DBを足す判断（先に正規化DBで始める）
3. スキーマをコードで管理できるかをAI時代の必須要件にする
4. バックアップ + リストア訓練の運用コストを前提に置く

「PostgreSQLから始めて、足りなくなってから足す」のが基本です。最初から多層構成は運用が破綻します。

まとめ

本記事はシステムアーキテクチャレベルでのデータストア配置方針について、Polyglot Persistence・スケール戦略・スキーマ変更の鬼門まで含めて解説しました。如何だったでしょうか。

新規はPostgreSQL中心に、用途特化を必要最小限で足す（キャッシュにRedis、検索にOpenSearch、画像にS3）のが2026年の鉄板です。最初から多層構成は運用が破綻するので、足りなくなってから足す順序が現実的です。

次回は「ネットワーク」（VPC・サブネット・CIDR設計）について解説します。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

それでは次の記事も閲覧いただけると幸いです。