MongoDB副本集内存不足时除分片外的替代方案：概念验证
内容提要
文章介绍MongoDB存储分层方案Thermocline：保留现有副本集作为归档层，前置小型快速副本集存放近期数据，应用通过代理连接，按数据年龄决定存储层。测试中吞吐量提升1.6至5.2倍，读延迟p95从86毫秒降至6毫秒，且无需分片或修改应用。该方案为概念验证，尚未用于生产。
延伸解读
适用场景：近期数据主导的读负载
Thermocline 的收益高度依赖访问模式。测试中，当流量集中在近期数据时，吞吐量提升 5.2 倍；而混合存储场景仅提升 1.6 倍。这意味着该方案更适合“大部分读请求针对新数据、旧数据仅偶尔访问”的业务，如订单、事件日志等。若查询随机分布或频繁访问历史数据，快速层命中率低，加速效果将大打折扣。
冷启动表现：快速层从空开始逐步预热
采用该方案时，快速层初始为空，需要依靠流量和预热器逐步填充。测试显示，在存储混合负载下，前 100 秒性能低于原集群，但 30 分钟内平均吞吐量仍比原集群高 42%，且期间从归档层复制了约 27 万条文档。因此，上线初期需容忍短暂的性能爬坡，并确保预热机制能及时将热点数据迁移至快速层。
未覆盖的写路径与一致性开销
文章主要验证了读性能的提升，但写操作仍需落到归档层，且维持两层一致需要额外机制（如代理路由、预热器、变更同步）。这些组件会引入延迟和运维复杂度。此外，测试未涉及跨层事务、批量写入或故障切换场景，生产部署前需评估写密集负载下的表现及数据一致性保障。
概念验证的局限：尚未生产验证
Thermocline 目前是个人构建的概念验证项目，代码开源但未在生产环境运行。测试基于 Hetzner Cloud 的特定集群，结果不能直接外推。作者也鼓励用户反馈不适用场景。在考虑替代分片前，应先在自身数据集和查询模式上复现测试，并评估代理层的可靠性、监控及长期维护成本。
Q&A
MongoDB副本集内存不足时，除了分片还有什么替代方案？
可以采用存储分层方案Thermocline：保留现有副本集作为归档层，在其前面部署一个小型快速副本集存放近期数据，应用通过代理连接，由数据年龄决定文档存储在哪个层。这样无需分片，也无需修改应用。
Thermocline是如何在不修改应用的情况下工作的？
应用连接到代理而不是原来的集群，代理根据数据年龄将请求路由到快速层或归档层。快速层初始为空，通过预热器和流量请求自动填充文档，保持两层数据一致。
Thermocline在测试中的性能提升具体有多少？
在相同硬件上，吞吐量提升1.6至5.2倍，具体取决于流量模式：集中近期数据的混合负载从4,447 ops/s提升到23,340 ops/s；读延迟p95从86毫秒降至6毫秒，p99从92毫秒降至8毫秒。
Thermocline适合什么样的工作负载？
适合大部分读请求针对近期数据的场景。流量越集中在近期数据，收益越大；如果读请求分散在所有数据上，收益会降低。文章建议先测量自己的负载再决定。
Thermocline目前可以用于生产环境吗？
不可以。Thermocline目前是概念验证（POC），尚未在生产环境运行。代码在GitHub上以Apache 2.0许可证开源，README提供了运行说明。
采用Thermocline有哪些限制或风险？
收益取决于流量模式，只有快速层能处理的读请求才会带来提升，其他请求仍会落到现有集群。此外，该方案尚未在生产环境验证，需要自行测试评估。
