ElectricSQL 中复制发布过滤器的清理机制优化

在 ElectricSQL 项目中发现了一个关于复制发布(replication publication)过滤器的重要可靠性问题。当数据形状(shapes)被移除时，系统未能正确清理相关的发布过滤器，这可能导致系统性能逐渐下降。

问题背景

ElectricSQL 使用 PostgreSQL 的复制发布机制来同步数据变更。当创建数据形状时，系统会自动向发布中添加相应的表和行过滤器。然而，当前实现存在一个关键缺陷：当形状被删除时，这些过滤器不会被自动移除。

这种设计会导致两个主要问题：

1. 发布定义会随时间不断增长，最终可能包含所有表和行
2. 系统会持续处理不需要的数据变更，浪费计算资源

技术分析

当前实现中，Electric.Postgres.Configuration模块负责在形状创建时修改发布定义。每次创建形状都会触发两次PostgreSQL往返操作来调整发布过滤器。然而，删除形状时却没有相应的清理机制。

更严重的是，这个问题会持续影响系统性能，即使在重启和重新部署后也无法自动修复。随着时间推移，系统会处理越来越多不必要的数据变更，导致整体性能下降。

解决方案探讨

针对这个问题，社区提出了几种改进方案：

1. 全量更新策略：修改Electric.Postgres.Configuration模块，使其基于所有活动形状来更新发布定义，而不是逐个处理。这样每次调用都会完整更新整个发布及其过滤器。

2. 引用计数机制：建立表级(未来可能包括列级)的索引引用计数。在形状增删时更新索引，并相应调整发布中的表和过滤器。这种方案可以避免对相同表和列的重复操作。

3. 定期清理：实现定期清理机制，而非在每次形状删除时立即执行。这种折中方案可以平衡即时性和系统负载。

性能考量

在讨论过程中，专家们特别关注了大规模形状操作时的性能影响：

• 对于高频形状创建场景(如每秒数千次)，全量更新可能带来性能挑战
• 但相比之下，不清理过滤器会导致持续的资源浪费，长期影响可能更严重
• 引用计数机制可以显著减少不必要的发布更新操作

最佳实践建议

基于讨论，建议采用以下优化策略：

1. 实现表级引用计数机制，仅在表的使用状态变化时更新发布
2. 对列级过滤保持谨慎，待性能评估后再决定实现方式
3. 考虑结合定期清理和事件驱动清理的混合策略

这种方案既能保证系统可靠性，又能维持良好的性能表现，是当前技术条件下的较优选择。

未来方向

长期来看，ElectricSQL团队计划重新思考整个复制槽过滤机制。当前基于形状的细粒度过滤方式可能不是最佳实践，未来可能会转向更高效的过滤策略，如仅过滤不需要的列等更可持续的方案。