深入理解MySQL原理之七--云原生时代将何去何从

落日映苍穹つ 2022-08-31 13:21 190阅读 0赞

# 一、前言 #

云原生是近几年互联网最热的词了，满嘴云原生，才显得有技术担当，格调高。那么什么是云原生，通俗理解，"生在云上，长在云上，也应用在云上"，但是目前为止，没有一个标准的专业定义。综合各家的说法，和水，电做个类比。

1、基础设施云原生，机房，网络，物理机，存储设备等等，这些云计算服务商都是需要考虑的，作为使用方感知不到，也无需关心的，就好像我们使用水，电，从不需要考虑污水处理设备和发电机，这也是云计算基本概念。

2、服务能力的云原生，服务系统部署在云计算上，天生就具有云原生的特征。从用户的角度来看，就是"按需分配，即时即用，按量付费"，没有时间，空间，以及资源的限制，需要多少用多少，什么时候想用就可以用，且只有用到的时候才付费，这也和水，电的服务一样。

要达成这个目标，那云原生需要具备以下能力：

*  高可靠性，系统能长久稳定的运行，具备韧性和冗余性，这个是最核心的要素。
 *  伸缩性，根据服务的波动，动态调整容量和资源，使资源的使用率达到合理的范围。
 *  敏捷性，能快速支持服务的变化和频繁更新，为服务的可持续性迭代提供基础。
 *  可预见性，系统具有预判能力，为一切未来的变化，作为必要的准备。

围绕这些能力，这些年做了大量的革新，涌现了一批新技术和概念，如微服务，docker，k8s，serviceless，servicemesh等。数据库作为核心的中间件，在云原生时代，也必然有所创新。

# 二、群雄逐鹿时代 #

我们来研究下近几年涌现的比较热门的云原生数据库，并了解下云原生数据库应具备哪些特点。

## 1、TiDB ##

TiDB是PingCAP设计和研发的开源分布式云原生数据库，具有水平扩缩容，高可用，实时HTAP，兼容MySQL协议等特点。其整体架构如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RjeTgz_size_16_color_FFFFFF_t_70][]

从架构上看，可以分成如下几个模块：

1.  iDB Server，即SQL层，暴露MySQL协议连接，负责接受客户端的连接，执行 SQL 解析和优化，最终生成分布式执行计划。该层类似于MySQL的引擎层。
2.  PD Server，是整个TIDB集群的中枢神经系统，负责集群的管理和调度。管理方面，存储每个 TiKV 节点实时的数据分布情况和集群的整体拓扑结构，同时收集TiKV 节点实时上报的数据分布状态；在调度方面，根据收集上来的TiKV节点，以及Region的状态信息，结合各种算法和策略，实现最优化调度。
3.  存储节点，提供了TiKV和TiFlash两种节点，TiKV，是一个分布式的提供事务的 Key-Value 存储引擎，可以认为，表中的每行数据，都是一个key-value键值对，key由表号，行号(主键)组合而成，value由每行的列数据组合而成。由多个连续的key-value形成一个段，每个段就是Region，Region是复制和调度的最小单位。TiFlash 是一类特殊的存储节点。和普通 TiKV 节点不一样的是，在 TiFlash 内部，数据是以列式的形式进行存储，主要的功能是为分析型的场景加速。

## 2、PolarDB ##

PolarDB是阿里巴巴自研的新一代云原生数据库，在存储计算分离架构下，利用了软硬件结合的优势，为用户提供具备极致弹性、高性能、海量存储、安全可靠的数据库服务。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RjeTgz_size_16_color_FFFFFF_t_70 1][]

1.   计算存储分离架构，数据库的计算节点（Database Engine Server）仅存储元数据，而将数据文件、Redo Log等存储于远端的存储节点（Database Storage Server）。计算和存储节点之间高速互联，并通过RDMA协议进行传输。
2.  共享分布式存储，多个节点共享一份数据，采用分布式块存储和文件系统，存储容量可以在线水平扩展，存储节点的数据采用多副本，通过Parallel-Rift协议保持数据的一致性。
3.  一读多写，读写分离，一个集群包含一个主节点以及最多15个只读节点，主节点处理读写请求，只读节点仅处理读请求，主节点和只读节点之间采用Active-Active的Failover方式，提供数据库的高可用服务。具备负载均衡能力，通过集群地址，SQL请求自动转发到PolarDB集群版的各个节点，提供聚合、高吞吐的并发SQL处理能力。

## 3、Snowflake ##

Snowflake是一家成立于2012年的创业型公司，2020年上市后市值达到700亿美金，其核心产品就是OLAP的数仓Snowflake，一开始就立志打造一款完全的云原生的Data Clound。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RjeTgz_size_16_color_FFFFFF_t_70 2][]

1.  存储层，存储层使用的AWS的S3对象存储，S3对象存储在性能，成本，高可用，弹性能力方面具有绝对优势，但是也存在延迟大(网络和io)，cpu负载大(http连接)缺点。为了解决这些问题，在virtual warehouse层，snowflake针对热点数据，做本地cache，并采用lru淘汰算法。
2.  计算层，Virtual Warehouse,由EC2组成集群，负责sql的执行，作为无状态的计算节点，根据用户需要，可以快速的扩缩容，当启动一个session，直到有一个Virtual Warehouse绑定到该session，sql才能执行；扩容后， 下一分钟后的新sql或者队列中的sql 就可以运行在扩容后virtual warehouse，当没有query时， 可以将virtual house 进行自动挂起。每个虚拟仓库是一个独立的计算集群，不与其他虚拟仓库共享计算资源，因此，每个虚拟仓库都不会影响其他虚拟仓库的性能。
3.  云服务层，协调整个Snowflake服务的集合，这些服务将Snowflake的所有不同组件结合在一起，以便处理从登录到查询等不同阶段分发的用户请求。包括：

*  认证方式
 *  基础设施管理
 *  元数据管理
 *  查询解析与优化
 *  访问控制

## 4、Aurora ##

Aurora是Amazon 提供兼容Mysql和PostgreSQL 的关系型数据库，专为云而打造，既具有传统企业数据库的性能和可用性，又具有开源数据库的简单性和成本效益。Amazon在SIGMOD 2017发表了论文《Amazon Aurora: DesignConsiderations for High Throughput Cloud-Native Relational Databases》，其中对于Aurora的架构设计做了较为详细的阐述。Aurora是基于MySQL和InnoDB，并采用计算存储分离架构。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RjeTgz_size_16_color_FFFFFF_t_70 3][]

(1)存储层，充分利用AWZ的云的特点，每个段有6个副本，跨3个AZ(每个AZ两个副本)，副本之间采用REDO log复制，解析之后生产页面数据，所有存储层保存的是logging日志以及data数据，相关数据保存到ssd盘，并备份到S3。多个副本之间通过Gossip协议可以保障数据的“自愈”能力。

(2)cache层，传统数据库的cache层，即能向上提供读的能力，提升读取速度，又能向下提供写入能力，将脏页刷到磁盘，减少随机IO操作，Amazon认为磁盘IO不是性能瓶颈(网络IO才是)，所以消除了脏数据刷出的过程，数据缓冲区的作用只是加载数据供上层使用。

(3）计算节点，计算节点负责SQL解析，优化，以及事务处理等能力，采用一主多从架构，主节点负责数据写入，从节点只读，最多有15个。

## 5、小结 ##

我们来小结下云原生数据库的特点。

*  计算和存储分离

欲练此功，必先自宫，每家都不约而同采用了该架构，并认为这是云原生和单体架构的核心区别。分离架构的优势，不言而喻，比如避免了计算和存储一起扩缩容的成本代价，实现了真正意义上的弹性；资源调度更好的与云计算相关工具统一协同，实现计算容器化，存储云化。

但是劣势也是很明显，主要体现在实现技术难度上，分离情况下，磁盘I/O就转化成了网络I/O，如何保证低延迟；OLTP场景下，事务的ACID特性如何保证；故障场景下，如何快速恢复等等，都是必须要解决的问题。

*  分布式

大数据时代，分布式是其核心场景，那么有一统OLTP，OLAP强烈意愿的云原生数据库，分布式也是必然选择，同时这也是符合云计算的理念的。在多个节点的情况下，通过管理和调度，将流量和数据均摊到每个节点，减少由于业务不均衡带来的节点压力；同时，分布式架构也能更好的支持扩缩容。

(3)多副本

多副本确保了系统的高可用和数据的一致性，在故障的情况下，能快速恢复。在单体架构下，也存在从库和备库，但是这与云原生数据库的多副本有根本的区别。云原生数据库是在计算和存储分离的情况下，多副本依赖的底层存储层能力实现，包括数据的同步和一致性。

## 三、MySQL的选择 ##

实际上，这几年MySQL在云原生时代并没有太多的动作，按部就班，貌似事不关己，高高挂起。我想MySQL并不是不想改变，而是有着难言之隐。主要有以下几点：

1、技术上还不成熟，当下云原生的基石是docker+k8s，一开始就是为无状态业务设计，并不擅长处理有状态业务。

2、云环境的多样性，云原生是要求生在云上，长在云上，与云环境的完美融合。目前的云提供商太多，仅头部的就有谷歌，亚马逊，微软，阿里，每家的技术实现差别很大，比如存储。MySQL要能兼容这些云环境，工作量和技术难度都很大。现在更多的是反向操作，每家云提供商积极推出云原生数据库产品，同时兼容MySQL协议。

3、历史包袱重，MySQL基本都用来存储核心数据,比如用户，订单，账单等，架构上，如果没有重大缺陷，一般不能轻易变动，而且也不见得有用户愿意为新架构买单，毕竟稳定压倒一切。

那是不是MySQL在云原生时代就没有任何作为了呢？那倒也不是，我觉得有两个发展途径：

1、大量云原生数据库的的技术反哺，大量云原生数据库涌现并如火如荼的发展，短期内会对MySQL造成了冲击。但是反过来思考，这些云原生数据库何尝不是在做技术探索呢，当技术积累到一定程度，而且用户习惯也养成后，采用拿来主义，一切都会水到渠成，毕竟目前这些云原生数据库都是宣称兼容MySQL协议。

2、基于K8S+Docker的生态尝试，不擅长不代表不可以，现在很多大厂就尝试了MySQL的容器化改造，也有很多较为成熟的方案，比如将存储分离，使用本地存储或者分布式块存储，而计算节点装载到pod，统一调度。但这些方案都有使用环境的限制，比如为了降低延迟，以及满足网络I/O要求，计算和存储节点必须在同一VPC内。

# 四、总结 #

云原生时代，我们即要积极拥抱变化，关注技术的发展趋势，同时也要冷静思考，这些技术会不会对我们的业务有帮助，在当下现实环境下，技术从来都是为业务服务的，毕竟大多数企业要靠业务活着，而不是技术。

可喜的是，数据库技术作为软件行业三座大山之一(操作系统，数据库，编译器)，这些年以PolarDB，TiDB等数据库为代表，国内的大厂在技术上实现了很多突破，Oracle已成为过去式。在云原生时代，我们能否实现数据库技术的弯道超车呢，非常值得期待。

云原生时代的MySQL何处何从，答案就留给未来。

附：

[深入理解MySQL原理之一--如何提升查询SQL的性能][MySQL_--_SQL]

[深入理解MySQL原理之二--如何建立高效索引][MySQL_--]

[深入理解MySQL原理之三--如何实现事务与分库分表][MySQL_-- 1]

[深入理解MySQL原理之四--如何实现高可用][MySQL_-- 2]

[深入理解MySQL原理之五--如何高效利用InnoDB存储引擎][MySQL_--_InnoDB]

[深入理解MySQL原理之六--核心算法有哪些][MySQL_-- 3]

[深入理解MySQL原理之七--云原生时代将何去何从][MySQL_-- 4]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RjeTgz_size_16_color_FFFFFF_t_70]: /images/20220829/e1700b2590b74dc7af46029861d44b6c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RjeTgz_size_16_color_FFFFFF_t_70 1]: /images/20220829/2f6e8be1f6604aeea7e254234f4fa117.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RjeTgz_size_16_color_FFFFFF_t_70 2]: /images/20220829/7136c95d625b4c3eb0501f86323b1d08.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RjeTgz_size_16_color_FFFFFF_t_70 3]: /images/20220829/b6ff3530263b4d94826ba285528f06ba.png
[MySQL_--_SQL]: https://blog.csdn.net/tcy83/article/details/108546004
[MySQL_--]: https://blog.csdn.net/tcy83/article/details/114048168
[MySQL_-- 1]: https://blog.csdn.net/tcy83/article/details/114848104
[MySQL_-- 2]: https://blog.csdn.net/tcy83/article/details/115453583
[MySQL_--_InnoDB]: https://blog.csdn.net/tcy83/article/details/117407724
[MySQL_-- 3]: https://blog.csdn.net/tcy83/article/details/117918385
[MySQL_-- 4]: https://blog.csdn.net/tcy83/article/details/119088747