我们是如何为 ClickHouse 列式存储构建快速 UPDATE 的 Part1/3：特别设计的专用引擎

本文字数：9340；估计阅读时间：24 分钟

作者：Tom Schreiber

本文在公众号【ClickHouseInc】首发

要点总结

ClickHouse 通过将更新视作插入操作，巧妙避开了行级更新带来的性能瓶颈。在这篇系列的第一篇中，我们将介绍几个专为此场景设计的引擎，它们是如何实现高速更新的。  

在第 2 部分，我们将展示如何引入 SQL 风格的 UPDATE，同时仍保持 ClickHouse 的高性能优势。

不用 UPDATE 也能实现快速更新 

列式存储天生不适合做行级更新。

ClickHouse 也不例外：它从一开始就是为了在大规模数据场景下提供极速的写入和查询性能而设计的，而不是为修改单行数据而优化的。

但现实中的数据应用并不会遵循教科书上的“只读”模式。

ClickHouse 的用户经常要处理快速变化的数据：IoT（传感器读数）、电商（订单与库存）、金融（支付状态）、游戏（玩家数据），以及 CRM/HR（用户或员工档案），这些数据需要被不断地更正、更新甚至删除。与其在一个为大规模读取设计的系统中硬塞进低效的 UPDATE 操作，我们选择了另一种方式：

我们将更新操作当作插入来处理，从而绕开了性能问题。

这不是一个临时解决方案，而是 ClickHouse 有意为之的架构设计。像 ReplacingMergeTree、CoalescingMergeTree 和 CollapsingMergeTree 这样的引擎，通过写入新行代替修改旧行，实现了对更新和删除的支持。它们充分利用 ClickHouse 高并发插入能力和后台合并机制，避开了原地更新常见的性能开销。

这些引擎在大规模数据场景中依然非常实用，尤其适合高写入、频繁变更的数据工作负载。同时，它们也为我们后来构建的新一代更新机制提供了灵感，理解它们的工作方式，有助于理解 ClickHouse 如何加速 SQL 风格的更新。

本系列将介绍以下内容：

• 本篇（第 1 部分）：介绍这些专为处理更新而设计的引擎是如何工作的，以及为何它们依旧非常高效。

• 第 2 部分(https://clickhouse.com/blog/updates-in-clickhouse-2-sql-style-updates)：将介绍如何引入标准 SQL 风格的 UPDATE，并由一种全新的机制 —— patch parts 提供支持。

• 第 3 部(https://clickhouse.com/blog/updates-in-clickhouse-3-benchmarks)：我们将对上述所有方案进行性能测试，对比它们在实际场景中的表现。

要理解 ClickHouse 是如何做到快速更新的，首先得知道为什么列式存储天生就不擅长处理更新操作。

为什么在列式存储中执行更新很困难 

在数据库系统中，更新与分析常常是性能上的对立面：一个优化了，另一个可能就会变慢。

在行式存储系统（如 PostgreSQL 或 MySQL）中：

• 每一行数据在磁盘上是连续存储的。

• 所以更新很方便，可以直接原地覆盖整行。

• 但分析性能不佳：即便你只查询两列，也必须把整行加载到内存中。

而在列式存储系统（如 ClickHouse）中：

• 每一列被存储为独立的文件。

• 因此分析非常高效，只需读取所需的列。

• 但更新变得更复杂，因为要修改某一行数据，必须同时修改多个文件，且需要重写部分数据。

这种结构性的取舍，让列式系统始终难以高效支持行级更新。

ClickHouse 选择了另一种思路：用专为此场景设计的引擎，通过“避开更新”来实现更新。

由于插入非常快，我们将更新实现为插入

核心理念其实很直接：C