在相同硬件和数据条件下，ClickHouse在单行更新性能上与PostgreSQL相当，而在批量更新测试中速度可达PostgreSQL的4000倍。ClickHouse的列式设计和并行处理能力使其在OLTP工作负载中的批量更新表现尤为突出。然而，PostgreSQL默认支持完整事务，而ClickHouse则不具备相同的事务保证。尽管ClickHouse以OLAP性能著称，但其在OLTP领域的潜力常被低估。2025年7月，ClickHouse v25.7引入了高性能的SQL标准更新功能，进一步提升了其竞争力。

标题：无法找到就无法更新：ClickHouse与PostgreSQL的更新性能对比

主要内容：

在相同的硬件和数据条件下，ClickHouse在单行更新（UPDATE）性能上与PostgreSQL相当，而在批量更新测试中，ClickHouse的速度比PostgreSQL快多达4000倍。这一差异主要源于ClickHouse的列式存储设计和并行处理能力，使其在处理OLTP（在线事务处理）工作负载中的批量更新时表现尤为出色。

背景： - PostgreSQL是全球最流行的开源OLTP数据库，通常被视为更新性能的基准。 - ClickHouse则是全球最流行的开源OLAP（在线分析处理）数据库，虽然其OLAP性能备受认可，但其在OLTP领域的潜力常被低估。

测试方法： - 测试使用了TPC-H的lineitem表，模拟了客户订单中的商品数据，包含约6亿行数据。 - 测试环境为AWS m6i.8xlarge实例，运行Ubuntu 24.04 LTS，分别测试了ClickHouse 25.7和PostgreSQL 17.5的性能。 - 测试分为单行更新和批量更新，重点关注更新速度和更新后的查询性能。

测试结果： 1. 单行更新：ClickHouse在单行更新中表现略优于PostgreSQL，主要因为PostgreSQL默认将每个语句包装在事务上下文中，增加了额外开销。 2. 批量更新：在批量更新中，ClickHouse的速度比PostgreSQL快多达4000倍，尤其是在需要扫描大量数据时，ClickHouse的并行处理和列式存储优势显著。 3. 更新后的查询性能：ClickHouse在更新后的查询性能上也大幅领先PostgreSQL，尤其是在处理大规模数据分析时，ClickHouse的表现更为出色。

结论： - ClickHouse不仅在更新操作上表现出色，还能在更新后立即支持高效的查询，这在OLTP场景中非常罕见。 - 尽管PostgreSQL默认提供完整的事务支持，而ClickHouse目前尚未完全支持事务，但未来ClickHouse有望在事务支持方面取得进展。

总结： ClickHouse在更新性能上的表现令人印象深刻，尤其是在批量更新和后续查询处理上，展现了其在OLTP和OLAP场景中的强大潜力。未来，随着事务支持的进一步完善，ClickHouse有望在更多应用场景中与PostgreSQL一较高下。

评论主要围绕ClickHouse（CH）和PostgreSQL（Postgres）的优缺点展开，观点如下：

1. 事务性支持：

   • Postgres：默认支持完整的事务性，适合金融应用等需要强一致性的场景。
     • 引用：“如果事务性对你很关键（如金融应用），Postgres仍然是更好的选择。”（If the transactionality is key for you (like a financial application or the data for an application) then Postgres still makes more sense.）
   • ClickHouse：默认不支持事务性，适合时间序列数据等允许少量数据丢失的场景。
     • 引用：“如果你主要存储可以丢失少量数据的数据（如时间序列数据），ClickHouse是显而易见的选择。”（If you're using Postgres primarily for storing data where it's ok if you lose a few (like time series data) then Clickhouse is the clear and obvious choice.）

2. 数据更新与操作复杂性：

   • ClickHouse：在仅追加/插入的场景下表现优异，但更新数据时操作复杂且效率低。
     • 引用：“如果你的工作负载是仅追加/仅插入，那么恭喜你，ClickHouse非常棒。但如果你需要更新数据，那就准备好迎接挑战吧。”（If your workload is append-only/insert-only then congrats, it's amazing, you'll have a great time. If you need to update data... Well, strap in.）
     • 引用：“UPDATE == INSERT，想象一下用数百万条UPDATE查询，那将是噩梦。”（UPDATE == INSERT and that's it. Imagine doing it with millions of UPDATE queries, that'll be nightmare.）
   • Postgres：在数据更新和操作上更为灵活和稳定。
     • 引用：“只要你能用Postgres，就继续用Postgres。”（As long as you can get away with Postgres, stay with Postgres.）

3. 默认设置与使用体验：

   • ClickHouse：默认设置和某些行为（如NULL连接行为）可能令人困惑，增加了使用难度。
     • 引用：“ClickHouse的默认设置让我抓狂，NULL连接行为让我一度考虑将其从基础设施中移除。”（The CH defaults drive me insane, the null join behavior alone made me reconsider trying to rip CH out of our infrastructure.）
   • Postgres：作为传统关系型数据库，使用体验更为直观和稳定。

4. 性能与ACID合规性：

   • ClickHouse：在非ACID合规的场景下性能卓越，但缺乏完整性保障。
     • 引用：“如果你不追求ACID合规，4000倍的性能提升并不难实现。”（4000 times faster is hardly difficult if you’re not trying to be ACID compliant.）
   • Postgres：在ACID合规的前提下提供稳定的性能。

总结：ClickHouse在特定场景（如时间序列数据、仅追加/插入）下表现优异，但在事务性、数据更新和默认设置上存在明显不足。Postgres则在事务性和操作灵活性上更具优势，适合需要强一致性和复杂数据操作的场景。