Erasure Code編碼大文件的問題？

分散式存儲系統使用Erasure Code來容錯的時候，對於大文件比如10GB，無法在單個節點上進行EC編碼，那麼怎麼對10GB文件編碼？分散式的方式？

---

謝邀！

問題不成立，Erasure Code編碼跟文件大小無關，任意大小的文件都能進行EC編碼，單節點還是分散式都行，10GB文件可以自身分塊編碼，也可以和其他文件分塊編碼。編碼速度採用AVX早已經突破10GB/s, EC編碼不存在計算瓶頸，主要還是IO瓶頸，定義好編碼塊大小和編解碼流程就行了。

---

EBS這種一般是條帶化處理，同時寫多個ec組的成員，大文件可以看成一個一個條帶

S3考慮吞吐和IO一般會先生成多副本，再考慮轉EC，寫入的時候按照AmazonS3的協議，會拆分成Multipart，Multipart由邏輯的多個Object組成，每個Object再包含多個分布在Replica里的Record，EC生成的時候以Replica為單位。

---

作者對EC的理解有問題，看EC的具體實現如RS編碼和LRC編碼，對於10GB的大文件，可以先切分成固定大小，如2M，然後這樣不管的進行編碼就可以了。分散式使用EC主要是為了降低存儲成本。

---

你先試一下再說單節點無法做10G文件級別的EC，只要不是小霸王學習機都沒問題的。現在大點的存儲默認都是分散式的。

你說的具體編碼的方法很多，各有千秋，選型看你現有團隊的習慣和開源軟體的發展水平。

第一種方法, 數據可以先不做EC，而是先放到本地盤上，一般是三副本群集，做為EC的持久化寫前緩衝池，然後EC勻速從池子里放水。

第二種方法，客戶端（sdk)做分片甚至EC，這種做法的比較少但有技術可行性，可能最大的缺陷是不靈活，鬼知道後端想做12+4還是16+2的EC。

第三種方法，數據上傳過程中先做分片，比如說lemon wonder 說的那樣，切成N個2M分片，每個分片做EC。

我覺得你該關注的不是EC本身的性能問題，而是EC之後，元數據的filehandle部分怎麼處理。

你是選擇一個文件一個filehandle，然後在FH和EC文件之間做二級映射，這會增加系統的複雜度和影響EC回收空間速率；

還是選擇讓一個FH只能找到第一個EC文件，讓EC文件像FAT32一樣首尾相接，這會限制文件讀取速度；

還有第三種方法，一個文件有多個（可能到幾百萬個）filehandle就，這樣最靈活也最考驗你的元數據負載能力。

fh和文件處理都選第一種是最簡單務實的方式；選第二種是詭異但有技術可行性的方式。

EC的filehandle選第三種，文件也提前做2M的分片，可以有效解決EC群集回收空間速度慢的問題，但就是技術細節太多，難度最大。

我寫了篇文章，前半段和技術沒關係，但後半段是在不泄密的前提下能談的最多的技術問題了。

【原創】讓PB級雲存儲不再神秘

---

通常大文件需要先進行條帶化處理，然後對每個條帶分別執行RS編碼

---

推薦閱讀：