元數(shù)據(jù)存儲(chǔ)系統(tǒng)管理演變升級(jí)
點(diǎn)擊上方藍(lán)色字體，選擇“設(shè)為星標(biāo)”
回復(fù)”資源“獲取更多資源
前言我們知道在一個(gè)存儲(chǔ)系統(tǒng)中，不光光只有它所存儲(chǔ)的數(shù)據(jù)文件重要，它的存儲(chǔ)系統(tǒng)的元數(shù)據(jù)管理同樣十分的重要。因?yàn)樯婕暗酱鎯?chǔ)系統(tǒng)數(shù)據(jù)訪問操作時(shí)，會(huì)經(jīng)過存儲(chǔ)系統(tǒng)元數(shù)據(jù)的查詢或更新操作，如果元數(shù)據(jù)這邊的操作出現(xiàn)性能瓶頸，同樣會(huì)導(dǎo)致用戶訪問數(shù)據(jù)的行為出現(xiàn)緩慢的情況。本文我們來(lái)聊聊存儲(chǔ)系統(tǒng)一般是如何做高效的元數(shù)據(jù)管理的，這里面會(huì)涉及到多種不同的元數(shù)據(jù)管理方式。
初代元數(shù)據(jù)管理首先我們來(lái)看最簡(jiǎn)單原始的初代存儲(chǔ)系統(tǒng)元數(shù)據(jù)管理方式，此時(shí)元數(shù)據(jù)往往存儲(chǔ)于外部db中，然后master服務(wù)和db進(jìn)行數(shù)據(jù)的交互，如下圖所示：
這個(gè)版本的存儲(chǔ)系統(tǒng)需要保證的是操作流程的流暢性處理，與此同時(shí)整個(gè)系統(tǒng)所維護(hù)的元數(shù)據(jù)體量也不是很大。內(nèi)存式元數(shù)據(jù)管理當(dāng)我們需要對(duì)元數(shù)據(jù)的訪問操作有更高的要求時(shí)，我們會(huì)自然想到的一種做法是將元數(shù)據(jù)load到服務(wù)內(nèi)存中，來(lái)加速元數(shù)據(jù)的訪問。然后我們會(huì)看到如下內(nèi)存管理式的元數(shù)據(jù)管理，master服務(wù)在初啟動(dòng)后加載外部元數(shù)據(jù)db文件到內(nèi)存中。
分區(qū)元數(shù)據(jù)管理一臺(tái)機(jī)器的內(nèi)存容量是有限的，但是元數(shù)據(jù)規(guī)模是可以隨著業(yè)務(wù)不斷擴(kuò)張的，這時(shí)就會(huì)出現(xiàn)一個(gè)內(nèi)存的bottleneck的問題。這個(gè)時(shí)候怎么來(lái)優(yōu)化這個(gè)事情呢？答案很簡(jiǎn)單，一個(gè)字：拆！我們將元數(shù)據(jù)按照給定規(guī)則進(jìn)行partition的分拆，然后啟動(dòng)多個(gè)master服務(wù)來(lái)管理各自的應(yīng)該維護(hù)的元數(shù)據(jù)，效果圖如下所示：
因?yàn)樵谶@里實(shí)際服務(wù)的service變?yōu)榱硕鄠€(gè)，對(duì)于屬于不同partition的元數(shù)據(jù)操作，系統(tǒng)應(yīng)讓請(qǐng)求轉(zhuǎn)發(fā)到對(duì)應(yīng)所屬的服務(wù)上面去，因此在service前面還需要一個(gè)Proxy Role這樣的角色在請(qǐng)求的轉(zhuǎn)發(fā)。這個(gè)設(shè)計(jì)一個(gè)比較典型的例子是HDFS的Federation方案，然后Proxy Role是client端的ViewFs，或者是HDFS RBF功能的Router角色。分層級(jí)元數(shù)據(jù)管理當(dāng)元數(shù)據(jù)管理再進(jìn)一步加大的時(shí)候，我們還能如何拓展單個(gè)節(jié)點(diǎn)元數(shù)據(jù)管理能力的極限呢？比如從支持百萬(wàn)級(jí)別量級(jí)文件到數(shù)十億級(jí)別體量文件。將數(shù)十億級(jí)別量級(jí)文件元數(shù)據(jù)全部load到機(jī)器內(nèi)存已經(jīng)是一件不太靠譜的做法了。這個(gè)時(shí)候我們有一種新的元數(shù)據(jù)管理系統(tǒng)模式：分層級(jí)的元數(shù)據(jù)管理，官方術(shù)語(yǔ)的稱呼叫做Tier layer的元數(shù)據(jù)管理。
這里主要分為兩種layer：
最近訪問的熱點(diǎn)元數(shù)據(jù)，做內(nèi)存緩存，叫做cached layer。
很久沒有訪問過的數(shù)據(jù)((也可稱作冷數(shù)據(jù))，做持久化保存存，叫做persisted layer。
熱點(diǎn)數(shù)據(jù)和冷數(shù)據(jù)根據(jù)用戶的訪問頻率行為可以互相之間做轉(zhuǎn)換，類似如下所示：
在此模式系統(tǒng)下，服務(wù)只cache當(dāng)前active的數(shù)據(jù)，所以也就不會(huì)有內(nèi)存瓶頸這樣的問題。下圖是一個(gè)此模式的樣例系統(tǒng)Alluxio的元數(shù)據(jù)管理模型圖：
以上就是本文所要闡述的關(guān)于存儲(chǔ)系統(tǒng)常見的元數(shù)據(jù)管理模式。文章不錯(cuò)？點(diǎn)個(gè)【在看】吧！??
評(píng)論
圖片
表情