抛弃 ElasticSearch？StarRocks 存算分离实战：亿级日志检索性能压测与成本对比

摘要：在日志分析与检索领域，ElasticSearch (ES) 曾是无可撼动的霸主。但在数据量爆炸的今天，ES 的高存储成本和 JVM 调优噩梦让无数架构师头秃。本文将实战演示如何引入StarRocks 存算分离架构，在亿级日志场景下，实现查询性能提升 3 倍同时存储成本下降 50%的降本增效奇迹。

1. 为什么“叛逃” ElasticSearch？

ES 确实好用，但它有三个“致死”痛点：

1. 存储成本高昂：倒排索引膨胀率高，且通常需要 SSD 支撑。
2. 存算耦合：扩容计算必须扩容存储，资源浪费严重。
3. 写入开销大：高并发写入时 CPU 飙升，不仅影响查询，还容易 OOM。

StarRocks 的破局之道：

• 存算分离 (Shared-data)：数据存 S3/OSS 对象存储，计算节点无状态弹性伸缩。
• 列式存储 + 倒排索引：既有 OLAP 的分析速度，又有全文检索的能力。

2. 架构对比：ES vs StarRocks

我们来看下两种方案的本质区别。

如果说 ES 是“重装坦克”，那 StarRocks 存算分离就是“航母编队”——计算（舰载机）随时起飞，数据（母舰）统一存储。

3. 亿级日志压测实战

3.1 环境准备

• 数据量：1 亿条 Nginx 访问日志 (约 50GB)。
• 机器：3 台 8C 32G 节点。
• 查询场景：多维过滤 + 关键词检索 + 聚合分析 (Group By)。

3.2 建表优化 (StarRocks)

利用 StarRocks 的GIN倒排索引加速文本过滤。

CREATETABLEnginx_logs(event_timeDATETIME,client_ipVARCHAR(32),urlVARCHAR(500),statusINT,user_agentVARCHAR(1000),INDEXidx_url(url)USINGBITMAP,-- 低基数用 BitmapINDEXidx_ua(user_agent)USINGGIN-- 文本检索用 GIN (类似 ES 倒排))ENGINE=OLAPDUPLICATEKEY(event_time)PARTITIONBYRANGE(event_time)(...)DISTRIBUTEDBYHASH(client_ip)BUCKETS10PROPERTIES("replication_num"="1","storage_medium"="S3"-- 关键：数据下沉到对象存储);

3.3 压测结果对比

我们使用 JMeter 模拟高并发查询，对比 P99 延迟：

深度解析：
StarRocks 在聚合分析上的碾压优势源于其向量化执行引擎，而 ES 需要从倒排索引回表或者使用 DocValues，CPU 开销巨大。

4. 存算分离的降本账单

假设日志量为每天 10TB，保留 30 天：

1. ES 方案：需要300TBSSD。按云厂商价格，SSD 极其昂贵。且为了保证写入性能，CPU 必须预留 50%。
2. StarRocks 存算分离：
   • 存储：300TB 数据压缩后仅需80TB对象存储（S3 价格是 SSD 的 1/10）。
   • 计算：白天查询高峰开启 20 个 CN 节点，晚上低峰缩容到 2 个 CN 节点。按需付费。

结论：综合算下来，StarRocks 方案的总 TCO (总体拥有成本) 至少可以降低60%。

5. 总结

ElasticSearch 不会死，它在极度复杂的全文搜索（如相关性打分、分词）场依然是王者。但在日志检索、安全审计、APM等“泛日志”场景下，StarRocks 这种**“倒排索引 + 列存 + 存算分离”**的新物种，正在发起一场降维打击。

作为架构师，是时候重新审视你的技术栈了。

互动：你们公司还在用 ES 存日志吗？遇到过哪些坑？欢迎评论区吐槽！