如何构建下一代去中心化云存储
这个问题是4年前创业时提出的， 因为技术问题以及商业模式问题，一直没有成功， 现在复盘整个心路过程，不是严肃的专业论文，权当听故事。
在2013年， 当时阿里云OSS存储价格在1900元/TB/年， 成本价格高于（TFS成本）4000元，考虑到未来海量的数据需求， 存储成本是一个不断累积增长的成本， 任何公司都很难承受，就有了利用闲置设备做分散式存储的想法！
基本想法是利用路由器、OTT机顶盒的存储空间，构建一个分散式的可靠存储体系， 每个设备的存储空间不大，但长尾设备的数量巨大， 通过冗余思想能对抗设备的不稳定性、在线率低等困难。
这个想法告诉了小米，于是有了小米路由器加一块硬碟的产品出现。但显然，小米并没有理解分散式存储的思想， 只是充分利用当时的技术， 加一块硬碟做了本地存储管理，当然商业价值还是有的。
先说说这个利用长尾资源做存储的技术问题吧，这是一个世界级的挑战。
每个设备假定只有1GB存储空间， 共有 100万同时在线设备， 这样总存储空间为1000TB。
假定我们存储一个1GB的文件， 首先把文件分成1024个1MB的Chunk， 每个chunk在分成1024个1KB的piece， 对每个chunk的1024个piece 进行编码， 这样假设可以生成2048个完全不同的piece, 我们需要把这2048个pieces 放在2048个节点上。对1024个chunk 进行同样的操作， 这样我们可以在每个节点上存储1024片piece， 但每个chunk 只保存一份， 这样，每个节点只存储 1GB原始文件的1MB数据量。 整个文件在2048个节点上有，数据冗余量为2倍。
为了恢复这些数据， 从2048个节点中随机取出1024个节点的数据即可恢复。
这就是去中心化存储的基础！ 但实现上述系统有著巨大的挑战：
- 海量节点对中心伺服器的心跳冲击
- 如果去掉中心存储服务的备份，这个存储系统必须可靠， 快速发现数据冗余不够是关键
- 发现冗余不够之后，快速修复是关键中的关键
- 安全
第一个问题是工程问题， 只能硬扛。
第二个问题， 可以分组来解决。
第三个问题，涉及到存储的最核心问题，已经不是工程能高效解决了。分散的数据已经用喷泉编码演算法进行了编码， 如果只有这个编码演算法， 则需要把数据恢复之后在重新编码，然后在推送到新的设备节点上， 这样修复成本就太高了。 而存储中修复成本是有指标衡量的， 就是修复占用的计算量及被修复数据量的百分比。 如果重新解码在编码，修复成本就是原始数据量的200%。 如果喷泉编码能再次被编码， 而且能生成原始喷泉编码的域空间内， 则数据就能像基因复制一样，用最小代价在节点间自由迁移，那就完美了， 这样整个存储系统甚至网路的架构就被完全颠覆！
这个技术就叫再生码（regeneration code) , 我们首次提出再生码在这个场景下应用, 借助这个思想， 成功的获得1000万美元投资.
但再生码的构造太困难了， 我们寻求复旦大学及香港大学顶级编码专家研究这个问题，但只能构造O(n^2)的演算法， 而且还不知道结果是否正确， 难点在于这个矩阵构造必须稀疏，但两个稀疏矩阵的运算得到的结果不稀疏，在工程上不可行，性能太差了，工程上必须达到O(n)。 这个问题留给科学家吧！
最终我们没有选择这个方向来做（现在想法有变化，但场景已不一样），主要有如下的考虑：
- 单碟存储能力在指数上升， 目前单硬碟容量已有120TB， 这样导致集中式云存储的成本下降非常快
- 在2014年就知道了Facebook的云存储成本降到了400/TB/年，也就是说云存储的margin越来越低
- 云存储的的系统瓶颈在内部数据恢复的IO上， 集中式云存储在内部通讯上有巨大优势，瓶颈不在存储的容量上
- 去中心化云存储部署在每个小设备上，每个设备上行带宽非常小， 导致数据通信及恢复很慢，效率比较低，而且为了对抗设备的不稳定性， 系统开销也变大，冗余倍数增加
- 在不安全的设备上做存储， 很难消除客户的顾虑， 安全性受到挑战， 教育市场任重道远。
总的来说，margin越来越低， 而且技术挑战性太大， 不是一个很性感的生意。 但反过来说， 可能是切入点不对， 如果这么好的技术，硬要去取代传统的云存储， 是否是一个错误的想法？ 是否有适合雾计算的场景出现， 特别适合这种去中心化的云存储体系。 所以说不能单纯技术思维去考虑商业问题。 每个创新一定有他合适的场景，只是没有认识到罢了。
===========================
未完待续
推荐阅读：
