当前位置：首页 > news >正文

简单介绍一下Clickhouse及其引擎

news 2025/9/11 8:34:39

一、ClickHouse 的优缺点

一、ClickHouse 的优点 ✅

1. 极致的查询性能

列式存储：只读取查询涉及的列，大幅减少 IO。
数据压缩：常见压缩率 5~10 倍，减少存储和带宽消耗。
向量化执行：按批次（block）处理数据，充分利用 CPU SIMD 指令。
并行查询：单机多核 + 集群分布式并行。

👉 结果：在 TB~PB 级数据量上，秒级甚至毫秒级返回复杂聚合查询。

2. 实时写入 + 即时可查

支持高并发写入（百万级/秒），数据写入后几乎立即可查询。
比 Hive、Presto 这类 批处理查询引擎 要快得多。

👉 适合 实时数据分析、监控、日志查询。

3. 分区、索引、分布式能力

主键索引 (Sparse Index)：按分区范围做稀疏索引，快速定位数据。
数据分区/分片 (Sharding & Partitioning)：支持海量数据水平扩展。
副本 (Replication)：保证高可用和容灾。

👉 可以支撑 大规模集群部署。

4. 丰富的数据引擎

MergeTree 系列：主力 OLAP 存储。
外部数据源引擎：MySQL、Kafka、HDFS、S3、Postgres、MongoDB 等。
Buffer、MaterializedView：支持实时 ETL。

👉 在 冷热数据分层、与大数据生态结合 方面很灵活。

5. 开源 + 活跃生态

Apache 2.0 协议，社区活跃。
已在 Yandex、腾讯、美团、字节跳动等大规模落地。
生态中有 Kafka、Spark、Flink、Airflow 等连接器。

6. 运维成本相对较低

单机就能跑得很好，部署门槛低。
不依赖 Hadoop 生态（相比 Hive/Presto）。
对比 Druid、Kylin，运维复杂度更低。

二、ClickHouse 的缺点 ⚠️

1. 不适合事务场景

没有完整的 ACID 事务，仅支持有限的 原子性操作 (Atomic engine)。
不适合 OLTP（银行转账、电商订单等强一致性场景）。

👉 它是 OLAP 系统，定位是分析，而不是事务处理。

2. 写入删除机制有限

删除 (DELETE/UPDATE) 操作本质上是 标记删除，数据会在后台合并时真正清理。
写入是 批量块 (block)，小量频繁写入效率较差。

👉 适合 append-only 的场景（日志、监控），不适合频繁更新。

3. 学习曲线

引擎种类多（MergeTree 系列、Log、Buffer…），新手需要理解其差异。
SQL 方言与标准 SQL 有些差别，比如 LIMIT BY、SAMPLE、FINAL 等。

4. 资源消耗

极致性能是通过 CPU、内存换取的：
- 查询时常常消耗大量内存。
- 并发查询太多时可能出现 OOM。
高性能存储介质（SSD/NVMe）更适合 ClickHouse，否则性能会打折扣。

5. 生态相对不如传统数据库

BI 工具支持在增强，但相比 MySQL/Postgres 还是稍弱。
机器学习、流处理生态，需要依赖 Spark/Flink 来补充。

6. 集群管理复杂性

虽然单机简单，但大规模集群下：
- 表分片、副本、分布式查询路由，需要良好设计。
- 运维经验不足时容易遇到 数据倾斜、分片不均衡 的问题。

三、总结表格

方面	优点	缺点
性能	秒级/毫秒级查询，列存+压缩+向量化	高并发查询时内存占用大
写入	高吞吐实时写入	不适合频繁更新/删除，小批量写入低效
事务	支持原子表	缺乏完整 ACID，不能做 OLTP
架构	分布式、分片、副本、高可用	集群管理复杂
生态	外部引擎丰富，社区活跃	BI/ML 生态不如 MySQL/PG 丰富
运维	单机简单，依赖少	大规模集群需要专业经验

📌 一句话总结

ClickHouse = 高性能 OLAP 引擎，适合日志分析、指标监控、用户行为分析、大数据实时查询；
不适合 事务处理、频繁更新删除、强一致性场景。

二、存储引擎 (Table Engines)

1. 核心概念

在 ClickHouse 里，表引擎 (Table Engine) 决定了表的数据如何存储、分布、复制、合并以及如何被查询。

有些引擎是 存储型（比如 MergeTree），真的把数据落盘。
有些是 视图型（比如 View），不存储数据，只做查询映射。
有些是 外部数据源型（比如 MySQL、Kafka、HDFS），数据存在别处。

2. 主流存储引擎类别

(A) MergeTree 系列（最常用、最强大）

这是 ClickHouse 的核心存储引擎族，支持 索引、分区、TTL、压缩、并行查询 等特性。
常见子类：

MergeTree：基础版本。
ReplacingMergeTree：支持用指定列替换重复数据。
SummingMergeTree：自动对相同 key 的数据做聚合（求和）。
AggregatingMergeTree：支持存储预聚合数据（配合 AggregateFunction）。
CollapsingMergeTree：支持“折叠”正负标记的数据（常用于 CDC、日志）。
VersionedCollapsingMergeTree：带版本号的折叠，解决数据顺序问题。
GraphiteMergeTree：专门为 Graphite 监控数据设计（支持 rollup）。

👉 特点：适合绝大多数 OLAP 场景，是 ClickHouse 的主力。

(B) 日志型引擎（简单轻量）

不做复杂的合并和索引，性能和功能有限，适合小表、临时表。

Log：简单的日志表。
StripeLog：数据按列分 stripe 存储。
TinyLog：最简单的存储形式，写入文件，几乎没有额外功能。

👉 常见于测试、小规模表。

© 内存型引擎

Memory：数据全在内存里，重启会丢失，适合临时计算。

(D) 外部数据源 / 文件系统引擎

File：读写本地文件（支持 CSV、TSV、Parquet、ORC 等）。
HDFS：读写 HDFS 文件。
S3：读写 AWS S3 或兼容的对象存储。
URL：直接通过 HTTP/HTTPS 访问远程文件。
MySQL：把 MySQL 表映射为 ClickHouse 表。
PostgreSQL：访问 PostgreSQL 数据。
ODBC / JDBC：通过 ODBC/JDBC 访问外部数据库。
Kafka：从 Kafka 消费数据。
RabbitMQ：从 RabbitMQ 读写数据。
MongoDB：访问 MongoDB 数据。

👉 适合做 外部数据源接入、ETL、实时数据摄取。

(E) 分布式 / 集群引擎

Distributed：把表分布到多个 ClickHouse 节点，支持分布式查询。
Dictionary：存储字典数据（常用于维表 join）。

(F) 特殊用途引擎

Null：丢弃所有写入，查询时返回空结果（类似 /dev/null）。
View：普通视图，不存储数据。
MaterializedView：物化视图，存储查询结果。
LiveView：实时视图，支持订阅数据变化。
Join：专门存储用于 JOIN 的数据。
Set：存储一个集合，用于 IN 查询。
Buffer：数据先写入内存缓冲区，再异步落到目标表。
Merge：将多个表合并为一个逻辑表。
Dictionary：存储字典型数据（维表）。

3. 总结

ClickHouse 的引擎大致可以分为几类：

类别	代表引擎	主要用途
核心存储	MergeTree 系列	高性能 OLAP，分区、索引、压缩
轻量存储	Log、TinyLog、StripeLog	小表、临时表
内存	Memory	临时计算
外部数据	File、HDFS、S3、MySQL、Kafka	数据交换、ETL、实时导入
分布式	Distributed	集群查询
特殊用途	Null、View、MaterializedView、Join、Buffer	特殊场景