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

2010年左右，MongoDB、redis、Neo4j、HBase等各类非关系型数据库的涌现引发了大家对NoSQL的思考，当时也不断有NoSQL会替代关系型数据库的声音。随着近十年来的发展，NoSQL数据库在细分领域表现得非常优异，常见的NoSQL主要包含以下几类：

key-value数据库：一种以键值对存储数据的一种数据库，目前主要代表为Redis 。Redis支持存储的value类型包括string（字符串）、list（链表）、set（集合）、zset（sorted set --有序集合）和hash（哈希类型）。这些数据类型都支持push/pop、add/remove、取交集并集和差集等更丰富的操作，而且这些操作都是原子性的。在此基础上，Redis支持各种不同方式的排序。与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是Redis会周期性地把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave（主从）同步。
文档数据库：面向集合的数据库，无需进行结构定义（简单来讲就是不用创建表就可以使用），以MongoDB为代表。所谓“面向集合”（Collection-Oriented），意思是数据被分组存储在数据集中，被称为一个集合（Collection) 。每个集合在数据库中都有一个唯一的标识名，并且可以包含无限数目的文档。集合的概念类似关系型数据库（RDBMS）里的表（table），不同的是它不需要定义任何模式（schema) 。
图数据库：随着社交、电商、金融、零售、物联网等行业的快速发展，现实社会织起了一张庞大而复杂的关系网，传统数据库很难处理关系运算，以neo4j、ArangoDB等为代表的图数据库满足了此类需求，将结构化数据存储在网络（从数学角度叫做图）上而不是表中。
列簇数据库：大数据的兴起也带动了列簇数据库的发展，主要代表为HBase和Cassandra 。列簇数据库将数据存储在列族中，而列簇里的行则把许多列数据与本行的“行键”关联起来。行是列的集合，由相似行构成的集合就是列族。列族数据库的各行不一定要具备完全相同的列，并且可以随意向其中某行加入一列。

目前而言，NoSQL主要是活跃在擅长的细分领域，但由于架构、成熟度等诸多因素，其在事务的支持上还需进一步完善，并且对于SQL支持度不高，也导致了研发人员额外的开发成本，未来会向哪些方向发展有待观望。
云原生数据库
2015年，全球市场份额最大的云厂商AWS发布了云原生的数据库产品Aurora，提出了log is database的新一代数据库理念，也从性能及可靠性上与RDS形成了差异化。
随后各个云厂商也推出了Aurze SQL Database、PolarDB以及CynosDB等云原生数据库。在将计算和存储等节点分离之后，各模块的性能和弹性就可以各自提升，具备应对大规模存储的能力。
以Aurura为例，通过log is database的设计哲学，将数据的更改变为只写日志，即write-once，极大地降低了数据库的写入操作。同时为了更好地适应云计算，他们认为应该将数据库系统这个“盒子”打开，在不同的层面进行扩展。
Aurora将恢复子系统委托给底层可靠的存储系统，依赖这个来保障系统服务层级（Service Level Agreement, SLA）。使得Aurora在没有引入分布式事务以及无需对应用进行改造的前提下，将性能和弹性扩展能力进行了极大的提升。
商业银行的挑战与选型思考
对于商业银行而言，随着国产化浪潮、线上支付的兴起以及大数据、AI等新技术的成熟，银行IT系统主要发展向着国产化、智能化、服务化的方向演进。银行的IT系统按功能划分大致可以分为四类：渠道服务系统、业务前置系统、账务处理系统、管理信息系统。
渠道服务系统与传统业务相比，已经与各个线上平台进行了相关对接，随着双11、618等各类平台的促销活动，高并发的支撑和资源能否快速弹性扩展成为线上渠道服务系统的必要考量因素。在这种背景下，可以采用基于私有云的弹性扩容以及云原生数据库的极致扩展来应对此类的业务爆发场景。
由于历史原因，核心账务类系统目前大多运行在IBM的大型机或小型机上，此类系统作为银行系统的心脏，并发高、一致性要求高，且兼顾联机交易及批处理场景，随着业务发展，面临着扩容成本高、扩容难度大的问题。
并且随着国际形势的变化，也必将面临着国产化之路，如何将核心数据库从Power 下移到ARM或将成为银行需要面对的课题。由于硬件本身的差异性，如何将现在的传统关系型数据库迁移到分布式数据库也必将是这个课题的核心重点和难点。