我将构建一个Web服务，在其中存储相当多的图像和PDF。为了存储这些文件，我可以选择将文件存储为常规文件，并将它们的文件名以及可能的标题、注释等记录在DB中。另一方面，我也可以使用Cassandra或MongDB等文档存储。鉴于我没有使用文档存储的经验，我有点不确定为什么我会选择这个选项。
据我所知，文档存储的优势主要是可扩展性和复制的可能性，而使用简单文件的主要优势（至少对我来说）是它的简单性。
你认为还有哪些原因对选择一个而不是另一个不利？欢迎所有提示！
从你的描述中，我想到了几件事：
我将存储相当多的图像和PDF。
好吧，让我们假设每个用户都要存储一些10MB，这实际上并不多。现在让我们假设您有10000个用户。这只是100GB的数据，没问题，你可以很容易地将其存储在文件系统中（这也有其他缺点，但稍后会详细介绍）。现在让我们假设你的应用程序很受欢迎，你的用户乘以10。现在我们有1TB的数据，即使在最大的磁盘上，我们也应该开始找到一种扩展的方法，对于EBS，您已经达到了硬限制。您的扩展选项是设置一个不太容易管理的集群文件系统，或者使用网络文件系统进行手动分区。现在，如果其中一台服务器出现故障，会发生什么？自动故障切换？运气不好，您必须自己设置一个高可用性解决方案。易于设置冗余？运气也不好。两者结合？这不是一项容易的任务，你真的需要知道自己在做什么。
使用MongoDB，扩展要容易得多（尽管要正确地做到这一点并不容易）。如果您知道自己在做什么，那么可以很快建立一个复制的分片集群。分片集群是分布在一到数百甚至数千个节点上的存储，这本质上意味着读写分布在集群上，集群共享其资源，从而可以存储PB的数据。由于集群中的一台机器在运行数百或数千台机器时很可能发生故障，MongoDB提供了一种称为副本集的自动故障转移机制。因此，单个shard至少由两个数据承载节点组成，当其中一个节点发生故障时，另一个节点会自动接管。
我从将文件存储在MongoDB中看到的另一个优势是：无论如何，你都必须访问数据库，我认为询问数据库文件可能在哪里没有意义，等待数据库响应，然后访问文件系统（在访问失败的情况下进行所有必要的检查）以检索文件，此时我可以首先从数据库将文件发回给我。
将元数据存储在数据库中而将文件存储在文件系统中的另一个微妙问题是，要保持元数据和实际文件之间的一致性要困难得多。毕竟，数据存储在两个未连接的系统中。
以下是我要做的：如果有一点点可能会有大于16MB的文件（MongoDB中BSON文档的限制），我会使用MongoDB的GridFS，并在单个文件的元数据中存储对相应所有者的引用。在某些情况下，将对该文件的引用存储在所有者文档中可能是合理的。
如果单个文件超过16MB限制的可能性微乎其微，那么可以使用标准的MongoDB集合来存储这些文件。
如果你决定使用MongoDB，一些建议：
- 如果这是一个商业项目，那么明智的做法是雇佣一名MongoDB DBA，至少一段时间。虽然MongoDB看起来非常简单，但也有一些需要注意的地方。由于这些通常取决于个人情况，我不能在这里给出太多一般性的建议
- 尽早规划您的扩展策略。如果有一点点机会打破硬件的限制，我建议从一个带有单个碎片的碎片集群开始
- Always 拥有由一个副本集组成的单个碎片，该副本集至少有2个数据承载节点和一个仲裁器。（根据经验：承载数据的节点越多越好。）否则，您就无法进行自动故障切换，维护集群将导致停机或数据不可用。根据您的写问题设置，如果您的碎片不由副本集组成，并且目标碎片已关闭，则数据甚至可能在写操作期间静默丢失。再次：始终让集群的碎片由副本集组成