Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

Season 5 Ep 6 — 如果说 Ep 5 讲的是“指标的语言”，那么 Ep 6 讲的就是 “AI·ML 所要求的特殊存储”。它们各自作为不同品类起步，但在 2025 年正以惊人的速度收敛。

Prologue — “DB 地形因为 AI 被重新绘制了”
第 1 章 · Feature Store — ML 的语言
第 2 章 · Vector DB — AI 的语言
第 3 章 · Graph DB — 关系的语言
第 4 章 · 时序 DB — 运维的语言
第 5 章 · “Unified DB”的登场
第 6 章 · AI 给 DB 地形带来的冲击
第 7 章 · 选择指南
第 8 章 · 韩国企业的实务
第 9 章 · 三个案例研究
第 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 的两层结构

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) 结合
也开始尝试用 Feature Store 管理 LLM RAG 的上下文数据

第 2 章 · Vector DB — AI 的语言

2.1 2022–2024 的爆发

LLM RAG 热潮把向量 DB 这个品类推到台前
Pinecone 的 B 轮 $100M (2023)
Weaviate·Qdrant·Milvus·Chroma·LanceDB 等大量涌现

2.2 主要的向量 DB

名称	类型	特点
Pinecone	SaaS	业界领先，管理省心
Weaviate	开源+SaaS	混合检索·模块化
Milvus	开源+SaaS	大规模，Zilliz 做商用
Qdrant	开源+SaaS	Rust，性能快
Chroma	开源	嵌入式/对开发者友好
LanceDB	开源	基于文件，嵌入式
pgvector	Postgres 扩展	集成进通用 DB
Vespa	开源	源自 Yahoo，排序是强项
Elasticsearch	检索 + 向量	已有检索+向量
Redis Vector	内存	超低延迟

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 统一了三大信号 (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 辅助预测·异常检测
OpenTelemetry + LLM 可观测性平台

6.4 Feature Store 的扩张

从传统 ML 特征 → 连 LLM RAG 的上下文也一起管
Vector + Feature 统合存储的实验
复用 Online-Offline 同步模式

6.5 警惕 DB Sprawl

每个产品 2–5 个 DB → 管理负担
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 的时点”

有 2 个以上 ML 模型在生产环境
共享 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 成本·性能小贴士

试验能否降低嵌入维度 (dimension reduction)
用 Dense+Sparse 混合来提升精度
Cold 数据放 Parquet + Iceberg，Hot 数据放向量 DB

8.4 2025 年韩国方面的动向

Upstage Embedding / Solar → 国产嵌入模型扩散
三星 SDS·LG CNS·NAVER Cloud 推出 Vector·Graph·LLM 整合套件
创业公司对 GraphRAG·本地 Vector DB 建设的需求

第 9 章 · 三个案例研究

9.1 电商推荐

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 却跑 5 个 ML

特征计算重复·skew。

10.5 缺少 Online-Offline 同步

训练得很好的模型到了生产就一塌糊涂。

10.6 不做向量索引调优

HNSW/IVF 用默认值导致性能下降。

10.7 忽视混合检索

只用 Dense 对关键词查询很弱。

10.8 不用 GraphRAG，只把 raw 文档丢给 LLM

关系型提问的准确率下降。

10.9 一开始就把多个专用 DB 全上

运维负担过重。

10.10 数据治理分散

5 种 DB 各有各的 PII/审计，一致性崩塌。

第 11 章 · 检查清单 — 引入特殊 DB 的 12 项

第 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。