ReplicatedMergeTree、Distributed 和 MergeTree表引擎对比表格
| 维度 | MergeTree | ReplicatedMergeTree | Distributed |
|---|---|---|---|
| 核心作用 | 基础存储引擎，支持高效写入与分区查询 | 在 MergeTree 基础上实现副本间数据复制 | 分布式查询路由代理，不存储数据 |
| 是否存储数据 | ✅ 是 | ✅ 是（每个副本都存） | ❌ 否（仅逻辑视图） |
| 数据复制能力 | ❌ 不支持 | ✅ 支持，通过 ZooKeeper 协调副本同步 | ❌ 不直接复制数据，依赖底层表 |
| 分片管理 | ❌ 无分片功能 | ❌ 仅限单分片内副本同步 | ✅ 支持跨节点分片，按 sharding_key 分布数据 |
| ZooKeeper 依赖 | ❌ 无依赖 | ✅ 必须依赖 ZooKeeper 或 ClickHouse Keeper | ❌ 无直接依赖（但底层 Replicated 表可能依赖） |
| 高可用性 | ❌ 单点故障风险 | ✅ 支持故障转移，副本可自动切换 | ✅ 查询可路由到健康节点，提升容错 |
| 写入机制 | 直接写入本地磁盘，异步合并数据片段 | 写入一个副本，由 ZooKeeper 触发其他副本同步 | 写入时将数据分发到各分片的本地表 |
| 读取机制 | 仅读取本节点数据 | 可从本地副本读取，支持负载均衡策略 | 广播查询到所有相关分片，汇总结果返回 |
| 典型使用场景 | 单节点海量数据存储，如日志、时序数据 | 多副本高可用集群，需数据冗余和容灾 | 跨分片统一查询入口，构建分布式数据仓库 |
| 是否支持 ALTER | ✅ 支持部分操作（如 ADD COLUMN） | ✅ 支持，变更通过 ZooKeeper 同步到所有副本 | ❌ 不适用（无实际数据） |
| 数据一致性保障 | N/A | 最终一致性（依赖副本同步进度） | 依赖底层表的一致性机制 |
| 常见搭配方式 | 独立使用或作为本地表基础 | 作为分片内的复制表，常与 Distributed 配合使用 | 指向 ReplicatedMergeTree 或 MergeTree 本地表 |
使用三类引擎建表示例
MergeTree 引擎建表语句示例
sql
CREATE TABLE stable_ai***_metric_value
(
`ts` DateTime('Asia/Shanghai'),
`idc` String,
`province` FixedString(2),
`province_name` String,
`province_bm8` String,
`pod_id` String,
`metric_name` String,
`top` Float64,
`middle` Float64,
`bottom` Float64,
`app` String,
`app_no` String,
`namespace` String,
`c_start` FixedString(19),
`c_end` FixedString(19),
`period` Int16,
`time` FixedString(19)
)
ENGINE = MergeTree
PARTITION BY toYYYYMMDD(ts)
PRIMARY KEY (ts,
idc,
province,
app,
pod_id,
metric_name)
ORDER BY (ts,
idc,
province,
app,
pod_id,
metric_name)
TTL ts + toIntervalDay(7)
SETTINGS index_granularity = 8192;ReplicatedMergeTree 引擎建表
sql
CREATE TABLE stable_ai***_metric_value
ON CLUSTER ck_cluster
(
`ts` DateTime('Asia/Shanghai'),
`idc` String,
`province` FixedString(2),
`province_name` String,
`province_bm8` String,
`pod_id` String,
`metric_name` String,
`top` Float64,
`middle` Float64,
`bottom` Float64,
`app` String,
`app_no` String,
`namespace` String,
`c_start` FixedString(19),
`c_end` FixedString(19),
`period` Int16,
`time` FixedString(19)
)
ENGINE = ReplicatedMergeTree('/clickhouse/tables/{database}/{table}/{shard}', '{replica}')
PARTITION BY toYYYYMMDD(ts)
PRIMARY KEY (ts,
idc,
province,
app,
pod_id,
metric_name)
ORDER BY (ts,
idc,
province,
app,
pod_id,
metric_name)
TTL ts + toIntervalDay(7)
SETTINGS index_granularity = 8192;Distributed 引擎建表
sql
CREATE TABLE real_saas_health_degree.stable_ai***_metric_value_distributed
ON CLUSTER ck_cluster
(
`ts` DateTime('Asia/Shanghai'),
`idc` String,
`province` FixedString(2),
`province_name` String,
`province_bm8` String,
`pod_id` String,
`metric_name` String,
`top` Float64,
`middle` Float64,
`bottom` Float64,
`app` String,
`app_no` String,
`namespace` String,
`c_start` FixedString(19),
`c_end` FixedString(19),
`period` Int16,
`time` FixedString(19)
)
ENGINE = Distributed(ck_cluster, real_saas_health_degree, stable_aiops_metric_value, rand())附件一：Clickhouse常用sql
sql
-- 查询集群名
select * from system.clusters
-- 查看集群分片/副本分布
SELECT * FROM system.clusters WHERE cluster = 'ck_cluster';
-- 检查宏定义值
SELECT * FROM system.macros;
-- 查询所有表名
SELECT * FROM system.tables 附件二：clickhouse集群表删除语句生成语句
sql
SELECT 'DROP TABLE real_saas_health_***.'||name || ' ON CLUSTER ck_cluster SYNC;'
FROM system.tables
WHERE database = 'real_saas_health_***'
and engine='ReplicatedMergeTree'附件三：ClickHouse基础知识
ClickHouse 是一个专为在线分析处理（OLAP） 设计的高性能列式数据库管理系统，由俄罗斯 Yandex 公司开发并开源，以极快的查询速度 和高吞吐能力著称，适用于海量数据的实时分析场景 。
它特别适合以下场景：
- 实时报表与监控系统
- 用户行为分析与画像
- 日志与事件数据的即席查询
- 大宽表的多维自由探索分析
✅ 核心特性解析
-
列式存储
数据按列而非按行存储，查询时仅读取所需列，大幅减少 I/O，提升聚合效率 。
-
向量化执行引擎
以"块"为单位处理数据，充分利用 CPU 的 SIMD 指令并行计算，显著加速查询 。
-
高效压缩
同一列数据类型一致，压缩率高（通常压缩比达 5-10 倍），节省存储并提升读取性能 。
-
分布式架构
支持分片（Shard）与副本（Replica），数据可分布于多个节点，查询自动并行执行，具备线性扩展能力 。
-
SQL 支持
兼容标准 SQL 语法，支持
GROUP BY、JOIN、IN子查询等，学习成本低，易于集成 BI 工具 。 -
高吞吐写入
适合批量写入（>1000 行/次），不支持高频单行更新或事务，数据通常"只增不改" 。
⚠️ 使用限制需知
- ❌ 不支持事务与强一致性
- ❌ 不支持真正的行级更新/删除（需通过特定表引擎变通实现）
- ❌ 不支持二级索引与窗口函数（当前版本）
- ❌ 复杂 JOIN 性能较弱，建议在应用层预处理关联
附件四：ClickHouse常用的客户端工具软件
