AWS re:Invent2019顯示AWS市場占用率達(dá)到45%,相比2018年?duì)I收增長29%。使用專用芯片構(gòu)建用于加速特定場景的戰(zhàn)略更加清晰,除去Intel和AMD的X86和Nvidia GPU,還有通過其Annapurna Labs部門推出的基于Arm的Graviton的定制芯片,并承諾基于Graviton2(7納米)的新型EC2實(shí)例的性能是第一代Graviton的7倍。
早在摩爾定律失效之前,一個(gè)逐漸達(dá)成的共識(shí)就是通用處理器的算力應(yīng)該專注于復(fù)雜的商業(yè)邏輯,而簡單重復(fù)的工作則由專用芯片完成更加合適。
超算和智能網(wǎng)卡
早在20年以前,基于異構(gòu)計(jì)算的智能網(wǎng)卡就已經(jīng)應(yīng)用于超算(HPC)領(lǐng)域。從1993年開始 TOP500 就以每年兩次的頻率,基于 Linpack benchmark 負(fù)載模型來統(tǒng)計(jì)地球上運(yùn)行最快的超級(jí)計(jì)算集群。
2003年,弗吉尼亞理工學(xué)院暨州立大學(xué)創(chuàng)建一個(gè)InfiniBand集群,在當(dāng)時(shí)的TOP500排名第三;
2009年,世界500強(qiáng)超級(jí)算機(jī)中,152個(gè)使用InfiniBand,并提供38.7%的算力;
2020年11月,根據(jù)最新的第56版,155個(gè)使用 InfiniBand,并提供40%的算力,排名前10的超算集群有8個(gè)由 InfiniBand 構(gòu)建,更是占據(jù)了前5的4席位置。
在構(gòu)建高速網(wǎng)路時(shí),爭論主要是把網(wǎng)絡(luò)功能Onload到CPU上,還是把這些功能Offload到專用硬件:
常用Onloading,TCP/IP技術(shù)在數(shù)據(jù)包從網(wǎng)卡到應(yīng)用程序的過程中,要經(jīng)過OS,數(shù)據(jù)在主存、CPU緩存和網(wǎng)卡緩存之間來回復(fù)制,給服務(wù)器的CPU和主存造成負(fù)擔(dān),也加劇網(wǎng)絡(luò)延遲。
Offloading 基于RDMA實(shí)現(xiàn)遠(yuǎn)程內(nèi)存直接訪問,將數(shù)據(jù)從本地快速移動(dòng)到遠(yuǎn)程主機(jī)應(yīng)用程序的用戶空間,通過Zero-copy和Kernel bypass來實(shí)現(xiàn)高性能的遠(yuǎn)程直接數(shù)據(jù)存取的目標(biāo)。
下圖可以直觀的看到兩者在訪問路徑的區(qū)別:
當(dāng)然,Offloading 需要將RDMA協(xié)議固化于硬件上,所以依賴于網(wǎng)卡的算力是否可以滿足運(yùn)行RDMA協(xié)議的開銷,這實(shí)際上就是專用芯片和網(wǎng)卡的結(jié)合。用更性感的說法是
SmartNICs are an example of DPU (Data Processing Unit) technology
AWS和Nitro
云計(jì)算催生超大規(guī)模數(shù)據(jù)中心,也同時(shí)放大通用算力的不足和異構(gòu)計(jì)算的優(yōu)勢。就好比研發(fā)團(tuán)隊(duì)規(guī)模變大的同時(shí)必然走向?qū)I(yè)化。AWS EC2早期由純軟(也意味著需要消耗CPU)的Xen對(duì)CPU、存儲(chǔ)和網(wǎng)絡(luò)完成虛擬化。基于這種實(shí)現(xiàn)方式,一個(gè)EC2實(shí)例的虛擬化管理開銷高達(dá)30%。
30%相當(dāng)可觀,最重要的是并沒有為客戶提供直接價(jià)值。按照 Werner Vogels(AWS CTO )的說法
想為客戶顯著提高性能、安全性和敏捷性,我們必須將大部分管理程序功能遷移到專用硬件上。
2012年,AWS開始構(gòu)建Nitro系統(tǒng),也正是這,登納德縮放定律(嚴(yán)格說是預(yù)測)幾乎消失:
2013年, Nitro 應(yīng)用于C3實(shí)例,其網(wǎng)絡(luò)進(jìn)程卸載到硬件中;
2014年,推出了C4實(shí)例類型,將EBS存儲(chǔ)卸載到硬件中,并開始和Annapurna Labs合作;
2015年,收購 Annapurna Labs;
2017年,C5實(shí)例卸載控制平面和剩余的I/O,實(shí)現(xiàn)完整的Nitro系統(tǒng);
此時(shí),Nitro系統(tǒng)已經(jīng)包含三個(gè)主要部分:Nitro卡、Nitro安全芯片和Nitro管理程序。主要卸載和加速IO,虛擬私有云(VPC)、彈性塊存儲(chǔ)(EBS)和實(shí)例存儲(chǔ),從而讓用戶可以使用100%的通用算力。
對(duì)客戶而言,意味更好的性能和價(jià)格,下圖可以看到基于Nitro的C5和I3.metal的延時(shí)明顯降低:
計(jì)算型存儲(chǔ)和數(shù)據(jù)庫
從AWS的營收看,網(wǎng)絡(luò)、存儲(chǔ)、計(jì)算和軟件是收入的四駕馬車,數(shù)據(jù)庫毫無疑問是存儲(chǔ)領(lǐng)域的關(guān)鍵場景。隨著云計(jì)算帶來基礎(chǔ)環(huán)境的改變,也直接加速云原生技術(shù)的發(fā)展和成熟,程序員不會(huì)再寫出單體(Monolithic)應(yīng)用,也再也不會(huì)在應(yīng)用中只使用一種數(shù)據(jù)庫。還是借用Werner Vogels的話
A one size fits all database doesn‘t fit anyone.
從AWS提供的數(shù)據(jù)庫服務(wù)也應(yīng)證了一點(diǎn)(國內(nèi)的云計(jì)算巨頭也類似)。
不同的數(shù)據(jù)庫針對(duì)不同的場景,比如Airbnb使用 Aurora 替代 MySQL,Snapchat 使用DynamoDB 承載起最大的寫負(fù)載,麥當(dāng)勞將ElastiCache應(yīng)用于低延時(shí)高吞吐的工作負(fù)載,旅游網(wǎng)站expedia.com使用ElasticSearch實(shí)時(shí)優(yōu)化產(chǎn)品價(jià)格。當(dāng)然,對(duì)于存儲(chǔ)介質(zhì),更快速和更大容量的需求普遍存在。從下面數(shù)據(jù)庫的工程實(shí)踐看,壓縮是實(shí)現(xiàn)這一目標(biāo)的共識(shí):
DB-Engines DBMS數(shù)據(jù)壓縮特性
DBMS
是否支持?jǐn)?shù)據(jù)壓縮
Oracle
MySQL
Microsoft SQL Server
PostgreSQL
MongoDB
IBM Db2
Elasticsearch
Redis
SQLite
Cassandra
壓縮率依賴于數(shù)據(jù)本身,1948年由美國數(shù)學(xué)家克勞德·香農(nóng)(Claude Shannon)在經(jīng)典論文《通信的數(shù)學(xué)理論》中首先提出信息熵,理想情況下,不管是什么樣內(nèi)容的數(shù)據(jù),只要具有同樣的概率分布,就會(huì)得到同樣的壓縮率。
在實(shí)現(xiàn)時(shí),常常要在壓縮吞吐,解壓吞吐,和犧牲壓縮率之間做取舍,這也是產(chǎn)生諸多壓縮算法的原因。下圖是基于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
從一個(gè)常見的場景出發(fā),應(yīng)用多次寫入壓縮率各不相同的數(shù)據(jù),邏輯寫入量為36KB,如下圖所示:
按照前面所示的壓縮率,最理想的情況是壓縮后占用15.2KB。
但現(xiàn)有的空間管理實(shí)踐會(huì)占用更多的物理空間,首先寫入時(shí)需要按照文件系統(tǒng)頁對(duì)齊寫入(假設(shè)4KB),占用物理空間為48KB,數(shù)據(jù)存儲(chǔ)分布如下圖所示:
但因?yàn)閴嚎s后數(shù)據(jù)依然需要按照文件系統(tǒng)頁大?。?KB)對(duì)齊,數(shù)據(jù)存儲(chǔ)分布如下圖所示:
所以實(shí)際占用的物理空間是36KB離預(yù)期的壓縮率相去甚遠(yuǎn)。
為進(jìn)一步提升壓縮效率,通常會(huì)進(jìn)一步壓實(shí)(compaction)空間,壓實(shí)后數(shù)據(jù)存儲(chǔ)分布如下:
這時(shí)占用的物理空間是 16KB,才接近15.2KB。
可見在工程實(shí)踐時(shí),要想在應(yīng)用場景中獲得可觀的壓縮收益,僅關(guān)注數(shù)據(jù)結(jié)構(gòu)和壓縮算法是不夠的,還要考慮壓實(shí)(Compaction)效率,如果還要兼顧算力消耗、IO延時(shí)和代碼復(fù)雜度等指標(biāo),工程難度將指數(shù)級(jí)提升。
針對(duì)這個(gè)場景,支持透明壓縮的計(jì)算型存儲(chǔ) CSD2000,將壓縮解壓縮算法offload到盤內(nèi)FPGA,使計(jì)算更靠近數(shù)據(jù)存儲(chǔ)的地方(“in-situ computing”),進(jìn)一步縮短數(shù)據(jù)路徑,從而提升數(shù)據(jù)處理的效率。
對(duì)比“軟”壓縮(基于CPU)和硬壓縮(基于FPGA)兩者的收益并不復(fù)雜,下面以MySQL為例,將MySQL頁壓縮,MySQL表壓縮和CSD2000透明壓縮三者進(jìn)行對(duì)比,采用TPC-C和TPC-E數(shù)據(jù)集和負(fù)載模型,以壓縮率和數(shù)據(jù)庫性能(TPS和時(shí)延)為指標(biāo)衡量壓縮效率。
先看壓縮率,計(jì)算型存儲(chǔ) CSD2000 提供更高的壓縮率,幾乎是MySQL自帶壓縮的2倍以上,如下所示:
再看性能,使用sysbench測試1/4/16/64/256/512并發(fā)下性能表現(xiàn),可以觀察到(如下圖所示):
≥ 64并發(fā)時(shí),CSD2000 QPS/TPS平均提高~5倍,最高提高~12倍,99%平均時(shí)延降低68%以上;
《64并發(fā)時(shí),CSD2000 QPS/TPS普遍高于普通NVMe SSD 20%~50%,99%平均時(shí)延降低8%~45%;
說明:為了便于對(duì)比,以普通NVMe SSD指標(biāo)為基線做歸一化。
Mark Callaghan (Facebook Distinguished Engineer)曾經(jīng)吐槽在數(shù)據(jù)庫中實(shí)現(xiàn)透明頁壓縮并應(yīng)用在生產(chǎn)環(huán)境,工程實(shí)現(xiàn)過于復(fù)雜,難怪Jens Axboe(Linux內(nèi)核代碼主要貢獻(xiàn)者之一,F(xiàn)IO和IO_URING的作者)建議他把這些工作丟給計(jì)算型存儲(chǔ)公司 ScaleFlux。而從計(jì)算型存儲(chǔ)帶來的壓縮及性能(詳見:可計(jì)算存儲(chǔ):數(shù)據(jù)壓縮和數(shù)據(jù)庫計(jì)算下推)收益來看已經(jīng)超額完成任務(wù)。
計(jì)算型存儲(chǔ)和文件系統(tǒng)
壓縮同時(shí)減少數(shù)據(jù)寫入量(Nand Written)和寫放大(Write Amplification),但實(shí)際的情況會(huì)更復(fù)雜一些,大多數(shù)情況下數(shù)據(jù)庫運(yùn)行在文件系統(tǒng)之上。
以日志型文件系統(tǒng)ext4為例,設(shè)計(jì)以下測試驗(yàn)證日志寫入量與數(shù)據(jù)庫數(shù)據(jù)寫入量的比例及透明壓縮對(duì)于減少寫入量的收益:
選用 MySQL 和 MariaDB;
200GB數(shù)據(jù)集;
3種負(fù)載模型:Insert/Update-Index/Update-Non-Index;
兩種數(shù)據(jù)訪問方式:熱點(diǎn)集中(Non-uniform Key Distribution) 和全隨機(jī)(Uniform Key Distribution);
最終測試結(jié)果如下:
因?yàn)槲募到y(tǒng)的 WAL(Write Ahead Log)機(jī)制,加上日志的稀疏結(jié)構(gòu),日志寫入量占整體寫入量20%~90%,可見文件系統(tǒng)日志寫入量可能大于上層應(yīng)用(數(shù)據(jù)庫)的數(shù)據(jù)寫入量;
透明壓縮對(duì)于減少數(shù)據(jù)庫數(shù)據(jù)量的寫入效果明顯,對(duì)于減少日志系統(tǒng)寫入量的效果更加顯著,全部測試場景減少日志寫入量約4~5倍;
說明:以普通NVMe SSD指標(biāo)為基線做歸一化,直方圖面積越小,數(shù)據(jù)寫入量越少。
人類的智慧注定都要在山頂相遇
亞馬遜經(jīng)常談?wù)搯蜗颍╫ne-way)和雙向(two-way)門決策。雙向門決策容易逆轉(zhuǎn),例如A/B test,這類決策可以快速采取行動(dòng),即使失敗,成本也不高。單向門決策大多數(shù)時(shí)候不可撤銷,必須”大膽假設(shè),小心求證“。Nitro 顯而易見是一個(gè)單向(one-way)門決策,即便是2012年開始,AWS也花了足足7年時(shí)間才完整落地。
在異構(gòu)計(jì)算領(lǐng)域,頭部云計(jì)算廠已經(jīng)達(dá)成共識(shí),相關(guān)產(chǎn)品也加速推出,包括支持計(jì)算下推的阿里云PolarDB(詳見:可計(jì)算存儲(chǔ):數(shù)據(jù)壓縮和數(shù)據(jù)庫計(jì)算下推),以及 AWS re:Invent2020 再次提到的基于 AUQA(Advanced Query Accelerator) 節(jié)點(diǎn)加速的 Redshift。
風(fēng)物長宜放眼量,人類的智慧注定都要在山頂相遇。
責(zé)任編輯:haq
-
存儲(chǔ)
+關(guān)注
關(guān)注
13文章
4123瀏覽量
85279 -
計(jì)算機(jī)
+關(guān)注
關(guān)注
19文章
7174瀏覽量
87158 -
AWS
+關(guān)注
關(guān)注
0文章
418瀏覽量
24184
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論