数据库是应用开发中非常重要的组成部分，可以进行数据的存储和管理。随着企业业务向数字化、在线化和智能化的演进过程中，面对指数级递增的海量存储需求和挑战以及业务带来的更多的热点事件、突发流量的挑战，传统的数据库已经很难满足和响应快速变化和持续增长所带来的业务诉求。伴随云原生理技术的不断普及，在数据库这个维度上也带来了巨大的变化。那就是云原生数据库技术的出现和被普及。
云原生数据库是一种通过云平台进行构建、部署并交付给用户的云服务，它专门为云环境设计的数据库，它可以自动扩展和缩减资源，提供高可用性和数据安全性，同时支持多种数据模型和编程语言。相对于传统数据库，它最大的不同就是以云原生的形式进行交付，它具备传统数据库所不具备的直接访问性和运行时的可伸缩性，属于 DBaaS 平台（DataBase as a Service）。
1、云原生关系型数据库
关系型数据库在当前软件研发领域一致都是最主流的数据库类型，而云原生关系型数据库在其架构上有着非常大的优势，具体体现在：
资源池化、大容量、高性价比
传统关系型数据库需要自行适配硬件，如果要扩展，需要购买设备。而云原生数据库从一开始就充分享受了云平台的各种技术优势，资源共享池化，可以存储海量的数据，同时提升了资源的利用率，让小公司也可以享受到像 BAT 这些大公司才能使用的先进硬件及部署环境。所使用的资源可以按需付费，只需要对使用的部分买单即可，降低了成本。
提供极致弹性
云原生数据库可以实现计算和存储分离，CPU、内存和存储这些都可以独立弹性，支持独立扩展，变配速度快，可以满足不断变化的多种业务需求，实现完全 Serverless 化。
强大的容灾能力和可靠性
云原生数据库充分利用强大的云基础设施，提供跨节点容灾支持。
云原生数据库充分利用新技术新硬件，比如，利用 RDMA（Remote Direct Memory Access，远程直接数据读取）技术实现分布式共享存储，通过数据的多副本技术提升容灾能力。
云原生数据库充分提升跨区域的复制能力，提升高可用能力，保证用户业务的可用性。
完全托管
云原生数据库完全托管给云平台，用户无须负责硬件的购买和部署、软件错误的修复、实例参数的配置、监控的开发、数据的备份和管理等工作。
智能化和自动化的管控平台
云原生数据库将机器学习、人工智能技术与数据库内核相结合，使得数据库更加智能化和自动化，实现自感知、自决策、自恢复和自优化。
2、云原生数据库技术分析
云原生数据库一致持续进行着技术演进。在硬件资源方面，CPU/内存/存储的独立资源化对资源间的互联提出了很高的要求，各个节点之间，包括存储节点、计算节点甚至内存池节点的互联，都需要高性能 RDMA 网络甚至其他新总线的支持。在软件方面，因为资源的池化并不能在操作系统层面实现完全透明，数据库需要对功能模块进行拆分和重构，以实现不同的组件通过高速网络在不同的物理机的互连和运行，从而实现性能的最大化。
OLTP 数据库作为一个整体，需要在资源分离的情况下，对外保证 ACID（原子性、一致性、隔离性和持久性）和外部一致性，因此需要高效的分布式缓存、分布式锁和分布式事务机制来保证读写的快速弹性和整体的高性能。另外，在保证正确性的前提下，需要减少节点之间数据日志的通信量。
基于阿里的 PolarDB 对云原生数据库的核心技术进行分析如下：
计算存储分离技术
云原生时代要求数据库具备海量的计算能力和数据存储能力。在这样的场景下，传统数据库的计算和存储耦合架构的缺点逐渐暴露，
- 资源浪费：计算能力、存储能力达到瓶颈，虽然这两种情况往往不会同时发生，但单纯增加机器必然导致资源浪费
- 扩展麻烦：在计算和存储耦合的模式下，如果单纯增加设备，总会或多或少衍生出数据迁移和系统重新配置的问题，扩展能力弹性不足
计算和存储耦合架构在云原生时代暴露出了缺乏弹性的严重问题。而在云原生数据库中已经实现了存储资源的独立扩展。基于分布式存储的云原生数据库 PolarDB 就已经实现了存储资源的池化及独立扩展。
计算和存储分离架构为云原生数据库带来了计算和存储上的实时水平扩展能力，实现了计算能力上的极致弹性。由于单个数据库实例的计算能力有限，传统做法往往是通过搭建多个数据库副本分担压力，从而提供数据库扩展能力。然而这种做法需要存储多份全量数据，日志数据频繁同步造成了过高的网络开销成本。同时，在传统数据库集群上，增加副本需要同步所有增量数据，这又带来了同步延迟上涨问题。所以，PolarDB 采用了共享存储集群的数据架构，实现多个计算节点可以挂载同一份存储。计算节点可以单独扩展，支持一写多读集群的部署，且提供读扩展能力，支持在分钟级扩展到15个读节点。
PolarDB 的系统架构图如下：
（图片来自于网络）
计算内存分离技术
计算和存储分离的云原生架构虽然实现了计算和存储资源的独立弹性，但计算节点仍然包含 CPU 和内存，无法实现这两者的秒级弹性扩容收缩。与此同时，在很多业务场景下，这两者的业务需求很不一样，所以云原生数据库也在尝试计算和内存的分离技术。
具体实现的核心点一般包括：
- 缓冲区通过单独进程进行管理，允许页面缓存独立于数据库。在出现数据库故障时，页面缓存将保留在内存中，确保数据库重启时不用重新加载数据，而是直接使用最新状态预热缓冲池
- 保留数据库实例崩溃前的数据内存状态
- 数据库崩溃重启时不必再执行“故障恢复”的过程（即回放日志以保障数据的一致性）
除了独立缓存技术，PolarDB 在 CPU 和内存分离方面有一些它独特的创新技术：
- 数据库实例的 CPU 和内存资源可以部署在不同的物理机上，并通过 RDMA 高速互联。因此，CPU 和内存资源占比不再固定，而是可以根据业务负载动态变化。所有 CPU 和内存资源都可以在集群资源池的维度进行分配，利用业务的错峰和水位，有效提升资源的利用率，降低整体成本
- 引入了独立的分布式共享内存池。在此架构下，同一个数据库实例的内存可以由位于不同内存节点上的多块内存组成。因此，缓冲区的大小不再受物理机限制
- 在 CPU 和内存分离后，PolarDB 的计算进程不再包含大量内存，而是只有少量高速缓存。这使得计算进程变成了无状态的节点，从而实现了快速的跨物理机弹性
高可用及数据的一致性
高可用率和灾难恢复能力是数据库的重要考量因素。云原生数据库通过多副本技术确保数据的可靠性。
PolarDB 通过 PolarFS 分布式文件系统实现了数据多副本及一致性。PolarFS 是国内首款面向 DB 应用设计的、采用了全用户空间 I/O 栈的低延迟高性能分布式存储系统。PolarFS 对 Raft 协议进行了优化，实现了 Parallel-Raft 算法，大幅提高了数据同步保证一致性的能力，以分布式集群的方式提供了优异的存储容量与存储性能的扩展能力。在一个主集群三个副本的基础上，PolarDB 还包含了一个跨机房的备节点，以提供多机房容灾能力。
（图片来自于网络）
PolarDB 在存储层（PolarStore）提供了三个副本的同时，还通过自研的 x-Paxos 库提供了跨节点、跨机房的数据同步，以此提供跨 AZ 级别的容灾、RPO=0 的解决方案。这个方案利用 PolarDB 自主物理复制能力，提供更可靠、更低延迟的复制。相比 RDS 和 MySQL 的逻辑日志复制，PolarDB 在节点切换时，受大事务、DDL 的影响更小，且可以保证 RTO 小于一分钟。PolarDB 三个节点分别用于部署 Leader、Follower 和 Log 节点。其中，Log 节点只记录日志，不参与选主，不存储数据，部署成本相比现在的架构多了 Active Redo Log，但成本增加很少。
（图片来自于网络）
数据及日志的复制技术
PolarDB 为代表的云原生数据是基于 MySQL 发展而来的，MySQL 数据库多采用逻辑日志和并行回放技术以提升备节点的性能。然而，逻辑日志只能在事务提交时产生，备节点也只能在主节点完成提交后才能在本地状态机中回放出主节点的状态。一旦遇到较大的事务，这种主备之间的延迟将会非常明显。另一方面，虽然 MySQL 具备并行回放能力，但由于回放的并行粒度较大，因此常受限于实际的使用场景。如在单表更新频繁的场景中，实际上备节点只能做到串行回放。同时，采用共享存储架构，虽然多个节点是读取同一份存储数据，但各个计算节点的 in-memory 数据仍需要保持一致，这个“物理”的数据一致性是逻辑复制无法做到的。所以，要想从根本上解决该问题，势必需要将逻辑日志复制演进为物理日志复制。物理日志即在数据库更新时产生的写前日志，这种日志一般针对数据库页面修改而产生，每个页面的修改对应于一条或者多条日志项。如果复制物理日志并在备节点上回放，那么数据库就具备了复制内容少、备节点上可执行更细粒度的并行回放（可以页面为粒度进行并行回放）等优势。
PolarDB 从架构设计开始就纳入了物理复制的思路。在代码实现中，PolarDB 在内核层面实现了大量优化，从而可以更好地适配 PolarFS 和 PolarStore。比如，在 Redo Log 中加入一些元数据，以减少日志解析时的 CPU 开销。这个简单优化减少了 60% 的日志解析成本。另外，PolarDB 也重用了一些数据结构，以减少内存分配器的开销。
（图片来自于网络）
跨地域高可用技术
随着数字经济时代的到来，越来越多的商业行为逐渐数字化，这就对互联网基础设施提出了越来越高的要求。数据库作为最基础的服务设施，需要达到数据零丢失、服务零间断等标准才能在最极端的环境下满足业务最苛刻的需求。为满足双零需求，在设计上，数据库架构多采用异地多活的部署模式：将数据库系统跨越一定的物理距离部署在多个地域，要求多个地域内的数据保持一致，并在某个地域发生故障时可以切换到另外一个可用域，且该切换要做到数据不丢失、应用无感知。同城三中心、跨城五副本等架构正逐渐成为业务标配。在这些需求下，云数据库不但要做到地域内的多节点和多副本，更要支持跨区域的多点复制、迁移和服务功能。
为了解决跨地域高可用的强需求，全球跨地域部署的强一致高可用解决方案不断涌现。 PolarDB 推出了全球数据库（PolarDB Global Database Network，PolarDB-GDN）解决方案，目前已覆盖全球 10 余个地域。PolarDB-GDN 主要解决了跨地域的数据读写问题和高网络延迟下的数据同步问题。全球数据库内的主集群与只读集群间采用了高速并行物理复制的技术，所有集群间的数据都保持同步，且在全球范围内的延迟控制在2秒之内，这大大降低了非中心区域应用访问的读取延迟。
Serverless 及多租户技术
云原生数据库的一个特点是能够提供按需分配的资源。随着资源的完全池化，整个数据中心（甚至多个数据中心）相当于现在的一台物理机，上面只有一个多租户的云原生数据库，每个用户都可以不受限制地扩展其读写能力：一个用户可以瞬间使用大量 CPU 或内存资源支撑起业务高峰。因为所有资源的完全池化，CPU、内存、存储使用率均可达到较高水平，所有资源都按量计费，相同的服务器资源可以支撑更多的用户业务，从而提升产品的竞争力。
HTAP
传统的企业数据库系统根据其主要功能和性能不同，可分为 OLTP（OnLine Transaction Processing，联机事物处理）系统和 OLAP（OnLine Analytic Processing，联机分析处理）系统。在传统数据库架构中，OLTP 数据库和 OLAP 数据库是完全分离的。随着新业务需求的不断衍生，OLTP 数据库往往还需要具备执行一些分析类 SQL 查询的能力。对分析需求不高的业务，企业可以节约极大的数据库成本。兼具 OLTP 和 OLAP 能力的 HTAP（Hybrid Transaction/Analytical Processing，混合事务/分析处理）系统已成为数据库发展的重要趋势。目前，越来越多主流的 OLTP 数据库加强了其执行复杂 SQL 的能力。可以预见，OLTP 数据库将持续在执行框架、数据格式、副本形态、软硬件设计等方面加强执行复杂分析 SQL 的能力，成为兼具 OLTP 和 OLAP 能力的 HTAP 数据库。
3、云原生多模数据库
随着业务的不断多样化，应用对于数据的多类型处理能力提出了新的要求，而传统多套系统组合解决方案又具有架构复杂、维护成本高、起步门槛高等痛点，使得企业对于数据库系统提供多模能力的诉求越发凸显。
为了适应不断演进的业务需求，云原生 NoSQL 数据库必须具备多模的能力，成为云原生多模数据库：实现一种数据库服务多种数据模型的能力，并内置数据模型的转化与统一的访问语言。
主流 NoSQL 多模数据库的实现方式通常是先将数据模型抽象为 KV 数据，再由 KV 数据通过存储引擎存储于硬件介质之上。以 KV 数据抽象为基础实现多模能力，工程复杂度低，但对于时序或者图这类具备显著数据特征的数据模型来说，却不能最大程度地发挥其能力优势。
4、数据库安全
数据安全是企业的生命线，而数据库又是对最核心数据进行计算和存储的部分，所以数据库在企业中通常处于最核心的位置。从机房、网络、服务器、数据交换设备、操作系统、应用程序到数据库自身，数据库所处的环境异常复杂，安全隐患非常多。在传统线下环境中，要想完整建设如此多环节的安全体系，从成本、可运维性、稳定性角度而言，所面临的挑战非常大。同时，安全能力的迭代和运营也需要持续进行，稍有不慎就会导致数据泄露和数据破坏的问题发生。
随着云原生数据库的普及，数据库安全机制云原生化的需求日益强烈。相比传统云下数据中心，云原生安全体系具有开箱即用、可弹性伸缩、自动进化与修复的能力。从安全漏洞、数据破坏等角度出发，云原生保护能力比传统线下基于边界的安全形态更有优势。云原生数据库在敏感数据加密能力上提供了全链路端到端的加密手段，以针对服务面和控制面的内外部人员操作进行全面的访问授权、审计和监测，对审计日志提供基于区块链技术的防篡改能力，使云原生数据库更加安全与可信。
版权归原作者 灸哥漫谈 所有， 如有侵权，请联系我们删除。