Feature Store と Vector・Graph・時系列 DB の融合ガイド: Feast・Tecton・Pinecone・Weaviate・Milvus・Neo4j・TimescaleDB (2025)

Season 5 Ep 6 — Ep 5 が「指標の言語」だったなら、Ep 6 は 「AI・ML が要求する特殊なストレージ群」。これらは別々のカテゴリとして始まったが、2025 年には驚くほど収束している。

• Prologue — 「DB の地形が AI によって描き直された」
• 第 1 章 · Feature Store — ML の言語
  • 1.1 なぜ必要か
  • 1.2 Feature Store の 2 階層
  • 1.3 主要ツール
  • 1.4 Feast の例
  • 1.5 Online-Offline Skew の防止
  • 1.6 2024–2025 の動向
• 第 2 章 · Vector DB — AI の言語
  • 2.1 2022–2024 の爆発
  • 2.2 主要なベクトル DB
  • 2.3 主要アルゴリズム
  • 2.4 ハイブリッド検索
  • 2.5 Postgres + pgvector の反撃
  • 2.6 使いどころ
• 第 3 章 · Graph DB — 関係の言語
  • 3.1 なぜ再び注目されるのか
  • 3.2 主要な Graph DB
  • 3.3 クエリ言語
  • 3.4 GraphRAG
  • 3.5 使いどころ
  • 3.6 限界と現実
• 第 4 章 · 時系列 DB — 運用の言語
  • 4.1 カテゴリ
  • 4.2 主要ツール
  • 4.3 AI・ML との出会い
  • 4.4 2024–2025 のトレンド
  • 4.5 使いどころ
• 第 5 章 · 「Unified DB」の登場
  • 5.1 2024–2025 の現象
  • 5.2 なぜ統合されるのか
  • 5.3 統合の限界
  • 5.4 2025 年の推奨
• 第 6 章 · AI が DB 地形に与えた衝撃
  • 6.1 ベクトル DB の爆発 → 収束
  • 6.2 Graph の再発見
  • 6.3 時系列 + LLM
  • 6.4 Feature Store の拡張
  • 6.5 DB Sprawl への警戒
• 第 7 章 · 選択ガイド
  • 7.1 「専用ベクトル DB が必要な場合」
  • 7.2 「Postgres + pgvector で十分」
  • 7.3 「Graph DB が必要な場合」
  • 7.4 「時系列 DB が必要な場合」
  • 7.5 「Feature Store が必要な時点」
• 第 8 章 · 韓国企業の実務
  • 8.1 導入の現状
  • 8.2 ネットワーク分離・オンプレの要求
  • 8.3 コスト・性能の Tips
  • 8.4 2025 年の韓国側の動向
• 第 9 章 · ケーススタディ 3 件
  • 9.1 EC のレコメンド
  • 9.2 金融の不正検知
  • 9.3 企業 AI Assistant (RAG)
• 第 10 章 · アンチパターン 10 選
  • 10.1 「すべてのプロダクトに Vector DB」
  • 10.2 Graph DB を OLTP の置き換えに
  • 10.3 時系列データを OLTP にそのまま積む
  • 10.4 Feature Store なしで ML を 5 つ運用
  • 10.5 Online-Offline 同期の不在
  • 10.6 ベクトルインデックスのチューニング不在
  • 10.7 ハイブリッド検索の無視
  • 10.8 GraphRAG なしで LLM に raw 文書だけ
  • 10.9 複数の専門 DB を初期にすべて
  • 10.10 データガバナンスの分散
• 第 11 章 · チェックリスト — 特殊 DB 導入の 12 項目
• 第 12 章 · 次回予告 — Season 5 Ep 7: 「データガバナンス・Lineage・PII」

Prologue — 「DB の地形が AI によって描き直された」

2015–2020 年には DB のカテゴリが鮮明だった:

• OLTP: Postgres/MySQL
• OLAP: Warehouse
• NoSQL: Mongo/Cassandra/Redis
• 時系列: InfluxDB

2022 年の LLM ブーム以降ベクトル DB が爆発し、2024–2025 年には逆に:

• Postgres + pgvector → 汎用 DB がベクトルを飲み込む
• Lakehouse → フィーチャー・ベクトル・時系列をまとめて受け入れる
• 時系列 DB がベクトル対応を追加
• Graph DB が AI レコメンド・GraphRAG で再浮上

境界が曖昧になっている。 この記事はその混沌を整理する。

第 1 章 · Feature Store — ML の言語

1.1 なぜ必要か

• ML モデルの学習と推論が 違うフィーチャー を使うと Online-Offline skew
• 各チームが自分のフィーチャーを再計算 → 重複・不一致
• 再現性・監査・ガバナンスの不在

1.2 Feature Store の 2 階層

• Offline Store: バッチ学習・バックフィル (Lakehouse/Iceberg/BigQuery)
• Online Store: 低遅延の推論 (Redis/DynamoDB/Cassandra)
• 二つの階層が 同じ定義 から生成される

1.3 主要ツール

• Feast (オープン): 最も人気、Tecton が主導
• Tecton (商用): リアルタイム Feature Pipeline
• Hopsworks: End-to-End の ML プラットフォーム
• Databricks Feature Store: Delta 統合
• Vertex AI Feature Store: GCP
• SageMaker Feature Store: AWS

1.4 Feast の例

from feast import Entity, FeatureView, Field
from feast.types import Float32

user = Entity(name='user', join_keys=['user_id'])

driver_stats = FeatureView(
    name='user_stats',
    entities=[user],
    schema=[Field(name='avg_order_value', dtype=Float32)],
    source=...
)

1.5 Online-Offline Skew の防止

• 同じ SQL / コード で両側のフィーチャーを生成
• Point-in-time correctness: 学習用フィーチャーはその時点の値
• Materialization: Offline → Online の周期的な同期
• Data validation: 分布の異常を検知

1.6 2024–2025 の動向

• Iceberg・Delta の上に Feature Store を構築するケースが増加
• リアルタイム Feature Pipeline (Flink/RisingWave) との結合
• LLM RAG のコンテキストデータも Feature Store で管理する試み

第 2 章 · Vector DB — AI の言語

2.1 2022–2024 の爆発

• LLM RAG の熱狂でベクトル DB カテゴリが急浮上
• Pinecone シリーズ B $100M (2023)
• Weaviate・Qdrant・Milvus・Chroma・LanceDB などが大量に登場

2.2 主要なベクトル DB

2.3 主要アルゴリズム

• HNSW: 業界標準の近似近傍探索
• IVF: 大規模に効率的
• ScaNN (Google): 大規模 + 精度
• DiskANN (Microsoft): SSD ベースの超大容量

2.4 ハイブリッド検索

• Dense (ベクトル) + Sparse (BM25) の結合
• 2024–2025 の基本標準として定着
• Weaviate・Vespa・Elastic・OpenSearch がすべて対応

2.5 Postgres + pgvector の反撃

• 2023–2024 に pgvector が爆発的に改善
• HNSW インデックス、メタフィルタリング、ハイブリッド検索
• 「DB をもう一つ作らずに Postgres で」が 2025 年のよくある選択

2.6 使いどころ

• RAG のコンテキスト検索
• レコメンドシステム
• 画像・動画・音声の類似度
• クラスタリング・異常検知

第 3 章 · Graph DB — 関係の言語

3.1 なぜ再び注目されるのか

• 知識グラフベースの RAG (GraphRAG) が 2024 年に浮上
• レコメンド・不正検知・サプライチェーン分析
• LLM が構造化された知識を活用するパターン

3.2 主要な Graph DB

• Neo4j: 業界の先導、Cypher 言語
• NebulaGraph: 中国起源、大規模
• Dgraph: 分散 GraphQL
• TigerGraph: 高性能な分析
• Amazon Neptune: AWS のマネージド
• ArangoDB: マルチモデル (document+graph)
• Apache AGE: Postgres 拡張 (graph)
• Kuzu: 組み込み Graph (最近注目)

3.3 クエリ言語

• Cypher: Neo4j の標準、最も広く使われる
• Gremlin: Apache TinkerPop
• GQL: ISO 標準化が進行中
• GraphQL: API 言語として Dgraph などが採用

3.4 GraphRAG

• LLM に関連するエンティティ・関係をグラフとして提供
• 「この人が関わったプロジェクトの中心担当者は?」といった質問に強い
• Microsoft GraphRAG (2024)、LlamaIndex KnowledgeGraph など

3.5 使いどころ

• 不正検知 (取引ネットワーク)
• レコメンド (ユーザー-商品-属性の関係)
• 知識グラフ (企業情報・学術・医療)
• Supply chain、サイバーセキュリティ

3.6 限界と現実

• Graph DB は「一部分」を担当するケースが多い
• メインは Postgres/Warehouse、Graph は特定のワークロード
• Apache AGE・Kuzu のような軽量オプションで参入障壁が低下

第 4 章 · 時系列 DB — 運用の言語

4.1 カテゴリ

• 専用: InfluxDB、TimescaleDB、VictoriaMetrics、QuestDB
• 観測性フレンドリー: Prometheus、M3、Cortex、Mimir、Thanos
• 汎用エンジンに内蔵: ClickHouse・BigQuery・Snowflake も時系列処理が可能

4.2 主要ツール

• InfluxDB 3: 2024 年に Parquet/Arrow ベースで再設計
• TimescaleDB: Postgres 拡張、最も汎用的
• VictoriaMetrics: Prometheus 互換、超高性能
• QuestDB: 超高速 ingest、SQL
• Prometheus: モニタリングの標準、長期保管は Thanos/Cortex
• ClickHouse: ログ・メトリック・トレースの統合

4.3 AI・ML との出会い

• 時系列フィーチャーの生成 (Feature Store の source)
• LLM による時系列の異常検知・要約
• 予測モデル (Prophet、Nixtla) との結合

4.4 2024–2025 のトレンド

• OpenTelemetry が 3 大シグナル (Metric・Log・Trace) を統合
• ClickHouse・SigNoz・Grafana Cloud Loki/Mimir/Tempo が統合バックエンドに
• TimescaleDB は Postgres エコを吸収 + ベクトルにも対応 (pgvector)

4.5 使いどころ

• APM・インフラモニタリング
• IoT・センサーデータ
• 金融取引のタイムライン
• ユーザー行動のタイムライン

第 5 章 · 「Unified DB」の登場

5.1 2024–2025 の現象

• Postgres + 拡張: OLTP + ベクトル + 時系列 + Graph (AGE)
• ClickHouse: OLAP + ログ/メトリック + ベクトル (2024 年に拡大) + 類似度
• MongoDB: Document + Atlas Vector Search
• Elastic: 検索 + ベクトル + 観測性
• Snowflake/Databricks: Warehouse + ベクトル + ML + ストリーミング

5.2 なぜ統合されるのか

• 複数 DB の運用コスト
• データ複製・一貫性の負担
• スタートアップは 一つで始める ことを好む

5.3 統合の限界

• 専門エンジン (Pinecone・Neo4j・InfluxDB) の性能・機能の深さに追いつけない
• 大規模では再び分離が必要
• 「単一 DB vs 複数の専門 DB」は規模・ワークロードごとのバランス

5.4 2025 年の推奨

• 初期 < 10M レコード: 単一 DB (Postgres + 拡張) で十分
• 中期 10M–1B: 統合 DB + 一部専用
• 大規模 1B+: ワークロードごとに専門 DB を分離

第 6 章 · AI が DB 地形に与えた衝撃

6.1 ベクトル DB の爆発 → 収束

• 2022: カテゴリの誕生
• 2023: 数十のベンダー
• 2024: Postgres/ES/Mongo が吸収 → 専門ベクトル DB は大規模・超低遅延に集中

6.2 Graph の再発見

• GraphRAG・LLM の知識基盤
• 企業データの統合 (知識グラフ)
• Neo4j・Microsoft GraphRAG の拡散

6.3 時系列 + LLM

• ログ・メトリックへの LLM 自然言語クエリ
• 予測・異常検知への LLM の補助
• OpenTelemetry + LLM 観測性プラットフォーム

6.4 Feature Store の拡張

• 伝統的な ML フィーチャー → LLM RAG のコンテキストも管理
• Vector + Feature の統合ストア実験
• Online-Offline 同期パターンの再利用

6.5 DB Sprawl への警戒

• プロダクトごとに DB が 2–5 個 → 管理の負担
• 2025 年の知恵: 「専門性の深さ vs 運用の簡潔さ」 のバランス

第 7 章 · 選択ガイド

7.1 「専用ベクトル DB が必要な場合」

• 1 億+ ベクトル、超低遅延が必要
• 複雑なメタフィルタリング + ハイブリッド
• ML 専任チームが存在する

→ Pinecone、Weaviate、Milvus、Qdrant

7.2 「Postgres + pgvector で十分」

• < 1000 万ベクトル
• 既存の Postgres スタックを活用
• 運用・監査の利便性を優先

7.3 「Graph DB が必要な場合」

• 関係が中核のビジネスロジック (不正検知・レコメンド)
• 再帰/経路クエリが頻繁
• 知識グラフが大規模

→ Neo4j、NebulaGraph、Neptune

7.4 「時系列 DB が必要な場合」

• 秒あたり万件+ の metric/log
• 長期保管 + 集計クエリ

→ TimescaleDB (汎用)、VictoriaMetrics/ClickHouse (大規模)

7.5 「Feature Store が必要な時点」

• ML モデルが 2 つ以上プロダクション稼働
• フィーチャーを 10 個以上共有
• 学習-推論の skew 問題が発生

→ Feast (軽量)、Tecton/Databricks (エンタープライズ)

第 8 章 · 韓国企業の実務

8.1 導入の現状

• Vector DB: 2023–2024 はほとんどが Pinecone/Weaviate で開始、2025 年は pgvector・Elastic への移行が増加
• Graph DB: 金融 (不正検知)・通信 (ネットワーク) で伝統的に利用、LLM 時代に再飛躍
• 時系列 DB: APM・IoT は InfluxDB/Prometheus が中心
• Feature Store: Coupang・Karrot・Toss・NAVER が自前構築の事例

8.2 ネットワーク分離・オンプレの要求

• 金融・公共: オープンソース (Milvus・Qdrant・Neo4j Community) を自前運用
• Vector DB のオンプレ配備 SI が成長中
• 韓国語の埋め込みモデル (Solar・KoSimCSE・E5-Korean) + ローカルのベクトル DB の組み合わせ

8.3 コスト・性能の Tips

• 埋め込みの次元を下げられるか実験する (dimension reduction)
• Dense+Sparse のハイブリッドで精度を改善
• Cold データは Parquet + Iceberg に、Hot はベクトル DB に

8.4 2025 年の韓国側の動向

• Upstage Embedding / Solar → 国産の埋め込みモデルが拡散
• Samsung SDS・LG CNS・NAVER Cloud が Vector・Graph・LLM の統合パッケージ
• スタートアップの GraphRAG・オンプレ Vector DB 構築の需要

第 9 章 · ケーススタディ 3 件

9.1 EC のレコメンド

• User・Item・Order のグラフ: Neo4j
• Item の埋め込み: pgvector または Pinecone
• リアルタイムのフィーチャー: Feast + Redis
• 結果: 「次に買われうる商品」の精度 +20%

9.2 金融の不正検知

• 取引グラフ: NebulaGraph
• ユーザー行動の時系列: TimescaleDB
• リアルタイムのルール + ML スコア: Feast + Flink
• 結果: 誤検知率の低下、対応時間の短縮

9.3 企業 AI Assistant (RAG)

• 文書の埋め込み: Weaviate
• 社内の知識グラフ: Neo4j + GraphRAG
• ユーザー権限・メタ: Postgres
• LLM は Semantic Layer と結合

第 10 章 · アンチパターン 10 選

10.1 「すべてのプロダクトに Vector DB」

pgvector で十分なのに過剰投資。

10.2 Graph DB を OLTP の置き換えに

トランザクション処理には不向き。

10.3 時系列データを OLTP にそのまま積む

テーブルが肥大化し、クエリが暴走。

10.4 Feature Store なしで ML を 5 つ運用

フィーチャー計算の重複・skew。

10.5 Online-Offline 同期の不在

うまく学習できたモデルがプロダクションでは台無しに。

10.6 ベクトルインデックスのチューニング不在

HNSW/IVF のデフォルト値のままで性能が低下。

10.7 ハイブリッド検索の無視

Dense-only ではキーワードクエリに弱い。

10.8 GraphRAG なしで LLM に raw 文書だけ

関係型の質問で精度が低下。

10.9 複数の専門 DB を初期にすべて

運用負担が過大。

10.10 データガバナンスの分散

DB 5 種にそれぞれの PII/監査があり、一貫性が崩壊。

第 11 章 · チェックリスト — 特殊 DB 導入の 12 項目

• ワークロードの分類 (ML フィーチャー・ベクトル・グラフ・時系列)
• 規模別の単一 vs 専門 DB の意思決定
• Feature Store の必要性の評価
• ベクトルインデックスのアルゴリズム・パラメータのベンチマーク
• ハイブリッド検索を導入するかどうか
• Graph クエリパターンの整理 (Cypher/GQL)
• 時系列の収集パイプライン
• Online-Offline skew の検知・アラート
• セキュリティ・権限・監査の統合
• PII・暗号化のポリシー
• コストの予測・モニタリング
• 運用・バックアップ・DR プラン

第 12 章 · 次回予告 — Season 5 Ep 7: 「データガバナンス・Lineage・PII」

特殊 DB が増えるほどガバナンスは難しくなる。Ep 7 は データが流れる全過程の管理 を扱う。

• OpenLineage 標準
• Collibra / Atlan / DataHub / Alation
• Unity Catalog / Polaris / Glue のガバナンス層
• PII の検出・マスキング・トークン化
• GDPR・韓国の個人情報保護法におけるデータ主体の権利
• 機微データの分類
• データ契約 (Ep 4 の延長) と監査
• マルチクラウド・マルチ DB のガバナンス
• 韓国企業のガバナンスの現実
• AI 時代のガバナンス拡張

「データを管理しなければ、データが会社を支配する」 Ep 7 の話題。

次の記事で会おう。

要約: 2025 年の DB 地形は AI・ML が揺さぶった後に収束する局面。Vector DB は専門ベンダーと Postgres/ES/Mongo の統合が共存、Graph DB は GraphRAG と不正検知で再浮上、時系列 DB は OpenTelemetry と結合、Feature Store は Iceberg・リアルタイムストリーミングと融合。「単一 DB で始め → 規模ごとに専門化」が支配的なパターンであり、韓国企業はネットワーク分離・韓国語の埋め込み・Feast/Neo4j/Milvus の自前運用が特殊性。次回はこのすべての上にある データガバナンス · Lineage · PII。