近日参加金融行业数据库使用交流，大家讨论热点问题之一就是分布式数据库的选型问题。近些年来，随着数据规模增加、数据使用复杂度提高，对底层数据库能力要求越来越高，传统集中式数据库已不能满足需要；分布式数据库成为必然的选择。金融行业，作为数据应用的高地，对数据库的要求自然更高。然而面对纷繁复杂的数据库种类，该如何选择呢？本文尝试从分布式数据库的发展路线、技术分类、行业痛点等角度，谈谈分布式数据库的选型问题。

人生基本上就是两件事，选题和解题。最好的人生是在每个关键点上，既选对题，又解好题。人生最大的痛苦在于解对了题，但选错了题，而且还不知道自己选错了题。正如人生最大的遗憾就是，不是你不行，而是你本可以。

单机型数据库，最早源自上世纪70年代，从IBM著名的论文开始，后面诞生了Oracle、DB2为代表的优秀商业产品以及PostgreSQL、MySQL为代表的开源产品。这些产品很好的满足了对数据存储和计算的需求。

随着21世纪初期，互联网浪潮的来临，数据规模呈爆炸式增长，单机数据库越来越难以满足用户需求。这也催生了分布式数据库的到来。到了2006年之后，出现以HBase/Cassadra/MongoDB为代表的NoSQL类产品。这些产品实现了分布式架构，可以实现容量的水平扩展，但也牺牲了诸如事务、SQL访问接口等能力。

存储模型的简化为存储系统的开发带来了便利，但是降低了对业务的支撑。在这一阶段，很多企业为了解决大规模数据存储与访问的问题，也研发了很多中间件产品。其原理是通过将数据分片存储到单机库，上层对SQL解析实现对语句的路由。这种方式有一定的难点，例如对分布式事务的处理及规模扩大下的管理问题。

到了2012年，Google的论文为关系模型的分布式架构，提供了新型分布式数据库理论基础。在此之后，诞生了一系列新型分布式数据库产品。其原理是通过分布式一致性算法协议完成底层数据多副本存储，上层则实现了标准SQL支持能力。

人生基本上就是两件事，选题和解题。最好的人生是在每个关键点上，既选对题，又解好题。人生最大的痛苦在于解对了题，但选错了题，而且还不知道自己选错了题。正如人生最大的遗憾就是，不是你不行，而是你本可以。

如之前所说，金融行业正面对底层基础设施的转型问题，数据库作为重要的底层技术栈同样面临一个选择的问题。但在这一选择过程中，往往存在较多的痛点和难点。这主要是因为金融行业的特殊性所造成的。

对标传统集中式数据库，现有的分布式数据库在功能上仍然有待完善。这一方面是因为分布式架构所造成的功能tradeoff，另一方面是在产品化能力完整性上的欠缺。前者是我们在使用分布式数据库产品时，需要在架构、设计层面需要在关注的，在项目初期都需要解决掉的。而后者厂商产品经过多年发展在内核能力上已趋于完善，但在周边配套的管理、设计、优化工具上，仍需进一步完善。毕竟最终为用户呈现的，是一套完整的数据库解决方案。

对于金融行业而言，稳定性是第一位的。虽然分布式数据库在设计之处，就将稳定性设计放在优先位置，其天然的分布式架构也有利于提供更高的可用性保证。但一方面分布式架构天然由多组件组成，其复杂程度较集中式更高；另一方面其对底层基础环境的要求也更高。此外，产品的稳定性是要在长期实践中不断打磨、持续改进的。分布式数据库作为后来者，也需要经历这一过程。

选择使用分布式数据库产品，对应用侧来说，需要有大量的应用迁移工作。一方面是由于分布式数据库较集中式数据库功能上有所削弱，另一方面更换数据库天然所需要的移植工作。虽然目前各分布式数据库也推出xx兼容能力，但从实际效果来看仅能减少部分移植工作，整体迁移任务量仍然很高。且迁移采用所谓的兼容模式，也不利于后期平滑更换，这点后面会讲到。

对底层数据库的更换，是存在较大技术风险的。一是由于新产品、新架构所带来的风险；二是应用迁移改造带来的不确定性；三是产品本身的稳定性的潜在风险。为应对这种情况，最为稳妥的方式是采取应用双发并行的方式解决。这种方式可在最大程度上减少可能初期的风险，可做到数据冗余、无缝切换、灵活可控等，但其花费的代价也是非常高的。需要从应用端做大量双发改造，如果更换系统很多，这方面代价是比较大的。

虽然发展多年，但国产分布式数据库在整体市场上仍然属于小众选择。之前国外厂商产品占据市场领导地位，经过多年发展已形成了较为完善的生态。随着近些年来，MySQL、PG开源数据库在互联网行业得到大量应用，积累大量用户，建立其不错的生态。很多国产分布式数据库采用迂回策略，通过兼容上述数据库标准，来享受开源生态红利。此外，近期国产数据库如TiDB、OB、PorlaDB、openGuass等，也纷纷开源建设自有生态。

作为国家安全的重要举措之一，安全可控成为基础要求，信创因而诞生。为保证上述政策执行到位，国家也设定实施计划。作为基础软件的数据库，也是信创工作的重点。如何在规定的时间内完成，也为各企业带来的很大压力。

与互联网企业不同，金融行业对数据的使用场景更加多元化，这也对数据库提出了较高的要求。仅选择单一数据库满足全场景需求，几乎是不可能的。在传统集中式数据库上，这一问题还不明显，因为这些数据库往往是多面手，各方面功能较为均衡；而分布式数据库则不然，其往往有明确的适用场景范围。而作为企业用户，是需要对自己场景有个清晰的认识，然后按图索骥找到适合自己的产品，例如下图。

选择某厂商产品，也就意味着选择某一技术路线，如果深度依赖厂商产品的特有能力，无疑存在绑定风险问题。这点对于分布式数据库来说，表现尤甚。各厂商产品实现差异很大，没有通用的使用标准。如何规避这一风险，带来最大的自由度选择？后文会展开说明。

人生基本上就是两件事，选题和解题。最好的人生是在每个关键点上，既选对题，又解好题。人生最大的痛苦在于解对了题，但选错了题，而且还不知道自己选错了题。正如人生最大的遗憾就是，不是你不行，而是你本可以。

针对上述诸多难点、痛点，作为金融行业如何选择分布式数据库呢？这谈几点个人的见解。

技术选型是个很严谨的过程，需要慎重对待。有很多第三方的评测和厂商宣传结论，但这些只能做参考，决策层面的依据还是需依靠自己。一方面宣传内容一般都会所选择有利于自己，这会带来一定误导性；另一方面对同一概念的理解是有偏差的，很难仅仅通过一段文字描述就能完全说清楚（例如，数据一致性，背后的解读就有很多）。这些问题只有在真实环境，叠加上自身需求，测试出的结果才具说服力。

业务场景千差万别，其对数据库能力要求和侧重点也有所不同。很难选择一款通用型产品满足全场景，那就需要根据实际情况做有针对性的选择。此外，不同产品各有强点和局限之处，选择最适合你的产品就好。例如上文谈到的分布式中间件产品，在超大规模、自定义分片、超高性能、业务控制等方面往往更有优势；而分布式数据库产品，则在分布式事务、数据强一致、混合负载等方面有所擅长。

当前分布式数据库，仍然处于快速发展期，很难确定未来的主流选择。为了规避路线选择、厂商绑定的风险，比较现实的方法是选择一款兼容通用性协议的产品，并且在使用中仅使用标准数据库的用法。举个例子，选择一款兼容MySQL的产品并且安装标准MySQL的用法使用；当出现风险时完全可选择另外一款同样兼容MySQL的产品来替代。目前MySQL生态在国内最为成熟，很多厂商产品也选择了兼容它，因此选择兼容性产品在未来的自由度最大。

面对技术发展多变、应用特点多变、外部需求紧迫的现状，时刻关注分布式数据库发展，保持足够的技术敏感度，紧跟技术发展趋势。采取架构前置、谨慎选型、局部试点、多线布局、掌握主动、自建增强等策略，保持主动。