Web应用程序的对象存储

Question

我目前正在开发一个网站,其中应该向其用户提供大约4000万份文档和图像.我需要建议哪种方法最适合存储符合这些要求的内容.

• 系统应具有高可用性,可扩展性和耐用性.
• 文件必须永久存储,用户应该能够修改它们.
• 由于客户端的限制,第三方对象存储提供商(如Amazon S3和CDN)不适合.
• 内容的文件大小可以从1 MB到30 MB不等.(但是大约90%的文件小于2 MB)
• 内容检索延迟不是什么大问题.因此索引或缓存不是很重要.

我做了一些研究,发现了以下解决方案;

• 将内容存储为数据库中的BLOB.
• 使用GridFS来分块和存储内容.
• 使用散列将内容存储在目录中的文件服务器中,并将元数据存储在数据库中.
• 使用分布式文件系统(如GlusterFS或HDFS)并将文件元数据存储在数据库中.

该网站使用PHP开发,Couchbase Community Edition用作数据库.

我真的很感激任何输入.

谢谢.

Answer 1

过去两年我一直在研究类似的系统，工作仍在进行中。但是，要求与您的略有不同：无法修改（我将在稍后解释原因），文件大小范围从几个字节到几兆字节，最重要的是重复数据删除，这两个都应该实现在文档和块级别。如果两个不同的用户将同一文件上传到存储，则应保留该文件的唯一副本。此外，如果两个不同的文件彼此部分交叉，则有必要存储这些文件的公共部分的唯一副本。

但是让我们专注于您的需求，因此重复数据删除并非如此。首先，高可用性意味着复制。您必须将文件存储在独立机器上的多个副本（通常为 2 或 3 个，但有一些技术可以减少数据奇偶校验）中，以便在后端的其中一台存储服务器死机时保持活动状态。此外，考虑到数据量的估计，很明显，您的所有数据都无法放入单个服务器中，因此垂直扩展是不可能的，您必须考虑分区。最后，您需要考虑交易当两个不同的客户端尝试同时写入或更新相同的数据时并发控制以避免竞争条件。这个话题接近于的概念（我的意思不是字面上的酸，而是接近的意思）。因此，总而言之，这些事实意味着您实际上正在寻找旨在存储 BLOB 的分布式数据库。

分布式系统中最大的问题之一是系统全局状态的困难。简而言之，有两种方法：

1. 选择将与其他对等方通信并维护分布式系统全局状态的领导者。这种方法提供了很强的一致性和线性化保证。主要的缺点是在这种情况下领导者成为单点故障。如果领导者死亡，则某个观察者必须将领导者角色分配给其中一个副本（master-slaveRDBMS 世界中复制的常见情况），或者剩余的对等节点需要选举新的（算法Paxos和Raft旨在解决此问题的）。无论如何，几乎所有传入的系统流量都经过领导者。这导致了后端的“热点”：CPU 和 IO 成本在整个系统中分布不均的情况。顺便一提，Raft基于系统的写入吞吐量非常低（如果您感兴趣，请检查etcd和consul限制）。
2. 完全避免全局状态。削弱对最终一致性的保证。禁用文件更新。如果有人要编辑该文件，则需要将其另存为新文件。使用组织为对等网络的系统。集群中没有保持系统完整跟踪的对等点，因此不存在单点故障。这导致高写入吞吐量和良好的水平可扩展性。

所以现在让我们讨论您找到的选项：

将内容作为 BLOB 存储在数据库中。

我认为将文件存储在传统 RDBMS 中不是一个好的选择，因为它们为结构化数据和强一致性提供了优化，而您不需要这些。此外，您在备份和扩展方面也会遇到困难。人们通常不会以这种方式使用 RDBMS。

使用 GridFS 对内容进行分块和存储。

我不确定，但看起来 GridFS 是建立在 MongoDB 之上的。同样，这是面向文档的数据库，旨在存储 JSON，而不是 BLOB。MongoDB 的集群问题也有很多年了。MongoDB仅在 2017 年才通过Jepsen 测试。这可能意味着 MongoDB 集群尚未成熟。如果您这样做，请进行性能和压力测试。

使用哈希将文件服务器中的内容存储在目录中，并将元数据存储在数据库中。

这个选项意味着你需要自己开发对象存储。考虑我上面提到的所有问题。

使用分布式文件系统（例如 GlusterFS 或 HDFS）并将文件元数据存储在数据库中。

我没有使用这些解决方案，但 HDFS 看起来有点矫枉过正，因为你依赖于 Hadoop 堆栈。不知道 GlusterFS 的性能。始终考虑分布式文件系统的设计。如果他们有某种专用的“元数据”服务，请将其视为单点故障。

最后，我对可能适合您需求的解决方案的想法：

1. 椭圆机。这种对象存储在俄语部分以外的互联网并不为人所知，但它成熟稳定，性能完美。它是由 Yandex（俄罗斯搜索引擎）开发的，许多 Yandex 服务（如磁盘、邮件、音乐、图片托管等）都建立在它之上。我在之前的项目中使用过它，这可能需要一些时间让您的操作人员使用它，但是如果您对GPL许可证没问题，那么这是值得的。
2. 头孢。这是真正的对象存储。它也是开源的，但似乎只有Red Hat人们知道如何部署和维护它。所以准备好供应商锁定。我也听说它的设置太复杂了。从未在生产中使用过，所以不知道性能。
3. 米尼奥。这是 S3 兼容的对象存储，目前正在积极开发中。从未在生产中使用它，但它似乎设计得很好。

您还可以查看包含可用解决方案完整列表的wiki页面。

最后一点：我强烈建议不要使用 OpenStack Swift（原因有很多，但首先，Python 不适合这些用途）。