计算型存储： 异构计算的下一个关键应用

cslehe

#111723#AWS re:Invent2019表现AWS市场占用率到达45%，比拟2018年营收增加29%。应用公用芯片构建用于减速特定场景的策略愈加清楚，撤除Intel和AMD的X86和Nvidia GPU，另有通过其Annapurna Labs部分推出的基于Arm的Graviton的定制芯片，并许诺基于Graviton2（7纳米）的新型EC2实例的机能是第一代Graviton的7倍。
早在摩尔定律生效之前，一个逐步告竣的共鸣就是通用途理器的算力应当专一于庞杂的贸易逻辑，而简略反复的任务则由公用芯片实现愈加适合。
超算和智能网卡
早在20年之前，基于异构盘算的智能网卡就曾经利用于超算（HPC）范畴。从1993年开端 TOP500 就以每年两次的频率，基于 Linpack benchmark 负载模子来统计地球上运转最快的超等盘算集群。
2003年，弗吉尼亚理工学院暨州立大学创立一个InfiniBand集群，在事先的TOP500排名第三；
2009年，天下500强超等算机中，152个应用InfiniBand，并供给38.7%的算力；

2020年11月，依据最新的第56版，155个应用 InfiniBand，并供给40%的算力，排名前10的超算集群有8个由 InfiniBand 构建，更是盘踞了前5的4席地位。

在构建高速网路时，争辩重要是把收集功效Onload到CPU上，仍是把这些功效Offload到公用硬件：
常用Onloading，TCP/IP技巧在数据包从网卡到利用顺序的进程中，要经由OS，数据在主存、CPU缓存和网卡缓存之间往返复制，给效劳器的CPU和主存形成累赘，也加重收集耽误。
Offloading 基于RDMA实现近程内存直接拜访，将数据从当地疾速挪动到近程主机利用顺序的用户空间，通过Zero-copy和Kernel bypass来实现高机能的近程直接数据存取的目的。
下图能够直观的看到二者在拜访门路的区分：

固然，Offloading 须要将RDMA协定固化于硬件上，以是依附于网卡的算力能否能够满意运转RDMA协定的开消，这现实上就是公用芯片和网卡的联合。用更性感的说法是
SmartNICs are an example of DPU （Data Processing Unit） technology
AWS和Nitro
云盘算催生超大范围数据核心，也同时缩小通用算力的缺乏和异构盘算的上风。就比如研发团队范围变大的同时必定走向专业化。AWS EC2初期由纯软（也象征着须要耗费CPU）的Xen对CPU、存储和收集实现虚构化。基于这类实现方法，一个EC2实例的虚构化治理开消高达30%。

30%相称可观，最主要的是并没无为客户供给直接代价。依照 Werner Vogels（AWS CTO ）的说法
想为客户明显进步机能、保险性和迅速性，咱们必需将大部份治理顺序功效迁徙到公用硬件上。
2012年，AWS开端构建Nitro体系，也恰是这，登纳德缩放定律（严厉说是猜测）几近消散：

2013年， Nitro 利用于C3实例，其收集过程卸载到硬件中；
2014年，推出了C4实例范例，将EBS存储卸载到硬件中，并开端和Annapurna Labs配合；
2015年，收购 Annapurna Labs；

此时，Nitro体系曾经包括三个重要部份：Nitro卡、Nitro保险芯片和Nitro治理顺序。重要卸载和减速IO，虚构私有云（VPC）、弹性块存储（EBS）和实例存储，从而让用户能够应用100%的通用算力。

对客户而言，象征更好的机能和价钱，下图能够看到基于Nitro的C5和I3.metal的延时显明下降：

盘算型存储和数据库
从AWS的营收看，收集、存储、盘算和软件是收入的四驾马车，数据库毫无疑难是存储范畴的要害场景。跟着云盘算带来基本情况的转变，也直接减速云原生技巧的开展和成熟，顺序员不会再写出单体（Monolithic）利用，也再也不会在利用中只应用一种数据库。仍是借用Werner Vogels的话
A one size fits all database doesn‘t fit anyone.
从AWS供给的数据库效劳也应证了一点（海内的云盘算巨子也相似）。

差别的数据库针对差别的场景，比方Airbnb应用 Aurora 替换 MySQL，Snapchat 应用DynamoDB 承载起最大的写负载，麦当劳将ElastiCache利用于低延时高吞吐的任务负载，游览网站expedia.com应用ElasticSearch及时优化产物价钱。固然，对于存储介质，更疾速和更大容量的需要广泛存在。从上面数据库的工程实际看，紧缩是实现这一目的的共鸣：
DB-Engines DBMS数据紧缩特征
DBMS
能否支撑数据紧缩
Oracle
MySQL
Microsoft SQL Server
PostgreSQL
MongoDB
IBM Db2
Elasticsearch
Redis
SQLite
Cassandra
紧缩率依附于数据自身，1948年由美国数学家克劳德·香农（Claude Shannon）在经典论文《通讯的数学实践》中起首提出信息熵，幻想情形下，不论是甚么样内容的数据，只有存在一样的几率散布，就会失掉一样的紧缩率。
在实现时，经常要在紧缩吞吐，解压吞吐，和就义紧缩率之间做弃取，这也是发生诸多紧缩算法的缘由。下图是基于Silesia compression corpus差别紧缩算法之间的差别。
Compressor Name
Ratio
CompressionDecompress
zstd 1.4.5 -1
2.884
500MB/S
1660MB/S
zlib 1.2.11 -1
2.743
90MB/S400MB/S
brotli 1.0.7 -0
2.703
400MB/S450MB/S
zstd 1.4.5--fast=1
2.434
570MB/S2200MB/S
zstd 1.4.5--fast=3
2.312
640MB/S2300MB/S
quicklz 1.5.0 -1
2.238
560MB/S710MB/S
zstd 1.4.5 --fast=5
2.178
700MB/S2420MB/S
lzo1x 2.10 -1
2.106
690MB/S820MB/S
lz4 1.9.2
2.101
740MB/S4530MB/S
lzf 3.6 -1
2.077
410MB/S860MB/S
snappy 1.1.8
2.073
560MB/S1790MB/S
从一个罕见的场景动身，利用屡次写入紧缩率各不雷同的数据，逻辑写入量为36KB，以下图所示：

依照后面所示的紧缩率，最幻想的情形是紧缩后占用15.2KB。

但现有的空间治理实际会占用更多的物理空间，起首写入时须要依照文件体系页对齐写入（假定4KB），占用物理空间为48KB，数据存储散布以下图所示：


但由于紧缩后数据仍然须要依照文件体系页巨细（4KB）对齐，数据存储散布以下图所示：

以是现实占用的物理空间是36KB离预期的紧缩率相去甚远。

为进一步晋升紧缩效力，平日会进一步压实（compaction）空间，压实后数据存储散布以下：

这时占用的物理空间是 16KB，才濒临15.2KB。
可见在工程实际时，要想在利用场景中取得可观的紧缩收益，仅存眷数据构造和紧缩算法是不敷的，还要斟酌压实（Compaction）效力，假如还要统筹算力耗费、IO延时和代码庞杂度等指标，工程难度将指数级晋升。
针对这个场景，支撑通明紧缩的盘算型存储 CSD2000，将紧缩解紧缩算法offload到盘内FPGA，使盘算更凑近数据存储的处所（“in-situ computing”），进一步收缩数据门路，从而晋升数据处置的效力。
对照“软”紧缩（基于CPU）和硬紧缩（基于FPGA）二者的收益并不庞杂，上面以MySQL为例，将MySQL页紧缩，MySQL表紧缩和CSD2000通明紧缩三者停止对照，采取TPC-C和TPC-E数据集和负载模子，以紧缩率和数据库机能（TPS和时延）为指标权衡紧缩效力。
先看紧缩率，盘算型存储 CSD2000 供给更高的紧缩率，几近是MySQL自带紧缩的2倍以上，以下所示：

再看机能，应用sysbench测试1/4/16/64/256/512并发下机能表示，能够视察到（以下图所示）：
≥ 64并发时，CSD2000 QPS/TPS均匀进步~5倍，最高进步~12倍，99%均匀时延下降68%以上；
《64并发时，CSD2000 QPS/TPS广泛高于一般NVMe SSD 20%~50%，99%均匀时延下降8%~45%；
阐明：为了便于对照，以一般NVMe SSD指标为基线做归一化。


Mark Callaghan （Facebook Distinguished Engineer）已经吐槽在数据库中实现通明页紧缩并利用在出产情况，工程实现过于庞杂，难怪Jens Axboe（Linux内核代码重要奉献者之一，FIO和IO_URING的作者）倡议他把这些任务丢给盘算型存储公司 ScaleFlux。而从盘算型存储带来的紧缩及机能（详见：可盘算存储：数据紧缩和数据库盘算下推）收益来看曾经逾额实现义务。

盘算型存储和文件体系
紧缩同时增加数据写入量（Nand Written）和写缩小（Write Amplification），但现实的情形会更庞杂一些，大少数情形下数据库运转在文件体系之上。

以日记型文件体系ext4为例，计划以下测实验证日记写入量与数据库数据写入量的比例及通明紧缩对于增加写入量的收益：
选用 MySQL 和 MariaDB；
200GB数据集；
3种负载模子：Insert/Update-Index/Update-Non-Index；
两种数据拜访方法：热门会合（Non-uniform Key Distribution） 和全随机（Uniform Key Distribution）；
终究测试成果以下：
由于文件体系的 WAL（Write Ahead Log）机制，加上日记的稀少构造，日记写入量占团体写入量20%~90%，可见文件体系日记写入量可能大于下层利用（数据库）的数据写入量；
通明紧缩对于增加数据库数据量的写入后果显明，对于增加日记体系写入量的后果愈加明显，全体测试场景增加日记写入量约4~5倍；
阐明：以一般NVMe SSD指标为基线做归一化，直方图面积越小，数据写入量越少。


人类的聪明注建都要在山顶相遇
亚马逊常常念叨单向（one-way）和双向（two-way）门决议。双向门决议轻易逆转，比方A/B test，这类决议能够疾速采用举动，即便失败，本钱也不高。单向门决议大少数时间弗成撤消，必需”勇敢假定，谨慎求证“。Nitro 显而易见是一个单向（one-way）门决议，即使是2012年开端，AWS也花了足足7年时光才完全落地。
在异构盘算范畴，头部云盘算厂曾经告竣共鸣，相干产物也减速推出，包含支撑盘算下推的阿里云PolarDB（详见：可盘算存储：数据紧缩和数据库盘算下推），以及 AWS re:Invent2020 再次提到的基于 AUQA（Advanced Query Accelerator） 节点减速的 Redshift。
景物长宜放眼量，人类的聪明注建都要在山顶相遇。

更多内容阅读推荐：空调电流大什么原因