金融业分布式数据库:SequoiaDB、GoldenDB、OceanBase等原理、POC性能对比及选择是怎样的?

以上三种数据库大家都多少有了解,也是在金融业都有实践的,可能很多金融业朋友选择分布式数据库的时候都会接触以上三个数据库中的一个或几个。
不知道是否有银行通过POC测试测试过其中的数据库?测试数据又是怎样的呢?还望不吝讲解一番,一下几点我想是有不少人所关心的问题:
1、分布式的实现,是通过中间件实现分布式,还是源码级别引入分布式算法实现的?
2、分布式事务支持以及在超大事务下的性能下降幅度?
3、大查询(亿级)下各数据库的性能如何?
4、对于从Oracle平迁至分布式数据库,除去存储过程等力不可抗拒因素外,其他的难度如何?有无便于使用的平迁工具?
5、分布式部署的高可用性:节点挂掉的数量对整个集群的服务能力、处理性能影响是怎样的?
6、集群增加节点后,对于整个集群的影响有哪些?增加节点后的数据平迁是否会对业务造成较大的影响?
7、搭建完成后,对于DBA运维来讲,各家有无工具能便于运维的条件?

若有实践过的,遇到同样问题的朋友,还望不吝赐教,感谢,感谢。

7回答

匿名用户匿名用户
Switchersamkingnoyinxin赞同了此回答
一.说一下产品概述1)SequoiaDB:创始团队主要来自 DB2,原定位于非结构化数据, 更多案例是 OLAP,最近几年开始研发 OLTP2)GoldenDB:和中信银行联合研发,基于 MySQL + 中间件的模式3)OceanBase:阿里完全自研的代码二.问题解答1、分布式的实现,是通过中间件实现分布式,还是源码级别引入分...显示全部

一.说一下产品概述
1)SequoiaDB:创始团队主要来自 DB2,原定位于非结构化数据, 更多案例是 OLAP,最近几年开始研发 OLTP
2)GoldenDB:和中信银行联合研发,基于 MySQL + 中间件的模式
3)OceanBase:阿里完全自研的代码
二.问题解答
1、分布式的实现,是通过中间件实现分布式,还是源码级别引入分布式算法实现的?
分布式的实现是指什么呢?如果是指技术路线,那么 GoldenDB是“中间件+MySQL”,SequoiaDB和OceanBase是源码级别;
2、分布式事务支持以及在超大事务下的性能下降幅度?
分布式事务的支持是分布式数据库的基本选项,由于涉及多个资源协调必然会下降。但是下降多少,与业务逻辑密切相关。
3、大查询(亿级)下各数据库的性能如何?
大数据是指“单条语句查单条记录”还是“单条语句查多条数据",不论任何情况,肯定是与业务相关。
4、对于从Oracle平迁至分布式数据库,除去存储过程等力不可抗拒因素外,其他的难度如何?有无便于使用的平迁工具?
每家公司都在尽量研发迁移工具,语法不是难度,只是工作量,难度在于数据分布模式的确认,只有合理的分布才可以提升性能,避免数据分布导致的性能下降
5、分布式部署的高可用性:节点挂掉的数量对整个集群的服务能力、处理性能影响是怎样的?
分布式数据库运行在开放平台,每个节点故障的可能性都很大,所以必然是保证功能正常。服务能力的 RTO 一般会分钟级,RPO =0,不影响整个的处理性能
6、集群增加节点后,对于整个集群的影响有哪些?增加节点后的数据平迁是否会对业务造成较大的影响?
增加节点就是为了提升性能,不然没有意义。增加节点后的数据重分布肯定会考虑对业务的影响,一般是在业务低峰期做
7、搭建完成后,对于DBA运维来讲,各家有无工具能便于运维的条件?
由于涉及多个节点,不仅仅搭建完,在整个搭建过程中必须有统一运管平台。

收起
 2019-07-19
浏览858
孔再华孔再华  数据库运维工程师 , 中国民生银行
Switcheryinxin赞同了此回答
谈谈个人对分布式数据库选型的理解吧。我觉得使用分布式数据库的根本原因就两点。一是高可用,数据分片后不容易出现全局故障,即便有单点故障,顶多影响部分数据和业务。另一个是性能扩展,因为单点性能容量有限,面对互联网交易,手机交易的大并发访问,单点数据库可能会遇到性能问题...显示全部

谈谈个人对分布式数据库选型的理解吧。我觉得使用分布式数据库的根本原因就两点。
一是高可用,数据分片后不容易出现全局故障,即便有单点故障,顶多影响部分数据和业务。另一个是性能扩展,因为单点性能容量有限,面对互联网交易,手机交易的大并发访问,单点数据库可能会遇到性能问题。
然而对于金融行业来说,为了这两点选择的分布式数据库,还得具备单数据库的基本功能,例如pitr,分布式事务,读写一致性等。而这些基本功能,众多分布式数据库基本都是通过设置全局事务号来搞定的。如果是基于客户端的分布式数据库,其实是做不到这一点的。所以基于客户端的分布式数据库只能应用在有限的场景下,需要应用开发支持才行。而也正因为如此,基于客户端的分布式性能是最好的,基本没有损耗。
客户端模式局限多不适合,那么就要考虑这些国产的分布式数据库产品了,我想把这些归为中间件式的分布式数据库。例如华为高斯,阿里ob,antdb,巨杉,tidb等等。这些数据库功能最齐全,支持强一致性的话都设置了全局控制组件,例如gtm,全局事务管理器,然后一大堆的数据节点,加上提供链接的协调节点。几乎所有这些分布式产品都是这么干的。也有些另类的例如基于分布式一致性协议,但是性能和整体功能兼容性都会差很多。
我们测了很多分布式数据库产品,结果在这里暂时不能透露,只说说我们测试会关注的点。一是高可用,关注每个组件故障回复时间,尤其是全局影响时间。还有就是单点事务性能和分布式的跨节点事务性能,读写强一致性。这个方面数据库差异特别大,因为有全局组件的原因,分布式数据库处理能力最终上限也会出现在这里,不可能无限扩展的,这与我们需要的性能扩展是相悖的,有些产品甚至还不如单机性能好。最后是混合型场景htap。因为任谁也不能保证自家的应用就是oltp没点复杂查询什么的,因此复杂查询的支持也需要验证。我想大家在测试的时候把这几点测到,基本上就有答案了。
分布式数据库属于新产品,尤其是集群类型的,虽然测好了单点故障,但是全局故障会不会有问题谁也说不好。因此pitr必须得有,额外保护也得考虑。建议将数据想办法同步一份到集群外面来,以防万一。
最后说说迁移。几乎所有的分布式数据库在做产品的时候都会考虑兼容性,但是事实上都做不到百分百的兼容。因此工作量还是有的,既然选择了,就不用太考虑工作量。平时也是做好对数据库告警功能或者特色功能使用的控制,尽量只使用数据库的基本功能,不要写一堆存储过程什么的,减少对数据库产品的依赖性。

收起
 2019-08-06
浏览619
aixchina 邀答
周光明周光明  软件架构设计师 , People's Bank of China
Switcheryinxin赞同了此回答
谈点个人理解:1)POC测试:SequoiaDB、OceanBase在金融行业都已经有大量用户了。 2)分布式数据库技术发展体系对比:SequoiaDB和OceanBase都是原生分布式数据库。GoldenDB是MySQL基础之上自研分布式中间件。 3)分布式事务及性能:对于分布式数据库,分布式事务支持都是难点和重点...显示全部

谈点个人理解:
1)POC测试:
SequoiaDB、OceanBase在金融行业都已经有大量用户了。

2)分布式数据库技术发展体系对比:
SequoiaDB和OceanBase都是原生分布式数据库。GoldenDB是MySQL基础之上自研分布式中间件。

3)分布式事务及性能:
对于分布式数据库,分布式事务支持都是难点和重点。
SequoiaDB和OceanBase作为原生分布式数据库,对于分布式事务支持比较好。GoldenDB作为分布式中间件,对于分布式事务支持比较难,特别是强一致性的支持比较难以做到,效率和性能更是问题。
SequoiaDB和OceanBase都有事务开关,可以参数化配置。
对于分布式事务的性能,一般都是通过底层数据布局来把控的。如果分布式事务涉及的数据在同一个数据节点或者相邻数据节点,分布式事务性能就比较好。所以,结合业务特点来合理规划和设计底层数据布局很重要。

4)大查(亿级)下各数据库的性能:
传统集中式数据库在大查(亿级)下各数据库的性能都是很好的,关键看你的数据库逻辑设计和物理设计的如何。
分布式数据库大查(亿级)下各数据库的性能应该更好,同样关键看你的数据库逻辑设计和物理设计的如何。
从数据库引擎设计来看,SequoiaDB对于非结构化数据的查询性能应该很好。

5)对于从Oracle平迁至分布式数据库:
OceanBase正在研制Oracle兼容性,OceanBase团队也请了Oracle出来的一些技术人员在专门搞这个兼容性和迁移。
从理论和实践来看,Oracle数据迁移到OceanBase应该没有问题,但是Oracle存储过程迁移到OceanBase应该比较难。当然,我们也可以变换一个角度来思考这个问题,为什么一定要原样迁移,毕竟是2套完全不同技术系统的东西,能够做到数据迁移就足够了;代码迁移必然遇到sql语法兼容性问题,即便没有sql语法兼容性问题,访问计划也是必然是不同的,从而运行效率也无法保障。

6)分布式部署的高可用性、集群增加节点等都是分布式本身要解决的核心问题,所以SequoiaDB和OceanBase等原生分布式数据库都能够比较好的解决这些问题。不过,不同分布式数据库产品之间可能存在成熟性的差异,相对来说,OceanBase这些方面会做得比较成熟。

7)DBA运维工具:这个方面,SequoiaDB应该更胜一筹,SequoiaDB应该具备工业级(industry-level)运维工具。

8)中国自研分布式数据库比较多,例如:SequoiaDB、OceanBase、GAUSSDB、TIDB、GoldenDB、HOTDB等等。

9)从分布式数据库的研发团队和技术基因来看,SequoiaDB、OceanBase、GAUSSDB都是未来前景很好的原生分布式数据库。

收起
 2019-08-05
浏览672
冯万里冯万里  数据库架构师 , IBM
yinxin赞同了此回答
巨衫,oceanbase了解一些,在金融行业都逐渐壮大,应用在OLAP场景,逐渐挑战传统数据库厂商的市场显示全部

巨衫,oceanbase了解一些,在金融行业都逐渐壮大,应用在OLAP场景,逐渐挑战传统数据库厂商的市场

收起
 2019-08-07
浏览556
韩成亮韩成亮  数据库架构师 , 某金融
yinxin赞同了此回答
目前没有做过三个的完全POC测试,不过对于分布式数据库选择有一些个人的看法,以下仅供参考1 对于金融业分布式数据库的选择,首先需要明确你的定位,这点很重要,如果你只是一个简单的系统我想也不需要分布式,往往是我们只需要使用合适的,但是这个合适不能统一而论,无论是哪个分布式,...显示全部

目前没有做过三个的完全POC测试,不过对于分布式数据库选择有一些个人的看法,以下仅供参考
1 对于金融业分布式数据库的选择,首先需要明确你的定位,这点很重要,如果你只是一个简单的系统我想也不需要分布式,往往是我们只需要使用合适的,但是这个合适不能统一而论,无论是哪个分布式,设计伊始都有一个特定的场景,大部分的分布式厂商都有对标的业务场景。
2 对于分布式而言,可以分成三个部分计算,存储,调度,这也是目前市面常见的,那么你需要根据你的实际去选择,这个是一个雷达图,根据业务场景去选择才是合适的。
3 其次是部署模式,本地、公有云、私有云和混合云混合部署,该部分主要考虑的是容灾高可用情况,分布式都拥有自己的副本模式,无论是数据的副本复制,多写乃至于克隆,我们不仅仅需要考虑本身的容灾还需要考虑同城、异地的容灾,这点也是需要关注的
4 接下来就需要考虑使用情况,分布式的事物支持,弹性扩容和语法兼容性
5 最后一个就是你选择的分布式数据库的生态环境,是否开源,是否有强大的社区或者官方支持,是否有相关背书等
没有最好的,只要最合适的。

收起
 2019-08-05
浏览660
共同进步共同进步  数据库架构师 , 中国金融电子化公司
yinxin赞同了此回答
对GoldenDB不太了解,粗略谈一下对其他两个产品的认识,仅供参考:1.SequoiaDB是和mongodb类似的一个产品,用作文档数据库使用,属于nosql的一种,从产品使用情况来看,和mongodb非常像,在索引定义上和关系型数据库比较接近,支持复合索引等多种索引类型;因没有做过深入的测试验证,对性能、...显示全部

对GoldenDB不太了解,粗略谈一下对其他两个产品的认识,仅供参考:
1.SequoiaDB是和mongodb类似的一个产品,用作文档数据库使用,属于nosql的一种,从产品使用情况来看,和mongodb非常像,在索引定义上和关系型数据库比较接近,支持复合索引等多种索引类型;因没有做过深入的测试验证,对性能、高可用、扩展性等方面没有太多发言权
2.OceanBase严格来说是一款可用于OLTP处理的内存数据库(要求内存很大),更适用于电商应用场景(高吞吐量,但事务间依赖性小),事务处理后的数据先放到内存中(为保证数据持久性,日志会及时写入磁盘),等业务高峰过后再统一刷新到磁盘上,可替代普遍采用的数据库访问中间件+mysql集群,分片是自动进行的,从数据库设计上与使用mysql集群相比要简化得多。
因为都是在pc服务器上部署,都是将pc服务器的故障作为常态处理,因此高可用这一块都做的比较好,支持节点故障时无感知自动切换。

收起
 2019-07-23
浏览759
匿名用户匿名用户
查询性能亿级别完全没问题,oracle迁移到oceanbase技术比较成熟。分布式部署,我们这边是cloudera的平台 节点挂掉可以正常使用。但是如果你的节点数量比较少,对你集群影响还是比较大的,尤其体现在处理速度和响应上。增加节点之后可以做一下数据均衡操作,对业务影响较小。...显示全部

查询性能亿级别完全没问题,oracle迁移到oceanbase技术比较成熟。分布式部署,我们这边是cloudera的平台 节点挂掉可以正常使用。但是如果你的节点数量比较少,对你集群影响还是比较大的,尤其体现在处理速度和响应上。增加节点之后可以做一下数据均衡操作,对业务影响较小。

收起
 2019-06-27
浏览1035

提问者

Switcher数据库管理员, 某银行

问题状态

  • 发布时间:2019-06-26
  • 关注会员:8 人
  • 问题浏览:3331
  • 最近回答:2019-08-07
  • 关于TWT  使用指南  社区专家合作  厂商入驻社区  企业招聘  投诉建议  版权与免责声明  联系我们
    © 2019  talkwithtrend — talk with trend,talk with technologist 京ICP备09031017号-30