Database-对数据库架构设计及结合计算型存储的思考

最近在看市场上一些NewSQL的构建和设计思路，但其本质上都是对目前常用开源数据库在架构上的拓展以及结合新的底层通用技术（例如可计算存储）实现的优化。在面对互联网的高并发和海量数据，传统的做法是在架构层面做出一些拆解，应用拆成了数个子系统，数据库也一样拆成了数个单一的数据库实例来应对计算和存储的瓶颈，从单体数据库，到主备来做高可用，再到Oracle RAC的多写，再到完全分布式架构的数据库，相应的，这些带来了更复杂的分布式服务间的通信调用、分布式事务、cache一致性和如何便捷维护等问题。

这篇文章我们不去重点谈阿里的PolarDB或者Amazon Aurora具体是如何设计和实现的，只谈现在的一些数据库系统是如何在架构设计和结合底层用的存储技术来面对典型痛点和瓶颈的。

数据库系统面临的瓶颈

我们假定有一套数据库系统，正常配置和使用索引的情况下随着数据量和用户量的增加带来的一些问题：
1、存储空间不足
2、内存不足
3、IO出现瓶颈
4、高并发负载过高
5、大事务导致的性能太差

针对以上问题，我们常用的做法：
1、存储硬件：更换容量和吞吐量更大更快速的存储硬件
2、数据拆分：数据库分库分表垂直/水平拆分打散压力
3、横向扩展：多个数据库实例均衡数据存储和计算
4、读写分离：常见一写多读，在读多的场景下扩展读的能力
5、设置缓存：各种缓存数据库，冷热分离

以上的做法其实并没有解决最根本的原因，虽然在这个架构演进过程中出现了中间件去包裹数据路由逻辑来对应用端透明的做法，但还是在一定程度上增加了系统的复杂度和信息系统的投入。
从低耦合高内聚，到系统变得庞大而引起的各类问题，于是出现了SOA、微服务等软件设计方法，出现了raft、zab等分布式协议和算法，但在底层技术没有大的突破的今天，面对用户量和数据量激增，架构演进的思路始终是在系统的拆分和处理由于系统的拆分带来的分布式调度和成本问题，但最根本的问题仍在于IO的瓶颈。

如何解决这些问题

下面从各厂商的数据库架构设计和应用计算型存储底层技术两个方面来说明。

数据库架构设计角度

先从数据库架构设计的角度来谈一谈如何解决以上的瓶颈问题。

计算和存储分离

计算存储分离的主要目标在于可以解决计算层和存储层弹性扩展的问题，即计算层和存储层可以独立的scale-up和scale-out。
由于所有的数据库实例共享同一份分布式共享存储，在实例发生故障或节点扩展时就不需要进行数据的拷贝。同样的，存储层的节点扩容也不会影响到计算节点。

数据库举例：阿里的PolarDB

日志下推

日志下推的主要目标在于解决性能问题，将日志下推到存储层进行。
在MySQL的写机制中，单实例MySQL的写操作会导致日志落盘，同时会有后台线程对于buffer pool中的脏页异步刷盘，在刷盘时为了避免页断裂导致原子性遭到破坏，在这个过程中，还会将页写进double write缓存中。

这里典型的使用日志下推的数据库是Amazon Aurora，Amazon将wal日志同步到所有节点，使用自己的EBS存储进行同步，不再需要MySQL参与，也不再需要脏页刷盘和二次写，并且将recovery的逻辑下移，可实现快速拉库。

日志和数据分离

对日志下推进一步的演进可以形成日志和数据两个存储池。
在日志和数据分离的架构中，日志池和数据池物理隔离，这样写入更为可控，可单独对日志池采用AEP存储加速，写操作到日志池就可返回，在日志apply到数据池时，并不会影响写操作，以此取得更高的性能。

嵌入底层存储引擎

举个例子：在TiDB 架构中， SQL 层和 KV 存储层分离，最底层是选用了当前比较流行的存储引擎 RocksDB来进行高效的压缩来减少存储空间的使用和更高的IOPS、更少的写磨损。

计算型存储带来的改变

信息系统的使用始终是要落在存储上，纵观现代存储技术的发展，从机械磁盘到SSD，从单一磁盘无法并行传输到RAID条带化带来的更大容量和速度，计算机内置存储–>外置存储–>外部独立磁盘阵列–>网络化独立磁盘阵列–>瘦服务器主机、独立NAS等，其中接口和协议都在变化以适应和不断提高独立存储的容量和性能。
计算型存储是一种新的发展趋势，何谓计算型存储呢？所谓计算型存储指的是一些数据处理的任务交给存储层来做，而不是把数据挪到主内存里用主机的CPU来处理，因为把数据从存储的地方迁移到计算的地方这一过程是耗费时间效率低下的。将计算和存储环节逐渐分离，让CPU更关注CPU本身的计算，将最合适的任务交给更适合的处理单元。
计算型存储可理解为在存储介质上加上计算单元，
结合数据库层面，可从以下几点来看计算型存储是如何结合数据库原理提高性能的。

数据库和存储原子写

原子写的概念与数据库的ACID的原子性有关，表示组成一个事务的多个数据库操作是一个不可分割的原子单元，只有所有的操作执行成功，整个事务才提交。事务中的任何一个数据库操作失败，已经执行的任何操作都必须被撤销，让数据库返回初始状态。也就是说，数据要么全部写入，要么全部没有写入，不存在部分写入的情况。
当数据库正在从内存向磁盘写一个数据页时，数据库宕机，从而导致这个页只写了部分数据，这就是部分写失效，它会导致数据丢失。这时是无法通过重做日志恢复的，因为重做日志记录的是对页的物理修改，如果页本身已经损坏，重做日志也无能为力。
前面已经介绍过MySQL的double write就是为了解决这个问题。

虽然double write写了两次，但是实际上所写的页面是缓存到内存里，将随机写整合为顺序写后才会写入磁盘，其性能上的损失没有2倍只有10%。
在一些有预防写失效机制文件系统(ZFS文件系统)或者具有原子写功能的存储上就可以关闭double write，在一定程度上提高吞吐量。

计算型存储压缩

在数据库产品尤其是列式存储（以列存储，相同数据类型有利于压缩）中会使用压缩技术来进行数据的压缩节省存储成本，但是传统的软压缩由应用程序定义解压缩逻辑，需要CPU参与解压缩运算，且过程中数据链路过长。而在硬压缩中使用硬件压缩卡实现的CPU Offload并不彻底，大量的数据复制依然会抢占带宽资源。另外，增加的压缩卡在数据链路中对于大量小数据块的写入增加了相应的IO延迟。为了进一步解决使用压缩卡仍存在的问题，在可计算存储中，将解压缩的计算单元移动至存储中，实现zero copy。

基于CPU的软压缩：

基于压缩卡的硬压缩：
下图可以看出虽然使用了FPGA，但在FPGA读写DRAM存储时依然存在着数据的复制。

计算型存储中的压缩：

在以上三张图中，我们可以很明显的看出IO计算的演进是逐渐向下移动的，基本思想在于解放CPU算力，减少IO的交互，这和当前的很多架构的思想都是类似。

算子下推

在数据库中检索数据时，从存储引擎中取得的数据往往比真实需要检索出的数据要多的多，因此我们希望能够避开那些从存储引擎中读取的不必要数据，而是尽量直接返回满足所有条件的数据。
我们在进行SQL优化时，通常会使用谓词下推的方法进行优化， 顾名思义，就是把SQL中的过滤算子（ where语句），尽可能地放在执行计划靠前的地方，通过谓词下推，我们可以使程序提前过滤部分数据，降低Join等一系列操作的数据量级，从而提高性能。
这里以MySQL的ICP特性为例聊一聊索引检索数据时的优化。
ICP（index condition pushdown）是MySQL 5.6以后的特性，是一种在存储引擎层使用索引过滤数据的一种优化方式。

在不使用ICP特性时，我们可以看到数据是在Server端进行的where条件过滤。

在开启ICP之后，我们可以看到where条件过滤被pushdown到存储引擎层进行，减少了存储引擎访问基表的次数以及Server访问存储引擎的次数。

ICP和我们常用的SQL层面的优化，严格意义上来说并不是真正的下推，因为它们仍然需要CPU参与运算。
像我们前面说到的下推逻辑，我们可以设想一下将运算进一步下推到存储层进行，实现进一步的CPU Offload，减少计算层和存储层之间的数据交互。

业界的一些pushdown做法：
阿里云PolarDB引入了LogicalView算子节点，LogicalView是从MySQL数据源拉取数据的算子，类似于其他数据库中的TableScan或IndexScan，但支持更多的下推。LogicalView中包含下推的SQL语句和数据源信息，更像一个视图。其中下推的SQL可能包含多种算子，如Project、Filter、聚合、排序、Join和子查询等。
华为的GaussDB（for MySQL）的存储层是建立在华为云存储DFV持久层之上，DFV持久层为上层SQL节点存储提供读写接口。GaussDB将特定计算任务（备份与恢复逻辑）下推到DFV，以便更高效快速地实现备份和恢复，这样上层计算节点会更专注于业务逻辑的处理。