我目前正在一个网站上工作,应该向其用户提供大约 4000 万份文档和图像。我需要关于哪种方法最适合存储符合这些要求的内容的建议。
我做了一些研究,发现了以下解决方案;
该网站是使用 PHP 开发的,并使用 Couchbase 社区版作为数据库。
我真的很感激任何输入。
谢谢你。
最佳答案
过去两年我一直在研究类似的系统,工作仍在进行中。但是,要求与您的略有不同:无法修改(我将在稍后解释原因),文件大小范围从几个字节到几兆字节,最重要的是重复数据删除,这两个都应该实现在文档和块级别。如果两个不同的用户将同一文件上传到存储,则应保留该文件的唯一副本。此外,如果两个不同的文件彼此部分交叉,则有必要存储这些文件的公共(public)部分的唯一副本。
但是让我们专注于您的需求,因此重复数据删除并非如此。首先,高可用意味着复制 .您必须将文件存储在独立机器上的多个副本(通常为 2 或 3 个,但有一些技术可以减少数据奇偶校验)中,以便在后端的其中一台存储服务器死机时保持事件状态。此外,考虑到数据量的估计,很明显,您的所有数据都无法放入单个服务器中,因此垂直扩展是不可能的,您必须考虑 分区 .最后,你需要考虑并发控制当两个不同的客户端尝试同时写入或更新相同的数据时,以避免出现竞争条件。这个话题接近的概念交易 (我的意思不是字面上的酸,而是接近的意思)。因此,总而言之,这些事实意味着您实际上正在寻找旨在存储 BLOB 的分布式数据库。
分布式系统中最大的问题之一是系统全局状态的困难。简而言之,有两种方法:
master-slave
复制的常见情况),或者剩余的对等节点需要选举新的(像 Paxos
和 Raft
之类的算法旨在针对这个问题)。无论如何,几乎所有传入的系统流量都经过领导者。这导致了后端的“热点”:CPU 和 IO 成本在整个系统中分布不均的情况。顺便说一句,Raft
基于系统的写入吞吐量非常低(如果您有兴趣,请查看 etcd
和 consul
限制)。 所以现在让我们讨论您找到的选项:
Storing content as BLOBs in databases.
我认为将文件存储在传统 RDBMS 中不是一个好的选择,因为它们为结构化数据和强一致性提供了优化,而您不需要这两者。此外,您在备份和扩展方面也会遇到困难。人们通常不会以这种方式使用 RDBMS。
Using GridFS to chunk and store content.
我不确定,但看起来 GridFS 是建立在 MongoDB 之上的。同样,这是面向文档的数据库,旨在存储 JSON,而不是 BLOB。 MongoDB 的集群问题也有很多年了。 MongoDB passed Jepsen 仅在 2017 年进行测试。这可能意味着 MongoDB 集群尚未成熟。如果您这样做,请进行性能和压力测试。
Storing content in a file server in directories using a hash and storing the metadata in a database.
这个选项意味着你需要自己开发对象存储。考虑我上面提到的所有问题。
Using a distributed file system such as GlusterFS or HDFS and storing the file metadata in a database.
我没有使用这些解决方案,但 HDFS 看起来有点矫枉过正,因为你依赖于 Hadoop 堆栈。不知道 GlusterFS 的性能。始终考虑分布式文件系统的设计。如果他们有某种专用的“元数据”服务,请将其视为单点故障。
最后,我对可能适合您需求的解决方案的想法:
GPL
没问题,那么这是值得的。执照。 Red Hat
人们知道如何部署和维护它。所以准备好供应商锁定。我也听说它的设置太复杂了。从未在生产中使用过,所以不知道性能。 您也可以查看 wiki包含可用解决方案完整列表的页面。
最后一点:我强烈建议不要使用 OpenStack Swift(原因有很多,但首先,Python 不适合这些用途)。
关于blob - Web 应用程序的对象存储,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/53061611/