我将构建一个Web服务，其中将存储大量图像和PDF。为了存储此文件，我可以选择将文件存储为常规文件，并将它们的文件名以及可能的标题，注释等记录在数据库中。另一方面，我还可以使用文档存储，例如Cassandra或MongDB。鉴于我没有使用文档存储的经验，因此我不确定为什么要使用该选项。
据我了解，文档存储的优点主要是可伸缩性和复制可能性，而使用简单文件的主要优点（至少对我而言）是其简单性。
您还会说其他哪些原因不利于选择一个？欢迎所有提示！
好吧，从您的描述中，我想到了几件事：
我将存储大量的图像和PDF。
好的，让我们假设每个用户将要存储大约10 MB，这实际上并不多。现在，假设您有10000个用户。这仅是100GB的数据，没问题，您可以轻松地将其存储在文件系统中（它有其他缺点，但稍后会介绍更多）。现在，假设您的应用程序很受欢迎，您的用户数乘以10。现在，我们有1TB的数据，即使在最大的磁盘上，我们也应该开始寻找扩展的方法，而对于EBS，您已经很难了限制。您可以选择扩展的方法是设置群集文件系统（这并不容易管理），或者使用网络文件系统进行手动分区。现在，如果这些服务器之一发生故障，会发生什么？自动故障转移？不幸的是，您必须自己设置一个高可用性解决方案。易于设置冗余吗？倒霉 整合两者吗？这不是一件容易的事，您确实需要知道自己在做什么。
使用MongoDB，向外扩展要容易得多（尽管要正确地进行扩展并不容易）。如果您知道自己在做什么，则可以相当快地建立复制的分片群集。分片群集是分布在一个到数百个甚至数千个节点上的存储，这实质上意味着读写分布在整个群集上，并且群集共享其资源，从而可以存储数据PB。由于运行数百或数千台群集时，群集中的一台计算机很可能发生故障，因此MongoDB附带了一种自动故障转移机制，称为副本集。因此，一个分片至少包含两个数据承载节点，当其中一个发生故障时，另一个将自动接管。
我从将文件存储在MongoDB中看到的另一个好处是：无论如何您都必须访问数据库，而且我看不到询问数据库文件可能在哪里，等待数据库响应然后访问文件的意义。系统（首先进行所有必要的检查，以防访问失败）在我可以首先从数据库将文件发送回给我时检索文件。
将元数据存储在数据库和文件系统中的文件中的另一个细微问题是，保持元数据和实际文件之间的一致性要困难得多。毕竟，数据存储在两个未连接的系统中。
这就是我要做的事情：如果极有可能文件大于16MB（MongoDB中BSON文档的限制），我将使用MongoDB的GridFS并存储对各自所有者的引用在单个文件的元数据中。在某些情况下，将对文件的引用存储在所有者文档中可能是合理的。
如果单个文件几乎没有机会超过16MB的限制，则可以使用标准的MongoDB集合来存储文件。
一些建议，以防您决定使用MongoDB：
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句