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

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

2016年2月9号《自然》杂志的《The chips are down for Moore’s law》写到即将出版的国际半导体技术路线图不再以摩尔定律（Moore’s law）为目标，芯片行业50年的神话终被打破。

Figure. 1

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

  • 登纳德缩放定律（Dennard Scaling）的核心观点是，随着晶体管密度的增加，每个晶体管的功耗会下降，因此，每平方毫米硅的功耗几乎是恒定的。由于硅的计算能力随着每一代新技术的发展而提高，计算机将变得更加节能。
  • 波拉克法则（Pollack's Rule）则指出，同制程工艺下，处理器的性能提升幅度，是芯片面积（晶体管数量）提升的平方根。
  • 登纳德缩放定律（严格说是预测）在2007年开始显著降速，并在2012年几乎消失，如下图所示：

Figure. 2

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

异构计算

2017 年图灵奖获得者John L. Hennessy and David A. Patterson在他们的文章《A New Golden Age for Computer Architecture》中指出通过异构处理器优化设计时间和成本。

As the focus of innovation in architecture shifts from the general-purpose CPU to domain-specific and heterogeneous processors, we will need to achieve major breakthroughs in design time and cost.

异构计算指将不同体系架构不同指令集（精简指令集和复杂指令集）的计算单元组合使用，将最合适的任务交给最擅长的计算单元（包括CPU、GPU和FPGA等），最大程度发挥各类计算单元的优势。

可计算存储和数据压缩

可计算存储可简单的理解成在原有的存储介质（比如NVMe SSD）上叠加计算单元（比如FPGA），并由该计算单元加速跟存储直接相关的计算任务，实现CPU计算任务卸载（Offload）。但持久化应用的相对复杂，如果不能洞察面临的重要问题、理解现存方案的取舍（Tradeoff）和提出创新性的设计方案，可计算存储很难发挥真正价值。计算机体系结构泰斗Yale Patt教授曾提出的Look backward(to the past)，Look forward(to the future)，Look up(to the problem)和Look down(to the device)在存储领域同样适用。

Look up(to the problem)，存储实现信息跨越时间的传递，对它的抱怨永远是“不够快，不够大”。SSD的出现极大的提升了存储性能（IOPS和Latency），但是逐年下降的价格依旧跟不上数据爆炸式的增长。SSD的特性决定容量不仅影响成本，也影响性能。SSD不能像内存和机械硬盘直接覆盖旧数据，只能擦除Block后才能写入其中一个“干净”的Page。当SSD剩余空间变少，出现大量数据碎片时，就要读取整个Block数据，将有效数据重新写到已经擦除的Block。这个过程叫Garbage Collection (GC)，导致写放大(Write Amplification)。单个擦除操作延迟是写操作延迟的几倍，而写操作的延迟又是读操作的几十倍。在混合读写的场景，GC会引发延时抖动，影响性能。为降低GC频率，SSD不仅会优化GC算法（比如“greedy reclaiming policy”），如下图所示：

同时也会留出空间(也叫OP：Over Provision)，企业级SSD的OP通常是28%，消费级SSD内部的OP通常是7%。IBM研究院的相关研究指出剩余空间为10%时写放大在3.5倍和4.5倍之间，剩余空间为30%时写放大可减少为0.2，如下图所示：

所以减少写入的数据量，不仅节省空间，也优化性能。针对不同场景，业界提供了很多压缩算法，比如zstd，zlib，brotli，quicklz，lzo1x，lz4，lzf，snappy...现有的解决方案可简单归纳成软压缩（基于CPU）和硬压缩（基于加速卡）。

《硅谷》中年轻的计算机天才Richard发明的超越理论极限的压缩算法“middle-out”，并由此组建了Pied Piper公司。

软压缩（基于CPU）

如上图所示，压缩和解压完全由CPU提供算力。“牺牲”CPU资源换取存储空间，存在个突出的问题：

  • CPU抢占：会占用大量CPU资源，同时也会跟应用抢占CPU资源。
  • 数据复制导致的带宽抢占：在主存和CPU之间引入频繁且大量的数据复制（DRAM<-->L3 Cache<-->L2 Cache<--> L1 Cache<-->Registers），抢占服务器PCIe 带宽和内存带宽，同时带来潜在的CPU Cache Miss，进一步影响计算效率。
  • 时延不稳定：因为CPU抢占和带宽抢占，当OS负载较高时，OS中的时钟中断和任务调度增加了延迟的不确定性，这是IO密集型业务很难忍受的。

硬压缩（基于压缩卡）

如上图所示，专有压缩卡提供压缩和解压算力，释放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 为例：

  • 缩短数据量的移动路径：数据库默认总是先将数据读取到自己维护的高速缓冲，Oracle 11g开始采用直接路径读取来扫描大表（默认 2% * buffer cache），从而绕开buffer cache，避免热数据被换出引发缓存命中率下降；
  • 减少移动的数据量：Oracle Exadata Smart Scan，该特性能通过将大部分的SQL操作下推（又叫卸载）到存储节点完成，极大的减少了存储节点和数据库节点之间的数据量；

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

当说下推时，到底指的是什么？可以从 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文件系统如何修改现有的监控...

Yesterday's technologies,today's problem

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

What we have before us are some breathtaking opportunities disguised as insoluble problems.

作者 ：熊中哲@ScaleFlux

ScaleFlux 成立于2014年，其被证明为可以批量部署复杂的计算和固态存储解决方案的领导者。计算存储是现代数据驱动的基础，该架构可为计算和I/O密集型应用提供低延时、易扩展和敏捷的能力

引用

  • A New Golden Age for Computer Architecture
  • A Reconfigurable Fabric for Accelerating Large-Scale Datacenter Services
  • A Cloud-Scale Acceleration Architecture
  • 浅谈 Cache Memory
  • wiki Locality of reference
  • Index Condition Pushdown Optimization
  • Write Amplification Analysis in Flash-Based Solid State Drives
  • Write Amplification

文章来源：ScaleFlux

赞 (0)

相关推荐