金融行业分布式关系型数据库需求及选型分析问题解析

随着互联网的深度应用和数字经济时代的到来，数字化接触渠道更加丰富，客户需求正在向定制化、碎片化、场景化转变，具有小额、高频、海量特点的互联网业务爆发式增长。

面对上述挑战，企业需要积极采用新的技术，适时进行架构转型，构建领先的IT服务平台，在提升信息系统支撑能力、提高系统可用性和灵活性的同时合理控制IT成本，从而更好地支撑业务发展和快速创新，适应未来发展需要。目前集中式架构已越来越不适应业务以及转型的要求，需要对架构进行分布式改造，提升IT系统的承载能力。分布式数据库作为分布式架构的基石，其选型直接关系到分布式架构转型的成败。

社区邀请我撰写了文章《分布式关系型数据库需求及选型分析》，本文结合企业自身情况，对分布式数据库的选型提供了参考，可降低选型和复杂度及工作量。同时组织了线上答疑活动，对大家的疑问进行了解答，本篇文章将这些问题进行了梳理，供大家参考！

分布式数据库需求分析方面问题：

1.所在银行有存储影像数据，交易文本的需求，离线数据分析与历史数据查询等，哪种数据库更合适？

我行目前才用了华为了hadoop平台，使用elk mpp数据库，感觉不够理想，有没有别的推荐？

解答1：这种建议用非关系型数据库，因为这是数据是非结构化的，具体根据自己的业务需求确定，比如hadoop，mongodb等等

解答2：非结构化数据，如：影像，图片，文本等我建议使用 巨衫或者MongoDB！
巨衫，银行这块影像平台已经有应用上线！

2.在分布式数据库项目中，为进行系统规格设计，如何进行定量需求分析？需要收集哪些需求数据信息？

解答：这个问题其实很难回答，尤其是对于第一次引入分布式数据库的企业。我提供下我们思路，仅供参考：1 对资源进行分类分档，并初步明确业务需求到资源档位的映射关系（可以逐步迭代）2 明确后续数据库扩容路径，一旦我们的档位无法匹配应用需求，那么就升档，升档不行就水平扩容

3.保险行业中上分布式数据库的多吗？现在形势如何？

解答：目前保险行业上分布式数据库的并不多，大多为一些小型保险公司，大部分保险公司现在正在探索阶段，保险头部企业已经有在做分布式数据库转型，但是距离全部分布式化还有一段路要走

分布式数据库选型方面问题：
1.在分布式数据库技术选型前，应该考虑哪些方面？

解答：首先要考虑您的其实是否有必要选择分布式数据库，要不上分布式的必要性想清楚
其次要对现有的系统进行分布式改造的可行性进行评估，并摸一摸市场上主流的解决方案和适用场景
最后要考虑成本的问题

2.市面上OLTP型的分布式数据库产品有哪些，该如何进行选型？
据个人的了解，市面上现在大多数MPP数据库产品都是主打OLAP型场景，OLTP型的分布式数据库产品少之又少。想请问专家，主流的OLTP数据库产品有哪些，他们各自的特点又是怎样的？

解答1：OLAP确实有很多，OLTP的目前主要的互联网巨头（比如阿里、腾讯、华为）都有相关的产品，特点上打通小异，都有一些自己主打的卖点，建议去官网具体了解

解答2：我知道一块分布式OLTP数据库蛮好，SequioDB广州巨杉数据库，开发的人以前在IBM实验室做Db2到L3支持的LEADER

3.选择分布式数据库应该关注哪些数据库特性？

解答：您可以参考文章中的技术能力匹配度分析，这个分析建议根据您的实际需求来确定

4.关于分布式数据库的选型问题？
目前金融行业很多业务系统都开始偏向互联网模式进行开发设计。但不同于互联网场景，支付类业务对于数据的并发性、一致性要求很高。而原生的开源数据库+中间件在分库分表的模式下有诸多限制很难做到高一致性。目前的分布式数据库很多，TiDB、 CockroachDB 、巨杉、各种云厂商的云原生产品等种类繁多，各有优势。 请问这些产品的稳定性和成熟度如何，是否有实际的测试对比。

解答：您提到这些数据库产品有开源，也有商业的，但我们均未测试过，我们考虑的还是产品背后强大的研发力量以及成熟的运营体系。还是在文中提到的观点，要看自己的需求，分布式数据库并不是唯一的选项，如果传统数据库可以解决问题，就选择传统的集中式数据库。我们在分布式数据库选型时，第一考虑的就是不采用开源的，只从商业的产本中选，且在大型金融企业中进行过商用。

5.去IOE背景下金融行业互联网业务数据库选型与考虑点？
背景：中美关系恶化，美企回归，去IOE，注重数据安全，符合金融监管等行业大背景
场景：金融行业互联网业务，基础软件数据库在监管层面或业务可靠性服务连续性方面的重点考虑方向
选择：第三方厂商如阿里OB，腾讯TDSQL, 国产数据库达梦等，NewSQL如TiDB等, 开源社区MariaDB，PgSQL等；
问题：在银行行业监管的要求有没有制度文件，有链接吗？大家在选型时最看重哪些特点？如何选型，分布式是你们重点考虑的吗，还有灾备，高可用，读写分离，KV缓存等等，谢谢。

解答1：老老实实选择 oracle rac 和 db2
部分边缘业务选择 mysql,或者 pgsql
分析性业务或者资源展现业务可以选择mongodb

分布式数据库, 目前在金融里面很少见到基本都在测试

解答2：（1）、主要系统数据库还是db2或者oracle吧，如果ibm产品买的比较多，db2可以买断的话也不需要花多余的钱去买oracle；
（2）、mysql等已经在逐步使用起来，在一些网络金融生产上面开始使用；
（3）、银行还是要考虑国产化率，虽没有纸面上要求，但国产化率还是要进行统计，特别是小型机使用比较多的话还是需要X86设备来提高设备国产化率；
（4）、去IOE是一个过程，不可能一蹴而就，对于银行来说还是要保证稳定可靠，新鲜事物可以尝试但不可能步伐过大。

解答3：据我了解，之前提过去IOE的说法，但是没有相关的制度文件，这个是一个循序渐进的过程。选型时主要考虑的点有技术能力匹配度、实施难度，成本，案例等。我们选择分布式的初衷是提升系统承载能力，并进行架构转型

分布式事务及数据一致性方面问题：
1.各主流OLTP数据库中，分布式事务是如何实现的？分布式事务较单机事务性能大致损耗百分之多少？
问题一、问一下有哪些主流的OLTP分布式数据库？如TiDB、巨杉等
问题二、这些数据库的分布式事务是如何实现的？如二阶段提交等
问题三、由于CAP不可兼得，以问题1的数据库来说，分布式事务较单机事务的性能有多少损耗，或者降低百分之多少的速度？

解答：问题一、我们选择范围是大型互联网公司的商业产品，不含您说的两种数据库
问题二、分布式事务大都采用两阶段提交的方式，可参见
https://www.w3cschool.cn/architectroad/architectroad-two-phase-commit.html
问题三、具体的损耗跟业务复杂度有关，这个建议以实测值为准

2.分布式数据库如何保证备份的一致性？
由于数据量较大，分布式数据库一般将数据分布在多个节点中。
主流的分布式数据库中，有哪些方案可以保证各节点的备份是一致的。

解答：成熟的分布式数据库产品是自带备份软件的，我们可以使用它们提供的产品，在POC测试过程中进行重点验证，所以建议您选择分布式数据库要选择有案例的成熟商业版本。另外再讲一下分布式数据库的备份花原理吧，分布式数据库主节点都有副本，有统一的工具下发固定的时间戳，然后锁住备节点的同步，从备节点把数据备走

3.如何处理多个分布式节点的分布式事务，在不影响效率的情况下保证数据一致性？
如何处理多个分布式节点的分布式事务，分布式事务的协调影响效率，而且容易造成数据一致性问题

解答1：根据CAP原则，鱼与熊掌不可兼得。分布式事务一般是牺牲效率来满足数据一致性的要求。
非要追求的话，可以参考google Spanner通过使用GPS和原子钟来处理分布式事务的方案

解答2：（1）、我们引入分布式数据库的初衷是扩展承载能力，分布式数据库本身由于跨节点，就存在效率问题，而且业务场景也较为复杂，属于尽量避免的。
（2）、分布式事务的数据一致性通过全局的事务管理器来保证

4.分布式关系型数据库如何保证数据的强一致性？
目前主流的开源或商用分布式关系数据库都能保证数据的强一致性不？是否存在丢数据风险？

解答：副本可以设置成为强同步或者弱同步，强同步必须等备节点确认接收到数据更改后主节点才能执行后续操作，确保数据完全一致。所以一旦主节点发生故障后，可以通过管理工具自动切换至强同步的副本，也不会存在数据丢失的风险。

5.分布式数据库主备故障切换时，应用事务控制和数据库事务控制一致性问题？
分布式数据库往往有类似网关的组件，负责事务的协调，应用通过网关与数据库交互，当发生故障后台数据库需要主备切换，此时如何检查应用和数据库事务控制是否一致？如何避免切换后应用在新老数据库都执行一遍之类的问题？

解答：分布式数据库会有全局的统一的事务管理器，负责保证全局的事务管理，来避免您提到的问题

其他方面问题：

1.金融行业上分布式数据库的整体成本是怎样的？
能否具体罗列下每个具体模块的大体成本

解答：成本包括软件许可费用、原厂技术服务、软件维保服务及关联的硬件资源投入成本。整体成本跟您的规模有关，其中最大的投入是硬件投入

2.分布式数据库项目相较于传统的数据库项目，主要难点有哪些？

解答：分布式数据库的难点主要在于以下两点：
（1）、对现有的开发人员和运维人员带来新的调整，需要试错成本
（2）、分布式数据库的整体部署规划，多活多中心的解决方案，业务改造复杂

3.分布式关系数据库的落地实践？
分布式关系数据库，从落地来看，大多数产品都是集中在I/O层的重构。SQL以上基本都是继承传统数据库的能力。或做了一些优化。I/O层有通过key/value的方式存储列值，再对key/value进行副本管理如TiDB。也有通过讲数据写到日志里，再在内存里通过日志记录构建表的方式, 如 AWS aurora。应用不同，产品的设计不同。这么理解OK不？

解答：您说的很对，应用不同，产品不同，适合自己的是最重要的，所以首先要想清楚自己的业务需求和能力匹配要求是什么，然后再在符合的产品中选型，POC测试，把自己关注的技术点在测试中落地，保障后续实际落地

4.目前主流的分布式数据库主要适用于哪些应用场景？

解答：分布式数据库主要解决的场景是并发量高，传统数据库处理性能难以满足，比如互联网高并发业务。另外如果对数据库的高可用性要求非常高，分布式数据库也是一个好选项，比如同城双活，异地多活，分布式数据库实现起来都比传统的集中式数据库简单

5.分布式关系型数据库是否等同于区块链？还是区块链中的一项关键技术？
区块链技术现在被广泛关注，并认为在金融行业有巨大的应用价值。那么分布式关系型数据库是否就是区块链中的一项关键技术？怎么来看待分布式关系型数据库与区块链之间的关系？

解答1：区块链是分布式账本，是泛化数据库的概念，或者说是广义意义上的数据库，主要记录某个实体在不同用户间流转的过程，实体比如电子货币，也可以是游戏币，服务通证。
狭义的数据库，是基础软件，是通用的用于支持增删改查操作，以及事务操作的存储软件。分布式的含义是单机无法支撑业务场景，比如单机TPS有上限等，或者业务数据量单机承受不了等。实际上大多数情况下，分布式数据库的业务场景并不是普遍的，如果做好垂直化和库表设计的话。
分布式数据库是多个master间share nothing, 备机和对应的master share all，而区块链是share all 并且存储所有全量的交易日志摘要数据到每个参与节点。
都叫数据库，但其实不是一回事。

解答2：我觉得分布式数据库并不等同与区块链，区块链是分布式账本，他主要如何保持数据一致性，如何让这个公共账本的数据不被篡改来展开的。这个公共账本的参与者比较多，网络环境比较复杂，多为互联网。分布式数据库多采用专用的设备，通过专线连接，设备数量有限，通过主来发起请求，其他节点没有否决的权利，只有接受主的请求，而区块链需要大家都同意，所以参与数据改变的所有节点的角色的不同是区块链和分布式数据库的最大区别，个人浅见，仅供参考