POLARDB Meets Computational Storage: Efficiently Support Analytical Workloads in Cloud-Native Relational Database
PolarDB结合可计算存储：高效支持云原生关系数据库的复杂查询操作
来自国际顶级存储行业会议FAST2020 Alibaba
Paper 读paper之前参考了FAST20论文赏析-PolarDB

计算下推：将数据从计算侧oddload到存储侧，从而降低计算节点到存储节点之间的带宽，利用存储节点侧富裕的计算能力来提高整体的资源利用率。
本文的PolarDB直接将计算节点的分析任务（scan table)从CPU端offload到物理介质（computational storage drives，CSD）

Abstract

本文聚焦于将计算下推到存储节点，充分利用存储侧的计算能力进行table scan任务。
但说起来容易做起来难，涉及到软件（数据库、文件系统、IO）以及硬件（计算存储驱动computational storage drive,CSD)

Section I Introduction

关系数据库采用存算分离的架构存在的一个问题是计算节点和存储节点之间的带宽限制，当密集数据访问时就会成为瓶颈尤其在OLTP任务中采用原始模型这一问题就会更为突出。
解决这一问题的方法之一就是将一些密集访问数据的任务offload到存储节点。实现上一方面存储节点需要有足够的处理能力完成table scan任务；另一方面还不能过分增加存储节点的成本。因此异构计算可以较好的平衡二者。异构我理解的就是在存储节点上增加其他计算硬件，如GPGA来执行计算任务，
本文的计算下沉不是将table scan完全offload到一个计算单元上而是一系列的CSD中。

Section II Background and Motivation

POLARDB

POLARDB的计算节点和存储节点通过高速RDMA网络连接（远程直接数据存取）；

Table Scan的计算下沉

table scan涉及到大量按列读取并处理数据，因此下沉的难点在于如何提升存储节点的计算能力完成table scan任务。方法之一是scale up倍增存储节点但会带来成本的增加，在此不考虑；另一种解决途径就是异构计算，为存储节点增加其他硬件增加算力（如CPU FPGA）。

异构计算传统上是配备一个集中的设备用于计算，但应用到本文中有以下不足：

（1）数据堵塞 table scan 本身是一个dataintensive的任务

（2）dataprocessing hot pot:鉴于存储节点需要通过PCIe搬运大量数据 还是逃不过bandwidth的限制。

因此本文采用的是分布式异构的体系架构，如Fig2所示，将table scan分给每一个存储节点

BosonNLP 论文_异构


conputational storage device：定义为任何可以实现数据处理的存储器件都可以叫做CSD。

CPU+CSD就可以组件一个异构系统。本文采用基于FPGA的CSD，FPGA实现flash的存储控制和计算，host通过地址映射、任务调度、garbage clooection等完成对CSD的控制。与ASIC相比设计、开发周期更灵活。但基于FPGA实现仍然存在两大挑战：如何降低硬件成本，如何完成table scan的计算下沉。

BosonNLP 论文_异构计算_02

Section III 设计与实现

在设计过程中我们发现计算下沉存在两大挑战：
（1）软件层面上支持tablescan的实现
storage engine操作的是file offset,而CSD通过实际的LBA控制实现table scan。为了实现计算下沉就需要在整个软件/驱动层面打开一条通路将table scan的任务给到具体的physical block
（2）低成本实现CSD
虽然前文说过基于FPGA的实现已经降低了成本，但由于FPGA时钟频率（200-300MHz)还是和CPU 的2-4GHz存在差异，因此需要通过堆叠资源实现并行化也会进一步提升成本。
为了解决上述两大挑战，进行了以下设计：

Software Stack

Part A Storage Engine
POLARDB的前端分析引擎叫做POLARDB MPP负责重写、优化SQL啥的。这一部分我们保留不做改动，为了适配MPP将tablescan下发到CSD上还进行了优化。每一个进行table scan的请求需要包含location、schema、evaluated condition。storageengine还提供了一个buffer用来存储CSD计算后的结果，因此请求中也需要包含这个buffer的位置。
Part B PolarFB
POLARDB通过分布式的文件系统POLARFB管理存储节点上的数据，每一个CSD只能对自己的数据进行table scan,storage engine会以file offset的方式生命数据的地址，可能要扫描的数据会存在很多歌CSD上。因此POLARFB需要先把请求转变为CSD能识别的模式。首先分解成m个子请求，再把每个自请求的地址转化为LBA逻辑块地址。

Part C CSD
CSD接收到POLARFS传过来的请求后进行一下操作：
首先分析扫描的情况，以及必要时进行优化（比较的顺序来提成资源利用率）；
随后将LBA地址信息转化为真正的与NAND Flash的物理地址
CSD还会再把scan请求继续细分，从而降低对IO的需求以及提高利用flash阵列的并行性。

Hardware Optimization

Part A Datablock Format

Table scan需要大量比较操作，但各种类型的比较在FPGA编程层面比较难。因此本文修改了POLARDB storage engine层的文件格式，转变为在memory层面可比的形式（通过memcmp())这样就可以处理各种类型的数据了。

为了进一步提升硬件资源利用率，本文进一步修改了data block的格式，开头增加了Type、keys和restarts。这样一方面无需engine传过来信息就可以自己decompose以及进行CRC校验，另一方面也更方便检测每一个block的始末。

BosonNLP 论文_数据库_03

为了更好的FPGA实现，采用了并行化、流水线设计。每个scan eigine包含memcmp 模块和RE模块。memcmp进行常规操作，RE模块一旦检测到当前的输出足以确定最终结果，就终止本次scan，然后继续recursive进行下去。

BosonNLP 论文_异构_04

Section IV Evaluation

Part A 实验设置

首先SSD要达到市面上的水平，SSD的配置是

64-layer TLC NAND Flash

接口：PCIe Gen3x4

配备Xilinx UltrsScale+KU15 FPGA芯片管理flash memory以及实现计算

Part B Table Scan性能对比

使用LINEITEM table测试CSD进行table scan的性能，Fig6显示了扫描时间以及CPU的利用率。每一个CSD配备了4组存储节点可以完成单核4线程or双核8线程。

计算下沉到CSD的结果显示，比纯CPU执行tablescan在latency和CPU utilization上都有明显下降（55s->39s,514%->140%);实验还表明对数据进行压缩可明显降低data traffic的发生

BosonNLP 论文_BosonNLP 论文_05

Part C 系统级测试

分布式系统包含7个数据库节点和3个存储节点，每个存储及诶点包含12个CSD，每个drive容量是3.7TB。对比不使用计算下沉、计算下沉到storage node的CPU上，以及计算下沉到CSD上三种情况下Table Scan的性能。

这部分给出了不同并行程度下的query latency。

这一部分的实验显示出随着并行指令增加，将计算下沉到CSD层面可以有效减少latency，尤其是数据压缩后。这一方面是因为并行到达的指令越多，CPU需要消耗更多的资源做decompression有可能就bound了。而CSD自己就轻而易举完成了分解。

BosonNLP 论文_异构_06


Part D Summary

到这里了解了 为了完成Table Scan 的计算下沉，设计了POLARDB storage engine->POLARFB->CSD
其中POLARFB需要完成一些格式上的转化，CSD则是根据request执行计算、进一步划分啥的。
根据实验结果，可以看到将table scan任务计算下沉到CSD存储节点侧，可以提高吞吐率、减少CPU资源占用以及减少storage-memory之间的数据移动。