前言
我們知道在一個存儲系統中，不光光只有它所存儲的數據文件重要，它的存儲系統的元數據管理同樣十分的重要。因爲涉及到存儲系統數據訪問操作時，會經過存儲系統元數據的查詢或更新操作，如果元數據這邊的操作出現性能瓶頸，同樣會導致用戶訪問數據的行爲出現緩慢的情況。本文我們來聊聊存儲系統一般是如何做高效的元數據管理的，這裏面會涉及到多種不同的元數據管理方式。
初代元數據管理
首先我們來看最簡單原始的初代存儲系統元數據管理方式，此時元數據往往存儲於外部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：
- 最近訪問的熱點元數據，做內存緩存，叫做cached layer。
- 很久沒有訪問過的數據((也可稱作冷數據)，做持久化保存存，叫做persisted layer。
熱點數據和冷數據根據用戶的訪問頻率行爲可以互相之間做轉換，類似如下所示：
在此模式系統下，服務只cache當前active的數據，所以也就不會有內存瓶頸這樣的問題。
下圖是一個此模式的樣例系統Alluxio的元數據管理模型圖：
以上就是本文所要闡述的關於存儲系統常見的元數據管理模式。
引用
[1].https://docs.alluxio.io/os/user/stable/en/operation/Journal.html#backing-up-the-journal