江苏龙网

  1. 主页 > 生活百科 > >

透析商业银行在云时代下的数据库需求与选型

云时代

作者介绍
洪烨，多年银行业系统架构设计及DBA实战经验，2013年出版数据库书籍《DB2数据库内部解析与性能调优》 。
伴随着云计算、分布式技术的逐步落地，近十年来数据库的形态也发生了很大变化，各类数据库如雨后春笋般不断涌现 。从架构形态和应用功能的角度来区分，本文将这些新兴的数据库分为三类：分布式、NoSQL及云原生数据库 。
过去关系型数据库滥用的时代已经逐渐结束，分布式、NoSQL及云原生数据库的出现，也带来了如SQL已死、NoSQL或NewSQL取代SQL的等各类声音 。但以目前的发展趋势来看，将来更大可能性是会出现多种数据库共存的情况，各个数据库奋战在最适合的场景下 。
因此，只有先对这些数据库有了深入的理解，才能更好地选择对应的场景 。尤其在商业银行场景下，如何通过这些数据库来更好地实现业务诉求，相信是很多银行仍在持续探索的方向 。
分布式数据库
2000年左右，以Teradata为代表的MPP架构的数据库在数据仓库系统逐步推广；2013年NewSQL一词的提出，标志着分布式数据库开始进军OLTP负载的领域 。随着NewSQL不断发展成熟，出现了Spanner、TiDB等主要代表性的产品 。
分布式数据库主要是将数据分布在多个物理节点上，通过网络传输的方式对多个物理节点进行协调，以横向扩展的方式突破了单机数据库在容量上的限制 。但随之而来也出现了新的问题：如何保证节点间的数据一致性？如何保证多节点对外的事务一致性？如何跨节点实现join、聚合、自定义函数、存储过程等原有的SQL操作？
分布式数据库本质而言还是单机数据库的扩展，如果把单机数据库拆开来看（如图1所示），数据库的核心组件主要分为服务层（提供SQL接口，也称SQL引擎层）、引擎层（实现事务的ACID，也称为存储引擎层）及存储层（实现数据结构及物理存储） 。

透析商业银行在云时代下的数据库需求与选型

文章插图
图1
存储层解决节点间数据一致性问题
横向扩展为了降低成本，通常会采用廉价的硬件，并且由于节点间需要通过网络传输，硬件的不可靠以及网络的不可靠也标志分布式数据库本身就处于一个不可靠的物理环境，需要通过额外的手段提升可靠性 。
目前主流的实现方式都是通过将数据写入到多个副本中，来确保数据的安全，由于网络传输的先后顺序，节点间收到数据同步请求也不一致，如果等待全部节点都同步写入成功，又会对性能有较大的影响 。
目前数据库产品通常采用Raft、Paxos等算法或变种来实现节点间数据一致性，节点间的数据传输通常包含应用数据、元数据及事务日志 。
引擎层保证对外的事务一致性
分布式数据库中不止需要考虑节点内部事务的一致性，更需要考虑全局事务，主流的工业实现在性能以及复杂度权衡，目前基本采用二阶段提交（2PC）来实现 。但二阶段提交的缺陷在于：
在不同的分布式应用架构下，实现一个分布式事务要考虑的问题并不完全一样，比如对多资源的协调、事务的跨服务传播等，实现机制也是复杂多变 。此外，针对全局时钟及序列的实现也是数据库产品的主要关注点 。
服务层实现跨节点的SQL操作
SQL可以按算子处理先后顺序为扫描、关联、汇总三个阶段，基本上所有SQL语句都包含了扫描阶段，部分SQL包含了关联（join）或汇总阶段 。
对于只进行扫描的SQL（就是SET/PUT某个表的一条或多条记录），这种SQL操作比较简单，在分布式数据库中此类SQL的性能关键点往往过滤条件中在于是否包含分布键，以及节点间的数据是否存在严重偏移 。
包含关联逻辑的SQL语句在分布式数据库场景下，需重点考虑SQL是否会引起跨节点的数据传输，是否能够将过滤和join逻辑下推到本地节点处理，通常会对性能产生极大的影响 。聚合操作的SQL通常为group by、order by、having、limit等子句以及聚合函数，数据库在读取数据之后，需要对结果数据在协调节点进行聚合，因此对于协调节点的内存开销较重，协调节点需要能够处理大数据量的内存轮换 。对于以上两类的SQL语句，常见的优化方法包含创建本地表、join下推、排序下推、过滤下推等方式 。
整体来说，分布式数据库的优势在于突破了单机数据库的容量限制，多节点可以实现高并发；而劣势在于，SQL的兼容性较差，落地过程伴随着应用程序改造，并且由于二阶段提交的问题，会导致额外的运维成本 。
NoSQL数据库


推荐阅读


上一篇：千里送绿电，究竟难在哪？

下一篇：中芯国际科创板上市！与浙江的关系超出想象！