---
title: '观点 | 金融行业数据库的选择'
date: '2023-08-28T16:51:04+08:00'
status: publish
permalink: /blog/selection-of-financial-industry-database
author: '周, 盛虎'
excerpt: 库里南作为豪车已经称霸多年。同样，数据库领域的Oracle也是豪车级的“库里南”，是集中式数据库的天花板。但是，面对异军突起的分布式数据库，在自主创新的环境下，我国自主研发的数据库能否厚积薄发成为“库里南”，将面临时代的考验。
type: post
id: 5814
category:
    - 观点洞察
tag:
    - HTAP
    - NewSQL
    - 金融
post_format: []
profile:
    - 邵健
---
> 本文转载自微信公众号《金融电子化》，作者为杭州银行信息技术部邵健。

库里南作为豪车已经称霸多年。同样，数据库领域的 Oracle 也是豪车级的“库里南”，是集中式数据库的天花板。但是，面对异军突起的分布式数据库，在自主创新的环境下，我国自主研发的数据库能否厚积薄发成为“库里南”，将面临时代的考验。

金融行业数据库发展状态分析
-------------

数据库技术产生于 20 世纪 60 年代末 70 年代初，关系数据库模型初期在 1970 年由 IBM 研究员 E.F.Codd 博士率先提出，之后成为数据库领域主流模型，其主要研究数据如何管理、存储和使用。随着时代的快速进步，计算机硬件和软件技术快速迭代，数据库的创新技术也不断蓬勃发展，在理论研究和系统开发上都取得了辉煌的成就。在当下，用户希望关系数据库稳定运行的同时，能够横向扩展，能够无限大、无限快。

在目前市场上，数据库特指占市场主导地位的传统 OLTP（联机事务处理）领域的关系数据库。只有这个产品，才是困扰我们多年的，无数人为之尝试的数据库产品。

依据数据模型发展的主要路线，数据库技术的形成过程和发展历程可主要分为如下几个重要阶段。

### 关系型数据库

关系数据库可以理解为使用二维表来表示。维护数据间的关系优点是满足 ACID 原则，严格遵守数据完整性约束，保证数据一致性；具有标准化语言 SQL。面对事务处理和分析决策的需求，OLTP 事务型数据库和 OLAP 分析型数据库应运而生。

（1）OLTP。OLTP 数据库发展初期更多属于集中式数据库。OLTP 业务系统必须保证数据强一致性，通常使用关系型数据模型，支持多并发、快速实时地实现增删查改。集中式 OLTP 数据库的局限性是缺乏横向可扩展性，需要解决跨服务器扩充的问题，海量数据和高并发条件下读写效率较低。

（2）OLAP。系统可从多种维度并且高速分析来自数据集市、数据湖的数据，主要面向分析师和管理者，支持对历史数据的复杂分析操作，OLTP 是指业务在线交易系统，OLAP 是指业务分析系统。OLTP 和 OLAP 是相辅相成，互相补充的过程，同时 OLAP 多采用 MPP 架构。

### NOSQL 非关系型数据库

针对关系型数据库存在数据模型、性能、扩展性、伸缩性等方面的缺点，出现了 NoSQL（非关系型数据库技术）。NoSQL 泛指非关系型数据库，其中典型的以 Key-Value 为主要模式。NoSQL 数据库重点解决了传统关系型数据库硬件垂直扩展的局限性。通过分库分表方式实现水平扩展。在互联网行业中，基础平台追求省钱，不会去买商业化的产品。数据的操作模式很简单，而 NoSQL 因为简单所以最先能够无障碍搭建分布式环境，能够得到广泛使用。笔者认为，它不是数据库发展的后继力量。如：内存数据库（Redis）、列式储数数据库（HBase）等。其优点是可扩展性高，在牺牲一致性的前提下，通过横向扩展提高可用性，无明显的单点故障。缺点是在数据一致性方面有所牺牲；SQL 标准化有待完善；事务的一致性无法保障，无法满足 ACID 特性。

### NEWSQL数据库

NewSQL，新一代数据库技术的研究和发展。2011 年前后，451Group 的 MatthewAslett 首先提出了 NewSQL 定义，用来表示新型、可横向扩展的关系型数据库。其中，大多 NewSQL 数据库有两个特点：其一，保持 NoSQL 数据库的高性能和可扩展性；其二，必须保证事务的 ACID 特性，保证事物的一致性。采用标准 SQL 为主要接口的关系数据模型。如：TiDB、OceanBase。

下面再来分析 NewSQL 数据库的分类：原生分布式和中间件（非原生）分布式。

对于金融机构而言，随着时代的发展，大数据分析潜力无限，特别对数据库“强一致性、高可用性、低时延性”的要求更为苛刻，同时众多金融机构将分布式数据库纳入下一步选型的重点。分布式数据库选型主要遵循“原生分布式”和传统的“中间件+分库分表”。基于中间件分布式数据库优点在于：方案成熟；整体性能类似于单机数据库，适用于金融机构低延时的要求。缺点在于：对业务开发的侵入强、不透明，开发工作量庞大；拓展性较差，数据分片后静态、不可变；中间件负担过重。

原生分布式数据库完全抛弃小型机体系，从底层全新研发，具有分布式数据库的高并发处理能力、高可用、高可扩展性，且对用户透明管理。采用计算、管理、存储分离的系统架构。实现计算下推到存储节点的特性，提高了响应效率，实现各层独立扩展、按需配置硬件设备的特点。优点在于：数据分片能够依据热点自动平衡到不同节点；业务开发没有侵入，研发人员专注于业务开发；利用计算下推的强大能力，多个节点并行计算，提高业务处理效率，满足轻量级实时分析。缺点是：架构较新，实践案例相对较少；基于 CAP 理论“扩展性、可靠性、性能”三者只能同时满足两个；存算分离的架构，对运维人员要求较高。

将传统关系型数据库（集中式）、NOSQL、NEWSQL 从横向进行的一个比较（如表所示）。

表 传统关系型数据库（集中式）、NOSQL、NEWSQL 横向比较  
![数据库对比](https://img1.pingcap.com/files/2023/12/20231210085552321.png)

### HTAP 数据库

HTAP 是混合 OLAP 和 OLTP 业务同时在线处理的系统，2014 年由 Gartner 公司提出，它打破了事务处理和数据分析之间的壁垒，支持业务在线信息处理和业务分析决策同时进行。

由于 OLAP 型数据库大多需要离线将 OLTP 数据导出，这就会造成数据时效性的降低。一些对决策时效性要求较高的场景就会对 OLTP 和 OLAP 混合的数据库需求较大，所以衍生出了 HTAP 数据库，其数据的存放方式大多为行列混存方式。

分布式和集中式数据库的抉择
-------------

综上所述，集中式数据库与分布式交易数据库的处理性能、硬件扩展性，存在较大差距。这个性能差距存在的前提是“数据量”。在几亿数据量的级别下，集中式数据库通过数据压缩和服务器内存、CPU，完全能够将这些数据存储在单台服务器的存储或者内存中。这种情况下，分布式数据库的二阶段提交执行的代码、网络开销都会对事务提交造成极大的延时。

分布式数据库主要场景应用于单台数据库无法处理海量数据，对并发要求高，分布式数据库是这类需求的绝佳选择。这类业务的数据量往往以数百亿甚至达到万亿级别。

笔者认为，如果应用数据量并不大，一个集中式数据库实例就装得下，并且传统关系型数据库架构的性能足以应对数据访问负载，那么就不需要使用分布式事务，从而获得更好的性能。在数据量、业务并发量可控的前提下，集中式数据库可以带来更低的响应延迟，减少投入成本，从而获得最大性价比。如果业务系统集中式架构就可以完全满足，却选择了分布式架构，无形中就会多投入很多服务器资源，而分布式数据库更契合于海量数据（数亿甚至达到万亿级别）、计算资源、存储资源的扩缩容能力是集中式数据库所不具备的。千万不要为了分布式而分布式。

金融行业数据库未来发展趋势
-------------

### 趋势一：HTAP

OLTP→OLAP→HTAP (混合型)：融合 OLTP 和 OLAP 的 HTAP 发展迅速。大数据时代数据价值深入挖掘，更多企业对数据库系统也提出了更高要求。当前阶段，企业为满足业务需求，最为常用 OLTP 结合 OLAP 的组合拳，但两套系统之间数据交互延时的壁垒无法避免。同时还需要管理两个数据库平台、投入更多硬件设备、组建两支技术团队，运维成本高。HTAP 混合型数据库，基于全新存、算分离部署架构，能同时处理 OLTP 和 OLAP 两种业务能力，规避了传统架构模型中，大数据量传输造成的硬件浪费和响应延迟。同时基于分布式架构，可在线按需扩展存储和计算资源，应对高并发、海量数据场景。

笔者相信，国内数据库未来是分布式与集中式并存，HTAP 是未来的趋势。

### 趋势二：开源

2021 年 3 月，开源正式被列入“十四五”规划发展纲要。从产业发展角度来看，一方面开源社区汇聚了全球的技术力量，有助于产品的技术创新，为技术交流提供空间，加速企业创新能力诞生；另一方面提高了数据库产品开发的效率，提高了基础程序的共享、复用。对于系统厂商而言，虽然表面上看，企业推进开源要投入大量技术力量，而且不能获得直接的利润，但在这个过程中，可以布局软件产品的生态圈，包括教育培训、实践反馈、产品影响力、配套周边产品等，从而在战略上占据有利的地形。如果不选择开源，一来传播速度会很慢，二来用户的信任成本会很高，最致命的是用户的增长并不会是一种病毒传播式的增长，进而导致产品的迭代速度会变得很慢。数据库产品作为一个“需要被用出来”的基础软件，只有产品不断迭代，才能逐步完善。