データモデルパノラマ（ドキュメント / グラフ / 時系列 / ベクトル）

核心となる問い

なぜすべてのデータをMySQLのテーブルに詰め込むことができないのか？ データがソーシャルネットワークの関係、毎秒100万件のセンサーデータのストリーム、あるいはAIが理解するための意味ベクトルである場合、リレーショナルテーブルでは力不足です。異なるデータの形状には、異なるモデリングアプローチが必要です。

1. リレーショナルの先へ：なぜ他のデータモデルが必要なのか？

リレーショナルデータベース（MySQL、PostgreSQL）は「テーブル＋行＋列」でデータを整理し、構造が固定され、関係が明確なビジネスデータに適しています。しかし、現実世界のデータはこれだけではありません：

データの形状	リレーショナルの課題	より適したモデル
ユーザープロファイル（フィールドが不定、ネスト構造）	頻繁なALTER TABLE、多くのNULL列	ドキュメントモデル
ソーシャルネットワーク（友達の友達の友達）	多段JOINでパフォーマンスが指数関数的に低下	グラフモデル
監視メトリクス（毎秒100万件の書き込み）	書き込みボトルネック、履歴データの膨張	時系列モデル
AIセマンティック検索（「意味が近い」コンテンツ）	セマンティック類似度を表現できない	ベクトルモデル

中核となる視点

リレーショナルの「代替」ではなく、「補完」です。ほとんどのシステムの中核業務は引き続きMySQL/PostgreSQLで動いていますが、特定のシナリオで専用データモデルを導入することで、桁違いのパフォーマンス向上が得られます。

2. ドキュメントモデル（Document）

2.1 ドキュメントモデルとは？

ドキュメントモデルはデータをJSON/BSONドキュメントとして保存し、各レコードが自己完結したドキュメントで、異なるフィールド構造を持つことができます。

json

{
  "_id": "user_1001",
  "name": "張三",
  "tags": ["VIP", "アクティブ"],
  "address": { "city": "北京", "district": "朝陽区" },
  "orders": [
    { "id": "o1", "amount": 299 },
    { "id": "o2", "amount": 599 }
  ]
}

主な特徴：

スキーマ制約なし：テーブル構造を事前定義する必要がなく、フィールドをいつでも追加・削除可能
ネスト構造：住所や注文がドキュメント内に直接埋め込まれ、1回の読み取りで全データを取得
水平スケーリング：シャーディングに自然に適しており、大量データに容易に対応

2.2 ドキュメント vs リレーショナル

比較項目	リレーショナル（MySQL）	ドキュメント（MongoDB）
データ構造	固定スキーマ、ALTER TABLEで変更	フレキシブルなスキーマ、いつでもフィールド追加
ネストデータ	複数テーブルのJOINが必要	ドキュメント内に直接ネスト
レコード間の関連	JOINが強力	関連クエリがやや弱い
適した場面	構造が安定したビジネスデータ	構造が変動しやすいコンテンツデータ

2.3 典型的なユースケース

CMSコンテンツ管理：記事、コメント、タグなど構造が多様
ユーザープロファイル：ユーザーによって異なる属性フィールド
商品カタログ：スマートフォンには「画面サイズ」、食品には「賞味期限」——フィールドが全く異なる
設定センター：各サービスの設定構造が統一されていない

よくある誤解

「MongoDBはデータ構造の設計が不要」——間違いです！ドキュメントモデルでも慎重な設計が必要です：ネストの深さは深すぎないようにし、頻繁に更新されるサブドキュメントは別のコレクションに分割すべきです。

3. グラフモデル（Graph）

3.1 グラフモデルとは？

グラフモデルはノード（Node）とエッジ（Edge）を使ってエンティティとその関係を表現します。各ノードはエンティティ、各エッジは関係であり、ノードとエッジの両方にプロパティを持たせることができます。

(張三) --[フォロー]--> (李四) --[フォロー]--> (王五)
   |                                    |
   +--------[購入]----> (iPhone) <--[購入]--+

3.2 グラフモデルの切り札：マルチホップクエリ

シナリオ：ソーシャルネットワークで「友達の友達の友達」を見つける

リレーショナルのアプローチ（3段JOIN）：

sql

SELECT DISTINCT f3.name
FROM friends f1
JOIN friends f2 ON f1.friend_id = f2.user_id
JOIN friends f3 ON f2.friend_id = f3.user_id
WHERE f1.user_id = 1001;

グラフデータベースのアプローチ（Cypherクエリ言語）：

cypher

MATCH (me)-[:FOLLOWS*1..3]->(target)
WHERE me.name = '張三'
RETURN DISTINCT target.name

リレーショナルではホップが増えるごとにJOINが増え、パフォーマンスが指数関数的に低下します。グラフデータベースはポインターを通じて直接関係を走査するため、マルチホップクエリのパフォーマンスはほぼ変わりません。

3.3 典型的なユースケース

ソーシャルネットワーク：友人レコメンド、共通のフォロー、影響力の伝播
ナレッジグラフ：エンティティ関係の推論（「誰の先生の学生は誰か」）
不正検知：資金のループ、関連口座ネットワークの発見
レコメンデーションシステム：ユーザー-商品-タグの関係グラフに基づく推薦

4. 時系列モデル（Time-Series）

4.1 時系列モデルとは？

時系列モデルはタイムスタンプを主軸とし、「時系列に書き込み、時間範囲でクエリする」シナリオに特化して最適化されています。

timestamp            device      cpu_usage   memory
2024-01-15 10:00:01  server-01   45%         12.3GB
2024-01-15 10:00:02  server-01   67%         12.5GB
2024-01-15 10:00:03  server-01   92%         14.1GB

4.2 なぜMySQLで時系列データを保存しないのか？

課題	MySQL	時系列データベース（InfluxDB）
書き込み速度	万件/秒	100万件/秒
履歴データ	手動削除、テーブルが大きくなり続ける	自動有効期限ポリシー（TTL）
集約クエリ	GROUP BYが遅い	内蔵ダウンサンプリング（5秒 → 1分平均）
ストレージ効率	汎用ストレージ、スペースの無駄	列指向圧縮、90%のスペース節約

4.3 典型的なユースケース

サーバー監視：CPU、メモリ、ディスクを毎秒収集
IoTセンサー：温度、湿度、GPS軌跡
金融相場：株価、取引量の秒単位データ
ログ分析：アプリケーションログのタイムライン集約

5. ベクトルモデル（Vector）

5.1 ベクトルモデルとは？

ベクトルモデルは、テキスト、画像、音声などの非構造化データをEmbeddingモデルを通じて高次元の数値ベクトルに変換し、ベクトル間の距離を計算することでセマンティック類似度を測定します。

「おいしい日本料理」 → Embedding → [0.82, 0.15, 0.91, 0.33, ...]
                                        ↓ コサイン類似度
「銀座の寿司の神様」  → [0.80, 0.18, 0.89, ...] → 96% 類似
「イタリアンピザ」    → [0.12, 0.85, 0.20, ...] → 31% 類似

5.2 ベクトル検索 vs キーワード検索

比較	キーワード検索（LIKE / 全文インデックス）	ベクトル検索
検索方式	文字列の完全一致	セマンティック類似度マッチング
「おいしい日本料理」	「日本料理」を含むテキストのみマッチ	「寿司」「刺身」「居酒屋」も見つかる
多言語	個別対応が必要	言語を越えたセマンティック理解
マルチモーダル	テキストのみ	テキスト、画像、音声の統一検索

5.3 典型的なユースケース

RAG（検索拡張生成）：LLMに関連知識断片を提供
セマンティック検索：キーワードではなくユーザーの意図を理解
画像検索：画像をアップロードして視覚的に類似した画像を見つける
レコメンデーションシステム：コンテンツのセマンティクスに基づく類似推薦

ベクトルデータベースの選択

専用ベクトルデータベース：Pinecone、Milvus、Weaviate —— ベクトル検索に特化、最高パフォーマンス
従来型データベースの拡張：pgvector（PostgreSQL）、Atlas Vector Search（MongoDB） —— アーキテクチャの複雑さを軽減
インメモリベクトルライブラリ：FAISS、Annoy —— 小規模、低遅延のシナリオに適している

6. 選択の決定：データモデルをどう選ぶか？

あなたのデータはどんな形？	推奨モデル	代表的な製品
構造が固定、関係が明確（注文、ユーザー）	リレーショナル	MySQL、PostgreSQL
構造が柔軟、ネストが深い（コンテンツ、設定）	ドキュメント	MongoDB、DynamoDB
エンティティ間の関係が複雑、マルチホップ走査が必要	グラフ	Neo4j、Amazon Neptune
時系列で書き込み、時間範囲でクエリ	時系列	InfluxDB、TimescaleDB
非構造化データ、セマンティック類似度検索が必要	ベクトル	Pinecone、Milvus、pgvector

実践的なアドバイス

現代のシステムは通常、複数モデルの組み合わせを使用します：

中核業務はPostgreSQL（リレーショナル）
ユーザー行動ログはInfluxDB（時系列）
AIナレッジベースはMilvus + pgvector（ベクトル）
レコメンデーションエンジンはNeo4j（グラフ）

「一つのデータベースですべての問題を解決する」ことを追求するのではなく、それぞれのデータに最も適した居場所を見つけさせましょう。

🗂️数据模型全景四种主流数据模型对比

不是所有数据都适合塞进关系型表格。社交网络的人脉关系、IoT 设备的时间流水、AI 搜索的语义向量——不同的数据形态需要不同的建模方式。

📄文档模型 (Document)MongoDB / DynamoDB

数据以 JSON 文档存储，每条记录可以有不同的字段结构，天然适合嵌套、半结构化数据。

{
  "_id": "user_1001",
  "name": "张三",
  "tags": ["VIP", "活跃"],
  "address": {
    "city": "北京",
    "district": "朝阳区"
  },
  "orders": [
    { "id": "o1", "amount": 299 },
    { "id": "o2", "amount": 599 }
  ]
}

无需预定义 Schema，字段随时扩展

嵌套数据一次读取，无需 JOIN

跨文档关联查询较弱

典型场景：用户画像CMS 内容商品目录配置中心

💡选型原则：没有万能数据库。关系型（MySQL/PostgreSQL）仍是大多数业务的基石，但当数据形态明确偏向文档、图、时序或向量时，选择专用模型能获得数量级的性能提升。

データモデルパノラマ（ドキュメント / グラフ / 時系列 / ベクトル） ​

1. リレーショナルの先へ：なぜ他のデータモデルが必要なのか？ ​

2. ドキュメントモデル（Document） ​

2.1 ドキュメントモデルとは？ ​

2.2 ドキュメント vs リレーショナル ​

2.3 典型的なユースケース ​

3. グラフモデル（Graph） ​

3.1 グラフモデルとは？ ​

3.2 グラフモデルの切り札：マルチホップクエリ ​

3.3 典型的なユースケース ​

4. 時系列モデル（Time-Series） ​

4.1 時系列モデルとは？ ​

4.2 なぜMySQLで時系列データを保存しないのか？ ​

4.3 典型的なユースケース ​

5. ベクトルモデル（Vector） ​

5.1 ベクトルモデルとは？ ​

5.2 ベクトル検索 vs キーワード検索 ​

5.3 典型的なユースケース ​

6. 選択の決定：データモデルをどう選ぶか？ ​