作者簡介：林意群，apache hadoop pmc member，主要專注於儲存領域的開發，曾主要參與過hdfs rbf以及hadoop ozone專案開發。目前為ebay hadoop team的研發工程師。
我們知道在乙個儲存系統中，不光光只有它所儲存的資料檔案重要，它的儲存系統的元資料管理同樣十分的重要。因為涉及到儲存系統資料訪問操作時，會經過儲存系統元資料的查詢或更新操作，如果元資料這邊的操作出現效能瓶頸，同樣會導致使用者訪問資料的行為出現緩慢的情況。本文我們來聊聊儲存系統一般是如何做高效的元資料管理的，這裡面會涉及到多種不同的元資料管理方式。
首先我們來看最簡單原始的初代儲存系統元資料管理方式，此時元資料往往儲存於外部db中，然後master服務和db進行資料的互動，如下圖所示：
這個版本的儲存系統需要保證的是操作流程的流暢性處理，與此同時整個系統所維護的元資料體量也不是很大。
當我們需要對元資料的訪問操作有更高的要求時，我們會自然想到的一種做法是將元資料load到服務記憶體中，來加速元資料的訪問。然後我們會看到如下記憶體管理式的元資料管理，master服務在初啟動後載入外部元資料db檔案到記憶體中。
一台機器的記憶體容量是有限的，但是元資料規模是可以隨著業務不斷擴張的，這時就會出現乙個記憶體的bottleneck的問題。這個時候怎麼來優化這個事情呢？答案很簡單，乙個字：拆！我們將元資料按照給定規則進行partition的分拆，然後啟動多個master服務來管理各自的應該維護的元資料，效果圖如下所示：
因為在這裡實際服務的service變為了多個，對於屬於不同partition的元資料操作，系統應讓請求**到對應所屬的服務上面去，因此在service前面還需要乙個proxy role這樣的角色在請求的**。這個設計乙個比較典型的例子是hdfs的federation方案，然後proxy role是client端的viewfs，或者是hdfs rbf功能的router角色。
當元資料管理再進一步加大的時候，我們還能如何拓展單個節點元資料管理能力的極限呢？比如從支援百萬級別量級檔案到數十億級別體量檔案。將數十億級別量級檔案元資料全部load到機器記憶體已經是一件不太靠譜的做法了。這個時候我們有一種新的元資料管理系統模式：分層級的元資料管理，官方術語的稱呼叫做tier layer的元資料管理。
這裡主要分為兩種layer：
熱點資料和冷資料根據使用者的訪問頻率行為可以互相之間做轉換，類似如下所示：
在此模式系統下，服務只cache當前active的資料，所以也就不會有記憶體瓶頸這樣的問題。
下圖是乙個此模式的樣例系統alluxio的元資料管理模型圖：
以上就是本文所要闡述的關於儲存系統常見的元資料管理模式。
[1].
儲存系統 儲存技術（1）
主機匯流排介面卡 host bus adapter hba 處理從伺服器到儲存裝置的連線，也可以執行其他幾個角色。而乙個基本的hba提供連線到儲存，更先進的hba已經嵌入陣列控制器。當儲存在位於或連線到伺服器，它被稱為直接附加儲存 direct attached storage das 通過專用的外...
儲存系統（4） 虛擬儲存
1.目的 將一部分磁碟空間作為主存，容量接近輔存，速度接近主存。2.工作原理 cpu給出虛擬位址，進行內部轉換，判斷改位址是否在主存中 若在，從主存中提取資料 若不在，進行外部位址轉換 利用外頁表，外段表，通常由軟體實現 外部轉換計算出輔存位址，並使用替換演算法，進行資料的調入調出 備註 cpu通過...
儲存系統 半導體儲存器
半導體儲存器分為隨機儲存器ram random access memory 和唯讀儲存器rom read only memory 隨機儲存器特點就是斷電資訊丟失，具有易失性 唯讀儲存器特點就是永久儲存，斷電續存。隨著需求發展，如今的唯讀儲存器也具有了可寫特性。按照rom原始定義，固態硬碟屬於rom。...