（来源：twt企业IT社区）

 导 读 

分布式数据库正在成为银行交易系统信创替换的主流选择。然而，初期广泛应用的“信创分布式数据库+服务器本地盘多副本”架构正面临着挑战，随着信创数据库在核心应用的规模化部署，数据安全风险、机房空间限制及运维复杂度日益凸显，在以下内容中，社区同行探讨了该架构下的一大难点——容量问题：生产中数据量大的系统经常会有容量告警，也没办法扩容，要经常清理数据，面对这种情况，有什么解决方案？

 探讨总结 

◉Ethan_Yang 某金融司 技术架构师：

该问题的根源在于架构层面“存算绑定”与冗余机制之间的固有矛盾。通俗来说，就是企业集采了一批同配置的服务器（包含足够大的本地存储），通常是签订了服务器框架协议。好处是上架快、部署简单，但随着数据迁移和系统数据增加，而本地存储却难以弹性扩容；另一个原因也和分布式数据库为保障数据一致性采用多副本有关，多副本策略使实际可用容量仅为物理空间的 1/2 或 1/3，而信创硬件在扩展性上存在限制，无法实现类似云平台的灵活扩盘。运维团队这个时候就很被动，不得不反复协调业务方清理数据，严重影响业务连续性与系统稳定性。

几位金融行业同行的实践经验和建议比较一致，主要从架构与管理两方面着手。在架构上，推动存算分离，探索纠删码等空间优化技术，提升存储利用率；在管理上，建立数据生命周期机制，实施冷热数据分层，将非活跃数据迁移至低成本存储。此外，加强容量规划与监控，结合压缩技术与空间回收策略，也被视为缓解容量压力的有效手段。

给同行的参考建议：架构向存算分离演进，从根本上突破容量瓶颈，另一方面带来的好处是存算分离架构的企业级共享存储（无论是集中还是分布式），可靠性会有企业存储级背书。此外，在架构设计阶段，考虑数据分级与归档策略，留有一定冗余容量。

分享与交流

◉busuzhike 某银行 工程师：

这种架构的核心卡点是存储与计算刚性绑定，多副本使有效容量仅剩1/n。导致无法快速弹性扩容，被动陷入“容量告警-催促清数据”的恶性循环，严重制约业务发展。根本解决之道在于推动存算分离架构；当前亟需实施数据生命周期管理 ，通过冷热数据分层归档，将非活跃数据迁移至廉价存储，为高性能主库释放空间。

◉chjayhsx 西南某城商行 数据库架构师：

分布式数据库存算分离架构下，特别是数据节点，受服务器的磁盘容量限制，无法弹性伸缩，本身服务器的磁盘插槽是固定的，无法像云平台那样无限添加云盘。当磁盘插槽用尽后，“无法扩容”就成了硬性约束。同时，哪怕是数据重分布将数据临时再打散分布到新节点，对业务影响的侵入也是非常大的，执行的效果不是很理想。

面对这种情况，长期规划上，可以通过容量检测与增长趋势，规划数据清理周期。必要时做好容量扩容准备，例如进行节点切换，满足扩容需求。同时作为技术延伸，提供一个共享存储的备用节点用于应急处理。我们目前采用的最多的就是容量管理制度，通过分离数据类型，及时将冷数据迁移至大数据，保障数据库在进行数据处理时，所使用的热数据处理效率。

◉koolkite 金融行业 数据库架构师：

根源应该是两个：

1.业务对数据量上涨预期，估算不准导致。

2.业务系统中是否存在较多的过程数据，导致大量空间被占用，可以让业务或研发降低此类数据的存储空间。

◉peterzhu 某农信 系统工程师：

作为银行用户，容量问题核心难点在于，信创架构下“数据高可靠（多副本）”与“存储容量利用率”及“硬件性能瓶颈”之间的多重矛盾。具体而言，采用服务器本地盘构建多副本（如两副本、三副本），会直接导致有效存储容量仅为总物理空间的1/2，1/3，成本高昂。同时，信创硬件在初期其单机性能和容量可能与传统商用硬件存在差距，这会使得存储资源快速见顶，引发频繁的、复杂的扩容操作，严重威胁业务连续性与稳定性。

我们目前的解决思路为“软硬结合、精细运维”。

1.在规划层面：

（1）探索采用纠删码等更高效的数据冗余技术，在相近可靠性下将空间利用率提升至70%以上；

（2) 实施数据生命周期管理，将冷热数据分离，冷数据可归档至更经济的对象存储。

2.在运维层面：

（1) 建立精准的容量监控与预测体系，变被动扩容为主动规划；

（2) 优化数据库本身的空间回收机制（如GBASE空洞率回收），压榨每一寸存储空间。

最终目标是通过架构优化和管理细化，在保障信创环境安全可靠的前提下，实现成本与效率的最佳平衡。

◉huhu097 某城商银行 DBA：

提前规划，针对上线系统数量以及业务数据大小有个大概的评估，需要重点关注的是，分布式数据库对数据的压缩率很高，建议可以在测试环境测试充分，再做生产环境的容量规划。

◉508mars 某证券 数据库管理员：

这个问题其实涉及到管理问题，要么留点buffer机器或者磁盘应急用，要么把压力抛给业务，他们作为使用方，对于数据增量评估不到位。还有经常遇到业务方把啥数据都往OLTP数据库堆，导致空间大幅增长。这个时候得逼他们一起看看，把那些低价值、几乎不会在线查的数据迁到大数据或者其他容量大成本低的的地方去，给数据库瘦身。

◉某证券行业用户：

1.提前做好容量管理和规划，一则是垂直扩容即加磁盘。二则是水平扩容，加服务器节点。

2.应用层做好设计，定时实施数据归档

欢迎您也来探讨