1. 程式人生 > 其它 >儲存老炮兒帶你盤一盤Filecoin儲存之選型指南篇

儲存老炮兒帶你盤一盤Filecoin儲存之選型指南篇

什麼樣的商業儲存產品才能更適用區塊鏈儲存的應用?首先我們區先要分儲存系統。市場上的儲存系統有多種分類方法,常見的分類方式是按照架構和協議區分的。

從架構上分為Scale-up(縱向擴充套件)集中式和Scale-out(橫向擴充套件)分散式兩類。Scale-up架構受儲存控制器擴充套件數量限制,常見的多為2控或4控的產品,其IO效能及磁碟擴充套件能力受限於控制器的數量。Scale-up架構的混閃和全快閃記憶體磁碟陣列,適用於對延遲較敏感但對儲存容量和併發頻寬要求一般的中小規模資料儲存場景。相反,Scale-out架構儲存利用通用的乙太網或高效能IB網路技術,儲存節點(控制器)的數量可以從幾十個擴充套件到幾百甚至幾千個,其儲存效能和容量並不取決於單個儲存節點的能力,而是聚合叢集中所有節點的資源。 分散式儲存系統就是Scale-Out架構最典型的產品形態。

儲存系統從協議上可分為塊、檔案、物件等幾種型別。塊儲存為上層應用提供卷級裸裝置儲存空間,儲存資源具有獨享性,延遲較低、單個卷的儲存空間一般不超過幾十個TB,適用於資料庫、虛擬化等典型應用場景;檔案儲存為上層應用提供目錄級共享儲存空間,取決於不同的檔案系統,單個目錄的空間大小可從TB到PB甚至EB級,適用於各類非結構化資料應用場景;與檔案系統類似,物件儲存同樣為上層應用提供共享的儲存空間,用於非結構化資料儲存應用場景。

所以適合海量非結構化資料的儲存系統包括分散式檔案和分散式物件兩類,但兩者在資料組織結構和訪問協議等方面存在顯著差異。由於海量非結構化資料應用場景非常多,對儲存系統的要求不同,具體選用哪種型別的儲存,還需要對分散式檔案和物件進行更詳細的分析和對比。

成熟的分散式儲存系統會隨著業務場景的發展而不斷完善。從起源上來看,分散式檔案和物件都是隨著大型網際網路公司業務的快速擴張同步發展起來的,旨在解決其海量非結構化資料所帶來的擴充套件性、可靠性和成本等瓶頸。

分散式檔案系統的起源是Google於2003年發表的一篇論文《The Google File System》,其核心目標是設計一款具有高擴充套件能力和容錯能力的高效能檔案系統。該系統可以執行在廉價的商用硬體上,為前端大量客戶端提供高效能、高可用的檔案共享服務,解決海量非結構化資料的儲存問題。

業界是這樣定義分散式檔案系統:基於一個單一併行檔案系統組合多個儲存節點為儲存叢集,為多個客戶端的併發高頻寬資料訪問提供單一名稱空間儲存池。資料分散儲存到叢集中的多個節點上,基於資料自愈技術為客戶端應用提供高可靠和高可用的資料服務,並可實現效能和容量的線性擴充套件。

分散式檔案系統具有如下幾個顯著特性:

1、 高效能

分散式檔案系統利用儲存叢集中所有節點的處理和IO效能提供高頻寬併發資料訪問,成熟的商業產品聚合訪問頻寬高達TB級,可以支援數千甚至數萬節點的併發訪問。

2、 易擴充套件

分散式檔案系統可以便捷地在叢集中新增資料節點,實現儲存系統性能和容量的線性增加,儲存節點可以擴充套件至數百甚至數千個,儲存容量擴充套件至數百PB甚至EB級。

3、 高可靠、可用性

儲存系統不依賴於單個裝置的可靠性,採用叢集架構,確保系統中無單點故障;同時支援副本以及N+M糾刪碼等資料保護技術,確保資料可用性;儲存系統具有一定的硬體故障與資料故障的冗餘自愈能力。

4、 高性價比

儲存節點基於工業標準商用伺服器,硬體的成本大幅降低。

5、 開放相容性

提供NAS、FTP、HTTP等通用檔案共享訪問協議。

分散式物件儲存系統定義如下:以物件結構來儲存資料的儲存系統,前端伺服器客戶端通過協議(例如HTTP)或者API介面(例如S3、Swift)進行訪問。從概念上來說,物件與檔案一樣,都包括內容和元資料。與檔案相比,物件通常支援更豐富的元資料,使用者或應用可為物件設定用於管理、資料探勘和資料遷移的元資料屬性。

與分散式檔案一樣,分散式物件同樣採用Scale-out分散式叢集架構,具有易擴充套件、高可靠和高性價比等優勢,其與檔案系統在使用上的不同主要體現在如下幾個方面:

1、支援的儲存訪問協議不同

分散式物件採用更加專用的協議(比如HTTP)或者API介面(例如S3或是Swift)進行訪問,相比通用的NAS檔案協議,需要前端應用做針對性的適配和介面定製開發。

2、支援的資料讀寫模式不同

與檔案系統不同,分散式物件不支援資料的隨機讀取和寫入,僅可針對整個檔案做put或是get操作,這種模式基本把分散式物件限定在有限的資料寫入後,有限的讀取、極少修改的應用場景,例如網際網路的雲盤、備份歸檔以及法規遵從等溫冷資料應用場景。

3、資料結構不同

檔案採用樹形目錄結構,可以滿足應用多級目錄巢狀使用模式,但是隨著巢狀層次和檔案數量的增加,讀取和儲存資料時需要更長訪問路徑,當訪問的檔案過小時,單個檔案訪問效能受影響較大。

物件採用扁平目錄結構,不支援多層巢狀的資料組織結構,只保留二級或是三級目錄結構,只需要一個ID就能直接獲取物件,這種資料結構在千億級別海量小檔案應用場景中會體現出一定的效能優勢。

另外,物件目錄結構更容易支援元資料定製,物件儲存非常適合於與物件有關聯性元資料的應用場景,物件儲存允許為一個物件設定唯一的元資料屬性,基於該元資料資訊,可以從一個海量非結構化資料卷中快速的定位與讀取該物件。

技術的發展並不是互相割裂、一成不變的,而是在相互借鑑中共同促進和發展。在分散式物件中應用比較廣的N+M糾刪碼技術已成為分散式檔案系統的標配,跨地域部署和資料容災等功能也被越來越多成熟的分散式檔案系統所支援。分散式檔案系統利用高速SSD儲存介質、元資料叢集和小檔案聚合等技術,支援的檔案系統規模從十億級向千億級邁進,小檔案訪問效能提升明顯;分散式物件也在利用高速SSD儲存介質,進一步提升資料讀取效能,從冷資料逐步向溫、熱資料應用場景推進。

分散式檔案和物件的技術差異在逐步縮小。分散式檔案由於其支援隨機讀寫模式、協議的廣泛相容性、類似本地硬碟的展現形式更符合使用者的使用習慣,在商業市場下有著普及性和大規模的應用案例,應用成熟度非常高。開原始檔系統有Lustre、Gluster、BeeGFS和Ceph等,國內外專業儲存廠商均開發了成熟的商用儲存產品。分散式物件受限於一寫多讀資料訪問模式、專用的介面協議、扁平化的資料組織架構,其適用的應用場景遠不如檔案系統廣泛。規模化的應用僅集中在有能力深度定製優化和開發的有限網際網路場景中,比如Facebook自研的用於海量圖片儲存的HeyStack、Amazon研製的支撐其雲業務的S3等。從技術實現層面而言,分散式物件的實現難度較低,開源產品有Ceph、Swift、Minio等,主要應用場景歸納如下:1、結合雲應用提供業務資料的備份歸檔儲存;2、金融證券、醫療等行業應用的法規遵從性檔案的歸檔。另外商用的物件儲存應用多以小規模、冷資料等限制性場景為主,對於資料寫入和讀取的實時效率要求並不高。

去中心化儲存系統的“成色”由儲存規模、資料IO效能、可靠性、線上擴容時間、資料重建影響等幾個要素直接決定,具備大規模部署案例的分散式儲存產品才能夠經得起此類應用長期的考驗。

從區塊鏈IPFS實際應用的技術需求來看:1、採用分散式物件儲存意味著應用需要根據儲存廠商物件介面API或SDK單獨開發與維護。當前去中心化儲存應用中,上層軟體多樣且迭代速度較快,已有軟體環境也存在著頻繁強制升級的現狀,任何上層軟體的變更都可能導致物件介面的迭代完善甚至重新開發,工作量巨大,運維成本急劇增加。2、行業內大部分分散式物件系統是基於開源Ceph構建,以Ceph為代表的物件儲存系統一般僅支援基於連線數的負載均衡策略,而商業全自研的檔案系統可支援基於連線數、儲存容量、節點負載等多維度的儲存負載均衡,在多併發、儲存效能異常時,可根據實際場景選擇更優的負載均衡模式,以提升儲存效率。3、實際應用中1個扇區(Sector)檔案大小是32GB。物件儲存單次put上傳的物件最大為5GB,對於32GB檔案,物件儲存系統必須在客戶端上拆分成多段(如4個單獨8GB)後,再進行併發傳輸;多個分段上傳至儲存系統後,再次合併成最終的Sector。多個Sector合併過程勢必會對儲存效能和資料抽取時間有較大影響,直接會影響Winning PoST完成時間,從而降低出塊效率。4、扇區檔案(Sector)和扇區索引檔案(Sector Cache)存在關聯性,若採用優化手段增強其關聯性,則會極大提升儲存效能。物件儲存需要多個桶分別儲存扇區檔案和扇區索引檔案,一般需要通過人為設定桶的屬性及大量桶之間的關聯繫結。業務資料量增長迅速,額外的設定與調整,同樣給業務執行及系統運維造成極大影響,這在實際應用中也是很難完成的。

綜上分析,基於應用當前需求和特點,Filecoin的儲存系統更適合採用成熟的分散式檔案系統構建。另外,同時支援檔案、物件、塊協議的分散式統一儲存將成為發展趨勢,也為去中心化儲存未來的多模式應用提供了技術可行性。

最後,筆者認為在選擇合作的儲存廠商時,首先,應關注其是否有專業的儲存研發團隊和完善的技術服務體系;其次,應具備超大規模系統部署和運維經驗、快速應用適配定製和深度優化實力;最後,有著長遠的分散式儲存產品發展規劃和資源投入。這樣的儲存廠商才能幫助使用者搭建長期可靠的資料儲存環境,支援去中心化儲存市場和應用的快速發展與普及。

原文地址:https://www.sugon.com/cut?id=1404&nav_id=