​作者

PostgreSQL中文社区顾问 李元佳

近年来，随着分布式数据库逐渐成为业界主流的技术方向之一，使用分布式架构仿佛即代表了技术先进性，而这种观点也十分契合大数据时代的海量数据需求。但是，在“账务类”业务场景下，是否也必须使用分布式架构呢？对此，业界充斥着截然不同的两种声音。

一种观点认为，大数据时代的“账务类”系统与其他系统一样，需要处理的数据量有可能被无限制地放大，因此需要使用通用的分布式数据库来满足未来“可能”存在的海量数据强交易场景，且即便是分布式架构的数据库性能与集中式数据库相比存在短板，也可以借助分布式的弹性扩展特性来实现整体性能的持续提升。

另一种观点认为，在商业化环境中单纯探讨理论并无实际意义，现实中“账务类”场景几乎不存在针对海量数据的强交易需求。同时，由于硬件条件限制，分布式架构是否能够真正突破网络性能瓶颈也依旧存疑。目前，对行业中的大部分“账务类”场景而言，Oracle等传统集中式数据库的处理能力绰绰有余，由此推断，分布式数据库技术在“账务类”场景中尚不确定存在刚需。

分布式数据库处理“账务类”场景

在技术上是否合适？

早在上世纪九十年代，IBM DB2 DPF即基于二段提交（2PC）机制实现了跨节点事务的一致性，将分布式数据库的交易能力进行了商业化实现；2003年，Greenplum也提供了可以保证分布式事务数据一致性的能力（包括增、删、改、查等）。但是，上述两种数据库都没有进一步在强交易的“账务类”场景上发力，迄今为止，其主要业务场景依然是围绕数据仓库展开，并没有过多涉足“账务类”交易场景。

从技术角度来看，分布式交易数据库的处理性能与集中式数据库Oracle相比仍存在较大差距，而这一差距主要体现在数据量方面。例如，当面对数十亿的数据量级时，集中式数据库通过服务器内存与数据压缩机制，完全能够将这些数据存储于一台服务器的内存当中。这种情况下，分布式交易需要执行的代码指令数量以及网络开销，与在单台服务器内部通过内存总线进行数据交换的开销完全无法相比。

以事务号分配为例，集中式架构往往只需简单使用一个原子变量即可生成进程唯一的事务号；而分布式架构则需要通过网络基于集中式GTM生成事务号，或通过Google Spanner等类似机制，使用原子钟生成一个时间范围作为事务顺序号，之后还必须等待一个毫秒级的误差延时才能完成事务提交。除此以外，无论是2PC提交还是优化后的Percolator机制，都会对事务造成更大的延时，在“账务类”场景下，通常需要点状记录修改的瞬时交易处理性能，而分布式技术虽然带来了并行执行效率的有效提升，但由于会同时引入处理开销延迟，因此并无用武之地。

综上，从技术以及算法的角度来看，在数据量完全能够使用一台服务器存放的场景中，集中式交易性能往往高于分布式交易性能，而且对于DB2、Oracle等成熟的传统交易型数据库而言，这个数字可以达到亿级记录的数据量。相反，对于Google等互联网巨头企业，海量数据使其对分布式交易能力有着较高需求，而Spanner也确实在Google内部发挥了重要作用。但是，如果分析Google Trends的数据可以发现，Spanner在海外的实际应用并不活跃。数据库应用热度随时间变化趋势如图1所示。

图1 数据库应用热度随时间变化趋势

针对这一现象，笔者认为有必要讨论一下“账务类”场景中的分布式数据库产品的市场契合度问题，比如有哪些行业及客户的“账务类”低延迟强交易场景存在海量数据，且必须通过分布式数据库来解决？一般而言，大部分会产生海量数据的业务系统（如互联网、物联网等）几乎都不需要在多数据之间进行大量信息的强事务交换，而对数据一致性要求大多体现在纯交易场景。对此，企业通过微服务及各类架构可将数据量控制在十亿行以下，集中式数据库在容量上足以支撑，并且在实时处理性能方面也远高于分布式架构，而这或许也是导致Spanner、CockroachDB等数据库在海外实际应用中并不活跃的原因。

分布式数据库与“账务类”场景的

市场契合度如何？

分布式数据库在“账务类”场景中是否具有商用价值，这并非一个纯技术问题，而是一个关系产品市场契合度（Product Market Fit）的综合性问题。在开发人员眼中，交易系统可谓包罗万象，例如银行的分户账核心、支付平台、渠道系统等都可以归纳为交易系统。然而，实际上真正涉及转账的“账务类”业务系统往往十分聚焦，在金融体系中除了分户账这类真正存储着每个账户金额的数据表，在交易的一刹那需要强交易能力以外，大部分产生海量数据的业务系统都可以归纳为“非账务类”系统，如报文、业务流水、历史记录等（如图2所示）。

图2 “账务类”系统与“非账务类”系统示意

在笔者看来，单纯认为分布式及大数据技术可以解决一切问题是一个误区。宏观条件下，企业在数字化转型过程中会以“非账务类”为主要场景产生海量数据，对此，单台数据库很难独立处理，而分布式数据库正是满足这类需求的绝佳选择。同时，考虑服务终端的业务众多，因此也需要更强的弹性并发能力，且同样需要保障ACID，但却在交易延迟上可以有一定的放宽。

在此基础上，当细分到如同分户账核心这类“账务类”场景时，其需求往往是极限的交易延迟，这一点却并非分布式数据库的优势所在。尤其是在微服务应用架构大行其道的今天，大部分类交易场景都会被拆分到多个微服务中，通过各种幂等性原则及补偿策略完成应用整体的端到端交易能力，从而降低对底层数据库强交易能力的依赖。“账务类”与“非账务类”性能对比见表1。

表1 “账务类”与“非账务类”性能对比

表1中，在“非账务类”场景中通常会产生海量数据，而分布式数据库十分契合“非账务类”场景的业务需求。同时，“非账务类”场景虽然同样需要联机处理事务一致性的能力，但相对于“账务类”场景对强交易能力的需求，却可以容忍更长的网络延迟。与之相比，“账务类”场景则对强交易存在刚需，其核心需求是总线级别的交易延迟，以及通过微服务架构细分控制单体数据量，进而更为切实地满足业务对各个子系统性能的需求。

此外，在信息技术应用创新的大背景下，考量长期成本及供应链等因素，银行对传统商业化集中式数据库有着较强的迁移诉求。目前，虽然有95%的“账务类”系统可以通过集中式MySQL或PostgreSQL架构承载，但对于剩余5%且数据量较大的系统而言，笔者认为可采用类似MyCat分库分表中间件的方案来承载“账务类”系统，并期待未来我国自研的企业级产品能够在分库分表中间件方案以外提供更多的选项。

总之，从市场契合度的角度来看，无论是在数据量还是应用开发架构趋势方面，集中式数据库均更为契合“账务类”场景，对分布式数据库并不存在强烈的市场刚需；而分布式数据库明显更契合于海量数据需求下的“非账务类”场景。

架构的选型应该遵循业务的实际需求

结合业界实际，任何技术选型都离不开业务需求，产品市场契合度（Product Market Fit）是所有新型产品能否在正确场景中获得广泛应用的核心基础。对于“账务类”场景而言，在数据量可控的情况下，集中式数据库可以带来更低的延迟，从而获得更高的业务处理性能。而在部分超大型企业系统中，即使是“账务类”系统也可能超出集中式数据库的处理能力，因此引入基于分库分表的数据库方案，并结合业务处理进行适应性改造，将可以更为合理地解决现实的业务需求。此外，鉴于“非账务类”场景主要面向海量数据以及弹性的高并发联机业务，基于分布式数据库的横向扩展能力，将可以获得更为有效的数据底座支撑能力。此外，无论是哪一类系统，对于数据库的ACID一致性能力都有着同样明确的要求。

因此，企业IT架构决策团队在进行技术产品选型时，需充分论证该目标业务的真实诉求，并以企业的长期发展需求为导向，为不同的业务选型不同的基础技术架构。

PostgreSQL中文社区欢迎广大技术人员投稿

投稿邮箱：press@postgres.cn