硬盤物理結(jié)構(gòu)

硬盤內(nèi)部主要部件為磁盤盤片、傳動手臂、讀寫磁頭和主軸馬達(dá)。實際數(shù)據(jù)都是寫在盤片上，讀寫主要是通過傳動手臂上的讀寫磁頭來完成。實際運行時，主軸讓磁盤盤片轉(zhuǎn)動，然后傳動手臂可伸展讓讀取頭在盤片上進(jìn)行讀寫操作

image.png

影響硬盤性能的因素

影響磁盤的關(guān)鍵因素是磁盤服務(wù)時間，即磁盤完成一個I/O請求所花費的時間，它由尋道時間、旋轉(zhuǎn)延遲和數(shù)據(jù)傳輸時間三部分構(gòu)成。

1. 尋道時間
   Tseek是指將讀寫磁頭移動至正確的磁道上所需要的時間。尋道時間越短，I/O操作越快，目前磁盤的平均尋道時間一般在3-15ms。

2. 旋轉(zhuǎn)延遲
   Trotation是指盤片旋轉(zhuǎn)將請求數(shù)據(jù)所在的扇區(qū)移動到讀寫磁盤下方所需要的時間。旋轉(zhuǎn)延遲取決于磁盤轉(zhuǎn)速，通常用磁盤旋轉(zhuǎn)一周所需時間的1/2表示。比如：7200rpm的磁盤平均旋轉(zhuǎn)延遲大約為60*1000/7200/2 = 4.17ms，而轉(zhuǎn)速為15000rpm的磁盤其平均旋轉(zhuǎn)延遲為2ms。

3. 數(shù)據(jù)傳輸時間
   Ttransfer是指完成傳輸所請求的數(shù)據(jù)所需要的時間，它取決于數(shù)據(jù)傳輸率，其值等于數(shù)據(jù)大小除以數(shù)據(jù)傳輸率。目前IDE/ATA能達(dá)到133MB/s，SATA II可達(dá)到300MB/s的接口數(shù)據(jù)傳輸率，數(shù)據(jù)傳輸時間通常遠(yuǎn)小于前兩部分消耗時間。簡單計算時可忽略。

衡量性能的指標(biāo)

機械硬盤的連續(xù)讀寫性能很好，但隨機讀寫性能很差，這主要是因為磁頭移動到正確的磁道上需要時間，隨機讀寫時，磁頭需要不停的移動，時間都浪費在了磁頭尋址上，所以性能不高。衡量磁盤的重要主要指標(biāo)是IOPS和吞吐量。

1. IOPS
   IOPS（Input/Output Per Second）即每秒的輸入輸出量（或讀寫次數(shù)），即指每秒內(nèi)系統(tǒng)能處理的I/O請求數(shù)量。隨機讀寫頻繁的應(yīng)用，如小文件存儲等，關(guān)注隨機讀寫性能，IOPS是關(guān)鍵衡量指標(biāo)。可以推算出磁盤的IOPS = 1000ms / (Tseek + Trotation + Transfer)，如果忽略數(shù)據(jù)傳輸時間，理論上可以計算出隨機讀寫最大的IOPS。常見磁盤的隨機讀寫最大IOPS為：

7200rpm的磁盤 IOPS = 76 IOPS
10000rpm的磁盤IOPS = 111 IOPS
15000rpm的磁盤IOPS = 166 IOPS

2. 吞吐量
   吞吐量（Throughput），指單位時間內(nèi)可以成功傳輸?shù)臄?shù)據(jù)數(shù)量。順序讀寫頻繁的應(yīng)用，如視頻點播，關(guān)注連續(xù)讀寫性能、數(shù)據(jù)吞吐量是關(guān)鍵衡量指標(biāo)。它主要取決于磁盤陣列的架構(gòu)，通道的大小以及磁盤的個數(shù)。不同的磁盤陣列存在不同的架構(gòu)，但他們都有自己的內(nèi)部帶寬，一般情況下，內(nèi)部帶寬都設(shè)計足夠充足，不會存在瓶頸。磁盤陣列與服務(wù)器之間的數(shù)據(jù)通道對吞吐量影響很大，比如一個2Gbps的光纖通道，其所能支撐的最大流量僅為250MB/s。最后，當(dāng)前面的瓶頸都不再存在時，硬盤越多的情況下吞吐量越大。

操作系統(tǒng)層的優(yōu)化

雖然15000rpm的磁盤計算出的理論最大IOPS僅為166，但在實際運行環(huán)境中，實際磁盤的IOPS往往能夠突破200甚至更高。這其實就是在系統(tǒng)調(diào)用過程中，操作系統(tǒng)進(jìn)行了一系列的優(yōu)化。

那么操作系統(tǒng)是如何操作硬盤的呢？類似于網(wǎng)絡(luò)的分層結(jié)構(gòu)，下圖顯示了Linux系統(tǒng)中對于磁盤的一次讀請求在核心空間中所要經(jīng)歷的層次模型。從圖中看出：對于磁盤的一次讀請求，首先經(jīng)過虛擬文件系統(tǒng)層（VFS Layer），其次是具體的文件系統(tǒng)層（例如Ext2），接下來是Cache層（Page Cache Layer）、通用塊層（Generic Block Layer）、I/O調(diào)度層（I/O Scheduler Layer）、塊設(shè)備驅(qū)動層（Block Device Driver Layer），最后是物理塊設(shè)備層（Block Device Layer）

image.png

虛擬文件系統(tǒng)層（VFS Layer）
VFS（Virtual File System）虛擬文件系統(tǒng)是一種軟件機制，更確切的說扮演著文件系統(tǒng)管理者的角色，與它相關(guān)的數(shù)據(jù)結(jié)構(gòu)只存在于物理內(nèi)存當(dāng)中。它的作用是：屏蔽下層具體文件系統(tǒng)操作的差異，為上層的操作提供一個統(tǒng)一的接口。正是因為有了這個層次，Linux中允許眾多不同的文件系統(tǒng)共存并且對文件的操作可以跨文件系統(tǒng)而執(zhí)行。

VFS中包含著向物理文件系統(tǒng)轉(zhuǎn)換的一系列數(shù)據(jù)結(jié)構(gòu)，如VFS超級塊、VFS的Inode、各種操作函數(shù)的轉(zhuǎn)換入口等。Linux中VFS依靠四個主要的數(shù)據(jù)結(jié)構(gòu)來描述其結(jié)構(gòu)信息，分別為超級塊、索引結(jié)點、目錄項和文件對象。

超級塊（Super Block）：超級塊對象表示一個文件系統(tǒng)。它存儲一個已安裝的文件系統(tǒng)的控制信息，包括文件系統(tǒng)名稱（比如Ext2）、文件系統(tǒng)的大小和狀態(tài)、塊設(shè)備的引用和元數(shù)據(jù)信息（比如空閑列表等等）。VFS超級塊存在于內(nèi)存中，它在文件系統(tǒng)安裝時建立，并且在文件系統(tǒng)卸載時自動刪除。同時需要注意的是對于每個具體的文件系統(tǒng)來說，也有各自的超級塊，它們存放于磁盤。

索引結(jié)點（Inode）：索引結(jié)點對象存儲了文件的相關(guān)元數(shù)據(jù)信息，例如：文件大小、設(shè)備標(biāo)識符、用戶標(biāo)識符、用戶組標(biāo)識符等等。Inode分為兩種：一種是VFS的Inode，一種是具體文件系統(tǒng)的Inode。前者在內(nèi)存中，后者在磁盤中。所以每次其實是將磁盤中的Inode調(diào)進(jìn)填充內(nèi)存中的Inode，這樣才是算使用了磁盤文件Inode。當(dāng)創(chuàng)建一個文件的時候，就給文件分配了一個Inode。一個Inode只對應(yīng)一個實際文件，一個文件也會只有一個Inode。

目錄項（Dentry）：引入目錄項對象的概念主要是出于方便查找文件的目的。不同于前面的兩個對象，目錄項對象沒有對應(yīng)的磁盤數(shù)據(jù)結(jié)構(gòu)，只存在于內(nèi)存中。一個路徑的各個組成部分，不管是目錄還是普通的文件，都是一個目錄項對象。如，在路徑/home/source/test.java中，目錄 /, home, source和文件 test.java都對應(yīng)一個目錄項對象。VFS在查找的時候，根據(jù)一層一層的目錄項找到對應(yīng)的每個目錄項的Inode，那么沿著目錄項進(jìn)行操作就可以找到最終的文件。

文件對象（File）：文件對象描述的是進(jìn)程已經(jīng)打開的文件。因為一個文件可以被多個進(jìn)程打開，所以一個文件可以存在多個文件對象。一個文件對應(yīng)的文件對象可能不是惟一的，但是其對應(yīng)的索引節(jié)點和目錄項對象肯定是惟一的。

Page Cache層

引入Cache層的目的是為了提高Linux操作系統(tǒng)對磁盤訪問的性能。Cache層在內(nèi)存中緩存了磁盤上的部分?jǐn)?shù)據(jù)。當(dāng)數(shù)據(jù)的請求到達(dá)時，如果在Cache中存在該數(shù)據(jù)且是最新的，則直接將數(shù)據(jù)傳遞給用戶程序，免除了對底層磁盤的操作，提高了性能。Cache層也正是磁盤IOPS為什么能突破200的主要原因之一。

在Linux的實現(xiàn)中，文件Cache分為兩個層面，一是Page Cache，另一個Buffer Cache，每一個Page Cache包含若干Buffer Cache。Page Cache主要用來作為文件系統(tǒng)上的文件數(shù)據(jù)的緩存來用，尤其是針對當(dāng)進(jìn)程對文件有read/write操作的時候。Buffer Cache則主要是設(shè)計用來在系統(tǒng)對塊設(shè)備進(jìn)行讀寫的時候，對塊進(jìn)行數(shù)據(jù)緩存的系統(tǒng)來使用。

磁盤Cache有兩大功能：預(yù)讀和回寫。預(yù)讀其實就是利用了局部性原理，具體過程是：對于每個文件的第一個讀請求，系統(tǒng)讀入所請求的頁面并讀入緊隨其后的少數(shù)幾個頁面（通常是三個頁面），這時的預(yù)讀稱為同步預(yù)讀。對于第二次讀請求，如果所讀頁面不在Cache中，即不在前次預(yù)讀的頁中，則表明文件訪問不是順序訪問，系統(tǒng)繼續(xù)采用同步預(yù)讀；如果所讀頁面在Cache中，則表明前次預(yù)讀命中，操作系統(tǒng)把預(yù)讀頁的大小擴大一倍，此時預(yù)讀過程是異步的，應(yīng)用程序可以不等預(yù)讀完成即可返回，只要后臺慢慢讀頁面即可，這時的預(yù)讀稱為異步預(yù)讀。任何接下來的讀請求都會處于兩種情況之一：第一種情況是所請求的頁面處于預(yù)讀的頁面中，這時繼續(xù)進(jìn)行異步預(yù)讀；第二種情況是所請求的頁面處于預(yù)讀頁面之外，這時系統(tǒng)就要進(jìn)行同步預(yù)讀。

回寫是通過暫時將數(shù)據(jù)存在Cache里，然后統(tǒng)一異步寫到磁盤中。通過這種異步的數(shù)據(jù)I/O模式解決了程序中的計算速度和數(shù)據(jù)存儲速度不匹配的鴻溝，減少了訪問底層存儲介質(zhì)的次數(shù)，使存儲系統(tǒng)的性能大大提高。Linux 2.6.32內(nèi)核之前，采用pdflush機制來將臟頁真正寫到磁盤中，什么時候開始回寫呢？下面兩種情況下，臟頁會被寫回到磁盤：

1. 在空閑內(nèi)存低于一個特定的閾值時，內(nèi)核必須將臟頁寫回磁盤，以便釋放內(nèi)存。
2. 當(dāng)臟頁在內(nèi)存中駐留超過一定的閾值時，內(nèi)核必須將超時的臟頁寫會磁盤，以確保臟頁不會無限期地駐留在內(nèi)存中。

回寫開始后，pdflush會持續(xù)寫數(shù)據(jù)，直到滿足以下兩個條件：

1. 已經(jīng)有指定的最小數(shù)目的頁被寫回到磁盤。
2. 空閑內(nèi)存頁已經(jīng)回升，超過了閾值。

Linux 2.6.32內(nèi)核之后，放棄了原有的pdflush機制，改成了bdi_writeback機制。bdi_writeback機制主要解決了原有fdflush機制存在的一個問題：在多磁盤的系統(tǒng)中，pdflush管理了所有磁盤的Cache，從而導(dǎo)致一定程度的I/O瓶頸。bdi_writeback機制為每個磁盤都創(chuàng)建了一個線程，專門負(fù)責(zé)這個磁盤的Page Cache的刷新工作，從而實現(xiàn)了每個磁盤的數(shù)據(jù)刷新在線程級的分離，提高了I/O性能。

回寫機制存在的問題是回寫不及時引發(fā)數(shù)據(jù)丟失（可由sync|fsync解決），回寫期間讀I/O性能很差。

通用塊層

通用塊層的主要工作是：接收上層發(fā)出的磁盤請求，并最終發(fā)出I/O請求。該層隱藏了底層硬件塊設(shè)備的特性，為塊設(shè)備提供了一個通用的抽象視圖。

對于VFS和具體的文件系統(tǒng)來說，塊（Block）是基本的數(shù)據(jù)傳輸單元，當(dāng)內(nèi)核訪問文件的數(shù)據(jù)時，它首先從磁盤上讀取一個塊。但是對于磁盤來說，扇區(qū)是最小的可尋址單元，塊設(shè)備無法對比它還小的單元進(jìn)行尋址和操作。由于扇區(qū)是磁盤的最小可尋址單元，所以塊不能比扇區(qū)還小，只能整數(shù)倍于扇區(qū)大小，即一個塊對應(yīng)磁盤上的一個或多個扇區(qū)。一般來說，塊大小是2的整數(shù)倍，而且由于Page Cache層的最小單元是頁（Page），所以塊大小不能超過一頁的長度。

大多情況下，數(shù)據(jù)的傳輸通過DMA方式。舊的磁盤控制器，僅僅支持簡單的DMA操作：每次數(shù)據(jù)傳輸，只能傳輸磁盤上相鄰的扇區(qū)，即數(shù)據(jù)在內(nèi)存中也是連續(xù)的。這是因為如果傳輸非連續(xù)的扇區(qū)，會導(dǎo)致磁盤花費更多的時間在尋址操作上。而現(xiàn)在的磁盤控制器支持“分散/聚合”DMA操作，這種模式下，數(shù)據(jù)傳輸可以在多個非連續(xù)的內(nèi)存區(qū)域中進(jìn)行。為了利用“分散/聚合”DMA操作，塊設(shè)備驅(qū)動必須能處理被稱為段（segments）的數(shù)據(jù)單元。一個段就是一個內(nèi)存頁面或一個頁面的部分，它包含磁盤上相鄰扇區(qū)的數(shù)據(jù)。

通用塊層是粘合所有上層和底層的部分，一個頁的磁盤數(shù)據(jù)布局如下圖所示：

頁內(nèi)磁盤數(shù)據(jù)布局

I/O調(diào)度層

I/O調(diào)度層的功能是管理塊設(shè)備的請求隊列。即接收通用塊層發(fā)出的I/O請求，緩存請求并試圖合并相鄰的請求。并根據(jù)設(shè)置好的調(diào)度算法，回調(diào)驅(qū)動層提供的請求處理函數(shù)，以處理具體的I/O請求。

如果簡單地以內(nèi)核產(chǎn)生請求的次序直接將請求發(fā)給塊設(shè)備的話，那么塊設(shè)備性能肯定讓人難以接受，因為磁盤尋址是整個計算機中最慢的操作之一。為了優(yōu)化尋址操作，內(nèi)核不會一旦接收到I/O請求后，就按照請求的次序發(fā)起塊I/O請求。為此Linux實現(xiàn)了幾種I/O調(diào)度算法，算法基本思想就是通過合并和排序I/O請求隊列中的請求，以此大大降低所需的磁盤尋道時間，從而提高整體I/O性能。

常見的I/O調(diào)度算法包括Noop調(diào)度算法（No Operation）、CFQ（完全公正排隊I/O調(diào)度算法）、DeadLine（截止時間調(diào)度算法）、AS預(yù)測調(diào)度算法等。

• Noop算法：最簡單的I/O調(diào)度算法。該算法僅適當(dāng)合并用戶請求，并不排序請求。新的請求通常被插在調(diào)度隊列的開頭或末尾，下一個要處理的請求總是隊列中的第一個請求。這種算法是為不需要尋道的塊設(shè)備設(shè)計的，如SSD。因為其他三個算法的優(yōu)化是基于縮短尋道時間的，而SSD硬盤沒有所謂的尋道時間且I/O響應(yīng)時間非常短。

• CFQ算法：算法的主要目標(biāo)是在觸發(fā)I/O請求的所有進(jìn)程中確保磁盤I/O帶寬的公平分配。算法使用許多個排序隊列，存放了不同進(jìn)程發(fā)出的請求。通過散列將同一個進(jìn)程發(fā)出的請求插入同一個隊列中。采用輪詢方式掃描隊列，從第一個非空隊列開始，依次調(diào)度不同隊列中特定個數(shù)（公平）的請求，然后將這些請求移動到調(diào)度隊列的末尾。

• Deadline算法：算法引入了兩個排隊隊列分別包含讀請求和寫請求，兩個最后期限隊列包含相同的讀和寫請求。本質(zhì)就是一個超時定時器，當(dāng)請求被傳給電梯算法時開始計時。一旦最后期限隊列中的超時時間已到，就想請求移至調(diào)度隊列末尾。Deadline算法避免了電梯調(diào)度策略（為了減少尋道時間，會優(yōu)先處理與上一個請求相近的請求）帶來的對某個請求忽略很長一段時間的可能。

• AS算法：AS算法本質(zhì)上依據(jù)局部性原理，預(yù)測進(jìn)程發(fā)出的讀請求與剛被調(diào)度的請求在磁盤上可能是“近鄰”。算法統(tǒng)計每個進(jìn)程I/O操作信息，當(dāng)剛剛調(diào)度了由某個進(jìn)程的一個讀請求之后，算法馬上檢查排序隊列中的下一個請求是否來自同一個進(jìn)程。如果是，立即調(diào)度下一個請求。否則，查看關(guān)于該進(jìn)程的統(tǒng)計信息，如果確定進(jìn)程p可能很快發(fā)出另一個讀請求，那么就延遲一小段時間。

前文中計算出的IOPS是理論上的隨機讀寫的最大IOPS，在隨機讀寫中，每次I/O操作的尋址和旋轉(zhuǎn)延時都不能忽略不計，有了這兩個時間的存在也就限制了IOPS的大小?，F(xiàn)在如果我們考慮在讀取一個很大的存儲連續(xù)分布在磁盤的文件，因為文件的存儲的分布是連續(xù)的，磁頭在完成一個讀I/O操作之后，不需要重新尋址，也不需要旋轉(zhuǎn)延時，在這種情況下我們能到一個很大的IOPS值。這時由于不再考慮尋址和旋轉(zhuǎn)延時，則性能瓶頸僅是數(shù)據(jù)傳輸時延，假設(shè)數(shù)據(jù)傳輸時延為0.4ms，那么IOPS=1000 / 0.4 = 2500 IOPS。

在許多的開源框架如Kafka、HBase中，都通過追加寫的方式來盡可能的將隨機I/O轉(zhuǎn)換為順序I/O，以此來降低尋址時間和旋轉(zhuǎn)延時，從而最大限度的提高IOPS。

塊設(shè)備驅(qū)動層

驅(qū)動層中的驅(qū)動程序?qū)?yīng)具體的物理塊設(shè)備。它從上層中取出I/O請求，并根據(jù)該I/O請求中指定的信息，通過向具體塊設(shè)備的設(shè)備控制器發(fā)送命令的方式，來操縱設(shè)備傳輸數(shù)據(jù)。這里不再贅述。

基于磁盤I/O特性設(shè)計的技巧

在上一節(jié)中我們了解了Linux系統(tǒng)中請求到達(dá)磁盤的一次完整過程，期間Linux通過Cache以及排序合并I/O請求來提高系統(tǒng)的性能。其本質(zhì)就是由于磁盤隨機讀寫慢、順序讀寫快。本節(jié)針對常見開源系統(tǒng)闡述一些基于磁盤I/O特性的設(shè)計技巧。

采用追加寫

在進(jìn)行系統(tǒng)設(shè)計時，良好的讀性能和寫性能往往不可兼得。在許多常見的開源系統(tǒng)中都是優(yōu)先在保證寫性能的前提下來優(yōu)化讀性能。那么如何設(shè)計能讓一個系統(tǒng)擁有良好的寫性能呢？一個好的辦法就是采用追加寫，每次將數(shù)據(jù)添加到文件。由于完全是順序的，所以可以具有非常好的寫操作性能。但是這種方式也存在一些缺點：從文件中讀一些數(shù)據(jù)時將會需要更多的時間：需要倒序掃描，直到找到所需要的內(nèi)容。當(dāng)然在一些簡單的場景下也能夠保證讀操作的性能：

• 數(shù)據(jù)是被整體訪問，比如HDFS

  • HDFS建立在一次寫多次讀的模型之上。在HDFS中就是采用了追加寫并且設(shè)計為高數(shù)據(jù)吞吐量；高吞吐量必然以高延遲為代價，所以HDFS并不適用于對數(shù)據(jù)訪問要求低延遲的場景；由于采用是的追加寫，也并不適用于任意修改文件的場景。HDFS設(shè)計為流式訪問大文件，使用大數(shù)據(jù)塊并且采用流式數(shù)據(jù)訪問來保證數(shù)據(jù)被整體訪問，同時最小化硬盤的尋址開銷，只需要一次尋址即可，這時尋址時間相比于傳輸時延可忽略，從而也擁有良好的讀性能。HDFS不適合存儲小文件，原因之一是由于NameNode內(nèi)存不足問題，還有就是因為訪問大量小文件需要執(zhí)行大量的尋址操作，并且需要不斷的從一個datanode跳到另一個datanode，這樣會大大降低數(shù)據(jù)訪問性能。

• 知道文件明確的偏移量，比如Kafka

  • 在Kafka中，采用消息追加的方式來寫入每個消息，每個消息讀寫時都會利用Page Cache的預(yù)讀和后寫特性，同時partition中都使用順序讀寫，以此來提高I/O性能。雖然Kafka能夠根據(jù)偏移量查找到具體的某個消息，但是查找過程是順序查找，因此如果數(shù)據(jù)很大的話，查找效率就很低。所以Kafka中采用了分段和索引的方式來解決查找效率問題。Kafka把一個patition大文件又分成了多個小文件段，每個小文件段以偏移量命名，通過多個小文件段，不僅可以使用二分搜索法很快定位消息，同時也容易定期清除或刪除已經(jīng)消費完的文件，減少磁盤占用。為了進(jìn)一步提高查找效率，Kafka為每個分段后的數(shù)據(jù)建立了索引文件，并通過索引文件稀疏存儲來降低元數(shù)據(jù)占用大小。一個段中數(shù)據(jù)對應(yīng)結(jié)構(gòu)如下圖所示：

kafka中一個段的物理結(jié)構(gòu)

在面對更復(fù)雜的讀場景（比如按key）時，如何來保證讀操作的性能呢？簡單的方式是像Kafka那樣，將文件數(shù)據(jù)有序保存，使用二分查找來優(yōu)化效率；或者通過建索引的方式來進(jìn)行優(yōu)化；也可以采用hash的方式將數(shù)據(jù)分割為不同的桶。以上的方法都能增加讀操作的性能，但是由于在數(shù)據(jù)上強加了數(shù)據(jù)結(jié)構(gòu)，又會降低寫操作的性能。比如如果采用索引的方式來優(yōu)化讀操作，那么在更新索引時就需要更新B-tree中的特定部分，這時候的寫操作就是隨機寫。那么有沒有一種辦法在保證寫性能不損失的同時也提供較好的讀性能呢？一個好的選擇就是使用LSM-tree。LSM-tree與B-tree相比，LSM-tree犧牲了部分讀操作，以此大幅提高寫性能。

• 日志結(jié)構(gòu)的合并樹LSM（The Log-Structured Merge-Tree）是HBase，LevelDB等NoSQL數(shù)據(jù)庫的存儲引擎。Log-Structured的思想是將整個磁盤看做一個日志，在日志中存放永久性數(shù)據(jù)及其索引，每次都添加到日志的末尾。并且通過將很多小文件的存取轉(zhuǎn)換為連續(xù)的大批量傳輸，使得對于文件系統(tǒng)的大多數(shù)存取都是順序的，從而提高磁盤I/O。LSM-tree就是這樣一種采用追加寫、數(shù)據(jù)有序以及將隨機I/O轉(zhuǎn)換為順序I/O的延遲更新，批量寫入硬盤的數(shù)據(jù)結(jié)構(gòu)。LSM-tree將數(shù)據(jù)的修改增量先保存在內(nèi)存中，達(dá)到指定的大小限制后再將這些修改操作批量寫入磁盤。因此比較舊的文件不會被更新，重復(fù)的紀(jì)錄只會通過創(chuàng)建新的紀(jì)錄來覆蓋，這也就產(chǎn)生了一些冗余的數(shù)據(jù)。所以系統(tǒng)會周期性的合并一些數(shù)據(jù)，移除重復(fù)的更新或者刪除紀(jì)錄，同時也會刪除上述的冗余。在進(jìn)行讀操作時，如果內(nèi)存中沒有找到相應(yīng)的key，那么就是倒序從一個個磁盤文件中查找。如果文件越來越多那么讀性能就會越來越低，目前的解決方案是采用頁緩存來減少查詢次數(shù)，周期合并文件也有助于提高讀性能。在文件越來越多時，可通過布隆過濾器來避免大量的讀文件操作。LSM-tree犧牲了部分讀性能，以此來換取寫入的最大化性能，特別適用于讀需求低，會產(chǎn)生大量插入操作的應(yīng)用環(huán)境。

文件合并和元數(shù)據(jù)優(yōu)化

目前的大多數(shù)文件系統(tǒng)，如XFS/Ext4、GFS、HDFS，在元數(shù)據(jù)管理、緩存管理等實現(xiàn)策略上都側(cè)重大文件。上述基于磁盤I/O特性設(shè)計的系統(tǒng)都有一個共性特點就是都運行在這些文件系統(tǒng)之上。這些文件系統(tǒng)在面臨海量時在性能和存儲效率方面都大幅降低，本節(jié)來探討下海量小文件下的系統(tǒng)設(shè)計。

常見文件系統(tǒng)在海量小文件應(yīng)用下性能表現(xiàn)不佳的根本原因是磁盤最適合順序的大文件I/O讀寫模式，而非常不適合隨機的小文件I/O讀寫模式。主要原因體現(xiàn)在元數(shù)據(jù)管理低效和數(shù)據(jù)布局低效：

• 元數(shù)據(jù)管理低效：由于小文件數(shù)據(jù)內(nèi)容較少，因此元數(shù)據(jù)的訪問性能對小文件訪問性能影響巨大。Ext2文件系統(tǒng)中Inode和Data Block分別保存在不同的物理位置上，一次讀操作需要至少經(jīng)過兩次的獨立訪問。在海量小文件應(yīng)用下，Inode的頻繁訪問，使得原本的并發(fā)訪問轉(zhuǎn)變?yōu)榱撕Ａ康碾S機訪問，大大降低了性能。另外，大量的小文件會快速耗盡Inode資源，導(dǎo)致磁盤盡管有大量Data Block剩余也無法存儲文件，會浪費磁盤空間。

• 數(shù)據(jù)布局低效：Ext2在Inode中使用多級指針來索引數(shù)據(jù)塊。對于大文件，數(shù)據(jù)塊的分配會盡量連續(xù)，這樣會具有比較好的空間局部性。但是對于小文件，數(shù)據(jù)塊可能零散分布在磁盤上的不同位置，并且會造成大量的磁盤碎片，不僅造成訪問性能下降，還大量浪費了磁盤空間。數(shù)據(jù)塊一般為1KB、2KB或4KB，對于小于4KB的小文件，Inode與數(shù)據(jù)的分開存儲破壞了空間局部性，同時也造成了大量的隨機I/O。

對于海量小文件應(yīng)用，常見的I/O流程復(fù)雜也是造成磁盤性能不佳的原因。對于小文件，磁盤的讀寫所占用的時間較少，而用于文件的open()操作占用了絕大部分系統(tǒng)時間，導(dǎo)致磁盤有效服務(wù)時間非常低，磁盤性能低下。針對于問題的根源，優(yōu)化的思路大體上分為：

1. 針對數(shù)據(jù)布局低效，采用小文件合并策略，將小文件合并為大文件。
2. 針對元數(shù)據(jù)管理低效，優(yōu)化元數(shù)據(jù)的存儲和管理。針對這兩種優(yōu)化方式，業(yè)內(nèi)也出現(xiàn)了許多優(yōu)秀的開源軟件。

小文件合并
小文件合并為大文件后，首先減少了大量元數(shù)據(jù)，提高了元數(shù)據(jù)的檢索和查詢效率，降低了文件讀寫的I/O操作延時。其次將可能連續(xù)訪問的小文件一同合并存儲，增加了文件之間的局部性，將原本小文件間的隨機訪問變?yōu)榱隧樞蛟L問，大大提高了性能。同時，合并存儲能夠有效的減少小文件存儲時所產(chǎn)生的磁盤碎片問題，提高了磁盤的利用率。最后，合并之后小文件的訪問流程也有了很大的變化，由原來許多的open操作轉(zhuǎn)變?yōu)榱藄eek操作，定位到大文件具體的位置即可。如何尋址這個大文件中的小文件呢？其實就是利用一個旁路數(shù)據(jù)庫來記錄每個小文件在這個大文件中的偏移量和長度等信息。其實小文件合并的策略本質(zhì)上就是通過分層的思想來存儲元數(shù)據(jù)。中控節(jié)點存儲一級元數(shù)據(jù)，也就是大文件與底層塊的對應(yīng)關(guān)系；數(shù)據(jù)節(jié)點存放二級元數(shù)據(jù)，也就是最終的用戶文件在這些一級大塊中的存儲位置對應(yīng)關(guān)系，經(jīng)過兩級尋址來讀寫數(shù)據(jù)。

• 淘寶的TFS就采用了小文件合并存儲的策略。TFS中默認(rèn)Block大小為64M，每個塊中會存儲許多不同的小文件，但是這個塊只占用一個Inode。假設(shè)一個Block為64M，數(shù)量級為1PB。那么NameServer上會有 1 *1024 *1024 * 1024 / 64 = 16.7M個Block。假設(shè)每個Block的元數(shù)據(jù)大小為0.1K，則占用內(nèi)存不到2G。在TFS中，文件名中包含了Block ID和File ID，通過Block ID定位到具體的DataServer上，然后DataServer會根據(jù)本地記錄的信息來得到File ID所在Block的偏移量，從而讀取到正確的文件內(nèi)容。TFS一次讀過程如下圖所示：

tfs_read

元數(shù)據(jù)管理優(yōu)化
一般來說元數(shù)據(jù)信息包括名稱、文件大小、設(shè)備標(biāo)識符、用戶標(biāo)識符、用戶組標(biāo)識符等等，在小文件系統(tǒng)中可以對元數(shù)據(jù)信息進(jìn)行精簡，僅保存足夠的信息即可。元數(shù)據(jù)精簡可以減少元數(shù)據(jù)通信延時，同時相同容量的Cache能存儲更多的元數(shù)據(jù)，從而提高元數(shù)據(jù)使用效率。另外可以在文件名中就包含元數(shù)據(jù)信息，從而減少一個元數(shù)據(jù)的查詢操作。最后針對特別小的一些文件，可以采取元數(shù)據(jù)和數(shù)據(jù)并存的策略，將數(shù)據(jù)直接存儲在元數(shù)據(jù)之中，通過減少一次尋址操作從而大大提高性能。

• TFS中文件命名就隱含了位置信息等部分元數(shù)據(jù)，從而減少了一個元數(shù)據(jù)的查詢操作。在Rerserfs中，對于小于1KB的小文件，Rerserfs可以將數(shù)據(jù)直接存儲在Inode中。

http://gao-xiao-long.github.io/2016/04/13/file-io/