我們通過一個(gè)具體場景來描述 Open-Channel SSD 的價(jià)值。RocksDB 作為一個(gè)單機(jī)存儲引擎，被廣泛應(yīng)用在很多分布式存儲的場景中。RocksDB 的數(shù)據(jù)存儲采用 LSM-Tree + WAL 的方式，其中，LSM-Tree 用于存儲數(shù)據(jù)和索引，WAL 用于保證數(shù)據(jù)寫入的完整性（Data Integrity）。由于目前在 RocksDB 的實(shí)現(xiàn)中，LSM-Tree 中的 SSTable 和 WAL 都是文件系統(tǒng)上的一個(gè)文件，所以數(shù)據(jù)寫入 WAL 的過程中，也會觸發(fā)文件系統(tǒng)的數(shù)據(jù)保護(hù)機(jī)制，例如 Journaling。而文件系統(tǒng)在將數(shù)據(jù)寫入 Journal 時(shí)，也會觸發(fā) SSD FTL 層的數(shù)據(jù)保護(hù)機(jī)制。所以，一次 RocksDB 的寫請求會經(jīng)過三個(gè) IO 子系統(tǒng)：RocksDB，F(xiàn)ile System，F(xiàn)TL。每一層子系統(tǒng)為了保證數(shù)據(jù)完整性，都會產(chǎn)生寫放大（Write Amplification），使得一次寫入被放大幾十甚至上百倍。這個(gè)現(xiàn)象可以被形象的描述為『Log-On-Log』的現(xiàn)象。
而實(shí)際上，對于 RocksDB 的 WAL，以及文件系統(tǒng)的 Journal，實(shí)際上都是臨時(shí)性的寫入，并不需要底層系統(tǒng)額外的數(shù)據(jù)保護(hù)機(jī)制。Open-Channel SSD 的出現(xiàn)提供了打破這個(gè)現(xiàn)象的機(jī)會，如果在 RocksDB 可以繞過文件系統(tǒng)層以及 FTL，則可以將三層 Log 合并為一層，避免寫入放大，最大化發(fā)揮 SSD 的性能。
除了避免寫放大之外，在 LSM-Tree 數(shù)據(jù)結(jié)中，由于 SSTable 是只讀不可修改的，而 SSD 的 Block 也是只讀的（如果要寫入必須先擦寫），那么 RocksDB 可以利用 SSD 的這個(gè)特點(diǎn)，讓 SSTable 與 Block 對齊，將 LSM-Tree 中的刪除 SSTable 操作與 SSD 的 Block 回收操作合并，避免 SSD Block 回收時(shí)產(chǎn)生的數(shù)據(jù)拷貝操作，避免 GC 對性能產(chǎn)生影響。在?『An Efficient Design and Implementation of LSM-Tree based Key-Value Store on Open-Channel SSD』中，就實(shí)現(xiàn)了將 LevelDB 直接運(yùn)行在 Open-Channel SSD 上。
除了避免寫放大，Open-Channel SSD 還提供了實(shí)現(xiàn) IO Isolation 的可能性。由于 SSD 的物理特性，SSD 的性能和數(shù)據(jù)的物理布局緊密相關(guān)。SSD 的性能來自于每一個(gè) NAND 芯片的性能的總和。每一個(gè) NAND 芯片提供的 IO 性能很低，但由于 NAND 芯片之間可以進(jìn)行并行化，這使得 SSD 的整體性能非常高。換句話說，數(shù)據(jù)的布局決定了 IO 性能。然而由于傳統(tǒng)的 SSD 上運(yùn)行了 FTL，F(xiàn)TL 不僅會對數(shù)據(jù)的布局進(jìn)行重映射，同時(shí)在后臺還會運(yùn)行 GC 任務(wù)，這使得 SSD 的性能是無法預(yù)測的，也無法進(jìn)行隔離。Open-Channel SSD 將底層信息暴露給上層應(yīng)用，通過將數(shù)據(jù)放置在不同的 NAND 芯片上，可以在物理層面達(dá)到數(shù)據(jù)分布隔離，同時(shí)也就打到了性能的隔離的效果。
為了方便的管理和操作 Open-Channel SSD，LightNVM?應(yīng)運(yùn)而生。LightNVM 是在 Linux Kernel 中一個(gè)針對 Open-Channel SSD 的 Subsystem。LightNVM 提供了一套新的接口，用于管理 Open-Channel SSD，以及執(zhí)行 IO 操作。為了和 Kernel 中現(xiàn)有的 IO 子系統(tǒng)協(xié)同工作，還存在 pblk（Physical Block Device）層。他在 LightNVM 的基礎(chǔ)上實(shí)現(xiàn)了 FTL 的功能，同時(shí)對上層暴露傳統(tǒng)的 Block 層接口，使得現(xiàn)有的文件系統(tǒng)可以通過 pblk 直接運(yùn)行在 Open-Channel SSD 上。2017 年 FAST 上的一篇 paper：『LightNVM: The Linux Open-Channel SSD Subsystem』專門介紹了 LightNVM。
目前 LightNVM 已經(jīng)被合并入 Kernel 的主線。而對于用戶態(tài)的程序來說，可以通過 liblightnvm 操作 Open-Channel SSD。
2018 年 1 月，Open-Channel SSD 發(fā)布了?2.0?版本的標(biāo)準(zhǔn)。但無論是 Open-Channel SSD，還是 LightNVM 都還處于非常早期的階段，目前在市面上很難見到 Open-Channel SSD，不適合直接投入到生產(chǎn)中。盡管如此，Open-Channel SSD 和 Host based FTL 帶來的好處是非常巨大的。對于追求極致存儲性能的場景，在未來很可能會采用 Open-Channel SSD + LightNVM 的實(shí)現(xiàn)方式。
NVM，或者 PM（persistent memory），SCM（storage class memory），實(shí)際上都是一個(gè)意思，指的都是非易失性內(nèi)存。NVM 在學(xué)術(shù)界火了很多年了， 相關(guān)的研究在不斷向前推進(jìn)。
一直以來，由于 2：8 定律的特性，計(jì)算機(jī)系統(tǒng)的存儲一直是采用分層的結(jié)構(gòu)，從上到下依次是 CPU Cache，DRAM，SSD，HDD。 其中，CPU Cache 和 DRAM 是易失性的（volatile），SSD 和 HDD 是非易失性的（non-volatile）。盡管 SSD 的速度遠(yuǎn)高于 HDD，但和 DDR 相比，還是有一定的差距。SSD 提供 10us 級別的響應(yīng)時(shí)間，而 DRAM 只有 ns 級別，這中間有一萬倍的差距。由于 DRAM 和 SSD 之間巨大的性能差距，使得應(yīng)用程序需要非常仔細(xì)的設(shè)計(jì) IO 相關(guān)的操作，避免 IO 成為系統(tǒng)的性能瓶頸。
而 NVM 的出現(xiàn)彌補(bǔ)了這個(gè)差距。NVM 在保持非易失性的前提下，將響應(yīng)時(shí)間降低到 10ns 級別，同時(shí)單位容量價(jià)格低于 DRAM。此外，NVM 是按字節(jié)訪問（byte-addressable），而不像磁盤按照塊（Block）訪問。NVM 的出現(xiàn)打破了傳統(tǒng)的存儲層次，將對軟件架構(gòu)設(shè)計(jì)產(chǎn)生巨大的影響。
NVM 看上去很美好，但目前并不能像內(nèi)存或磁盤一樣，做到即插即用。在傳統(tǒng)的操作系統(tǒng)中，Virtual Memory Manager（VMM）負(fù)責(zé)管理易失性內(nèi)存，文件系統(tǒng)負(fù)責(zé)管理存儲。而 NVM 既像內(nèi)存一樣可以通過字節(jié)訪問，又像磁盤一樣具有非易失性的特點(diǎn)。使用 NVM 的方式主要有兩種：
面向 NVM 進(jìn)行編程和面向傳統(tǒng)的內(nèi)存或磁盤編程是非常不同，這里我們舉一個(gè)非常簡單的例子。例如，有一個(gè)函數(shù)用于執(zhí)行雙鏈表插入操作：
void list_add_tail(struct cds_list_head *newp, struct cds_list_head *head) {
head->prev->next = newp;
newp->next = head;
newp->prev = head->prev;
head->prev = newp;
}
然而對于 NVM 來說，由于是非易失性的，假設(shè)在執(zhí)行到函數(shù)的第一行后發(fā)生了斷電，當(dāng)系統(tǒng)恢復(fù)后，鏈表處于一個(gè)異常且無法恢復(fù)的狀態(tài)。同時(shí)，由于 CPU 和 NVM 之間還有 CPU Cache 作為緩存，以及 CPU 執(zhí)行具有亂序執(zhí)行的特性，所以 NVM 需要使用特殊的編程模型，也就是 NVM Programming Model。通過顯示的指定 Transaction，達(dá)到原子性操作的語義，保證當(dāng)系統(tǒng)恢復(fù)時(shí)，不會產(chǎn)生中間狀態(tài)。
在分布式場景下，如果要充分發(fā)揮 NVM 的性能，就必須和 RDMA 結(jié)合。由于 NVM 的超高的性能，Byte Addressable 的訪問特性，以及 RDMA 的訪問方式，使得分布式的 NVM + RDMA 需要全新的架構(gòu)設(shè)計(jì)，包括單機(jī)數(shù)據(jù)結(jié)構(gòu)，分布式數(shù)據(jù)結(jié)構(gòu)，分布式一致性算法等等。在這方面，清華計(jì)算機(jī)系高性能所去年發(fā)表的?Octopus?提供了一個(gè)思路，通過 NVM + RDMA 實(shí)現(xiàn)了分布式文件系統(tǒng)，同時(shí)在自己實(shí)現(xiàn)一套基于 RDMA 的 RPC 用于進(jìn)行節(jié)點(diǎn)間的通信。
然而尷尬的是，盡管學(xué)術(shù)界在 NVM 上已經(jīng)研究了數(shù)十年，但在工業(yè)界目前還沒有可以大規(guī)模商用的 NVM 產(chǎn)品，大家還只能基于模擬器進(jìn)行研究。Intel 和 Micro 在 2012 年合作一起研發(fā) 3D XPoint 技術(shù)，被認(rèn)為是最接近能商用的 NVM 產(chǎn)品。Intel 在 2017 年發(fā)布了基于 3D XPoint 技術(shù)的磁盤產(chǎn)品 Optane，而 NVM 產(chǎn)品（代號 Apache Pass）還沒有明確的發(fā)布時(shí)間。
然而即使 NVM 產(chǎn)品面世，由于 NVM 的價(jià)格和容量的限制，以及復(fù)雜的編程模式，在實(shí)際生產(chǎn)中很少會出現(xiàn)純 NVM 的場景，更多的還是 tiering 的形式，也就是 NVM + SSD + HDD 的組合。在這個(gè)方面，2017 SOSP 上的一篇論文?Strata?也提供了一個(gè)不錯(cuò)的思路。
去年 Jeff Dean 所在的 Google Brain 團(tuán)隊(duì)發(fā)表了一篇非常重要的論文『The Case for Learned Index Structures』。可以說從這篇文章開始，系統(tǒng)領(lǐng)域展開了一個(gè)新的方向，Machine Learning 與系統(tǒng)相結(jié)合。不得不贊嘆 Jeff Dean 對計(jì)算機(jī)科學(xué)的影響力。
這篇文章，以及 Jeff Dean 在 NIPS17 ML Systems Workshop 上的?talk，都釋放出了一個(gè)很強(qiáng)的信號，計(jì)算機(jī)系統(tǒng)中包含了大量的 Heuristics 算法，用于做各種各樣的決策，例如 TCP 窗口應(yīng)該設(shè)置為多大，是否應(yīng)該對數(shù)據(jù)進(jìn)行緩存，應(yīng)該調(diào)度哪一個(gè)任務(wù)等等。而每一種算法都存在性能，資源消耗，錯(cuò)誤率，以及其他方面的 Tradeoff，需要大量的人工成本進(jìn)行選擇和調(diào)優(yōu)。而這些正是Machine Learning 可以發(fā)揮的地方。
在?『The Case for Learned Index Structures』?文章中，作者提到了一個(gè)典型的場景，數(shù)據(jù)庫的索引。傳統(tǒng)的索引通常采用 B 樹，或 B 樹的變種。然而這些數(shù)據(jù)結(jié)構(gòu)通常是為了一個(gè)通用的場景，以及最差的數(shù)據(jù)分布而進(jìn)行設(shè)計(jì)的，并沒有考慮到實(shí)際應(yīng)用中數(shù)據(jù)分布情況。對于很多特殊的數(shù)據(jù)分布場景，B 樹并不能夠達(dá)到最優(yōu)的時(shí)間和空間復(fù)雜度。為了達(dá)到最佳效果，需要投入大量的人力進(jìn)行數(shù)據(jù)結(jié)構(gòu)的優(yōu)化。同時(shí)，由于數(shù)據(jù)的分布在不斷的變化，調(diào)優(yōu)的工作也是持續(xù)不斷的。作者提出的的 Learned Index，則是通過與 Machine Learning 技術(shù)結(jié)合，避免人工調(diào)優(yōu)的開銷。
在這篇文章中，作者把索引數(shù)據(jù)結(jié)構(gòu)當(dāng)做一個(gè) Model，這個(gè) Model 的輸入是一個(gè) Key，輸出是這個(gè) Key 對應(yīng)的 Value 在磁盤中的位置。而 B 樹或其他的數(shù)據(jù)結(jié)構(gòu)只是實(shí)現(xiàn)這個(gè) Model 的一種方式，而這個(gè) Model 也可以存在其他的實(shí)現(xiàn)形式，例如神經(jīng)網(wǎng)絡(luò)。
和 B 樹相比，神經(jīng)網(wǎng)絡(luò)具有很大的優(yōu)勢：
通過進(jìn)行離線的模型訓(xùn)練，犧牲一定的計(jì)算資源，可以達(dá)到節(jié)省內(nèi)存資源，以及提高性能的效果。
當(dāng)然，這種方法也存在一定的局限性。其中最重要的一點(diǎn)，就是 Learned Index 只能索引固定數(shù)據(jù)分布的數(shù)據(jù)。當(dāng)有數(shù)據(jù)插入時(shí)導(dǎo)致數(shù)據(jù)分布發(fā)生了變更，原有的模型就會失效。解決的方案是對于新增的數(shù)據(jù)，依然采用傳統(tǒng)的數(shù)據(jù)結(jié)構(gòu)進(jìn)行索引，Learned Index 只負(fù)責(zé)索引原有數(shù)據(jù)。當(dāng)新增數(shù)據(jù)積累到一定程度時(shí)，將新數(shù)據(jù)與原有數(shù)據(jù)進(jìn)行合并，并根據(jù)新的數(shù)據(jù)分布訓(xùn)練出新的模型。這種方法是很可行的，畢竟和新增數(shù)據(jù)量相比，全量數(shù)據(jù)是非常大的。如果能對全量數(shù)據(jù)的索引進(jìn)行優(yōu)化，那應(yīng)用價(jià)值也是巨大的。
盡管存在一定的局限性，Learned Index 還是有很多適用的場景，例如 Google 已經(jīng)將其應(yīng)用在了 BigTable 中。相信 Learned Index 只是一個(gè)開端，未來會有越來越多的 System 和 Machine Learning 結(jié)合的工作出現(xiàn)。
LSM-Tree 是 LevelDB，以及 LevelDB 的變種，RocksDB，HyperDB 等單機(jī)存儲引擎的核心數(shù)據(jù)結(jié)構(gòu)。
LSM-Tree 本身的原理我們不過多介紹。目前 LSM-Tree 最大的痛點(diǎn)是讀寫放大，這使得性能往往只能提供裸硬件的不到 10%。所以關(guān)于解決 LSM-Tree 讀寫放大問題成為近些年研究的熱點(diǎn)。
在 2016 年 FAST 會議上發(fā)表的論文?WiscKey?提出了將 Key 與 Value 分開存放的方法。傳統(tǒng) LSM-Tree 將 Key 和 Value 相鄰存放，保證 Key 和 Value 在磁盤上都是有序的。這提高了 Range Query 的效率。然而，當(dāng)進(jìn)行 Compaction 時(shí)，由于需要同時(shí)操作 Key 和 Value，所以造成了較大讀寫比例放大。而在 WiscKey 中，通過將 Key 和 Value 分開存放，Key 保持 LSM-Tree 結(jié)構(gòu)，保證 Key 在磁盤上的有序性，而 Value 使用所謂 『Value Log』 結(jié)構(gòu)，很像 Log-Structured File System 中的一個(gè) Segment。通過在 Key 中保存 Value 在磁盤上的位置，使得可以通過 Key 讀取到 Value。由于 LSM-Tree 中只保存 Key，不保存 Value，且 Key 的大小通常遠(yuǎn)小于 Value 的大小，所以 WiscKey 中的 LSM-Tree 的大小遠(yuǎn)小于傳統(tǒng) LSM-Tree 的大小，因此 Compaction 引入的讀寫放大可以控制在非常小的比例。WiscKey 的缺點(diǎn)是犧牲了 Range Query 的性能。由于相鄰 Key 的 Value 在磁盤上并沒有存在相鄰的位置，WiscKey 中對連續(xù)的 Key 讀取被轉(zhuǎn)化成隨機(jī)磁盤讀取操作。而作者通過將預(yù)讀（Prefetching）IO 并行化的方式，盡可能降低對順序讀性能的影響。
而在 2017 年 SOSP 上發(fā)表的論文?PebblesDB?提出了另外一種思路。在傳統(tǒng) LSM-Tree 中，每一層由多個(gè) SSTable 組成，每一個(gè) SSTable 中保存了一組排好序 Key-Value，相同層的 SSTable 之間的 Key 沒有重疊。當(dāng)進(jìn)行 Compaction 時(shí)，上層的 SSTable 需要與下層的 SSTable 進(jìn)行合并，也就是將上層的 SSTable 和下層的 SSTable 讀取到內(nèi)存中，進(jìn)行合并排序后，組成新的 SSTable，并寫回到磁盤中。由于 Compaction 的過程中需要讀取和寫入下層的 SSTable，所以造成了讀寫放大，影響應(yīng)能。
PebblesDB 將 LSM-Tree 和 Skip-List 數(shù)據(jù)結(jié)構(gòu)進(jìn)行結(jié)合。在 LSM-Tree 中每一層引入 Guard 概念。 每一層中包含多個(gè) Guard，Guard 和 Guard 之間的 Key 的范圍是有序的，且沒有重疊，但 Guard 內(nèi)部包含多個(gè) SSTable，這些 SSTable 的 Key 的范圍允許重疊。
當(dāng)需要進(jìn)行 Compaction 時(shí)，只需要將上層的 SSTable 讀入內(nèi)存，并按照下層的 Guard 將 SSTable 切分成多個(gè)新的 SSTable，并存放到下層對應(yīng)的 Guard 中。在這個(gè)過程中不需要讀取下層的 SSTable，也就在一定程度上避免了讀寫放大。作者將這種數(shù)據(jù)結(jié)構(gòu)命名為 Fragemented Log-Structured Tree（FLSM）。PebblesDB 最多可以減低 6.7 倍的寫放大，寫入性能最多提升 105%。
和 WiscKey 類似，PebblesDB 也會多 Range Query 的性能造成影響。這是由于 Guard 內(nèi)部的 SSTable 的 Key 存在重疊，所以在讀取連續(xù)的 Key 時(shí)，需要同時(shí)讀取 Guard 中所有的 SSTable，才能夠獲得正確的結(jié)果。
WiscKey 和 PebblesDB 都已經(jīng)開源，但在目前最主流的單機(jī)存儲引擎 LevelDB 和 RocksDB 中，相關(guān)優(yōu)化還并沒有得到體現(xiàn)。我們也期待未來能有更多的關(guān)于 LSM-Tree 相關(guān)的優(yōu)化算法出現(xiàn)。
Crash Consistency 的意思是，存儲系統(tǒng)可以在故障發(fā)生后，保證系統(tǒng)數(shù)據(jù)的正確性以及數(shù)據(jù)，元數(shù)據(jù)的一致性?？梢哉f Crash Consistency 是存儲領(lǐng)域永恒不變的話題。
早些年大家熱衷于通過各種方法在已實(shí)現(xiàn)的文件系統(tǒng)中尋找 Bug，而這兩年構(gòu)造一個(gè)新的 Bug Free 的文件系統(tǒng)成為熱門的方向。在這方面最早做出突破的是 MIT 的團(tuán)隊(duì)的?FSCQ。FSCQ 通過 Coq 作為輔助的形式化驗(yàn)證工具，在 Crash Hoare Logic 的基礎(chǔ)上，實(shí)現(xiàn)了一個(gè)被證明過 Crash Safty 的文件系統(tǒng)。
然而使用 Coq 的代價(jià)是需要人工手動(dòng)完成證明過程，這使得完成一個(gè)文件系統(tǒng)的工作量被放大了幾倍，例如 FSCQ 的證明過程花費(fèi)了 1.5 年。
而 Washington 大學(xué)提出的?Yggdrasil?則基于 Z3，將文件系統(tǒng)證明過程自動(dòng)化，也就是最近非常流行的『Push-Button Verification』 的方法。
值得注意的是，無論是 FSCQ 還是 Yggdrasil 都存在著巨大的局限性，例如不支持多線程訪問，文件系統(tǒng)功能并不完備，性能較弱，以及代碼生成過程中依賴一些沒有被驗(yàn)證過的工具等等。我們距離構(gòu)建一個(gè)在通用場景下可以完全替代已有文件系統(tǒng)（如 ext4）還有很長的路要走。這也依賴于形式化驗(yàn)證方面的技術(shù)突破。
隨著虛擬化技術(shù)的成熟和普及，存儲的接入端逐漸從 HBA 卡或傳統(tǒng)操作系統(tǒng)，轉(zhuǎn)變?yōu)?Hypervisor。在 Linux KVM 方面，隨著存儲性能逐漸提高，原有的 virtio 架構(gòu)逐漸成為了性能瓶頸，vhost 逐漸開始普及。所謂 vhost 就是把原有 Qemu 對于 IO 設(shè)備模擬的代碼放到了 Kernel 中，包含了 vhost-blk，以及 vhost-net。由 Kernel 直接將 IO 請求發(fā)給設(shè)備。通過減少上下文的切換，避免額外的性能開銷。
在容器方面，隨著 K8S 的應(yīng)用和成熟，在 K8S 的存儲方面也誕生了一些新的項(xiàng)目。比如?rook.io?是基于 K8S 的編排工具。而 K8S 本身也發(fā)布了?Container Storage Interface（CSI），用于第三方存儲廠商更好的開發(fā) K8S 的存儲插件。未來也會看到越來越多的存儲廠商對 K8S 進(jìn)行支持。
2017 年 Linux Kernel 共發(fā)布了 5 個(gè)版本，從 4.10 到 4.14，目前最新的版本是 4.15。其中存儲相關(guān)比較值得注意的變化包括：AIO 改進(jìn)，Block Layer 錯(cuò)誤處理改進(jìn)，基于 MQ 的調(diào)度器 Kyber?等等。然而比較悲傷的消息是，為了修復(fù) Meltdown 和 Spectrue 漏洞，Kernel 引入了?Kernel Page Table Isolation（KPTI）技術(shù)，這導(dǎo)致系統(tǒng)調(diào)用和上下文切換的開銷變得更大。Brendan Gregg 在他的博客中詳細(xì)分析了 KPTI 對性能產(chǎn)生的影響。對于系統(tǒng)調(diào)用與上下文切換越頻繁的應(yīng)用，對性能的影響越大。也就是說，IO 密集型的應(yīng)用將受到比較大的影響，而計(jì)算密集型的應(yīng)用則影響不大。
在企業(yè)級存儲方面，去年有很多存儲廠商都開始向純軟件廠商進(jìn)行轉(zhuǎn)型，包括 Nutanix，Kaminario 以及 E8 等等。向軟件化轉(zhuǎn)型并不是處于技術(shù)的原因，而是商業(yè)的考慮?？紤]到 Dell 和 EMC 的合并，存儲硬件的利潤率必定會不斷下降。軟件化最大的好處，就是可以提升財(cái)務(wù)報(bào)表中的利潤率，使得公司的財(cái)務(wù)狀況更加健康，也避免了和 Dell EMC 的存儲硬件發(fā)生競爭。
在資本市場方面，2017 年可以說是波瀾不驚。上圖是 2017 年存儲行業(yè)發(fā)生的并購案。其中 Toshiba Memory 被收購的案件是存儲行業(yè)歷史上第三大收購案（第一名是 Dell 收購 EMC）。
以上是作者對當(dāng)前存儲熱點(diǎn)和趨勢的不完整的總結(jié)。希望幫助讀者對存儲領(lǐng)域增加一點(diǎn)點(diǎn)了解，或者是對存儲技術(shù)產(chǎn)生一點(diǎn)點(diǎn)的興趣。也歡迎大家把自己感興趣的話題寫在評論里，我們將在后面盡可能的為大家進(jìn)行介紹。
順便廣告一下，SmartX 是全球技術(shù)領(lǐng)先的分布式存儲廠商，如果想在存儲領(lǐng)域做出一番事業(yè)的話，歡迎加入 SmartX。
@張凱(Kyle Zhang)，SmartX 聯(lián)合創(chuàng)始人 & CTO。SmartX?擁有國內(nèi)最頂尖的分布式存儲和超融合架構(gòu)研發(fā)團(tuán)隊(duì)，是國內(nèi)超融合領(lǐng)域的技術(shù)領(lǐng)導(dǎo)者。
文章 來源：SmartX知乎專欄
