access 压缩和修复数据库-access 数据库压缩修复

关于作者

作者：熊中哲，现任彩云科技工程副总裁，负责产品及研发工作。 曾任职于阿里巴巴、我趣科技、美团点评。 超过12年数据库领域工作经验，目前对云原生、机器学习和异构计算感兴趣。

介绍

阿里巴巴为刚刚结束的国际存储行业顶级会议FAST 2020贡献了三篇论文：

结合阿里云数据库负责人李飞飞教授在《如何看待数据库的未来》中提到的

新硬件：软硬件一体化设计

这一切都表明，行业领导者正在定义云原生数据库的行业标准。 数据库不仅仅是运行在CPU和内存中的二进制代码，也不再是简单的高端硬件堆砌。 关键硬件在设计阶段就必须根据数据库的特点进行设计。 深度定制优化，借用Alan Kay的名言：

真正认真对待软件的人应该自己制作硬件。

下面的文字应该只是“吞枣”后的一些粗浅思考。 限于本人能力，没有提到的应该做。

“乘风潜入夜，润物细无声”，其实早在十多年前，数据库软硬件一体化的进程就在潜移默化中拉开了序幕。

2010年，笔者在生产环境中第一次接触到Infiniband技术。 当时Oracle RAC（real application cluster）在超级计算领域（HPC）通过Infiniband网络技术优化了集群实例间的内存数据（Cache Fusion）。 相互影响。 与10G网络相比，Infiniband不仅提供了更高的带宽和更低的延迟，还提供了基于RDMA的Zero Copy和Asynchronous I/O特性，进一步提高了通信协议的效率，同时大大降低了CPU资源的消耗。

同年，也开始在电商数据库生产环境中应用固态硬盘（SSD）技术。 为了说明SSD的价值，我们简单介绍一下关系型数据库中的Write-ahead Logging（简称WAL）机制。 WAL提供了原子性和持久性（RDBMS的ACID属性二）关键技术，我们常用的关系型数据库Oracle、MySQL（Innodb Engine）和SQL Server都是基于WAL实现的（具体实现不尽相同）。

在Oracle中，也称为Online redo log（以下简称日志）。 日志持久化延迟直接影响TPS（Transaction per Second）。 在OLTP（在线交易）场景中，TPS是衡量数据库性能最关键的指标。 相信各位Oracle DBA对“log file sync”和“log parallel wirte”这两个等待事件都非常熟悉。 根据实践access 压缩和修复数据库，如果“log file sync”的延迟超过3ms，应用访问数据库就会有“慢”的感觉。 固态磁盘 (SSD) 可以大大减少日志写入延迟。 当时写入放大（Write Amplification，简称WA）和垃圾收集（garbage collection，简称GC）的问题比较明显，甚至没有SSD写入寿命的监控界面。 这是一次革命性的技术变革。 也有人判断SSD是近10年来数据库（当时是关系型数据库）领域最大的一次技术革命。

这一阶段的明显特征是“拿来主义”。 Infiniband 和 SSD 无需针对数据库进行优化即可获得显着优势。

没有硬件技术，很难凭空简单地定制任何软件技术。 关系数据库理论诞生于20世纪60年代末70年代初，其设计思想受限于当时的磁盘技术。

只使用了MySQL数据持久化中的一个场景。 MySQL实例会将内存中的脏（修改）数据以数据页为单位写入磁盘持久化。 数据页的大小为 16KB。 假设写2KB时服务器异常掉电。 此时数据页的前2KB已经更新，剩下的14KB还没有更新。 那么数据页是由于partial write。 写得不好。 但是MySQL redo log无法修复这种坏数据页，导致数据丢失。

受限于机械盘只能提供512B的原子写（Atomic Write），Innodb Engine通过Double Write机制解决了这个问题，副作用也很明显，不仅增加了存储引擎代码的复杂度，还引入了额外的磁盘写入压力，让宝贵的存储资源（IOPS）更加紧张。

如果MySQL所依赖的存储介质能够提供可配置写入大小的原子写（Atomic Write），则可以直接禁用Double Write，这将在以下几个方面带来巨大的好处：

强大的硬件厂商相继提供了大页面的原子写（Atomic Write）特性，如Intel、Sandisk、Scaleflux。 细心的读者可能已经发现，一些公有云RDS厂商在使用具有双写功能的硬件后默认关闭了双写功能。

与“自带”阶段相比，硬件厂商对数据库的理解程度更高，但仍未跳出“传统”的存储认知范畴。

摩尔定律无效。 这里扯远了，说说摩尔定律。 2016年2月9日，全球最著名的学术期刊《自然》在《芯片因摩尔定律而落伍》一文中写道，即将出台的国际半导体技术路线图不再以摩尔定律为目标，50年的神话芯片行业终于被打破了。

这意味着该软件不再享受18个月的CPU算力翻倍订阅服务，这也意味着CPU算力更加珍贵。

基于异构计算的软硬件一体化设计。 2017 年图灵奖获得者 John L. Hennessy 和 David A. Patterson 在他们的文章《计算机架构的新黄金时代》中给出了答案

随着架构创新的重心从通用CPU转向领域专用和异构处理器，我们需要在设计时间和成本上取得重大突破。

例如access 压缩和修复数据库，在机器学习领域，GPU 代替 CPU 进行大规模矩阵运算。 《POLARDB Meets Computational Storage: Efficiently Support Analytical Workloads in Cloud-Native Relational Database》一文也在数据库领域呼应。 如论文所述：

对行存储数据的表扫描不太适合现代 CPU 架构，并且往往在很大程度上未充分利用 CPU 硬件资源。

OLAP 场景下的表扫描对 CPU 不友好。 POLARDB pushdowns table scans到具有计算能力的存储介质（FPGA-based），论文中也称为Computational Storage，如下图所示：

更多详情请参考论文《POLARDB Meets Computational Storage: Efficiently Support Analytical Workloads in Cloud-Native Relational Database》。 Scaleflux首席科学家张彤教授也在FAST 2020做了专题演讲，感兴趣的读者也可以一起阅读。

表扫描下推对于 MySQL DBA 来说并不陌生。 MySQL 5.6 引入了索引条件下推（Index Condition Pushdown，简称ICP）特性。 当不开启ICP特性时，存储引擎会根据第一个索引条件查找数据，并将整行数据抽取到实例层，实例层根据Where后的其他条件过滤数据行。 启用ICP特性后，如果Where条件同时包含检索列和过滤列，并在这些列上创建多列索引，实例层会将这些过滤列同时下推到存储引擎层。 该层过滤掉不满意的数据，只读取和返回需要的数据，减少存储引擎层和实例层之间的数据传输和表返回请求，通常可以大大提高查询效率。 下图可以直观的看到启用ICP前后的数据链路：

试想一下，如果把类似“索引条件下推”的工作下推（pushdown）到一个有算力的存储介质上，你会得到类似POLARDB的收益吗？

过去只有甲骨文有实力设计软硬件一体化。 Exadata无疑是集成设计的先行者，吸收了大量的“异构”硬件。 它在10年前推出了PCIe SSD（也叫Flash），还在X4版本推出了基于PCIe SSD的“透明”压缩（Exadata Flash Cache）。 Compression），试图在易用性、成本和性能之间找到一个完美的平衡点，功能描述如下：

闪存缓存压缩通过透明地压缩加载到闪存缓存中的用户数据来动态增加闪存缓存的逻辑容量。 这允许将更多数据保存在闪存中，并减少访问磁盘驱动器上数据的需要。

虽然这个功能既不够透明也不够便宜，但它显示了它通吃所有软件和硬件的野心。

经过50年的发展，一大批公司和研发公司在关系数据库上构建了无数的关键应用。 朝夕相处让他们熟悉了数据库的痛点，而这些痛点在传递给硬件厂商的过程中被严重衰减。 也是极少数巨头秘而不宣的独特秘籍。 POLARDB无疑在异构计算和数据库中搭建了一座让更多人可以通过的桥梁。 借用丘吉尔的名言，我相信这只是“开始的结束”。

现在这还没有结束。 这甚至还没开始结尾。 但这也许是开始的结束。

我教的《MySQL优化教程》第17期开课了。 我们的课程从第15期开始升级到MySQL 8.0版本。 现在正好上车，让我们一起开启MySQL 8.0实践之旅。扫描二维码进群，了解“MySQL优化”课堂，有助教等着你