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

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

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

10回答

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

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

收起
 2019-08-06
浏览7920
aixchina 邀答
周光明周光明  软件架构设计师 , People's Bank of China
libai21pobirdgongpu等赞同了此回答
谈点个人理解: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
浏览8006
  • 周总,我们并不是mysql基础上自研的中间件,全局一致性是我们的一个亮点,这一点范行也李司长都是认可的,否则也不可能用在中信银行的卡中心。您这边是不是在北京,人行我们最近也是经常在走动,如有机会期待能和您当面做一个交流。
    2020-03-16
AmygoAmygo  DBA , 分布式事务数据库
SeaskybluepobirdAmygoing等赞同了此回答
1、分布式的实现,是通过中间件实现分布式,还是源码级别引入分布式算法实现的? 解答: (1) 分布式数据库 是至少由 计算节点、存储节点、管理平台、备份还原程序 四个部分组成,从数据库系统理论知识上说分成:全局自治 和场地自治 ,也粗略认为: 全局可理解为计算节点、场地可...显示全部

1、分布式的实现,是通过中间件实现分布式,还是源码级别引入分布式算法实现的?

解答:

(1) 分布式数据库 是至少由 计算节点、存储节点、管理平台、备份还原程序 四个部分组成,从数据库系统理论知识上说分成:全局自治 和场地自治 ,也粗略认为: 全局可理解为计算节点、场地可理解为存储节点

(2)这个问题的标题 “中间件实现分布式 还是源码级别引入分布式算法”  这个说法存在误导性,修改为 : 存储节点自主研发数据库存储引擎 还是采用 市场上存在的数据库产品为数据库存储引擎。只要知道通信协议,存储节点可以是任何集中式数据库产品

(3)存储节点自主研发:SequoiaDB、OceanBase 是属于自主研发数据库存储引擎

(4)存储引擎采用已有数据库产品:TiDB(存储引擎是开源KV的RocksDB)、HotDB(MySQL开源数据库,从知识产权能看寻到自主研发的存储引擎HotDB Engine)、GaussDB T(PostgreSQL开源数据库)、GoldenDB( MySQL开源数据库 )、TDSQL( MySQL开源数据库 )

2、分布式事务支持以及在超大事务下的性能下降幅度?

解答:

(1) 超大事务下的性能下降幅度

采用sysbench的方式太简单了,意义不大。这个问题需要采用相同的硬件环境、数据环境、业务场景,对比测试才能回答。信通院正组织厂商在测试模拟银行传统核心业务场景的性能测试。另外,从网络上拿到的信息:6000万账户基础数据、每笔业务96条SQL(也即一个数据库事务是96条SQL组成)、随机两个账户转账,HotDB 能做到 12000笔 转账业务 /秒、平均响应时间 78毫秒/笔转账业务、成功率100%;TiDB能做到  2200笔 账业务 /秒、平均响应时间 315毫秒/笔转账业务、成功率99.3%

( 2) 分布式事务支持

分布式事务支持分成两块:采用NOSQL架构的 乐观锁 还是  集中式数据库的 悲观锁、分布式事务等同集中式数据库的能力。如下:

(2.1) 采用NOSQL架构的 乐观锁 的产品:SequoiaDB、GoldenDB、TiDB

(2.2) 采用 集中式数据库的 悲观锁 的产品:OceanBase、HotDB、GaussDB T

   (2.3)  分布式事务等同集中式数据库的能力 : OceanBase和 HotDB 完全等同 集中式数据库 的事务能力,其他产品都需要借助 “管理协调节点”来完成,所以在事务透明、实时一致等方面存在困难,还无法等同。

3、大查询(亿级)下各数据库的性能如何?

解答:这个看是否复杂JOIN,还只是简单SELECT,对于基于NOSQL技术架构的TiDB、 SequoiaDB在数据分析方面占优,OceanBase、HotDB、 GoldenDB等其他产品基本上只专注OLTP业务场景。

4、对于从Oracle平迁至分布式数据库,除去存储过程等力不可抗拒因素外,其他的难度如何?有无便于使用的平迁工具?

解答:主要是要修改只有Oracle才有的SQL特性、函数等,现在 GoldenDB在做深入兼容Oracle,HotDB、 GoldenDB能兼容函数、序列等基础SQL语法而已。

5、分布式部署的高可用性:节点挂掉的数量对整个集群的服务能力、处理性能影响是怎样的?

解答:分布式数据库产品的高可用性 需要看这个产品由那几部分组件构成及参与业务系统的数据服务的组件模块,例如如下

(1)HotDB:参与业务系统的数据服务必备组件为 计算节点(负责全部的SQL语句执行、事务控制、存储节点存活探测、高可用切换、死锁检测、死锁解除等)、存储节点(负责数据存储、场地SQL执行)

(2)GoldenDB:参与业务系统的数据服务必备组件为 计算节点 (负责全部的SQL语句执行 )、存储节点 (负责数据存储、场地SQL执行) 、管理协调节点(负责分布式事务等)、管理节点(负责存储节点存活探测、高可用切换等)

(3)TiDB: 计算节点 (负责全部的SQL语句解析、转发 等)、存储节点 (负责数据存储、场地SQL执行) 、管理协调节点(负责分布式事务、 存储节点存活探测、高可用切换 等)

.............................其他类似

所以一款产品每个组件都必须无单点,且确认组件是否属于有状态的,对有状态的组件因涉及全局信息同步故是要特别对待的,例如:HotDB的计算节点是有状态、 TiDB 管理协调节点 PD 是有状态 等

6、集群增加节点后,对于整个集群的影响有哪些?增加节点后的数据平迁是否会对业务造成较大的影响?

解答:

(1) TP业务 跟AP业务在集群增加存储节点  对业务的影响是不同,或 增加计算节点类似

(2 ) TiDB、 SequoiaDB、OceanBase、HotDB、 GoldenDB在增加计算节点时对业务无影响

(3) TiDB、 SequoiaDB、OceanBase 、 HotDB 在增加存储节点时对业务无影响, GoldenDB 暂不清楚

7、搭建完成后,对于DBA运维来讲,各家有无工具能便于运维的条件

解答:从各家对外发布的信息看,HotDB产品在运维工具方面或者说产品化方面做最好,其次是 OceanBase .....微信群里看到的两张HotDB产品截图如下

收起
 2020-03-15
浏览5480
aixchina 邀答
  • (3) TiDB、 SequoiaDB、OceanBase 、 HotDB 在增加存储节点时对业务无影响, GoldenDB 暂不清楚 这一条,我仔细看了中信银行丁总的演讲和材料,Goldendb是做不到的,它的宣传材料里的概念和Tidb/OB不一样,他的计算节点,实际上是dbproxy,数据节点,其实是完整的MySQL,并没有类似TiKV/SequoiaDB的独立存储集群。
    2020-09-22
匿名用户匿名用户
netsafeSwitchersamkingno等赞同了此回答
一.说一下产品概述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
浏览8327
GoldenDBGoldenDB  产品经理 , 中兴通讯
cook9862roam_boy赞同了此回答
感谢大家对GoldenDB的关注,关于GoldenDB的信息,大家可以看一下这一篇文章。看的出来大家都GoldenDB存在一些误会,比如说中间件+mysql的误会,借这里我澄清一下借用oceanBase白皮书中的一个说法,中间件+开源数据库存在4个不足 那么全局一致性事务是我们的最主要的竞争力,不然中信...显示全部

感谢大家对GoldenDB的关注,关于GoldenDB的信息,大家可以看一下这一篇文章。
看的出来大家都GoldenDB存在一些误会,比如说中间件+mysql的误会,借这里我澄清一下
借用oceanBase白皮书中的一个说法,中间件+开源数据库存在4个不足

那么全局一致性事务是我们的最主要的竞争力,不然中信银行也不会采用,GoldenDB采用一阶段提交+事务补偿的方式,对业务完全透明,还能避免而极端提交prepare阶段和commit阶段短暂的不一致,不需要业务写异常回滚。
复杂的跨库查询,全局索引,和全局一致的DDL都是我们最基本的特性。
因此说我们是中间件我们真的有点冤。

GoldenDB在中信银行信用卡核心应用实践

摘要:中信银行卡中心新核心系统于2019年10月27号正式开业。采用中信银行与中兴通讯联合研发的分布式数据库GoldenDB来承载核心业务系统,该数据库是国内第一家在大型股份制银行信用卡核心系统成功落地的国产分布式数据库。

随着信息技术的发展,金融行业已经进入4.0时代,金融服务已经突破传统的服务边界,变得无处不在,这对银行的战略布局、营销模式以及IT系统提出更高的要求。

中信银行信用卡中心于2017年开始启动分布式新核心系统建设,目标是扩展业务范畴、完善经营模式、提升活跃客户量、提升业务交易量。要求核心系统具备架构的前瞻性,构建资源可扩展的开放平台,能够快速响应业务大规模增长,实现面向决策的核心信用卡系统。

中信银行卡中心新核心系统于2019年10月27号正式开业。采用中信银行与中兴通讯联合研发的分布式数据库GoldenDB来承载核心业务系统,该数据库是国内第一家在大型股份制银行信用卡核心系统成功落地的国产分布式数据库。
GoldenDB分布式数据库

GoldenDB主要由4个功能模块节点构成:

计算节点: 与业务通过标准JDBC连接,主要用于解析业务SQL请求,分布式优化,分布式路由以及分布式事务控制。

数据节点: 由数据库实例构成,用于承载业务数据,支持横向水平扩展,多数据副本保证数据安全可靠。

全局事务管理节点: 负责分布式事务生命周期的管理,与计算节点一起进行分布式事务控制。

管理节点: 对集群进行管理,负责系统集群的高可用,管理系统元数据。同时对备份恢复、主备切换、监控分析都提供了可视化的操作界面。

GoldenDB产品架构图

中信银行核心数据库应用实践

中信银行信用卡核心系统,主要包括授权、账务、数据服务等三块业务系统。每种业务场景不一样,性能要求也不一样,分布式优化方案也各有侧重点。另外,如何保证在尽可能短的时间内,顺利正确地完成数据迁移也是非常重要的。

核心分布式数据库部署

核心系统的三个业务内部的故障不能相互感染。因此,在设计业务连接实例时,把业务连接的计算节点进行物理隔离,杜绝业务故障的传染性。且业务系统要求的隔离级别和运行模式也不一样,在集群配置上也能做到统一管理,灵活多变,方便后期运维管理。

在底层数据节点,配置的X86服务器性能很高,从成本和可用性上考虑,一个数据服务器中部署了两个数据库实例,不同服务器之间做交叉主备,同时主备机磁盘也相互独立。保障单机内主备机磁盘IO隔离,单机异常也不会影响系统可用性。

中信银行核心业务系统架构图

核心业务分布式设计应用实践

卡中心核心业务中最重要的业务是授权联机交易业务,对时延非常敏感,以快捷支付业务为例,单笔业务30多条SQL语句,时延必须小于40ms。因此,替换分布式数据库后,必须消除分布式带来入侵性并提供稳定的高性能服务。

中信银行信用卡新核心分布式设计

首先,在数据模型方面,所有业务表按照客户号进行拆分。大表先分表再分区,减少单分片上的压力。常用的小表加载到Redis上,减少网络消耗的同时,提升数据查询性能。

其次,梳理交易场景,对业务进行分布式优化。优化后的交易,GoldenDB仅作简单路由,业务语句直接下推到DB层执行,减少分布式事务开销,提升业务响应时间。

最后,增加业务映射表,减少业务层的复杂性。在核心系统内添加客户号映射表,业务中只需增加获取客户号的流程,即可方便的拿到客户号,这样后续业务中的事务控制就可直接下推到数据库底层DB节点完成,业务层不必关注事务控制逻辑。

最终性能压测达到1.8W TPS达到上线标准,稳定通过网联4500TPS压测,以及双11和双12实际考验。

核心批处理业务分布式应用实践

批处理业务的特点就是在一定时间窗口内,集中处理一批数据文件。这个期间内业务会调起大量的并发,在短时间内完成跑批作业,对于分布式系统来说,如何做好跑批作业的分布式优化也是难点。

如按照原有逻辑批量处理业务,业务统一按照分布式业务场景处理,部分业务场景未优化,并行度不高,我们对业务进行了分布式和非分布式业务场景的识别,优化逻辑处理流程。梳理出可分布式改造的业务场景,数据文件先导入到的分片表中,然后对一个分片内的数据进行批量操作,所有分片并行处理,提升并行度,缩短了处理时间。

业务划分后,从系统稳定性角度出发,再梳理批处理业务逻辑,按照业务场景并行处理批处理作业。提升业务的并发度,降低系统资源压力。

最终核心日终批处理性能提升1倍,处理时长优化到1.5小时以内。

核心数据迁移应用实践

数据迁移作为卡中心核心系统下移关键一步,整个迁移要在很短的窗口期内完成,业务会以数十万的并发来加快迁移过程,大量迁移数据会使得网络长期维持在高负荷的状态。要求数据库能够在高并发、重负载的业务场景下,提供稳定可靠的数据服务。

中信银行信用卡新核心数据迁移流程

数据迁移的主要流程: 外围系统数据文件通过文件传输平台落到共享存储上,旧核心的DB2数据文件通过FTP下载到Hadoop集群,通过调用MCO转码工具转码后,生成标准的数据文件落到HDFS上。迁移工程运行在容器云中,通过生成insert语句和调用迁移工具两种方式将两部分数据迁移到GoldenDB内:

在整个迁移过程中,采用了如下方案确保数据迁移的效率:

1、优化业务逻辑。在高并发场景下,合理使用索引,调整业务逻辑顺序,最大程度减少锁冲突问题。

2、优化数据库参数。使得数据库在迁移阶段具备一定的容错能力,如适当调大锁等待时间,将切换阈值调高,容忍系统心跳延迟等。

整个核心业务投产数据迁移期间,最大活跃连接数达到24万,网络流量峰值达到900MB/s。在这种极端的业务场景下,历经了数十次的演练,顺利完成了核心业务投产数据迁移工作。

自2014年以来,中信银行与中兴通讯共同研发分布式数据库GoldenDB,稳中求进,不断深入。在冠字号、门户网站、金融同业平台、统一零售积分系统、电商管家、开放银行、用户权益系统以及信用卡中心核心系统陆续成功投产。
中信银行信用卡中心分布式核心系统StarCard于2019年10月27日正式开业,支撑1亿用户,日均交易9000万笔,顺利通过双十一的业务峰值考验,数据库性能表现平稳。经过5年的不断打磨,GoldenDB经历了严苛的商用考验,已经具备全面替换银行交易类业务数据库的能力。、中兴通讯领导参加了启动仪式。

(原文载于《金融电子化》2020年1月刊,作者:中信银行 张兴强 陈建峰 中兴通讯 付裕 戴扶)1

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

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

收起
 2019-07-23
浏览7521
DDBDDB  IT顾问 , 中兴通讯
roam_boy赞同了此回答
分布式数据库在架构上都是逻辑节点,中间件的说法是需要明确的定义,是否能做跨节点的强一致性事务,是否能做跨节点的全局查询,是否能做全局索引等?把握住核心部分而不是长的样子。在具体的实现上,对于金融只有适用还是不适用,是否能理解金融的这些复杂场景。基于互联网的模式是否...显示全部

分布式数据库在架构上都是逻辑节点,中间件的说法是需要明确的定义,是否能做跨节点的强一致性事务,是否能做跨节点的全局查询,是否能做全局索引等?把握住核心部分而不是长的样子。在具体的实现上,对于金融只有适用还是不适用,是否能理解金融的这些复杂场景。基于互联网的模式是否适合传统的核心,一致性,容灾,跑批,批量执行等等。
能做这种复杂的测试的在国内基本上只有大行,大型股份制行,大部分行里要做一个完整的验证测试还是很困难的。

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

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

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

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

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

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

收起
 2019-06-27
浏览7741

提问者

Switcher数据库管理员, 某银行

分布式关系型数据库选型优先顺序调查

发表您的选型观点,参与即得50金币。

问题状态

  • 发布时间:2019-06-26
  • 关注会员:16 人
  • 问题浏览:14325
  • 最近回答:2020-03-15