Hacker News 中文摘要

RSS订阅

我们提升了Postgres写入速度，却破坏了复制功能 -- We made Postgres writes faster, but it broke replication

原文链接 | HN讨论 | 2025-07-22 01:01:55

文章摘要

ParadeDB团队在开发Postgres扩展pg_search时，为了提高写入性能，采用了LSM树数据结构，以替代传统的B树或GIN索引。尽管这一优化显著提升了写入吞吐量，适用于实时搜索和分析场景，但也导致了复制功能的失效。

文章总结

标题：ParadeDB：我们提升了Postgres的写入速度，但破坏了复制功能

在开发Postgres的搜索和分析扩展pg_search时，我们优先考虑了写入吞吐量。为了成为Elasticsearch的有效替代品，我们需要支持实时的高写入负载，因为许多Elasticsearch用例（如实时仪表盘、电子商务搜索和推荐系统）都涉及必须立即索引和可搜索的连续写入。

在标准的Postgres实现中，全文搜索依赖于B树或GIN（广义倒排索引）结构。这些索引对于相对快速的查找是有效的，但在写入方面并不快。我们选择了一种优化写入的数据结构：日志结构合并树（LSM树）。这大大提高了写入吞吐量，但却破坏了Postgres的复制功能，特别是物理复制。物理复制是Postgres从主节点复制数据到一个或多个只读副本的两种机制之一，另一种是逻辑复制，它发送单独的行更改而不是逐字节复制数据库。

我们发现，Postgres对物理复制的开箱即用支持（基于预写日志WAL传输）不足以确保像LSM树这样的高级数据结构的复制安全性。为了解决这个问题，我们深入探讨了以下内容：

  1. 什么是LSM树？
    LSM树是一种写入优化的数据结构，常用于RocksDB和Cassandra等系统。其核心思想是将随机写入转换为顺序写入。写入首先存储在内存中的memtable中，一旦memtable填满，它会被刷新到磁盘作为一个排序的、不可变的段文件（通常称为SSTable）。这些段文件按大小组织成层，新数据写入最上层，随着时间的推移，数据通过压缩过程逐渐推入下层。

  2. 复制安全性意味着什么？
    可靠的分布式数据存储必须确保数据库副本的物理和逻辑一致性。物理一致性意味着副本包含结构上有效的数据，而逻辑一致性确保副本上的数据反映了数据库的一致和稳定视图。

  3. Postgres如何通过WAL传输保证物理一致性？
    在主备物理复制设置中，主服务器与备用服务器配对，备用服务器作为主服务器的只读副本。服务器通过使用WAL记录主服务器上存储块的所有二进制级别更改来保持同步。WAL文件的更改被流式传输到备用服务器（称为“日志传输”）并按接收顺序应用。

  4. 为什么原子性是物理一致性的要求？
    原子性是物理一致性的要求，因为Postgres锁不会在副本服务器上重放。WAL使用每缓冲区锁来按特定顺序重放编辑，但当修改跨越多个Postgres缓冲区的数据结构时，如果没有保证操作在整个结构上是原子的，这些修改可能导致结构损坏。

  5. 我们如何利用hot_standby_feedback解决逻辑一致性问题？
    hot_standby_feedback是一个可选的Postgres设置，当启用时，备用服务器可以告诉主服务器从副本的角度来看哪些数据可以安全清理。这大大减少了元组被过早清理的可能性，并允许pg_search确定何时可以安全删除段。

最终，我们通过实现原子记录的LSM树和依赖hot_standby_feedback来确保物理和逻辑一致性。这一挑战值得应对，因为它在不牺牲一致性的情况下实现了最快的搜索性能。

评论总结

评论主要围绕技术深度、工具选择和学习经验展开。

  1. 技术深度的认可

    • 评论1赞赏了文章的技术深度，认为Hacker News需要更多此类内容。
      引用： "Love this style of no-fluff technical deep dive. HN needs more content like this."
      中文： “喜欢这种无废话的技术深度探讨。Hacker News需要更多这样的内容。”

  2. 工具选择的质疑

    • 评论3质疑为何不使用现有的OpenSearch或ElasticSearch，认为这是不必要的重复造轮子。
      引用： "Why not just use OpenSearch or ElasticSearch? The tool is already in the inventory; why use a screwdriver when a chisel is needed and available?"
      中文： “为什么不直接使用OpenSearch或ElasticSearch？工具已经存在了，为什么需要用一个螺丝刀当凿子？”

  3. 学习经验的反思

    • 评论2指出在真实工作负载下，LSM树和Postgres的B树及vacuum机制会冲突，强调了CAP定理的实际限制。
      引用： "Guess we will live to relearn that CAP theorem is a physical limit and not just a theory."
      中文： “看来我们又要重新认识到CAP定理是物理限制，而不仅仅是理论。”

  4. 图表制作的疑问

    • 评论4简单询问了图表的制作方式。
      引用： "diagramas made how?"
      中文： “图表是怎么做的？”