ElectricSQL 项目中大容量数据初始同步的性能优化问题

背景介绍

ElectricSQL 是一个开源的 PostgreSQL 实时同步解决方案，它能够将 PostgreSQL 数据库的变化实时同步到客户端。在 ElectricSQL 的设计中，为了提高数据传输效率，系统会将响应数据分块(chunking)处理，默认每个块的大小为 10MB(未压缩状态)。

问题发现

在 ElectricSQL 的实际应用场景中，开发团队发现了一个关键的性能问题：初始快照(initial snapshot)的数据传输没有应用分块机制。这个问题在包含大量数据的表同步时尤为明显。

以 linearlite+pglite 演示项目为例，当同步一个包含 50 万条记录的评论表时，产生的 JSON 数据量达到了约 250MB。由于没有分块处理，浏览器在尝试同时加载多个大型表的数据(如 80MB 的问题表和 250MB 的评论表)时遇到了严重性能瓶颈。

问题分析

1. 并行加载问题：浏览器同时加载多个大型 JSON 数据文件时，会出现资源竞争和内存压力。在测试中，虽然 80MB 的问题表可以成功加载，但 250MB 的评论表在加载到约 80MB 时就会挂起并最终失败。

2. 服务器端超时：有趣的是，Electric 服务器日志中出现了超时错误，这表明可能存在某种背压(back pressure)机制导致服务器端超时。

3. 单独加载成功：当仅尝试加载评论表数据时，250MB 的数据可以成功传输，这说明问题不是由单个大文件本身引起的，而是由并行处理多个大文件导致的系统资源竞争。

解决方案

开发团队认为实施响应分块机制可以解决这个问题。通过将大数据集分割成多个 10MB 的块，可以带来以下优势：

1. 减轻浏览器压力：分块加载允许浏览器逐步处理数据，而不是一次性处理整个大数据集。

2. 更好的资源管理：分块机制可以更有效地管理内存和网络资源，避免大请求导致的资源耗尽。

3. 提高可靠性：即使某个块传输失败，也可以仅重试该块，而不需要重新传输整个数据集。

技术实现建议

1. 初始快照分块：将初始快照数据也纳入现有的分块机制，确保所有大数据传输都遵循相同的分块策略。

2. 流式处理：考虑实现流式处理机制，使客户端可以边接收边处理数据，而不是等待完整数据集。

3. 并行度控制：对于多个表的初始同步，实现并行度控制机制，避免同时传输过多大表数据。

总结

ElectricSQL 在处理大型数据集初始同步时遇到的性能问题，突显了分块传输机制在实时数据同步系统中的重要性。通过将初始快照也纳入分块处理机制，可以显著提高系统处理大数据集的能力和可靠性，为用户提供更流畅的同步体验。这一改进对于需要处理大量数据的应用场景尤为重要。