ClickHouse是什么

什么是ClickHouse？

ClickHouse 是由俄罗斯搜索引擎公司 Yandex 开发的一款高性能、列式存储的开源 OLAP（联机分析处理）数据库，专为处理海量数据的实时分析查询而设计。它的核心特点是极致的查询速度，能够在秒级甚至毫秒级内完成对 TB 级乃至 PB 级数据的复杂分析（如多维度聚合、统计、关联查询等），广泛应用于数据仓库、日志分析、实时监控、用户行为分析等场景。

ClickHouse可以做什么？

ClickHouse 专注于 OLAP 场景，尤其适合：

• 海量数据的统计分析（如用户行为分析、业务指标监控）；
• 日志存储与查询（如服务器日志、应用日志的实时检索）；
• 数据仓库建设（存储历史数据，支持复杂多维分析）；
• 实时报表生成（快速响应动态查询，生成可视化报表）。

但它不适合事务性场景（如银行转账、订单支付），因为不支持完整的 ACID 特性，且写入后修改 / 删除数据成本较高。

ClickHouse与传统数据库的区别？

ClickHouse 作为专为 OLAP（联机分析处理）设计的新型数据库，与传统数据库（以 OLTP 为主的关系型数据库，如 MySQL、PostgreSQL、Oracle 等）在设计理念、技术特性和应用场景上存在显著差异。

设计目标与核心场景不同

MySQL、PostgreSQL等传统数据库

以 OLTP（联机事务处理） 为核心目标，聚焦于支持高并发的小事务（如用户注册、订单提交、库存更新等），强调数据的实时性、一致性和事务完整性（ACID 特性）。
适用场景：支撑业务系统的日常操作，如电商交易、银行转账、用户账户管理等，需频繁处理单行 / 少量数据的增删改查。

ClickHouse

是列式存储的 OLAP 数据库，专为 OLAP（联机分析处理） 场景设计，侧重支持海量数据的复杂查询与分析（如多维度聚合、统计报表），牺牲部分事务特性换取极致查询性能。
适用场景：日志分析、用户行为分析、实时监控、数据仓库等需要对大规模数据进行批量分析的业务。

存储方式：行式 vs 列式

传统数据库：行式存储

数据按行连续存储（一行的所有列打包成一个整体）。例如，一条用户记录（ID、姓名、年龄、地址）会作为一个完整单元存储。

• 优势：适合查询或修改一整行数据（如查询某个用户的全部信息），单行操作效率高。
• 劣势：当查询仅涉及部分列时（如统计所有用户的年龄），仍需读取整行数据，导致大量无效 IO，效率低下。

ClickHouse：列式存储

• 优势：
  • 查询时仅读取涉及的列（如统计年龄时只读 “年龄” 列），减少 80%-90% 的 IO 量；
  • 同一列数据类型一致，可通过压缩算法（如 LZ4、ZSTD）大幅压缩（压缩率通常 5-10 倍），节省存储空间并降低 IO 压力；
  • 列级并行处理更高效（同一列可拆分给多个 CPU 核心处理）。
• 劣势：不适合单行数据的频繁修改（修改一行需更新多个列的存储文件，成本高）。

事务与一致性

传统数据库

严格支持 ACID 事务（原子性、一致性、隔离性、持久性），通过锁机制（如行锁、表锁）和事务日志（如 MySQL 的 binlog、Oracle 的 redo log）保证并发事务的正确性。例如，银行转账时，“扣款” 和 “到账” 必须同时成功或同时失败，避免数据不一致。

ClickHouse

几乎 不支持事务：

• 支持简单的 INSERT 操作，非常有限支持 UPDATE/DELETE（效率极低，需全表重写，本质是 “标记删除 / 更新”）；
• 没有事务隔离级别，并发写入时可能出现短暂的数据不一致（通过异步合并机制最终一致）；
• 设计上优先保证查询性能，牺牲事务完整性。

数据规模与处理能力

传统数据库

• 单表数据量通常建议控制在千万级以内（超过后需分库分表，否则查询性能急剧下降）；
• 依赖单机性能，不支持分布式并行计算，复杂聚合查询（如全表 GROUP BY）在大数据量下耗时极长（分钟级甚至小时级）。

ClickHouse

• 轻松支持 亿级、十亿级甚至 PB 级数据，单表可存储数万亿行记录；
• 原生支持 分布式架构，数据按分片存储在多个节点，查询时通过 MPP（大规模并行处理）框架自动拆分任务到各节点并行计算，结果汇总后返回，复杂查询可在秒级完成（如对 10 亿行数据按 5 个维度聚合）。

索引与查询优化

传统数据库

依赖 B + 树索引 加速查询，适合单行或小范围数据的点查（如 WHERE id = 123），索引设计围绕 “减少扫描范围” 优化。但对于全表扫描或大范围聚合查询，索引作用有限。

ClickHouse

采用 面向分析的特殊索引：

• 稀疏主键索引：不保证每行都有索引，仅对部分行建立索引，适合范围查询（如 WHERE time > '2023-01-01'）；
• 跳数索引（Skip Index）：针对高频查询场景（如枚举值、数值范围），通过预计算跳过大量无关数据，加速筛选；
• 向量搜索优化：支持列级数据的批量处理，配合 CPU 指令集（如 AVX2）提升计算效率。索引设计围绕 “高效扫描和聚合” 优化，不适合点查，但对大范围分析查询友好。

读写性能特点

传统数据库

• 写入：支持高并发小批量写入（每秒数千至数万条），事务提交开销低；
• 读取：单行查询或小范围查询快（毫秒级），但大批量聚合查询慢（分钟级）。

ClickHouse

• 写入：适合 大批量写入（每秒数十万至数百万条），小批量写入效率低（因需频繁创建数据块）；
• 读取：批量分析查询极快（秒级），但单行查询可能比传统数据库慢（因需扫描列文件）。

CAP分析

上述针对几大场景对比了传统数据与ClickHouse的区别，下面再从CAP原理进行分析。不清楚CAP原理的同学也不用担心，下面会从原理开始介绍，熟悉的同学可以一起复习下。

CAP原理是什么？

CAP 原则（又称 CAP 定理）是分布式系统设计中的核心理论之一，由加州大学伯克利分校的计算机科学家 Eric Brewer 于 1998 年提出（后经 Seth Gilbert 和 Nancy Lynch 于 2002 年从数学上证明）。它揭示了分布式系统在三个关键特性之间的 “不可能三角”——无法同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance），必须根据业务场景牺牲其中一项。

CAP原理核心定义

要理解 CAP 原则，首先需要明确三个原则的精确含义

一致性（Consistency，简称 C）

指 “所有节点在同一时间看到的是相同的数据”，即分布式系统中，当一个更新操作完成后，所有后续的读取操作（无论访问哪个节点）都必须返回这个最新值；如果更新未完成，则所有节点都不能返回中间状态或错误数据。

• 类比：银行转账时，A 账户扣款 100 元后，无论查询哪个银行服务器，A 账户余额都必须是 “原余额 - 100”，B 账户余额必须是 “原余额 + 100”，不存在 “部分节点显示扣了、部分节点没扣” 的情况。
• 关键：数据的 “全局统一性”，强调更新后的 “正确性”。

可用性（Availability，简称 A）

指 “只要客户端的请求是合法的（无故障），分布式系统就必须在有限时间内返回响应（成功或失败），不能出现‘无响应’或‘超时’”，即系统服务始终可用，不拒绝合法请求。

• 类比：电商平台的商品详情页，即使部分服务器故障，用户访问时仍能快速加载页面（可能加载的是缓存数据，但必须有响应），而不是出现 “502 错误” 或无限转圈。
• 关键：服务的 “可访问性”，强调 “不宕机、有响应”。

分区容错性（Partition Tolerance，简称 P）

指 “当分布式系统中的部分节点与其他节点失去网络连接（形成‘网络分区’）时，系统仍能继续运行，不会因为网络故障而整体崩溃”。

• 网络分区是分布式系统的 “必然风险”：由于节点分布在不同机器 / 机房，网络延迟、断网、防火墙故障等都会导致部分节点无法通信（例如：北京机房的节点与上海机房的节点断连，形成两个独立分区）。
• 类比：微信的消息发送功能，即使用户 A 所在的服务器与用户 B 所在的服务器暂时断连，A 发送消息时仍能成功（消息暂存本地或其他节点），待网络恢复后再同步给 B，系统不会因分区而无法使用。
• 关键：系统的 “抗故障能力”，强调 “网络故障下的可用性”。

CAP 原则的核心：“不可能三角”

在分布式系统中，网络分区（P）是客观存在且无法完全避免的（除非系统退化到单机，不再是分布式）。因此，CAP 原则的实际落地场景中，往往需要在 “一致性（C）” 和 “可用性（A）” 之间做权衡，形成两种典型取舍方案：

方案 1：牺牲一致性（C），保证可用性（A）和分区容错性（P）→ 即 AP 系统

当网络分区发生时，系统优先保证 “服务可用”，允许不同分区的节点返回 “暂时不一致” 的数据，但待网络恢复后，再通过数据同步机制（如最终一致性）修复差异。

• 适用场景：对 “实时一致性” 要求低，但对 “服务可用性” 要求极高的业务。
• 典型案例：
  • 电商商品库存：秒杀场景下，允许部分用户看到 “缓存中的库存”（可能与实际库存有短暂差异），避免因网络分区导致所有用户无法下单；
  • 社交软件消息：微信 / QQ 消息发送后，即使暂时未同步到对方节点，发送方仍能看到 “已发送”（本地存储），待网络恢复后再同步，保证用户能正常使用；
  • 分布式缓存（如 Redis 集群）：主节点故障时，从节点立即切换为主节点提供服务，允许短暂的数据不一致（后续通过主从同步补全）。

方案 2：牺牲可用性（A），保证一致性（C）和分区容错性（P）→ 即 CP 系统

当网络分区发生时，系统优先保证 “数据一致性”，拒绝可能导致不一致的请求（例如：禁止某个分区的写入操作），直到网络分区恢复、数据同步完成后，再恢复服务。

• 适用场景：对 “数据一致性” 要求极高，不允许任何中间状态的业务。
• 典型案例：
  • 银行转账 / 金融交易：如果两个节点断连，系统会拒绝转账请求（避免出现 “扣款成功但到账失败”），直到网络恢复后再允许操作；
  • 分布式数据库（如 ClickHouse 分布式表、HBase、ZooKeeper）：ZooKeeper 作为分布式协调工具，当节点分区时，仅 “多数派节点” 组成的分区能提供服务，少数派分区拒绝请求，保证数据一致；
  • 订单支付确认：必须确保 “用户付款” 和 “订单状态更新” 完全一致，否则拒绝支付请求，避免 “付了钱但订单未生效”。

传统数据库与ClickHouse的CAP定位

由上可知，MySQL 是传统的 关系型数据库（RDBMS），设计目标是支持事务型场景（OLTP）（如电商订单、金融交易），核心需求是 “数据一致性” 和 “事务可靠性”，偏向 CP系统。ClickHouse 是 列式存储的分析型数据库（OLAP），设计目标是支持大规模数据的快速查询分析（如日志统计、用户行为分析），核心需求是 “高查询性能” 和 “高吞吐量”，对事务一致性要求极低，偏向AP系统。

对比总结