我打算建立一个网络服务，我将在其中存储相当多的图像和PDF。为了存储这个，我可以选择将文件存储为常规文件，并将它们的文件名记录在数据库中，以及它们可能的标题，注释等。另一方面，我也可以使用文件存储，如Cassandra或MongDB。看到我没有使用文档存储的经验，我有点不确定为什么我会选择该选项。
据我所知，文档存储的优势主要在于可伸缩性和复制的可能性，而使用简单文件的主要优势（至少对我而言）就是它的简单性。
你会说其他哪些理由不利于选择其中一个？欢迎所有提示！
答案 0 :(得分：1)
嗯，根据你的描述，我想到了一些事情：
我要存储相当多的图片和PDF文件。
好吧，让我们假设每个用户都要存储大约10 MB，实际上并不多。现在让我们假设你有10000个用户。这只是100GB的数据，没问题，您可以轻松地将其存储在文件系统中（这有其他缺点，但稍后会有更多）。现在让我们假设你的应用程序很受欢迎，你的用户乘以10.现在我们有1TB的数据，即使在最大的磁盘上，我们也应该开始寻找扩展的方法，对于EBS，你有已经达到了硬限制。您的扩展选项是设置一个群集文件系统，它不容易管理或使用网络文件系统进行手动分区。现在如果其中一台服务器发生故障会怎样？自动故障转移？运气不好，您必须自己设置高可用性解决方案。容易设置冗余？运气不好。整合两者？这不是一件容易的事，你真的需要知道自己在做什么。
使用MongoDB，扩展更容易（尽管不容易正确执行）。如果您知道自己在做什么，则可以非常快速地设置复制的分片群集。分片群集是分布在一个到数百甚至数千个节点上的存储，这实质上意味着读取和写入分布在群集上，并且群集共享它的资源，从而可以存储PB的数据。由于群集中的一台机器很可能在运行数百或数千台机器时出现故障，因此MongoDB附带了一种称为副本集的自动故障转移机制。因此，一个分片至少由两个数据承载节点组成，当其中一个失败时，另一个会自动接管。
这是我在MongoDB中存储文件时看到的另一个优点：无论如何你必须访问数据库，而且我没有看到向数据库询问文件可能位置的位置，等待数据库响应然后访问文件系统（在访问失败的情况下进行所有必要的检查），以便在我可以将文件首先从数据库发回给我时检索文件。
将数据库中的元数据和文件系统中的文件存储的另一个微妙问题是，在元数据和实际文件之间保持一致性要困难得多。毕竟，数据存储在两个未连接的系统中。
以下是我要做的事情：如果有可能存在大于16MB的文件（MongoDB中BSON文档的限制），我会使用MongoDB's GridFS和在单个文件metadata中存储对相应所有者的引用。在某些情况下，将所有文件的引用存储在所有者文档中可能是合理的。
如果单个文件没有多少机会超过16MB限制，您可以使用标准MongoDB集合来存储文件。
如果您决定使用MongoDB，请提供一些建议：