云计算时代的数据库之战

想要参透云原生数据库，首先要回归产品本身所扮演的角色。如今处理数据不再是仅仅靠算力，主要集中于对智能化算法的研究，而算法又与用户的需求息息相关，进而演进出云原生数据库的框架，即“完整的基础设施云化、核心技术的互联网化以及叠加’大数据+智能化’的平台”。循着云原生数据库的框架再对其进行提炼，核心脉络的三要素逐渐变得清晰，即“云计算在框架中仅作为基础算力；行业算法是智能化处理数据的主要工具；形成’数据+智能花的平台’的前提是基础设施的云化和核心技术的互联网化。”再深入一步思考云原生数据库的模型，不难联想到原生数据库所扮演的其实是“数据中台”的角色。

那么，什么是“数据中台”？即通过数据技术，对海量数据进行采集、计算、存储、加工，同时统一标准和口径。数据中台将数据统一之后，会形成标准数据，再进行存储，进而形成大数据资产层，从而为客户提供高效服务。以阿里云 PolarDB为例，其在原有的RAFT协议的基础上开发了一种全新的共识协议（ParallelRaft），在保障数据一致性的前提下，遵从共识协议提升了PolarFS并行写入性能，在高负载情况下，达到平均延迟缩短一半、系统吞吐量翻倍的效果。这也解释了为什么PolarDB不再是一件单一的产品，而是充当一套完整的生态框架协助企业将数据库迁移上云。对此，阿里云数据库产品总监曹伟对钛媒体表示，“提供智能是数据库的未来发展方向，PolarDB将在后续版本中继续围绕“数据中台”这一概念，向用户提供多维分析和分析计算能力。”

与此同时，厘清云数据库的架构方向也是理解云数据库本质的关键所在。当下多模架构成为云原生数据发展的主流趋势，即在一个数据库平台支持多种存储方式，包括满足应用程序对于结构化、半结构化、非结构化数据的统一管理需求。一般来说，结构化数据特指表单类型的数据存储结构，典型应用为银行核心交易等传统业务；半结构化数据则在用户画像、物联网设备日志采集、应用点击流分析等场景中得到大规模使用；而非结构化数据则侧重于海量的的图片、视频、和文档处理等业务，主要应用在金融科技方面。多模架构在降低使用和运维的成本同时，也完成跨部门、跨业务的数据统一存储与管理，从而实现多业务数据融合，支撑起多样化的服务。

此外，“计算-存储层”分离现已演进成主流的技术方向。那么，何谓“计算-存储层”分离？即将协议解析、计算等模块与底层存储解耦，数据库云平台再将存储层进行分片以实现存储的弹性水平扩张，同时通过计算层的无状态设计允许计算层通过增加节点数量线性提升计算能力，从而整个数据库云平台的弹性水平扩张。简而言之，是指数据库的存储引擎和SQL引擎两部分互相松耦合独立工作的架构。

一般来说，这种类型的分离架构由存储、SQL和元数据三个模块组成。存储层是数据库的存储引擎，负责处理数据的存储管理，同时包含路由及事务控制，保障数据的ACID特性，除此之外，存储层还应还具备索引、查询条件过滤、排序等一系列功能；SQL层为中间件层，主要负责处理SQL请求，上层对接应用程序，将应用程序的访问请求分发给存储层，并接收存储层返回的数据结果；而元数据区负责存储整个数据库的所有元数据信息。目前AWS Aurora在SQL访问的单一过程上也采用了类似的架构。

数据来源：安信证券研究中心整理

无独有偶，阿里云 PolarDB通过利用高速网络做到分布式共享存储，从而达到“计算-存储层”全面性的分离。这种分离架构到来的直接影响是对存储节点和技术节点进行弹性索扩容，缘由技术节点具备一写多读的功能，进而满足云原生数据库时代用户在云上按需、按量使用、极致弹性等一系列在“马车时代”的传统数据库所不能提供的服务。正是基于此架构的上的技术优势，让阿里云 PolarDB在sysbench（一款开源的多线程性能测试工具，可以执行CPU/内存/线程/IO/数据库等方面的性能测试，目前是业界标准的测试评估工具）中拔得头筹——“与传统数据库相比，阿里云 PolarDB多达十倍性价比；与国外领先的厂商（如AWS Aurora）相比，阿里云 PolarDB在某些情况下性能达到前者的两倍。”

若技术层面来分析，阿里云 PolarDB采用的计算和存储分离架构让“计算—存储”资源池化。数据库通过计算节点运转，计算节点则组成了计算资源池；数据都存储在存储节点之上，同时存储节点也组成了一个存储资源池。当CPU和内存不能匹配需求时，可以扩充计算资源池，当容量或IOPS（每秒进行读写）不能匹配需求时，则可扩充存储资源池，这两个池都是按需扩容，而且存储节点和计算节点可以沿着两个方向进行优化。

反观传统数据库部署模型则是一种烟囱模型，一台主机既要跑数据库又要存取数据，性能交叉之下带来两个问题。其一，缘由CPU和磁盘的配比主要取决于实际业务的需求，很难提前找到最优比例，直接导致难以选择最为匹配的机型；其二，带来了磁盘碎片问题，在一个生产集群中存在部分使用率极低的机器磁盘，有的甚至不到10%，但出于业务稳定性要求，这些机器磁盘会独占主机的CPU，对于主机的资源分配来说，这是一种极为奢侈的资源浪费。通过存储资源池化，这两个问题都能得到解决，SSD的利用率得到提高，成本自然也降低下来。

若从存储成本的只读实例来分析，缘由传统数据库做只读实例。所谓的实施“一写多读”方案，即通过搭建只读副本的方案，先拷贝一个最近的全量备份恢复一个临时实例，紧接着让临时实例连接主库或者其它binlog（二进制日志）源同步增量数据。当数据增量追上时，则将临时实例加到线上升级为一个只读副本。这种方式存在两个问题，一方面是耗时，搭建一个只读实例需要的时间往往与数据量成正比；另一方面费用昂贵，这其中需要增加一份存储的成本，例如当用户购买一个主实例加上五个只读实例，则需要付7~8份存储的钱（其中是7份还是8份主要取决于主实例是两副本还是三副本）。

（编辑：应用网_阳江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!