hanfeng_twt
作者hanfeng_twt2021-12-31 14:13
数据库架构师, SphereEx

银行OLTP类业务分布式数据库应用场景及架构选型探讨总结

字数 11811阅读 10454评论 0赞 3

近年来,在互联网金融和数字化转型趋势下,因为分布式数据库具备低成本、灵活性、易扩展性等优势,越来越多的银行加快尝试分布式数据库在行内系统落地。而银行OLTP类业务系统是银行最重要的业务系统,直接参与客户交易,例如手机银行、网上银行、直销银行(互联网银行)、聚合支付、核心系统等,可靠性和性能要求高,需要具备应对高并发、海量数据访问需求。
目前分布式数据库产品处在“百花齐放、百家争鸣”的时期,产品功能和种类丰富,采用分布式数据库支撑OLTP类业务建设挑战很多,针对难点,12月28日twt社区组织银行行业同行交流活动,邀请到大型国有银行数据库技术专家以及英特尔资深技术专家和大家分享经验,共同探讨应对之道,本期交流总结如下,希望给大家带来帮助和参考。总结一共分为四个部分:1、分布式数据库的选型及适用场景;2、分布式数据库的架构设计;3、分布式数据库的安全性保证;4、分布式数据库的未来发展趋势解读;5、交流共识的总结。

一、 分布式数据库的选型及适用场景;

1、什么样的OLTP业务系统需要上分布式数据库,应考虑哪些因素?

什么样的OLTP业务系统需要上分布式数据库,除了政策、技术储备等因素的考量,还有哪些因素值得作为决策依据?

嘉宾:hanfeng_twt 数据库架构师 , 大型金融单位
是否上分布式数据库,取决于几个因素:
1.业务诉求(如原有架构无法满足存储需求、计算需求,并发需求等情况下)
2.可用性要求(如需要使用分布式数据库的有些特性,带来更好的可用性能力)
3.管理需求(如统一技术栈等要求)

嘉宾:任晓蕾 解决方案架构师 , 英特尔社区
分布式数据库对比传统数据库解决方案 ,通常具有水平扩展,高可用性和更高的性价比 。企业有时会基于成本考虑希望商业转开源,或者原有的垂直扩展的数据库已经无法满足性能需求等考量,转向分布式数据库技术。

嘉宾:wanglaye 信息技术经理 , 某大型金融机构
交易量规模是否很大。
交易是否有明显的周期性。周期性的交易系统很适合分布式数据库,利用弹性伸缩能力灵活调度资源。
预算。分布式数据库对硬件需求较低,节省硬件成本。
业务系统架构。分布式架构与分布式数据库搭配使用。

2、 在分布式数据库架构选型中,如何看待计算与存储分离?

在众多分布式数据库中,有的采用了计算与存储分离的架构,例如TiDB,有的并未做算存分离,例如OceanBase。如何看待这两种架构的不同优劣势,以及如何进行选择?

嘉宾:luxh08 科技部门副总 , 某互联网银行
计算和存储分离是数据库的发展趋势,分离式的优势是可以根据计算和存储资源分别进行扩容,但是也带来了额外的网络调用的性能损失。

嘉宾:邓刚 解决方案架构师 , 英特尔社区
计算和存储分离,更容易实现资源池化,部署与扩展也能更加灵活,是未来发展的趋势。计算和存储绑定的方式,从目前来看,能更加充分地利用资源,实现更高的性能。在选择上,需要遵从企业数据中心规划的要求,比如是否计划近期进行数据库上云等的要求。

嘉宾:任晓蕾 解决方案架构师 , 英特尔社区
存算分离 的架构,在带来云计算灵活和弹性的红利的同时,也带来存储和计算集群的大量数据交互, 对网络磁盘要求更高, 需要采用低延时RDMA网络,高IOPS的存储 来弥补性能上的损耗。

嘉宾:hanfeng_twt 数据库架构师 , 大型金融单位
存算分离,还是要看具体解决的问题。其最早是由云厂商提出的,目的是将资源解耦,从而实现不同资源的分层扩缩。看待这个特性,还是要看其背后带来的收益,是否是自身关注的;否则没有太大意义。

嘉宾:wanglaye 信息技术经理 , 某大型金融机构
个人认为OceanBase也是存算分离。OceanBase也分为OBProxy、SQL引擎、计算引擎、存储引擎等不同的角色,只不过是逻辑上的分离,而在物理上可以部署在同一台服务器上。
如果想要实现一定程度上的物理上的存算分离,那么可以把 OBProxy 、OBServer分别部署。
TiDB的优势在于集群中设置了非常明显的存算分离角色,即TiDB和TiKV,这种架构下,后续扩缩容可以分别进行,更加便捷,互不影响,最大化利用资源。

3、对于OLTP而言,中小城商行的数据量不如大行,是否有必要引入分布式数据库?什么情况下需要引入,如何选型?

对于中小城商行,单个交易系统的数据量远不如大行,集中式数据库已经能满足业务需求,在此情形下,是否还需要引入分布式数据库,什么情况下需要引入?如何进行分布式数据库选型,重点应关注哪些方面?

嘉宾:wanglaye 信息技术经理 , 某大型金融机构
分布式是大趋势,不仅体现在数据库上,也体现在应用上。
数据库有分布式数据库,应用也有分布式架构。容器、云、分布式,这些技术潮流还是要赶上的,也许目前不需要,但总要防患于未然。
并且,即使是中小城商行,业务规模将来总会增大的,现在提前把技术平台搭建好,以应对未来业务所需。
如果行里有线上交易系统,或者有系统已经开始拆分业务节点和数据库节点,那么可以换到分布式数据库。
在分布式数据库选型时,应该关注数据库的综合能力,不仅要测试对于数据库传统功能的支持度、分布式特性(如弹性伸缩、高可用、高性能),更要测试数据库运维管理能力和兼容性,后者是应用迁移最为关注的问题。此外,也要考虑成本,根据行里预算进行选型。

嘉宾:邓刚 解决方案架构师 , 英特尔社区
对于中小城商行,从性能和数据量上来说,单个交易系统使用传统数据库也可以满足要求。引入分布式数据库主要是从提高响应业务的敏捷性,弹性扩容、降低运营成本等几个方面来考虑。引入分布式数据库,由于性能一般都能满足要求,可以从数据库产品的稳定性、功能、协议支持的完备性、服务质量这些方面来选型。

嘉宾:hanfeng_twt 数据库架构师 , 大型金融单位
在做出合适选择之前,需要以下准备工作:

  1. 业务画像
    针对不同的业务,做出业务侧的数据库画像,包括但不限于如下维度
    业务指标:使用方式、使用特征(在线用户、峰值用户、并发用户等)、重要级别、可用性要求。此外,针对未来发展也要有所评估。
    系统指标:包括应用系统来源、技术栈、开发语言、系统拓扑、与数据库交互方式等
    数据库指标:包括数据规模、访问特征、物理环境、软件环境、数据库拓扑等
    运行特征:场景分类(TP、AP、混合)、架构分类、数据规模、数据特征、计算规模、事务一致性要求、扩展性要求、高可用要求、应用耦合性等
  2. 产品测试
    对数据库产品进行测试,形成对产品的统一认识。这其中包括数据库内核、管理、开发、安全等多方面能力的评估。这方面可参考我之前分享的《分布式数据库评测标准》。
  3. 其他因素
    除上述外,还应包括企业内部的一些自身因素的考虑,如成本、运维、开发改造等因素。
    上述因素综合考虑后,才能做出相对合理的选择。

4、分布式数据库如何选型?

问题1.分布式数据库如何选型,每家单位产品特点及商务选定一种特定数据库,然后有分布式数据库需求的应用再根据选定的数据库进行适配;还是每套应用根据自身适配的情况选择合适的数据库。

嘉宾:wanglaye 信息技术经理 , 某大型金融机构
在分布式数据库选型时,更应该关注数据库的综合能力,不仅要测试对于数据库传统功能的支持度、分布式特性(如弹性伸缩、高可用、高性能),更要测试数据库运维管理能力和兼容性,后者是应用迁移最为关注的问题。此外,也要考虑成本,根据行里预算进行选型。
至于采用哪种方式,得看贵司的运维管理模式是怎样的,如果是基础资源和应用分开管理,那最好选定一种数据库,应用来接入和适配;如果是应用系统负责制,那可以考虑每套应用自行选择数据库产品。
个人更倾向于,选择一种分布式数据库,搭建一套分布式数据库平台,应用进行迁移和适配。

嘉宾:邓刚 解决方案架构师 , 英特尔社区
两种方式各有利弊、都是可以的。需要根据实际情况进行选择。比如,如果业务系统是重新开始搭建的,可以更多考虑适配选定的数据库。但如果业务系统已经上线使用,更多的需要考虑数据库适配应用。

嘉宾:hanfeng_twt 数据库架构师 , 大型金融单位
通常不会根据每套应用来选择合适的数据库,这样做的话技术栈可能过于发散。建议的做法是,根据公司业务场景,收敛为若干种类型,然后为每个类型选择2~3款产品。选择多款产品的原因,是为了避免厂商绑定问题。然后需要根据每类场景,制定开发规范(取2~3款产品的功能交集作为标准)。

5、中小银行分布式数据库选型实施路径?

中小银行在行内传统架构大前提下,进行分布式数据库方向转型,面临诸多难题与不可控因素。
1.引进分布式数据库后如何确保全局一致性
2.架构选型阶段,如何在高可用方面进行把关

嘉宾:luxh08 科技部门副总 , 某互联网银行
可以分几部走,首先要指定数据库开发规范,将数据库轻量化,将一些功能上升到应用层面解决,再者要标准化,统一技术标准,减少对数据库的技术依赖,后面用什么数据库就是管理规范的事情了。

嘉宾:wanglaye 信息技术经理 , 某大型金融机构
个人认为,题主不用纠结于一致性和高可用这方面,因为现在比较知名的分布式数据库,如ob、TDSQL、TiDB等,对于题主这些问题已经解决的很好了。如果一定要考虑这些方面,那么可以在poc测试阶段增加相关的测试方案,比如一致性测试时对于ACID的验证,在高可用测试时设置单节点、单机柜故障等场景用于验证。
我认为,在分布式数据库选型时,更应该关注数据库的综合能力,不仅要测试对于数据库传统功能的支持度、分布式特性(如弹性伸缩、高可用、高性能),更要测试数据库运维管理能力和兼容性,后者是应用迁移最为关注的问题。此外,也要考虑成本,根据行里预算进行选型。

嘉宾:hanfeng_twt 数据库架构师 , 大型金融单位
1.分布式数据库大致两种技术路径,一种是以分布式共识协议来保证副本数据一致,一种是采用主从复制模式并保证数据或日志强同步后才提交。
2.在选型阶段,需要对高可用能力进行评测,包括进程级、主机级、硬件级、同城AZ、异地多种情况下的可用性验证测试。

嘉宾:任晓蕾 解决方案架构师 , 英特尔社区
分布式数据库的高可用性针对不同的解决方案有不同的解决方式,对于share nothing架构的分布式数据库通常是通过数据库主从复制来达到节点间的同步,也有通过中间件proxy或者节点管理协调框架来实现同步, 在选择方案时候要根据运维规模,研发能力和业务需求做权衡。 运维规模越大,节点间同步开销越大,对网络和磁盘I /O 的要求会越高。

嘉宾:邓刚 解决方案架构师 , 英特尔社区
关于“ 引进分布式数据库后如何确保全局一致性 ”的问题,多数分布式数据库由于采用基于数据分片的 share nothing 架构,全局一致性问题是一个很大的挑战。业内一般的解决办法,一个是利用特殊的硬件设备如原子钟来确保个节点的时间戳全局有序,另一个是通过集中服务来获得全局一致的版本号。无论哪种方式,都需要分布式数据库原生支持。在部署时,按照相应的产品文档配置来确保全局一致性。

6、如何结合不同的业务场景选择合适的数据库?

分布式数据库种类较多,有基于开源内核的,有纯自研内核的;有计算存储紧耦合,有计算存储分离;有的擅长OLTP,有的擅长OLAP,也有支持HTAP的等目前没有哪一款产品可以适合所有应用场景,所以选型如何结合不同的业务场景选择合适的数据库?
嘉宾:任晓蕾 解决方案架构师 , 英特尔社区
如果业务偏重交易, 需要支持高TPS,需要选择低延迟高 带宽 的网络(比如RDMA网络)和高IOPS的块存储。如果业务偏重分析,可以选择相对便宜的 高带宽的网络和高I/O吞吐量的对象存储 。如果需要实现交易/分析融合,在选择HTAP方案的同事要考虑交易和分析的资源隔离,避免相互干扰。 如果需要实现多租户, 弹性扩容和灵活调度 ,需要选择储算分离 的解决方案。 分布式数据库选型需要根据具体的业务场景来选择合适的解决方案,没有one-fits-all的万能方案。

嘉宾:邓刚 解决方案架构师 , 英特尔社区
目前确实没有哪一款产品可以满足所有的需求。在选型时,首先需要考虑的是业务需要支撑的并发交易量。如果需要支撑的并发交易量很大,比如大型银行的核心系统需要支撑每秒上万次的交易,那么选型首先要选出能够满足需求的,擅长 OLTP 的分布式数据库。业务的 OLAP 需求,可以通过单独再建的方式来进行。如果需要支撑的并发交易量不大,比如中小银行的网银系统,如果同时又有一定的 OLAP 需求,可以在确保 OLTP 能力满足的前提下,考虑支持 HTAP 的分布式数据库。

二、分布式数据库的架构设计

1、在同城双活的架构下,分布式的架构该如何进行设计?

分布式数据库可以理解为主要是以分布式数据库集群的方式进行部署;同城双中心的环境下来讲,可以认为数据中心为偶数个,那么此时该如何对数据库集群节点、数据副本进行分配,才能使单个中心出现异常,整个集群可正常运行?

嘉宾:wanglaye 信息技术经理 , 某大型金融机构
双中心的话,实现单中心故障下的高可用,有点困难,因为无论如何分配,一定有一个中心只有少数副本,无法满足分布式数据库的“大多数”原则。
如果单中心故障,集群不受影响的话,可以考虑主从集群模式,但这种模式对于资源的需求比较高,增加了一倍的资源需求了。

嘉宾:hanfeng_twt 数据库架构师 , 大型金融单位
这个不同数据库产品是存在实现差异的。某些产品,在同城双AZ的情况下,是可以通过多个副本设置,保证的第二个AZ数据落地,但不能实现自动切换(因需要多数选主)。一般有条件的情况下,建议实现同城3AZ,或者2AZ+冲裁的方式来设计。

2、分布式数据库使用规则?

分布式数据库和传统的share everying的数据库差别感觉还是非常的大,目前来说,一些锁、阻塞机制确实没有o做的全面和细致,此外,分布式数据库中类似于两阶段提交的特性,也可能会经常造成死锁、阻塞,在实时交易系统中灰造成比较严重的影响,那么目前是否有技术或者使用规范来避免这些问题呢?

嘉宾:邓刚 解决方案架构师 , 英特尔社区
分布式数据库由于多数采用 share nothing 的架构,跨节点事务的性能是一个很大的挑战。对于死锁检测问题,分布式数据库都有各自的方式,比如在 TiDB 中维护了全局的 wait-for-graph ,通过确保该图无环来避免死锁。在中间件类型的分布式数据库,一般是由计算节点来检测死锁。
另外 ,英特尔 ® 至强 ® 可扩展 处理器中的TSX (事务内存) 指令,也可以用于加速数据库的事务处理,减少锁的开销 。更多关于Intel TSX的信息 可以参考文档 : https://www.intel.com/content/dam/develop/external/us/en/documents/sf12-arcs004-100-393551.pdf

嘉宾:hanfeng_twt 数据库架构师 , 大型金融单位
分布式数据库较传统单机数据库或集中式数据库,是存在较多不同,因此在开发之处就有针对性的进行规避比较重要。这其中常见的点包括:事务大小、SQL复杂度、分布式事务、DDL变更等。基本的处理原则就是3B原则,即避免Big SQL、Big Transaction、Big Batch。此外,尽量减小分布式数据库中的变更,无论是架构上的(如扩缩容)、结构上的(如DDL)等。

3、业务系统应用架构设计时如何适配分布式数据库以实现高性能,在线扩展后性能如何同步提升?

嘉宾:任晓蕾 解决方案架构师 , 英特尔社区
针对分布式数据库的热点数据,可以采用内存计算网格或者基于高性能存储介质(比如英特尔的傲腾SSD或者 可持久内存 ) 的缓存技术来实现热数据的高速访问, 以实现更高的性能。
在线扩展要实现同步提升,达到近线性的扩展能力 ,需要开发设计中尽量利用本地计算, 减少节点间同步的开销。

嘉宾:邓刚 解决方案架构师 , 英特尔社区
由于分布式数据库多数采用 share nothing 架构,跨节点的分布式事务对性能的影响非常大。因此,在业务系统架构设计时,需要确保事务尽可能不减少跨节点的分布式事务。分布式数据库性能的线性扩展能力,一方面却决于选型的分布式数据库的实现。另一方面,也和业务系统设计时,热点数据是否可以被均匀地分布到了多个节点上有关。

嘉宾:hanfeng_twt 数据库架构师 , 大型金融单位
性能问题,是需要慎重考虑的。如果仅仅考察个体的表现,分布式数据库很有可能不如传统单机数据库或集中式数据库。其分布式架构在原理就先天存在一些短板,对于要求极致性能的场景是不合适的。
分布式数据库的强处,是在于扩展系统的整体吞吐能力,可承载更多的业务量。因此从原理上讲,扩展后不会提升性能。当然,分布式系统扩展后,数据库被做个更多的拆分,会有助于单体执行效率的提升,这种情况下是有性能提升的。
基于上面,在应用架构设计时,应充分利用分布式数据库的数据分布特点,做好业务单元化。通过在更小的数据单元完成,进而达到优化效果。

4、 OLTP类业务基于分布式数据库架构,如何从软件和硬件层面分别保障性能和可靠性?

嘉宾:任晓蕾 解决方案架构师 , 英特尔社区
针对当前流行的不同类型分布式数据库解决方案,英特尔都进行了相应的PoC验证并给出了硬件配置推荐, 以保证高性能和高可靠 。 具体技术细节可以参考我们的演讲内容,英特尔分布式数据库的最佳实践文档。

嘉宾:hanfeng_twt 数据库架构师 , 大型金融单位
分布数据库一般多从软件层面做了可用性保证,如采取多副本机制等,通常不采用传统基于硬件的可用性方案。

5、金融企业应用分布式数据库在跨机房数据同步需要考虑哪些因素?

金融企业应用分布式数据库在跨机房数据同步需要考虑哪些因素?希望有经验的专家可以多分享一些自己的经验,感谢!

嘉宾:luxh08 科技部门副总 , 某互联网银行
分布式数据库大部分要考虑下面部分的调用延时,二阶段协商、多副本同步、时钟调用,通过架构设计、业务纬度分离、或者数据库策略减少夸机房的上述调用

嘉宾:wanglaye 信息技术经理 , 某大型金融机构
跨机房数据延时。
分布式数据库大多采用多副本机制+一致性协议,当数据写时,需要大多数副本写成功才认为写成功,因此,要保证“大多数副本”写的延时不能太大,否则会影响写效率。所以,在设计多机房部署时,要考虑副本的所在位置以及写延时。如果是同城,那么写数据副本的耗时差别不大;如果是异地,就要考虑异地机房的延时,若延时很大,那么最好将大多数副本设置在本地,异地只放少数副本,这样在写时只需本地副本写成功即可,无需等待异地副本完成写操作。

三、分布式数据库的安全性如何保证

1、 分布式数据库容灾容错方案?

两地三中心分布式数据库如何保证数据一致性,切换方案的具体案例,是否可以使用工具进行标准化操作一键式切换。

嘉宾:wanglaye 信息技术经理 , 某大型金融机构
分布式数据库的“切换”概念与传统数据库不太一样。
分布式数据库的“切换”包含两层意思:
第一层是主从副本的切换,这部分工作可以由集群根据一致性协议自动选举leader后实现,无需进行人工干预,完全自动进行;当然,也可以手工进行切换。
第二层是主备集群的切换,这种与传统数据库更加类似,前提是要准备一套灾备集群。
分布式数据库生产集群采用两地三中心五副本架构,同城生产机房2副本、同城灾备机房2副本、异地灾备机房1副本,根据一致性协议以及“大多数”原则,必须保证有3副本存活才能维持数据库正常服务。为了保证数据库写服务效率,异地机房的1副本仅作为从副本,因此无leader,所有的leader都分布在同城两个机房里。
如果异地机房出故障,那么集群剩下4副本,此时写操作请求发生后,只要有3个副本写成功即可,同时,同城两个机房有全部leader,因此无需重新选举leader,也就不存在主从切换;
如果同城任一机房故障,那么集群剩下3副本 ,此时写操作请求发生后,需要3个副本都写成功才认为成功, 但是由于有1个副本在异地,存在异地延时,影响写效率,因此这种情况要先人工将集群5副本降为3副本,然后由集群在同城另一个正常的机房自动选举出leader,从而实现所谓的“主从切换”。
除了上述场景,在异地灾备机房可以单独准备一套灾备集群,与生产集群进行数据同步,从而实现传统意义上的“灾备”。

嘉宾:hanfeng_twt 数据库架构师 , 大型金融单位
高可用方案,各家产品实现有所差异。一般情况下,在同城双中心异地单中心的情况下,当同城某AZ出现问题时,是无法自动切换到同城第二个AZ,是需要引入第三个AZ,满足仲裁需求的。当然有些是可以写死切换逻辑在里面,但非标准的切换流程。因此,一般建议在同城采用3AZ,满足多数派选举,可实现自动切换能力。异地一般不建议参与其中,毕竟存在较长时延。

2、中小银行后端稳态类系统进行分布式方向改造的必要性?

中小银行在进行分布式数据库选型时应如何通过场景区分进行有针对性改造,如整体架构中传统稳态类系统是否有必要逐步纳入选型范围,金融强监管态势下,核心重要账务类系统对系统可用性、稳定性要求日益提升,如何确保分布式架构在此类系统中高可用、单点故障有效隔离、事务强一致性等。

嘉宾:wanglaye信息技术经理 , 某大型金融机构
稳态类系统进行分布式改造是件非常谨慎的事情。
如果要提高性能和可用性,可以采用业务拆分的方式,将业务分布在不同的应用节点上,每个应用节点有自己的传统数据库。这种架构也在某种意义上实现了分布式。性能方面可以对每个应用节点及对应的数据库进行扩容;可用性方面,由于业务进行了拆分,当某个业务节点发生故障时将这个业务节点隔离,将请求导向其他节点,这部分工作可以通过自动化运维平台实现自动切换。

嘉宾:hanfeng_twt数据库架构师 , 大型金融单位
分布式改造的必要性,主要来自于几个方面:业务驱动(应数据规模、算力不足等需要扩展)、政策驱动(有监管方明确需求)、技术驱动(为适配技术栈革新)、管理驱动(从统一管理等角度考虑)等等。这里需权衡分布式改造所带来的投入产出比及对应的风险评估。个人建议,中小型银行的稳态业务,不一定非要做分布式改造,需要做更严谨的评估。

3、分布式数据库故障时如何确保故障自动转移,自动恢复业务,实现高可用?

嘉宾:wanglaye信息技术经理 , 某大型金融机构
高可用可以分为单机级、机柜级、机房级、数据中心级、城市级等很多不同的层级。
无论是哪一种层级,都需要分布式数据库的多副本机制和一致性协议来保证。简单来说,分布式数据库故障时,一致性协议可以重新选举leader,在保证大多数副本正常的情况下,确保业务不受影响,数据库不停服务。

嘉宾:任晓蕾 解决方案架构师 , 英特尔社区
分布式数据库实现自动故障转移,自动恢复 ,需要对数据库指标进行实时监控,使用自动化脚本对数据库进行智能调优,智能化恢复,实现自主自治的智能化数据库,这也是目前分布式数据库的一大技术热点。市场上的很多分布式数据解决方案都在增强这一特性。

嘉宾:hanfeng_twt 数据库架构师 , 大型金融单位
分布式库的组件较多,大致可分为数据节点、计算节点、控制节点三类角色。其中,计算节点一般为无状态的,故障后可切换自动恢复;控制节点一般采用自身高可用保障,出现问题是会主动自愈;数据节点出现问题时较为重要,因为其上面承载的数据。我理解问题主要是对应这一角色。针对数据节点,不同分布式数据库产品,底层实现有所差异,大致可分为两种情况:
1基于单机数据库的主从复制模式 2.基于多数派协议保证的多副本模式 无论是那种模式,当出现故障时都会完成自动选主,自动切换,从而实现高可用。目前的大部分产品,都已可实现在同AZ、同城跨AZ的自主切换、对业务无感(业务需实现出错重试机制)。针对异地的情况,一般还是建议人工介入,而不自动完成切换。

嘉宾:邓刚 解决方案架构师 , 英特尔社区
不同的分布式数据库实现高可用的方式和能力也各不相同,需要在选型时进行专门的比较甚至进行原型验证。

4、分布式数据库全局一致性和高性能如何取舍达到平衡?

嘉宾:wanglaye 信息技术经理 , 某大型金融机构
个人认为,传统银行业对于一致性一定是放在第一位的,在满足一致性的基础上再去追求高性能,而高性能可以由数据库层或中间件来实现(如业务数据分片、分布式数据库、缓存等),也可以由硬件层来优化(如采用更好性能的cpu,更大的内存,更快的数据存储设备等)。

嘉宾:邓刚 解决方案架构师 , 英特尔社区
在确保全局一致性的前提下实现更高的性能,是分布式数据库实现的一个关键点和难点。不同的分布式数据库有不同的实现方式。一般来说,如果集群的规模很大,达到几千甚至上万台,有的选择专门硬件如原子钟,来保证整个机群版本的全局有序。如果集群的规模不是很大,可以选择集中的全局事务 id 服务。 分布式数据库由于需要支持分布式的全局一致性, 势必对于性能有较大的影响。 这就 对硬件 提出更高的要求,特别是在延时方面,需要在计算、存储、网络三方面综合考虑。

嘉宾:hanfeng_twt 数据库架构师 , 大型金融单位
个人觉得这两者不存在平衡关系,一般一致性要求是来源于业务,很难去做业务上的取舍。都是在有明确一致性要求的情况下,尽量做到性能最好。

嘉宾:任晓蕾 解决方案架构师 , 英特尔社区
全局一致性是基于银行业务需求,银行关键交易一定要保证全局一致性,在全局一致性的基础上再对性能进行优化。

四、分布式数据库的未来发展趋势

1、关于国产分布式数据库未来趋势分析?

如何找到三五年后成为主流的国产分布式数据库产品?该产品应具有最高的市场份额和认可度,拥有比较完整生态圈。例如,从该产品的研发投入、研发人员、技术支持人员的数量,技术管理体系,产品成熟度等方面评估,目前的现状又是怎样?

嘉宾:wanglaye 信息技术经理 , 某大型金融机构
无法预测。目前没有哪一款分布式数据库可以一统天下,因为每款产品都有自身的优势和客户群。或者说,没有必要一统天下,多产品共存对于用户、市场不是更好的局面么。
题主如果要进行选型,除了技术因素,也要考虑其他的管理因素。技术因素可以通过poc测试来选择对比,管理因素就如题主问题描述中所提到的那些方面,可以在招标阶段进行评价。

嘉宾:任晓蕾 解决方案架构师 , 英特尔社区
分布式数据库技术百花齐放,云原生数据库,多模,智能化自适应,HTAP数据库都是当前的热点和未来的发展趋势。 同时数据库技术由最开始的优化I/O的设计初衷,随着存储介质性能和非易失内存技术的发展,转向更多的内存计算。

嘉宾:hanfeng_twt 数据库架构师 , 大型金融单位
目前尚处于早期阶段,趋势发展上还不是很明朗。个人有以下一些判断:
1.多技术路线会长期共存
2.云会在未来达到统一,但周期会很长
3.MySQL、PG会成为事实生态标准,各产品会加以适配

2、传统dba如何转型?

面对分布式数据库百花齐放,对于传统的运维dba既是挑战也是机遇,传统的运维dba该如何快速学习转型?

嘉宾:邓刚 解决方案架构师 , 英特尔社区
分布式数据是未来数据库发展、建设的方向。分布式数据库也是从传统数据库演化来的,传统的 DBA 大多数的知识和经验仍然能够用到分布式数据库的运维上,比如 SQL 的优化,服务器资源的监控、优化等。建议可以从了解、搭建一个主流分布式数据库开始,了解分布式数据库的一些新特点,比如分布式数据库如何实现高可用、负载均衡等。

嘉宾:任晓蕾 解决方案架构师 , 英特尔社区
DBA需要学习开发自动化脚本 实现数据库智能监控预测和运维的能力 ,为数据库增加智能调参,自学习索引 ,智能负载均衡等能力来实现自主自治的数据库。

嘉宾:hanfeng_twt 数据库架构师 , 大型金融单位
可参考下我的总结。
https://www.talkwithtrend.com/Article/259683

五、本期交流共识总结

根据近期线上交流及线下问答环节情况总结,有以下几点共识:
1.金融级分布式数据库,是各家金融机构非常关心的技术方向。分布式数据库为数据基础设施层面带来的改变,颇引人关注。与会者普遍关心分布式数据库能解决的业务场景问题,及带来的收益。
2.对于金融业采用分布式数据库,在场景选择、技术选型、功能评测、可用性、多活容灾等方面,与会人员普遍比较关心。作为一种新兴技术,还需要在金融级场景中充分磨炼,大量存在很多基本工作需要完成,不能一蹴而就。
3.针对这种新的技术架构,如何融入到现有基础环境,如何规避可能带来的风险,如何综合评估成本及产出收益,成为金融企业关心的问题。
4.新兴架构的引入,对于应用设计、系统开发、运维保障等都带来的一定冲击。需要提升现有人员技能、甚至转型发展,来适应这种新的架构。好的技术是需要好的落地,如何发挥分布式数据库的最大效能,是需要上下游共同努力。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

3

添加新评论0 条评论

Ctrl+Enter 发表

本文隶属于专栏

活动总结
活动总结是社区交流活动内容的总结及延伸,为大家提供了社区专家们丰富且高水平的理论知识、实践经验以及常见问题的最佳解决方法,非常值得大家收藏学习。

作者其他文章

相关文章

相关问题

相关资料

X社区推广