我知道怎么做，但我想知道它是否有效。据我所知，MongoDB 拥有非常高效的集群，我可以灵活地控制集合及其驻留的服务器。唯一的问题是文件的大小和通过 MongoDB 访问它们的速度。
我应该探索类似 Apache Hadoop 的东西，还是如果我智能地集群 MongoDB，我会得到类似的访问速度结果吗？
GridFS 是为方便起见而提供的，它并非旨在成为最终的二进制 blob 存储平台。
MongoDB 对其存储的每个文档施加了 16 MB 的限制。例如，这不同于许多允许存储更大值的关系数据库。
由于许多应用程序都处理大型二进制 blob，MongoDB 解决这个问题的方法是 GridFS，它的工作原理大致如下:
- 对于每个要插入的 blob，元数据文档都会插入到元数据集合中。
- 然后，实际的 blob 被分成 16 MB 的 block ，并作为文档序列上传到 blob 集合中。
- MongoDB 驱动程序提供编写和读取 blob 和元数据的帮助程序。
因此，乍一看，问题已解决 - 应用程序可以直接存储任意大的 blob。然而，深入挖掘，GridFS 存在以下问题/局限性:
- 在服务器端，存储 blob block 的文档不会与其他文档分开存储。因此，它们与实际文档竞争缓存空间。同时具有内容文档和 blob 的数据库的性能可能比仅具有内容文档的数据库差。
- 同时，由于 blob block 的存储方式与内容文档相同，因此存储它们通常昂贵。例如，S3 比 EBS 存储便宜得多，而 GridFS 会将所有数据放在 EBS 上。
- 据我所知，不支持并行写入或并行读取 blob(一次写入/读取同一 blob 的多个 block )。这原则上可以在 MongoDB 驱动程序或应用程序中实现，但据我所知，任何驱动程序都没有开箱即用。当 blob 很大时，这会限制 I/O 性能。
- 同样，如果读取或写入失败，则必须重新读取或重写整个 blob，而不仅仅是丢失的片段。
尽管存在这些问题，GridFS 对于许多用例来说可能是一个很好的解决方案:
- 如果总体数据量不是很大，缓存的负面影响是有限的。
- 如果大多数 blob 都可以放在一个文档中，那么它们的存储应该非常高效。
- 对 blob 进行备份，并以其他方式与数据库中的内容文档一起传输，从而提高数据一致性并降低数据丢失/不一致的风险。