Doris 与 ES 同时存在：实时分析用谁、搜索用谁？别让两个 OLAP 打架
一个越来越常见的架构
数据密集型 AI 后端项目里，下面的架构正在变多：
1 | MySQL（业务主库） |
问题来了：ES 和 Doris 都能做”聚合查询”，都能做”全文搜索”，都能做”向量检索”。两个一起跑，是不是重复了？能不能砍掉一个？
这是个真实的问题。我自己的踩坑经历是：砍不掉，但必须划清边界。这两个系统在”重叠区域”上看起来都能做，但做了之后的工程成本、运维成本、性能特征完全不同。
各自最擅长什么？
Elasticsearch 真正擅长的
- 多字段全文搜索（中文分词、拼音、纠错、同义词、相关度调优）
- 多维度过滤聚合（facet、nested aggregation、cross-field query）
- 向量检索 + 混合搜索（kNN + BM25 一条 query 解决）
- 时序日志场景（Logstash + Beats 生态成熟）
- 模糊匹配（fuzzy query、wildcard、regex）
核心优势：搜索领域的工具链成熟度。中文分词（ik、拼音、繁简）、相关度算法（BM25、DFR、BM25+）、查询 DSL、调参经验，这些东西 ES 积累最深。
Doris 真正擅长的
- 大规模 OLAP 聚合（数十亿行的 SUM/COUNT/AVG/GROUP BY）
- 高吞吐实时写入（秒级导入百万行）
- 列存压缩（同样数据量，存储成本是 ES 的 1/3 到 1/5）
- SQL 兼容（MySQL 协议，分析师上手快）
- 存算分离（Doris 3.x 起支持，弹性扩缩容）
核心优势：列存 + 向量化执行的极致分析性能。同一个查询，Doris 在亿级数据上比 ES 快 5-10 倍很正常。
重叠区域：哪些场景两个都能做？
场景 1：业务订单的多维度筛选 + 统计
- “过去 7 天，状态=已完成、金额>1000、按品类分组的订单数和总金额”
- ES：能跑，但聚合到千万级就慢，需要提前 rollup 或用 transform。
- Doris：天然强项，秒级返回。
场景 2：日志/文本的全文搜索
- “在 1000 万条客服对话中找出包含’退款慢’的 top 100”
- ES：核心场景，毫秒级。
- Doris 4.x：内置倒排索引 + BM25 也能做，但分词器生态弱、相关度调优经验少。
场景 3：向量检索（语义搜索）
- “找出和这个问题最相似的 10 个文档”
- ES：kNN 检索 + 混合查询成熟。
- Doris 4.x：HNSW + 内积距离 + IVF_PQ 也能做，性能对标专用向量库。
场景 4：宽表聚合分析 + 简单过滤
- “用户维度的累计指标，包含若干标签过滤”
- ES：可以但慢，Doris 的几十倍。
- Doris：快。
我的边界划分原则
经过几次实际项目，我现在用的判断标准是：
| 场景特征 | 用 ES | 用 Doris |
|---|---|---|
| 中文搜索相关性要求高 | ✅ | ❌ |
| 多字段组合 facet | ✅ | ⚠️（不如 ES 自然） |
| 实时聚合指标到秒级 | ⚠️ | ✅ |
| 数据量过 10 亿 | ❌（成本失控） | ✅ |
| 向量检索 + 关键词混合 | ✅ | ⚠️（Doris 4.x 可以但生态弱） |
| 列存分析型聚合 | ❌ | ✅ |
| 团队搜索经验集中在 ES | ✅ | ❌ |
| 团队 OLAP 经验集中在 Doris | ⚠️ | ✅ |
简而言之：ES 做”找”的事，Doris 做”算”的事。
最常见的反模式
反模式 1：在 ES 里存宽表做聚合
“我把所有订单宽表同步到 ES，业务查询全在 ES”。
代价：
- ES 索引体积爆炸（订单宽表一行几 KB，ES 的倒排索引对大字段不友好）
- 聚合到几千万行时性能断崖
- 存储成本是 Doris 的 3-5 倍
应该做的：
- ES 存”用户/商品/工单”这种主键型 + 多字段文本的索引
- Doris 存”订单/事件/日志”这种事实型 + 宽字段的数据
反模式 2：在 Doris 里硬上全文搜索
“我让分析师用 Doris 写全文搜索，搜索栈就一个组件”。
代价：
- 分词器生态弱（默认就 standard，对中文支持差）
- 相关度调优经验少（业务方反馈”搜索结果不相关”你不知道改哪）
- 高亮、纠错、拼音这些搜索必备功能都得自己写
应该做的：
- 搜索相关的体验优化放 ES
- Doris 只做”包含某关键词的过滤”，不参与相关度排序
反模式 3：让两个组件做同一份数据
最坑的是这个：MySQL → MQ → 消费者 1 → ES，消费者 2 → Doris。结果 ES 和 Doris 里的数据轻微不一致——一个数字指标，ES 显示 12345，Doris 显示 12348。
这种 0.03% 的差异是数据同步延迟造成的（ES 准实时 1s refresh，Doris 准实时 5s stream load）。业务方发现数据对不上，第一反应是问”为什么”，工程师无言以对。
应该做的：
- ES 和 Doris **不要都做”权威数据源”**。业务查实时数字 → MySQL；查历史趋势 → Doris；查相关性 → ES。
- 跨系统的”对账”由 MySQL 承担，ES 和 Doris 都不做权威。
AI 场景下的特殊考量
AI 应用里有个新问题：ES 和 Doris 现在都能做”语义检索”。
我的取舍：
- RAG 主链路用 ES。因为 RAG 需要关键词+向量混合检索，相关性调优要求高，ES 的混合查询是事实标准。
- **Doris 4.x 的向量搜索用在”分析型 AI 场景”**——比如”分析用户评价的语义聚类，找出本周负面反馈的主要话题”。这种场景的查询是 SQL 主导，向量只是 WHERE 条件之一，Doris 4.x 的 Hybrid Search 比 ES 写起来自然。
- 千万级以下的小 RAG 可以用 MySQL 9.2 + 向量，省 ES 和 Doris 中的一个。
意味着什么？
ES 和 Doris 不是”二选一”的关系，是”两个 OLAP 但分工完全不同”。
- ES 是搜索引擎，长在相关性、过滤、混合查询。
- Doris 是分析引擎，长在列存聚合、宽表计算。
重叠区域在变大（Doris 4.x 加了全文+向量，ES 加了 PPL），但两者的核心优势还没交叉。强行用其中一个覆盖另一个，必然在某个真实场景里掉链子。
数据密集型 AI 后端的工程师，最有价值的判断力是：看一眼业务需求，就能决定哪些放 ES、哪些放 Doris、哪些放 MySQL。这是架构选型能力，不是技术熟练度。