从10亿条日志压测看OLAP选型：Doris全文检索竟比ClickHouse快10倍？
当企业面临海量日志分析需求时，技术选型往往陷入两难：是选择传统搜索引擎的Elasticsearch，还是拥抱新兴的OLAP引擎？近期我们针对10亿级日志数据集进行的压测揭示了一个反常识结论——在全文检索场景下，Apache Doris的性能表现竟比ClickHouse快近10倍，甚至与Elasticsearch不相上下。这背后隐藏着哪些技术原理？我们又该如何根据业务场景做出最优选择？
1. 测试环境与基准设计
1.1 硬件配置与集群部署
本次测试采用完全对等的硬件环境，确保比较的公平性。所有集群节点均配置：
- CPU: 32核 Intel Xeon Gold 6248R
- 内存: 128GB DDR4 ECC
- 存储: 2TB NVMe SSD (Intel Optane P5800X)
- 网络: 25Gbps RDMA互联
集群规模配置如下：
| 组件 | 节点数 | 分片策略 | 副本数 |
|---|---|---|---|
| ClickHouse | 4 | 分布式表+本地表 | 2 |
| Doris | 6 | 动态分区+哈希分桶 | 2 |
| Elasticsearch | 10 | 自定义分片规则 | 1 |
1.2 数据集特征
测试使用真实生产环境的服务器日志，具有典型半结构化特征：
{ "@message": "2023-07-15 ERROR [query_id:cdb56920] READ_ONLY mode active", "@ip": "192.168.1.100", "@path": "/var/log/service.log", "@timestamp": "2023-07-15T14:32:18.123Z" }关键数据指标：
- 总记录数: 10亿条
- 原始大小: 155GB (Kafka压缩后)
- 字段分布:
- 文本字段占比85%（平均长度512字节）
- 数值/时间字段占比15%
2. 写入性能深度对比
2.1 吞吐量表现
通过调整并发写入线程数，我们得到以下峰值吞吐数据：
| 并发数 | ClickHouse (records/s) | Doris (records/s) | Elasticsearch (records/s) |
|---|---|---|---|
| 5 | 1,205,000 | 532,000 | 106,000 |
| 10 | 890,000 | 559,000 | 75,000 |
| 15 | N/A | 675,000 | N/A |
注意：ClickHouse在15并发时出现写入抖动，故未记录有效数据
2.2 资源消耗分析
对比各系统在峰值写入时的资源占用：
| 指标 | ClickHouse | Doris | Elasticsearch |
|---|---|---|---|
| CPU利用率 | 78% | 65% | 92% |
| 内存压力（GB） | 8 | 10 | 39 |
| 存储压缩比 | 0.35:1 | 0.57:1 | 1.81:1 |
| 网络带宽（MB/s） | 320 | 280 | 190 |
关键发现：
- ClickHouse的写入吞吐最高，但CPU消耗也最为剧烈
- Elasticsearch内存占用惊人，是其他系统的3-4倍
- Doris在资源利用率上表现均衡，没有明显短板
3. 查询性能颠覆性发现
3.1 全文检索场景对比
测试6种典型查询模式，响应时间对比如下（单位：秒）：
| 场景描述 | ClickHouse | Doris | Elasticsearch |
|---|---|---|---|
| IP+Path分组统计 | 0.064 | 7.08 | 9.09 |
| 错误日志计数 | 16.284 | 2.56 | 1.54 |
| 多关键词AND查询 | 1.688 | 0.09 | 0.556 |
| 短语联合出现统计 | 12.879 | 0.48 | 0.296 |
| 错误日志详情查询 | 16.065 | 0.33 | 0.248 |
| 中文关键词检索 | 14.694 | 0.48 | 0.49 |
3.2 技术原理剖析
Doris在全文检索上的优势源于其独特的倒排索引+预聚合设计：
两级索引结构：
- 第一级：基于BKD树的区间索引
- 第二级：基于FST（有限状态转换器）的倒排索引
查询优化策略：
-- Doris的MATCH_ALL语法实际触发索引合并操作 SELECT * FROM logs WHERE MATCH_ALL('Error READ_ONLY') OPTION(merge_threshold=0.8);内存计算加速：
- 向量化执行引擎处理倒排链
- 利用SIMD指令加速位图操作
4. 生产环境选型建议
4.1 场景匹配指南
根据业务特征选择最适合的方案：
| 需求特征 | 推荐方案 | 理由 |
|---|---|---|
| 高吞吐实时写入 | ClickHouse | 卓越的批量写入性能 |
| 复杂中文搜索 | Doris | 原生分词支持+低延迟 |
| 混合分析+搜索 | Doris | 统一SQL接口 |
| 纯文本搜索 | Elasticsearch | 丰富的分词插件生态 |
| 成本敏感型存储 | ClickHouse | 最优压缩比 |
4.2 性能调优实战
针对Doris的全文检索优化建议：
索引配置技巧：
ALTER TABLE logs ADD INDEX idx_msg(`message`) USING INVERTED PROPERTIES( "parser" = "chinese", "parser_mode" = "fine_grained", "support_phrase" = "true" );关键参数调整：
inverted_index_ram_limit=0.3 # 控制索引内存占用 inverted_index_cache_size=32G # 查询缓存配置硬件资源分配：
- 为BE节点配置至少32核CPU
- 预留30%内存给倒排索引操作
在实际部署中，我们发现为Doris配置高频CPU（如AMD EPYC 7B13）能带来额外20%的性能提升，而内存带宽对Elasticsearch的影响更为显著。对于既需要分析又需要搜索的场景，Doris的物化视图与倒排索引组合往往能产生奇效——在某次故障排查中，这种组合将查询时间从原来的47秒缩短到0.8秒。
