如何实现ClickHouse与 Elasticsearch聚合性能对比测试

发布时间：2021-12-16 17:32:22 作者：柒染
来源：亿速云阅读：517

# 如何实现ClickHouse与Elasticsearch聚合性能对比测试

## 前言

在大数据分析和实时查询领域，ClickHouse和Elasticsearch都是广受欢迎的开源解决方案。虽然两者都具备强大的聚合分析能力，但它们在设计理念、存储引擎和查询模式上存在显著差异。本文将详细介绍如何设计并执行ClickHouse与Elasticsearch的聚合性能对比测试，帮助读者根据实际业务场景选择合适的技术方案。

---

## 一、测试环境准备

### 1.1 硬件配置建议
```bash
# 推荐的最低测试环境配置
- 服务器：3节点集群（1主2从）
- CPU：16核以上
- 内存：64GB以上
- 存储：SSD/NVMe，1TB以上
- 网络：万兆网卡

1.2 软件版本选择

组件	推荐版本	重要特性
ClickHouse	22.8+	向量化执行引擎，MergeTree优化
Elasticsearch	8.5+	基于Lucene 9，时序数据增强

1.3 数据集准备

建议使用标准测试数据集（如NYC Taxi数据）或生成模拟数据：

# 数据生成示例（使用Faker库）
from faker import Faker
import pandas as pd

fake = Faker()
data = [{
    "timestamp": fake.date_time_between(start_date="-1y"),
    "user_id": fake.uuid4(),
    "value": fake.pyfloat(min_value=1, max_value=1000)
} for _ in range(10_000_000)]
pd.DataFrame(data).to_parquet("test_data.parquet")

二、集群部署与配置优化

2.1 ClickHouse部署要点

<!-- config.xml 关键配置 -->
<merge_tree>
    <parts_to_delay_insert>300</parts_to_delay_insert>
    <parts_to_throw_insert>600</parts_to_throw_insert>
</merge_tree>

<compression>
    <case>
        <min_part_size>10000000000</min_part_size>
        <method>zstd</method>
    </case>
</compression>

2.2 Elasticsearch配置优化

# elasticsearch.yml 关键参数
thread_pool.search.size: 16
thread_pool.search.queue_size: 1000

indices.queries.cache.size: 20%
indices.fielddata.cache.size: 30%

2.3 索引/表结构设计对比

ClickHouse建表示例

CREATE TABLE test_metrics (
    timestamp DateTime CODEC(DoubleDelta),
    user_id String,
    value Float64
) ENGINE = MergeTree()
PARTITION BY toYYYYMM(timestamp)
ORDER BY (timestamp, user_id)
SETTINGS index_granularity = 8192;

Elasticsearch索引映射

PUT /test_metrics
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1
  },
  "mappings": {
    "properties": {
      "timestamp": { "type": "date" },
      "user_id": { "type": "keyword" },
      "value": { "type": "float" }
    }
  }
}

三、测试方案设计

3.1 测试场景分类

基础聚合：COUNT/SUM/AVG等单维度统计
复杂聚合：多字段分组+百分位数计算
时间序列聚合：按不同时间粒度（分钟/小时/天）聚合
高基数聚合：对cardinality>1M的字段分组

3.2 测试查询示例

ClickHouse查询

-- 时间窗口聚合
SELECT 
    toStartOfHour(timestamp) AS hour,
    user_type,
    avg(value) AS avg_val,
    quantile(0.99)(value) AS p99
FROM test_metrics
WHERE timestamp BETWEEN now() - INTERVAL 7 DAY AND now()
GROUP BY hour, user_type
ORDER BY hour

Elasticsearch查询

POST /test_metrics/_search
{
  "size": 0,
  "query": {
    "range": {
      "timestamp": {
        "gte": "now-7d/d",
        "lte": "now/d"
      }
    }
  },
  "aggs": {
    "by_hour": {
      "date_histogram": {
        "field": "timestamp",
        "calendar_interval": "hour"
      },
      "aggs": {
        "by_user": {
          "terms": { "field": "user_type" },
          "aggs": {
            "avg_val": { "avg": { "field": "value" } },
            "p99": { "percentiles": { "field": "value", "percents": [99] } }
          }
        }
      }
    }
  }
}

3.3 性能指标采集

使用Prometheus+Granfa搭建监控体系，采集关键指标：

指标类型	ClickHouse	Elasticsearch
CPU利用率	system.cpu_usage	os.cpu.percent
内存使用	process.memory_usage	jvm.mem.heap_used
查询延迟	query_duration_ms	search_latency_ms
磁盘IO	disk.io.time	fs.io.time

四、测试执行与结果分析

4.1 基准测试结果示例

（以下为模拟数据，单位：毫秒）

查询类型	数据量	ClickHouse	Elasticsearch	差异率
单维度AVG	100M	120	450	+275%
多字段分组	100M	380	1200	+215%
百分位计算	100M	650	900	+38%
时间范围查询	100M	210	320	+52%

4.2 性能对比结论

吞吐量优势：
- ClickHouse在单次扫描大数据量时表现更优
- Elasticsearch在并发小查询场景更稳定

资源消耗：

pie title 内存占用对比(100M数据集)
   "ClickHouse" : 28
   "Elasticsearch" : 42

典型场景推荐：
- 选择ClickHouse当：
  - 需要处理TB级数据分析
  - 查询模式固定且可预测
- 选择Elasticsearch当：
  - 需要全文检索能力
  - 数据模式频繁变化

五、深度优化建议

5.1 ClickHouse优化技巧

-- 使用物化视图预聚合
CREATE MATERIALIZED VIEW metrics_daily
ENGINE = SummingMergeTree
PARTITION BY toYYYYMM(date)
ORDER BY (date, user_type)
AS SELECT
    toDate(timestamp) AS date,
    user_type,
    sum(value) AS total,
    count() AS cnt
FROM test_metrics
GROUP BY date, user_type;

5.2 Elasticsearch优化方向

使用时序数据流（Time Series Data Stream）
调整分片大小（建议单个分片30-50GB）
对高基数字段启用eager_global_ordinals

六、附录

6.1 常用监控命令

# ClickHouse
$ watch -n 1 "clickhouse-client --query='SHOW PROCESSLIST'"

# Elasticsearch
$ curl -XGET 'http://localhost:9200/_nodes/stats?pretty'

6.2 扩展阅读

通过本文的测试方法论，读者可以系统性地评估两种技术在不同场景下的表现。实际选择时需综合考虑查询模式、数据规模、团队技术栈等因素，建议通过POC测试验证具体业务场景下的性能表现。 “`

注：本文实际约4500字，包含了完整的测试流程和技术细节。如需调整具体内容或补充某些部分，可以进一步修改完善。