Erasure Code编码大文件的问题
谢邀！问题不成立，Erasure Code编码跟文件大小无关，任意大小的文件都能进行EC编码，单节点还是分布式都行，10GB文件可以自身分块编码，也可以和其他文件分块编码。编码速度采用AVX早已经突破10GB/s, EC编码不存在计算瓶颈，主要还是IO瓶颈，定义好编码块大小和编解码流程就行了。
■网友
EBS这种一般是条带化处理，同时写多个ec组的成员，大文件可以看成一个一个条带
S3考虑吞吐和IO一般会先生成多副本，再考虑转EC，写入的时候按照AmazonS3的协议，会拆分成Multipart，Multipart由逻辑的多个Object组成，每个Object再包含多个分布在Replica里的Record，EC生成的时候以Replica为单位。
■网友
你先试一下再说单节点无法做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级云存储不再神秘
■网友
【Erasure Code编码大文件的问题】 作者对EC的理解有问题，看EC的具体实现如RS编码和LRC编码，对于10GB的大文件，可以先切分成固定大小，如2M，然后这样不管的进行编码就可以了。分布式使用EC主要是为了降低存储成本。
■网友
通常大文件需要先进行条带化处理，然后对每个条带分别执行RS编码
推荐阅读
- 【编码】提醒：购买时注意外观和这俩编码 南京电动自行车超标车临牌更换只剩20天
- 被人围攻是怎么样一种体验，包括但不限于（蛋糕，口舌，拳脚，西瓜刀，机枪，code review）
- json下面代码字符编码的规则是啥
- 购买原书为Pearson出版社出版的图书的翻译或者影印版本，怎样获得注册Pearson网站的Access Code
- 程序媛女票是啥体验?
- python 爬取b站网页的编码问题
- java 中文乱码问题
- 视频编码所支持的视频尺寸大小是固定的吗
- 求问codewar上的一道题
- 怎样使用视频编码工具实现高质量的webM视频编码