可计算存储: 数据压缩和数据库计算下推

“摩尔定律失效“指的是什么？

Figure. 1

狭义的摩尔定律指每18到24个月，芯片上晶体管集成的密度会翻一番或者价格下降一半，它连接了价格和集成度。但我们普遍所讨论的是摩尔定律其实包含"摩尔定律"、"登纳德缩放"和"波拉克法则"三个重要法则。

登纳德缩放定律（严格说是预测）在2007年开始显著降速，并在2012年几乎消失，如下图所示：

Figure. 2

所以，常说的“摩尔定律失效”指的是基于三个重要法则构建的用户价值三角（价格、集成度和性能）的失效。

异构计算

硬压缩（基于压缩卡）

如上图所示，专有压缩卡提供压缩和解压算力，释放CPU资源，实现CPU-Offload，但是并不彻底。频繁且大量的数据复制依然存在，即便压缩卡使用DMA技术，也无法彻底实现Zero-Copy，DRAM和压缩卡之间依然存在频繁的数据复制，抢占大量的服务器带宽资源。同时，因为数据链路中增加压缩卡，势必增加IO时延，尤其是数据库和高速块存储系统的小数据块（如4KB、8KB、16KB）场景。

可计算存储

针对已经存在的问题，可计算存储的思路如下：

• CPU-Offload：采用FPGA完成压缩和解压缩计算，实现CPU-Offload。Look down(to the device)，FPGA 在低延时上具备天然的优势，非常适合计算密集型任务（比如矩阵运算、压缩和非对称加密）。首先，片上集成缓存和DRAM接口，减少与CPU交互，免于OS的进程调度和进程间干扰，从而提供可预期的时延。同时，FPGA 基于定制流水线 MIMD设计，同时拥有流水线并行和数据并行，进一步降低时延。下图（Figure. 5和Figure. 6）是FPGA应用于Bing搜索排名中的查询加速，可以观察到更低的平均延时；

  Figure. 5                                           Figure. 6

• Zero-Copy：以内置FPGA的方式，不改变原有的数据路径，完全在盘内进行压缩解压任务（又叫in-situ processing），避免额外的数据复制，这也是为什么可计算存储又叫“近”存储计算的原因；

如下图所示：

Look forward(to the future)，IDC（International Data Corporation）预计到2025年全球数据将达到175ZB。即便考虑压缩技术，存储介质的容量和数据量的增速剪刀差会越来越明显。

可以做个简单的算术题，读取1PB数据，仅考虑数据从存储介质传输到到主存（DRAM），PCIe 3.0 * 32、PCIe 4.0 * 32 和PCIe 5.0 * 32分别耗时多久？如果数据存放存储阵列上，使用100Gbps存储网络，耗时多久？如下所示：

Look backward(to the past)，在现代处理器系统中，CPU高速缓存处于内存系统的顶端，其下是主存（DRAM）和存储介质。在一个现代处理器系统中，CPU高速缓存通常由多层次组成（L1，L2 和 L3 Cache）。基于时间局部性，CPU数据读取时将访问各级Cache直至到达主存（DRAM）。如果需要访问的数据在CPU高速缓存中命中，将不会访问主存（DRAM），以缩短访问延时，访问流程大致如下：

在联机分析（OLAP）的场景中，如果同一作业的运行频率低，不同作业之间数据的关联度低，使得现有缓存体系极为低效甚至失效，比如热数据被换出引发Cache Miss，导致应用性能急剧下降。在数据库领域有不同的解决思路，以 Oracle 为例：

数据增长永无止境，硬件性能终会遇到天花板，减少移动的数据量似乎更有启发。

当说下推时，到底指的是什么？可以从 MySQL 特性 Index Condition Pushdown（简称ICP）入手，建立更具体的认识。

关闭 ICP

未启用ICP特性时，会按照第一个索引条件列到存储引擎查找数据，并把整行数据提取到数据库实例层，数据库实例层再根据Where后其他的条件过滤数据行。如下图所示：

Figure. 8

启用 ICP

启用ICP特性后，如果Where条件中同时包含检索列和过滤列，且这些列上创建了一个多列索引的情况下，那么数据库实例层会把这些过滤列同时下推到存储引擎层，在存储引擎层过滤掉不满足的数据，只读取并返回需要的数据，减少存储引擎层和数据库实例层之间的数据传输和回表请求，通常情况下可以大幅提升查询效率。如下图所示：

Figure. 9

数据库计算下推

MySQL ICP虽然将MySQL Server层的过滤下推到存储引擎层，但仍需要消耗CPU资源，严格来说，这不是真正意义的下推。如果要更进一步，可以考虑将第4步下推到可计算存储，原因如下：

• 收益大：关键步骤，由它完成实例层向存储引擎层的下推，符合“近”存储计算原则，实现收益相对大；

• 成本低：从调用关系看，对数据库实例层影响很小，绝大部分改动可在存储引擎层完成，修改和验证成本相对低；

• 对FPGA友好：易于并行，对计算密集任务友好（比如压缩，加密，计算，过滤和聚合）；

如下图所示：

受篇幅和能力所限，省略了一些细节。比如：

在压缩和解压缩的场景中，追求极致的压缩率或性能都会相对容易，但是对于持久化业务而言，往往是既要（压缩率）又要（时延）。在这些前提要求下，可计算存储在提供稳定IO时延的同时实现了数据压缩，降低了存储成本。当然，要实现并发布商用产品涉及的内容就太多了，比如，FPGA选型（资源和功耗），如何调试压缩算法以对FPGA更友好，面对不同压缩比的数据如何提供可预期的时延，如何提供对应用透明的使用体验，如何实现LBA（逻辑地址）和PBA（物理地址）变长映射等等。

在计算下推的场景中，设计的内容包括如何识别底层的CSD设备以及暴露的Pushdown接口，如何将下推的条件传输给硬件，如果优化设备内部逻辑（流式处理和并行数据过滤），存储数据格式修改以对流式处理更友好，因为bypass文件系统如何修改现有的监控...

从曾经的专有计算，再到Intel奠定的通用计算，再到今天的异构计算。历史总是惊人的相似又被赋予新的内涵。计算机领域的创新也未必都是天才们“灵光乍现”, 更多时候是建立在对已有系统（软件和硬件）深刻理解之上, 用一个新的角度解决问题。可计算存储将会给持久化应用，尤其是数据库，带来更多深远的影响和变化。