Timescale Blog
·
只读副本无法解决写入瓶颈
内容提要
添加只读副本可以缓解主数据库的读取瓶颈，但无法解决写入瓶颈。写入延迟可能因副本滞后而增加，导致主数据库负担加重。解决写入瓶颈需要改变存储模型，而非仅依赖副本。
关键要点
-
添加只读副本可以缓解主数据库的读取瓶颈，但无法解决写入瓶颈。
-
写入延迟可能因副本滞后而增加，导致主数据库负担加重。
-
只读副本解决了主数据库的资源竞争问题，改善了写入延迟。
-
写入路径在添加副本后没有改变，仍然需要经过完整的Postgres写入路径。
-
添加副本会增加WAL相关的工作负载，而不是减少它。
-
副本滞后问题会导致主数据库重新处理读取请求，增加资源竞争。
-
添加副本意味着需要管理多个Postgres实例，增加了运维负担。
-
只读副本是隔离问题的解决方案，而不是根本解决写入瓶颈。
-
写入瓶颈的根本原因在于存储模型，需要改变存储模型来解决。
-
列式存储可以减少WAL记录的生成，从而改善写入性能。
延伸解读
只读副本的局限性
虽然只读副本可以有效缓解主数据库的读取瓶颈，但它并不能根本解决写入瓶颈。写入延迟的增加主要源于副本滞后，导致主数据库的负担加重。因此，依赖只读副本来解决写入问题是不够的，必须从存储模型入手进行根本性改进。
运维负担的增加
添加只读副本意味着需要管理多个Postgres实例，这会显著增加运维的复杂性。每个副本都需要独立的监控和维护，包括复制延迟警报和连接池管理等。这些额外的运维工作往往在决策时被忽视，可能导致团队在后期面临意想不到的压力。
写入瓶颈的根本原因
写入瓶颈的根本原因在于存储模型的设计，尤其是每行数据的MVCC开销和WAL记录的生成。仅仅通过添加副本无法改变这些固定成本，必须考虑采用列式存储等不同的存储模型，以有效降低写入负担和提升整体性能。
延伸问答
只读副本如何缓解主数据库的读取瓶颈？
只读副本通过将读取请求转移到副本上，减少了主数据库的CPU和I/O竞争，从而改善了写入延迟。
写入瓶颈的根本原因是什么？
写入瓶颈的根本原因在于存储模型，特别是每行的MVCC开销和每次插入的WAL记录。
添加只读副本会带来哪些运维负担？
添加只读副本需要管理多个Postgres实例，包括监控副本延迟、连接池和故障转移程序，增加了运维复杂性。
只读副本如何影响写入延迟？
虽然只读副本可以改善读取性能，但如果副本滞后，写入延迟可能会增加，因为主数据库需要处理更多的WAL。
如何根本解决写入瓶颈问题？
根本解决写入瓶颈需要改变存储模型，例如采用列式存储，以减少WAL记录的生成。
只读副本和写入瓶颈之间有什么区别？
只读副本解决的是读取瓶颈，而写入瓶颈则是由于存储模型的限制，二者的机制完全不同。
