所以，数据库这样的存储中间件出现基本上是历史必然。尽管数据库很通用，但它决不会是唯一的存储中间件。比如业务中用到的富媒体（图片、音视频、Office文档等），我们很少会去存储到数据库中，更多的时候我们会把它们放在文件系统里。但是单机时代诞生的文件系统，真的是最适合存储这些富媒体数据的么？不，文件系统需要改变，因为：
伸缩性。单机文件系统的第一个问题是单机容量有限，在存储规模超过一台机器可管理的时候，应该怎么办。
性能瓶颈。通常，单机文件系统在文件数目达到临界点后，性能会快速下降。在4TB的大容量磁盘越来越普及的今天，这个临界点相当容易到达。
可靠性要求。单机文件系统通常只是单副本的方案，但是今天单副本的存储早已无法满足业务的可靠性要求。数据需要有冗余（比较经典的做法是3副本），并且在磁盘损坏时及早修复丢失的数据，以避免所有的副本损坏造成数据丢失。
可用性要求。单机文件系统通常只是单副本的方案，在该机器宕机后，数据就不可读取，也不可写入。
　　在分布式存储系统出现前，有一些基于单机文件系统的改良版本被一些应用采纳。比如在单机文件系统上加 RAID5 做数据冗余，来解决单机文件系统的可靠性问题。假设 RAID5 的数据修复时间是1天（实际上往往做不到，尤其是业务系统本身压力比较大的情况下，留给 RAID 修复用的磁盘读写带宽很有限），这种方案单机的可靠性大概是100年丢失一次数据（即可靠性是2个9）。看起来尚可？但是你得小心两种情况。一种是你的集群规模变大，你仍然沿用这个土方法，比如你现在有 100 台这样的机器，那么就会变成1年就丢失一次数据。另一种情况是如果实际数据修复时间是 3 天，那么单机的可靠性就直降至4年丢失一次数据，100台就会是15天丢失一次数据。这个数字显然无法让人接受。

Google GFS 是很多人阅读的第一份分布式存储的论文，这篇论文奠定了 3 副本在分布式存储系统里的地位。随后 Hadoop 参考此论文实现了开源版的 GFS —— HDFS。但关于 Hadoop 的 HDFS 实际上业界有不少误区。GFS 的设计有很强的业务背景特征，本身是用来做搜索引擎的。HDFS 更适合做日志存储和日志分析（数据挖掘），而不是存储海量的富媒体文件。因为：
HDFS 的 block 大小为 64M，如果文件不足 64M 也会占用 64M。而富媒体文件大部分仍然很小，比如图片常规尺寸在 100K 左右。有人可能会说我可以调小 block 的尺寸来适应，但这是不正确的做法，HDFS 的架构是为大文件而设计的，不可能简单通过调整 block 大小就可以满足海量小文件存储的需求。
HDFS 是单 Master 结构，这决定了它能够存储的元数据条目数有限，伸缩性存在问题。当然作为大文件日志型存储，这个瓶颈会非常晚才遇到；但是如果作为海量小文件的存储，这个瓶颈很快就会碰上。
HDFS 仍然沿用文件系统的 API 形式，比如它有目录这样的概念。在分布式系统中维护文件系统的目录树结构，会遭遇诸多难题。所以 HDFS 想把 Master 扩展为分布式的元数据集群并不容易。
　　分布式存储最容易处理的问题域还是单键值的存储，也就是所谓的 Key-Value 存储。只有一个 Key，就意味着我们可以通过对 Key 做 Hash，或者对 Key 做分区，都能够让请求快速定位到特定某一台存储机器上，从而转化为单机问题。这也是为什么在数据库之后，会冒出来那么多 NoSQL 数据库。因为数据库和文件系统一样，最早都是单机的，在伸缩性、性能瓶颈（在单机数据量太大时）、可靠性、可用性上遇到了相同的麻烦。NoSQL 数据库的名字其实并不恰当，他们更多的不是去 SQL，而是去关系（我们知道数据库更完整的称呼是关系型数据库）。有关系意味着有多个索引，也就是有多个 Key，而这对数据库转为分布式存储系统来说非常不利。

在经过了四个大的版本迭代，七牛新一代云存储（v2）终于上线。新存储的第一大亮点是引入了纠删码（EC）这样的算术冗余方案，而不再是经典的 3 副本冗余方案。我们的 EC 采用的是 28 + 4，也就是把文件切分为 28 份，然后再根据这 28 份数据计算出 4 份冗余数据，最后把这 32 份数据存储在 32 台不同的机器上。这样做的好处是既便宜，又提升了可靠性和可用性。从成本角度，同样是要存储 1PB 的数据，要买的存储服务器只需 3 副本存储的 36.5%，经济效益相当好。从可靠性方面，以前 3 副本只能允许同时损坏2块盘，现在能够允许同时损坏4块盘，直观来说这大大改善了可靠性（后面讨论可靠性的时候我们给出具体的数据）。从可用性角度，以前能够接受 2 台服务器下线，现在能够同时允许 4 台服务器下线。
　　新存储的第二大亮点是修复速度，我们把单盘修复时间从 3 小时提升到了 30 分钟以内。修复时间同样对提升可靠性有着重要意义（后面讨论可靠性的时候我们给出具体的数据）。这个原因是比较容易理解的。假设我们的存储允许同时坏 M 块盘而不丢失数据，那么集群可靠性，就是看在单位修复时间内，同时损坏 M+1 块盘的概率。例如，假设我们修复时间是 3 小时，那么 3 副本集群的可靠性就是看 3 小时内同时损坏 3 块盘的概率（也就是丢数据的概率）。
　　让我们回到存储系统最核心的指标 —— 可靠性。首先，可靠性和集群规模是相关的。假设我们有 1000 块磁盘的集群，对于 3 副本存储系统来说，这 1000 块盘同时坏 3 块就会发生数据丢失，这个概率显然比 3 块盘同时坏 3 块要高很多。基于这一点，有些人会想这样的土方法：那我要不把集群分为 3 块磁盘一组互为镜像，1000 块盘就是 333 组（不好意思多了1块，我们忽略这个细节），是不是可以提升可靠性？这些同学忽略了这样一些关键点：
3 块盘同时坏 3 块盘（从而丢失数据）的概率为 p，那么 333 组这样的集群，丢失数据的概率是 1-(1-p)^333 ≈ p * 333，而不是 p。
互为镜像的麻烦之处是修复速度存在瓶颈。坏一块盘后你需要找一个新盘进行数据对拷，而一块大容量磁盘数据对拷的典型时间是 15 小时（我们后面将给出 15 小时同时坏 3 块盘的概率）。要想提升这个修复速度，第一步我们就需要打破镜像带来的束缚。
　　如果一个存储系统的修复时间是恒定的，那么这个存储集群在规模扩大的时候，必然伴随着可靠性的降低。所以最理想的情况是集群越大，修复速度越快。这样才能抵消因集群增大导致坏盘概率增加带来负面影响。计算表明，如果我们修复速度和集群规模成正比（线性关系），那么集群随着规模增大，可靠性会越来越高。

下表列出了1000块硬盘的存储集群在不同存储方案、不同修复时间下的可靠性计算结果：
副本存储方案 容错度（M） 修复时间 数据丢失概率（P） 可靠性
3副本方案 2 30分钟 1. 00E-08 8个9
3小时 1. 00E-05 5个9
15小时 1. 00E-02 2个9
28+4算术冗余方案 4 30分钟 1. 00E-16 16个9
3小时 1. 00E-11 11个9
15小时 1. 00E-07 7个9
　　对于数据丢失概率具体的计算公式和计算方法，由于篇幅所限，本文中不做展开，我会另找机会讨论。
　　对我个人而言，七牛新一代云存储（v2）的完成，了了我多年的夙愿。但七牛不会就此停止脚步。我们在存储系统上又有了一些好玩的想法。从长远来说，单位存储的成本会越来越廉价（硬件和软件系统都会推动这个发展趋势）。而存储系统肯定会越来越复杂。例如，有赖于超高的容错能力，七牛对单块磁盘的可靠性要求降低了很多，这就为未来我们采用桌面硬盘而不是企业硬盘作为存储介质打下基础。但是单块磁盘可靠性的降低，则会进一步推动存储系统往复杂的方向发展。基于这个推理，我认为存储必然需要转为云服务，成为水电煤一样的基础设施。存储系统越来越复杂，越来越专业，这就导致自建存储的难度和成本越来越高，自建存储的必要性也越来越低。必然有那么一天，你会发现云存储的成本远低于自建存储的成本，到时自建存储就会是纯投入而无产出，也就没有多少人会去热衷于干这样的事情了。