2

免责声明：使用 Amazon S3 或 Azure Blob 存储等云服务根本不是一种选择。

目标：在 Windows 服务器上托管数百万 (*) 个图像和视频文件。我知道 NTFS 在这种情况下的局限性。所以我尝试了带有 GridFS 和 2 GB 容器的 MongoDB，它运行良好但有点慢（我还不知道为什么）。

我的问题：

  1. 是否有关于在大量文件的上下文中使用 MongoDB/GridFS 的真实世界报告？
  2. 是否有其他已知的可靠、易于配置和水平可扩展的选项？

我知道我的场景描述得很模糊，但我现在没有任何真实数据，所以请不要怪我;-)。

(*) 可能只有几万到几十万，但希望有一天能达到数百万......

谢谢！

4

2 回答 2

3

我想分享我们的成功故事。我们正在使用 MongoDB GridFS 来存储数百万张图像。我们的其中一个存储有：

  • 2个mongodb分片
  • 大约 500 Gb 的数据
  • 14,998,166 个文件
  • 2.5 Gb 索引大小

作为前端，我们有 nginx 和用 Go 编写的简单守护程序，它能够为来自 GridFS 的数据提供每秒超过 1,000 个请求。

于 2013-08-21T12:45:56.843 回答
2

鉴于我对 GridFS 一无所知，我将在一个相当大的（250+ 百万个文档@ 10kb 到数百 mb 大小）系统中记录我几年前看到的一些东西。

文档检索由只知道存储库名称和文档令牌的主机系统（可能是您的核心应用程序）启动。

文档存储本身由 Web 服务器、数据库和（安静复杂的）文件系统（带有 SATA、SCSI 和磁带的 SAN）组成。

Web 服务器接收到对某个 repo 中的文档的请求，从数据库中获取元数据（reponame、token -> 文件夹名、文件名）从磁盘中获取文件并通过网络将其吐出。没有使用数据库集成文件流等。这个概念非常快速、简单且坚固。我们曾经与一些数据库存储（IIRC Oracle 和 MSSQL）进行了比较，这导致了这些数据库的灾难，尤其是在速度方面。我认为 MSSQL 在这些时候没有使用本机文件系统。

要添加一些水平可扩展性，您可能只需要找到一种机制来在服务器（也称为存储库、分片）之间分配负载。

根据我的经验，此类文档存储中文件的检索和加载速度与您使用的存储类型高度相关。RAID 系统、SAN、内存文件系统或 RAMSAN 是必须具备的，具体取决于您的要求。

恕我直言，如果您想要速度，请始终使用本机文件系统并知道它在做什么。这意味着您必须自己做一些肮脏的工作（尤其是分片）。

于 2013-07-31T19:24:35.703 回答