核心系统主机环境如何向分布式数据库转型？

来自社区交流，供同行参考

核心系统主机环境如何向分布式数据库转型？

18万MIPS和2 PB磁盘容量的生产环境运行在北京的双活IBMGDPS集群中，上海则作为灾备中心，交易峰值达到每秒近16,000的速度，生产环境每天处理高达19亿次交易，平均交易响应时间为30毫 秒。所有核心业务都运行在IBM Z 上，并且已经运行了20多年, 稳定性非常好。目前，只实现了查询交易向开放平台的下移，每年节约资金几个亿。请问，如何选择分布数据库和相关技术架构，逐步实现核心系统的整体替换？需要哪些软硬件资源？预计费用多少？预计实施周期多久？

问题来自社区会员 @catalinaspring 金融行业项目经理

@孔再华 中国民生银行  数据库运维工程师：

这是个巨大的工程啊，现在估算资源和费用太难了。从数据量和交易量来说，这个量级应该都属于行业内比较高的。而且这些都是在主机上，要下移到开放式平台确实非常难。

如果仅仅是考察分布式数据库，这个数据量级和交易量其实都是分布式数据库的强项。分布式数据库测试中达到1w6的tps还是比较容易实现的。但是事务和事务不一样，分布式对于适合的事务几乎能达到线性扩展，而对于不适合的事务例如复杂点的查询，效果还不如一个简单的单机。

但是现在也是一个最好的考虑如何分片业务的时候，因为现在还是集中式的主机，只有现在考虑好如何划分业务，如何一步步下移各项功能，后面工作中才会少走弯路。所以现在设计是最好的时刻。

每个业务的实现方式不一样，因此还是需要好好测试才能做好未来的方案和预算。这是个一整个工程式的需求，还是找专业的实施方评估吧。

@wanglaye 某大型金融机构 项目经理：

如何选择分布数据库和相关技术架构，逐步实现核心系统的整体替换？

题主问的是整个核心系统替换为分布式架构，还是核心系统数据库替换为分布式数据库？这涉及到基础资源层、应用层两个层面的事情。我暂且理解为后一种吧。

核心系统作为账务类系统，与单纯的交易类系统不一样，我们现在也只是把核心系统的查询、报表功能迁移到了分布式数据库，还没有迁移账务系统。现在基于分布式数据库的应用更多的是互联网交易类系统，如网银、银联无卡支付等，在改造过程中，不仅要选择分布数据库，还需应用开发团队做迁移改造。在分布式数据库选型方面，考虑从以下几个方面入手：

（1）技术方面：制定一套poc测试方案，将贵行最关注的分布式数据库特性作为关键考核点。

（2）成本方面：不同厂商的数据库采购成本以及配套的维保服务差别很大，需要结合预算选择产品。

（3）迁移改造方面：在选型阶段拿常见应用进行改造试点，评估从原数据库迁移到分布式数据库的代码改造量。有的数据库很好，但是跟原有代码语法兼容性并不是特别高，这点也是避免买完数据库后迁移难情况。

需要哪些软硬件资源？预计费用多少？

软件：分布式数据库软件及配套的开发工具、运维工具，尤其是开发和运维工具，真的非常非常重要。大部分分布式数据库软件按照数量收费，有的按照服务收费，这些报价也都不一样，从一百多万到上千万都有。

硬件：分布式数据库的计算节点建议都使用x86物理机，管理节点可适当使用虚拟机。分布式数据库对硬件配置要求较高，cpu、内存、硬盘配置要求都比较大，预算需要结合贵行x86供应商报价来看。

预计实施周期多久？

从poc测试，到数据库选型，到采购，再到最终的实施与应用迁移，乐观估计1年左右。前期工期较长， 应用迁移工期不确定，与贵行的应用改造难度有关。

@Amygo 分布式事务数据库管理员：

1、 如何选择分布数据库和相关技术架构，逐步实现核心系统的整体替换？

（1）分布式数据库的技术架构

（1.1）技术架构决定基础设施选型、交易响应时间大小、交易吞吐量大小、运维管理成本高低、跨数据中心灾备/双活如何实现。以4G普及/5G大发展、数字化转型为社会变革的前提，则推测该大行未来至少到2万笔业务/秒，采用分布式事务数据库之后因每条SQL语句的网络来回都增加了，则响应时间日常在100毫秒以内、峰值控制在200毫秒以内为目标。

（1.2）选择数据分片的分布式技术架构还是文件存储的分布式技术架构。

（2）分布式数据库的产品选型

（2.1）产品必须是专注交易关系型数据库，支持SQL92/SQL99标准，拥有完善的上下游生态链，避免从一个封闭式大型机生态进入一个新的小众生态。

（2.2）产品必须做到同银行正在使用的集中式数据库一样的透明实时数据一致、悲观锁、死锁检测/死锁接触、JOIN、分页排序分组计算、透明全局序列、唯一索引/主键的唯一约束、事务隔离级别至少支持RC及以上等。

（2.3）产品厂商的服务能力：基础软件厂商的服务能力与服务品质，参照行业总结是三部分组成：产品化程度的高低、产品缺陷修复响应的快慢、售后服务支持的方案资料丰富详尽程度的高低， 数据库作为三大基础软件之一则也遵守这个原则，基础软件跟应用类软件厂商、技术驻场类服务厂商的服务能力与服务品质是有重大区别的， 应用类软件厂商、技术驻场类服务厂商 的服务能力和服务品质必须依靠驻场研发工程快速响应甲方需求、驻场服务工程师快速响应甲方要求决定因素，而基础软件则是产品化程度作为决定因素，其次是产品缺陷修复响应的速度。

（2.4）产品厂商的产品化率能力：数据库作为基础软件是业务系统中至关重要的地位，业务系统的数据库出现问题就像一辆汽车的发动机出现问题，必须产品自身提供相应的产品功能实现隐患故障分析、定位和自动转移等能力，尤其是性能问题的分析、定位和优化如何产品化。分布式事务数据库产品有一个容易忽视在使用后可能出现严重性能瓶颈的工作项：

A、数据分片是学互联网企业全部按主键或隐含字段，还是业务系统访问特征按不同的业务键。

B、按互联网企业全部按主键或隐含字段做数据分片：则业务系统每笔业务操作的响应时间会因多走网络和数据合并操作等缘故，导致每笔业务的响应时间进一步变大，同等业务量的情况下数据库集群的吞吐量也会被放大。因为互联网企业90%以上业务场景都是按主键或唯一索引来访问的，所以很好地规避此问题。

C、按业务系统访问特征按不同的业务键做数据分片：银行、保险、运营商等行业的业务系统复杂度是远远高于互联网行业的，则需要有非常资深的数据架构师，且必须综合掌握业务系统的每个业务模块业务量及增长趋势、数据流及数据增长趋势、ER模式、全部SQL语句和数据分片设计理论知识等信息，这种类型的数据架构师行业属于凤毛菱角，且需要花费的时间周期也长，还不能100%确认做到最佳。

2、预计实施周期：核心系统要做下移，最重要是两点：做此事之前的核心系统不同业务场景POC测试验证，这个时间周期应该3个月及以上，不超过6个月的周期，验证产品是否满足功能、性能、稳定和运维四个维度的要求，并且给出业务系统特殊业务场景的处理逻辑是否改进，例如：批处理；核心系统的数据如何迁移POC测试，给出最佳的数据迁移方案和数据同步回到老系统的方案。

欢迎点击文末阅读原文到社区讨论交流，发表您的观点

觉得本文有用，请转发或点击“在看”，让更多同行看到

 资料/文章推荐：

欢迎关注社区以下  “分布式数据库”技术主题 ，将会不断更新优质资料、文章。地址：http://www.talkwithtrend.com/Topic/37323

下载 twt 社区客户端 APP

长按识别二维码即可下载

或到应用商店搜索“twt”

长按二维码关注公众号

*本公众号所发布内容仅代表作者观点，不代表社区立场