选择分布式数据库的担忧?

一直担心分布式数据库的原因如下【简单说几点】:
1、采用分布式数据库,解决了数据分布式存储,则数据的一致性如何保证?若是实时交易性系统,数据并发写访问量大的情况下,依然会出现性能瓶颈【没有办法或者很难将访问关系进行拆分】,故写数据大量集中,而数据要同步到其它存储上,会存在一定的时间延迟。若这是进行大量的读访问【此时可采用分布式】,会存在已存在的数据未同步完成,不能有效访问。故分布式数据库的应用场景在银行中是交易性型系统还是管理型系统?还是分析型系统?案例较少,故一致未确定采用
2、采用分布式数据库后,系统架构变得较为复杂。首先是设备数量增多,其次数据拆分规则难以确定【技术与业务人员的口径难以得到统一】。还有分布式数据库第三方的技术支持困难。最后是目前市场上分布式数据库没有一个大家公认的领头羊

参与12

3同行回答

AmygoAmygo  DBA , 分布式事务数据库
1、采用分布式数据库,解决了数据分布式存储,则数据的一致性如何保证?若是实时交易性系统,数据并发写访问量大的情况下,依然会出现性能瓶颈【没有办法或者很难将访问关系进行拆分】,故写数据大量集中,而数据要同步到其它存储上,会存在一定的时间延迟。若这是进行大量的读访问【此...显示全部

1、采用分布式数据库,解决了数据分布式存储,则数据的一致性如何保证?若是实时交易性系统,数据并发写访问量大的情况下,依然会出现性能瓶颈【没有办法或者很难将访问关系进行拆分】,故写数据大量集中,而数据要同步到其它存储上,会存在一定的时间延迟。若这是进行大量的读访问【此时可采用分布式】,会存在已存在的数据未同步完成,不能有效访问。故分布式数据库的应用场景在银行中是交易性型系统还是管理型系统?还是分析型系统?案例较少,故一致未确定采用

解答:

(1) 依然会出现性能瓶颈【没有办法或者很难将访问关系进行拆分】 :这个需要分布式数据库拆分的时候选择合适的数据分片字段、数据分片算法、数据分片类型 三者共同决定。还有一类是P2P资金托管账户则需要做中间账户的模式去拆解托管方的账户以提升并发,这个类似支付宝的中间子账户实现。

(2)分布式数据库场景:A、 分布式数据库的应用场景在银行中是交易性型系统还是管理型系统 是都有的 、属于OLTP分布式数据库产品方向,分析型系统则是属于OLAP分布式数据库产品方向。

等一等金标委就会发布金融行业标准和检测方案标准,下半年还会发布测试用例标准。

总结:建议挑选产品做测试,采购的时候把数据分片设计、运维管理 两项作为兜底要求数据库厂商承担。

2、采用分布式数据库后,系统架构变得较为复杂。首先是设备数量增多,其次数据拆分规则难以确定【技术与业务人员的口径难以得到统一】。还有分布式数据库第三方的技术支持困难。最后是目前市场上分布式数据库没有一个大家公认的领头羊

解答: 

(1)OLTP分布式数据库产品最难的是 数据分片设计,完全依靠人工去设计很容出现思维死角 或调研信息缺失等造成设计的数据分片方案不合理,从而导致整个集群的吞吐量、响应时间等大打折扣。

从金标委会议上了解 热璞数据库HotDB产品大规模使用了AI算法经历3年研发打磨成功了。

(2)还有分布式数据库第三方的技术支持困难

这个就需要看分布式数据库产品化做的如何,建议作为业主方直接要求数据库产品厂商方兜底的做法,否则扣钱。

产品化可以看下这篇文章描述的:http://www.talkwithtrend.com/Article/247813

收起
银行 · 2020-04-01
浏览2602
anikikonganikikong  数据库运维工程师 , 中国民生银行
数据库的一致性一定是要强一致性保证的,金融行业的数据库这是必须的要求。分布式数据库的全局一致性一般通过两阶段提交的方式来实现,基本上就是要求全局一致的提交和回滚。如果有异常发生,数据库内部可以查到全局事务的残留,处理之后也能最终达到一致性。分布式数据库的性能...显示全部

数据库的一致性一定是要强一致性保证的,金融行业的数据库这是必须的要求。分布式数据库的全局一致性一般通过两阶段提交的方式来实现,基本上就是要求全局一致的提交和回滚。如果有异常发生,数据库内部可以查到全局事务的残留,处理之后也能最终达到一致性。

分布式数据库的性能问题是个很重要的点。大家都知道分布式是为了解决单点的性能才被提出来的。但是他仅仅是为了解决单点的集中式高并发需求,而不是为了复杂查询或者是大查询。因此使用分布式数据库一定要把握好他的应用场景。实时交易系统这种写并发大的情况其实也适合分布式,前提是他们的写是能基于分布式进行分片,能把写操作分散到各自的分片上去完成。读也是一样。分布式不适合的场景就是复杂的关联查询,大量的分布式事务等场景。分布式适合交易型系统,不适合管理类分析类。

分布式最大的痛点就是怎么分片,数据拆分这个是不可避免需要花最大力气的地方。因为这个前提,这里控制不好,后面擦屁股的活儿根本干不完。目前没有领头羊,押注吧。

收起
银行 · 2020-03-28
浏览2875
  • 分布式最大的痛点就是怎么分片,数据拆分这个是不可避免需要花最大力气的地方。因为这个前提,这里控制不好,后面擦屁股的活儿根本干不完。目前没有领头羊,押注吧 ---- ITPUB会议上 和金标委的会议上听 热璞分布式事务数据库HotDB产品 有一个智能数据分片的功能可以自动实现,等我找一找对方的产品功能截图 另外,同OceanBase老师聊到,正在研发此功能:智能数据分片
    2020-04-01
wanglayewanglaye  信息技术经理 , 某大型金融机构
1、一致性,分为强一致性、弱一致性、最终一致性。属于哪个一致性等级,与数据库多副本状态下的读写成功所需的最小化副本数有关。最常用的一致性协议有paxos、raft。 若采用强一致性,则又分为两种情况:读写分离、读写不分离。读写分离情况下,无论读或写都需要大多数副本成功才...显示全部

1、一致性,分为强一致性、弱一致性、最终一致性。属于哪个一致性等级,与数据库多副本状态下的读写成功所需的最小化副本数有关。最常用的一致性协议有paxos、raft。
若采用强一致性,则又分为两种情况:读写分离、读写不分离。读写分离情况下,无论读或写都需要大多数副本成功才认为读写成功;读写不分离情况下,写需要大多数副本写成功才返回成功,读只能读主副本,也能保证读到的数据是最新的。
写并发高的情况,通过合理策略进行数据分片(甚至二次分片),把数据打散,避免热点盘。在主机配置和网络带宽有限的情况下,写数据量大到一定程度是无法避免性能瓶颈的,事先可以通过分片避免热点盘,事中可以扩容。所以一般建议根据应用系统的交易量来规划设计数据库,可以一定程度上避免高并发写带来瓶颈。
读并发高的情况,还是选择强一致性的数据库吧。
交易类系统我们选用的是高性能事务型分布式数据库。分析类系统对实时事务处理要求不高,会选择HBase这类建数仓。管理类系统,得看是哪类,如果是实时监控类的管理系统对性能要求高可以上,其他的管理系统为了节约成本可以选择普通数据库。
2、系统架构并没有很复杂,反而更利于运维管理,一般分布式数据库都有管理节点和计算节点,对于管理员来说维护复杂度反而下降了,不用每个业务系统维护一套了。
数据分片时,业务和技术听谁的,这个难以回答,每家企业有自己的做事策略。
领头羊当然是有的。

收起
银行 · 2020-03-26
浏览2706

提问者

lyq6666
IT顾问重庆农村商业银行

问题来自

相关问题

相关资料

相关文章

问题状态

  • 发布时间:2020-03-23
  • 关注会员:8 人
  • 问题浏览:4408
  • 最近回答:2020-04-01
  • X社区推广