银行分布式数据库建设路径探讨,希望听听同行的看法
近来行领导听到非常多的人来沟通说分布式数据库如何好如何有价值,银行在分布式数据库的核心诉求究竟是什么?为什么一定要上分布式数据库?有没有其他的技术路线可以满足需求?如果上分布式数据库,需要避免哪些坑?希望能听听同行的经验和看法,让我们也能知道同行是如何想的。
(问题来自@pobird 系统架构师)
以下是社区用户的探讨:
wanglaye 技术经理 , 金融机构
银行传统数据库在应对互联网金融场景时遇到了明显瓶颈,在面临交易复杂度和交易频率的大幅提升时,传统数据库能够采取的优化方案非常有限,若仅依靠软硬件升级来提升性能的话,成本非常昂贵。另外,在应对双十一这类特殊交易日时,需要在短期内提升数据库的能力,传统数据库缺乏这方面的灵活性。若仅仅为了应对有限特殊日的流量,而配置很高的性能,又会造成资源的极大浪费。基于能力、可控、弹性、成本等方面的考虑,引入具有高可用、高性能、高可扩展性的分布式数据库成为优先选择方案。
分布式数据库设计阶段需要考虑很多方面,比较重要的像是高可用方案、存储方案、灾备方案、安全、监控、运维等,这些在前期都要规划好。还有一点很重要,分布式数据库最终是为应用服务的,要充分考虑应用从传统数据库迁移至分布式数据库的难度,尤其在测试阶段,要充分考量分布式数据库的兼容性。
在分布式数据库选型时,最好结合具体的应用场景,如OLTP和OLAP。另外,数据库厂商的技术服务支持能力和案例成熟度也要充分考虑。
以上是本人的一些小经验,供大家讨论。
Aero 其它 , 某银行
关于诉求和为什么一定要上分布式数据库,不想多说,因为这些问题是仁者见仁智者见智的问题,近期我们做了一些分布式数据库的验证测试工作,其中还是碰到很多问题的,通过测试,发现分布式基础问题21个,分布式和ORACLE兼容性问题28个,分布式和应用兼容性问题2个,分布式性能问题8个,以上问题都的到了厂商的确认,并进行了底层的修复。发现以上问题,都是通过大量的业务测试、场景测试和压力测试发现的,并进行了分析提交BUG修复。因此所谓的坑不是能避免的,而是要通过大量的测试去发现BUG,解决BUG,才能避免上了生产后踩坑。
目前我们通过认真讨论,也制定了大量异常场景进行破坏性测试,例如硬件问题场景、网络问题场景、业务问题场景(异常SQL)及极端场景进行了测试,通过以上大量的测试,技术人员自行编制了健康检查和健康巡检方案、慢查询SQL优化指南、分布式数据库异常问题解决案例手册、各异常场景测试报告及处理方案及总体测试报告等文档。
所以我们认为一个好的数据库是用时间、应用场景磨合出来的,只是我们在走之前ORACLE、DB2已经走过的磨合道路罢了。
508mars 数据库管理员 , 华泰证券
核心诉求我觉得有以下几个:
1)一些数据库越来越大,访问量越来越高,单机已经无法承载,或者纵向扩容的成本太高,这时候就需要通过支持横向扩展、支持廉价x86服务器的分布式数据库技术来解决
2)现在很多行都开始微服务以及数据中台的建设,如果采用传统数据库技术,数据库实例的数目将会非常恐怖,DBA的运维工作将会受到极大挑战,解决这个问题我们就需要一个既能很方便的弹性伸缩,又能资源隔离(多租户)的数据库来存储数据,很多分布式数据库都提供了这样的能力
市面上的分布式数据库技术分为两个流派:
1)采用中间件的分库分表方案,比如使用mycat
2)原生分布式数据库,比如国产的有tidb、oceanbase、巨杉数据库等等
分库分表方案在市面上使用很多,尤其在互联网。这种方案的优势是底层采用成熟的传统数据库,所以数据库层面比较稳定,缺点是对应用的侵入性比较强、限制比较多,同时运维非常不方便。
而原生分布式数据库对应用非常友好,在应用看来就是一个单库,无需关心分布式事务、数据存储在哪个节点等一系列问题,同时运维也非常方便,一个DBA可以轻松管理100多台机器构成的集群。因此它的诞生其中一个目标就是替代分库分表方案,而且全球技术评级机构像Gartner、Forrester都从来不会把分库分表方案放到他们的评估列表中。原生分布式数据库同时还提供了良好的弹性伸缩容能力、高可用甚至容灾能力,这也是业界对其比较看好的重要原因。当然目前原生分布式数据库的缺点也很明显:
1)太年轻,与传统数据库相比无论从稳定性(主要指性能,发生bug的概率)和功能性上来说都有一定差距
2)对存储过程、外键、触发器等特性基本不支持
需要避免的坑,我想到的主要有:
1)如果应用大量使用oracle PL/SQL存储过程,迁移会很痛苦,个人不太建议拿这些系统做试点
2)分布式数据库一般都采用两阶段提交,因此效率上会不如单机数据库事务,为了提升两阶段提交的性能,有些数据库会采用乐观锁,乐观锁会出现一些跟悲观锁不一样的行为,因此应用逻辑可能需要调整来适应
3)在分布式数据库上跑中间结果集很大但最终结果集很小的查询效率可能不太好,主要是跨节点传输大量数据导致耗时较长,而传统数据库顶多就是从磁盘到内存这个过程,没有网络IO
4)分布式数据库和传统数据库之间如何做容灾的问题,比如分布式数据库作为主库上线运行了,但是我们担心它会出问题,想利用传统数据库做备库,两者之前的数据同步如何进行,这目前也是我们想要解决的事情
孔再华 数据库运维工程师 , 中国民生银行
现在所有的大行都在实践分布式数据库。
分布式主要解决两个问题。一是性能扩展,弹性伸缩。单机数据库的处理能力是有上限的,尤其是纵向扩展有极限,也不能解决单库的瓶颈。分布式数据库的横向扩展几乎是唯一的解决途径。二是高可用性,单节点的异常不会导致整个集群的损坏,不会影响全局。异常节点的数据和任务能动态漂移,恢复时间短。
然而分布式数据库也存在很多挑战,并不是那么容易实现。分库分表对应用是否透明? 如果从应用角度就开始分,合理开发应用,对于性能来说是最好的方式,但是需要很高的设计开发成本。 如果对应用透明,完全由数据库来做,那么性能可能会成为问题,因为应用会存在夸库事务,存在两阶段提交等。 分布式事务是否支持? 我们会看到接触的大多数分布式产品都支持,然而性能呢,都是问题。在测试的很多分布式数据库,都存在gtm这样的设计,用来协调数据库节点的事务。测试过程中,性能的瓶颈也基本出在这个核心功能上。
因此在上分布式数据库的时候,一定要关注这些点。挑选合适自己的数据库。从性能,高可用,管理性等方面全面评审才行。
undefined 其它 , undefined
一、分布式数据库能解决什么问题?
首先,分布式数据库主要用于解决单机存储上限的问题。如今每天产生各类的数据量非常巨大,如果使用传统方案,要么不便于管理,要么成本过大。
其次分布式数据库可以一定程度分散单节点数据库压力,如读写分离、多节点并行运算等。
最后,某些分布式数据库有多数据中心方案,可以以较低的成本实现数据库层面的多活方案
二、银行在分布式数据库有什么核心诉求?
主要还是看用在什么业务场景,不同的分布式数据库有不通的优缺点和适用场景,这里只讨论厂商原生的分布式数据库。比如有的需要强事务可以考虑tidb,大量的写可以考虑hbase/cassandra,结构常变快速迭代可以考虑mongodb,搜索为主可以考虑es/solr,大量数据缓存可以考虑redis(cluster)等
三、为什么一定要上分布式数据库?
大多数情况是因为单机无法满足存储或性能要求,参考第一问
四、有没有其他的技术路线可以满足需求
公司研发团队自行编写中间件,可以满足需求,只是对研发能力要求较高,需要考虑到各类所需的场景。目前有不少大型互联网公司有采用此方案。
五、如果上分布式数据库,需要避免哪些坑?
1、出于稳定性考虑,最好用官方原始的分布式方案,谨慎选择使用第三方中间件。
2、因为分布式技术要求较高,建议有专人或者供应商进行维护。
3、使用主流的且经过时间考验的分布式方案,某些厂商为了分布式而分布式反而有不少问题。
4、对研发进行相关使用培训,否则性能损耗明显。
5、分布式架构时,某些特性会不支持,需要提前调研。
6、分布式场景下一致性的备份是个难点,不同数据库有不同解决方案。
7、重要数据各分片节点至少有2份或以上冗余,避免数据丢失
岳彩波 产品经理 , 无
一、 采用分布式系统架构是由于业务需求决定的,若系统要求具备如下特性,便可考虑采用分布式架构来实现:
二、 分布式系统遵循几个基本原则
1、CAP 原理
CAP Theorem , CAP 原理中,有三个要素:
一致性 (Consistency)
可用性 (Availability)
分区容忍性 (Partition tolerance)
2.C10K 问题
Amygo 数据库管理员 , oracle
现在我们行领导听到非常多人来沟通说分布式数据库如何好如何有价值,那银行在分布式数据库的核心诉求是什么?
回答:行里有安全可控的技术创新压力;也有业务转型的业务创新压力和合理控制试错成本。
为什么一定要上分布式数据库?
回答:创新就一定要控制试错的成本,及取得更大的行业影响力,要跟上时代的主流,避免技术路线上落后。
有没有其他的技术路线可以满足需求?
回答:不差钱的话,直接上IOE设备,实在不行就上AS400 或S390 ,
如果上分布式数据库,需要避免哪些坑?
回答:关键选对产品,选对厂商。产品一定要有生态链、行业应用案例和主流成熟的技术;厂商一定要专注做数据库产品研发和做到满足行里随叫随到的服务体验。
杨建旭 技术经理 , 中国人民银行清算总中心
1 为什么一定要上分布式数据库?
业务量大了,必须要分库分表。
2 有没有其他的技术路线可以满足需求?
if you know, pls tell me
3 如果上分布式数据库,需要避免哪些坑?
如何分库分表要根据自己业务、技术能力来做。 x轴拆分(水平复制数据库)、y轴拆分(按功能分)、z抽拆分(按用户分)。
杨文云 数据库管理员 , GBS
在当前技术高速发展的背景下,用户选择分布式平台或任何平台方案时应该慎重!因此需要从多个维度对市场上众多的商业和开源产品进行全方位的评估。大致应包括功能、性能、高可用性、可扩展性、开放性、数据加载速度、跨云平台能力、与第三方工具的集成能力、监控管理特性、总体成本等因素。或根据自身需要选择 按 x 轴拆分(水平复制数据库) 按 y 轴拆分(按列功能分) 按用户分类参考选择 ,在分布式系统中,现有市场上有专业大厂提供的多种产品。大致如下:
IBM DB2 DPF
POSTGRESQL citus,greenplum
couchdb
HABSE
MONGODB
redis等
分布式系统产品 国内也有众多厂商如巨杉数据库等各有特点。
从技术角度看,选择分布数据库时,应该着眼于大数据分析和后继的 AI 处理等。因此建议参考以下因素:
对与分布式数据库的选择,就分布数据库集成数据库是一大亮点或特色。
通常不同的业务场景使用不同的数据库处理技术,如 OLTP 、联机分析 OLAP 处理、文本处理、流数据处理、科学计算等都具有不同的特点,
就当前的众多需求和硬件软件技术发展来看,集成数据库( OLTP+OLAP 和其他文本、 GIS 、流数据)平台满足很多市场的需求和场景。
集成数据库的优势:
韩成亮 数据库管理员 , KE
看了上面说的很多,其实讲到底,还是场景问题,核心诉求是满足压力其次考虑现在的瓶颈问题,或者将来可能遇到的瓶颈问题,此外没有说一点要上分布式数据库的说法,这个还是看你们的大致的规划和相应的投入,然后就是分布式讲究的AP/TP 分离或者混合部署,当然混合的往往的来自于业务的耦合情况,根据分布式的基本整体架构,目前的趋势是 计算、存储、调度,各个厂商都有各自的产品,需要进行对应的POC测试,只要经过POC测试才能准确的知道哪些坑,不能一概而论。
以上就是目前本问题的探讨,如果您也想发表自己的观点,请转到该问题下进行讨论
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞4
添加新评论1 条评论
2019-11-13 17:08