在Windows服务器上托管大量二进制数据（图像）

Question

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

目标：在Windows服务器上托管数百万（*）的图像和视频文件。我知道NTFS在这种情况下的局限性。所以我给了带有2 GB容器的GridFS的MongoDB一次试用，效果不错但有点慢（我还没弄清楚原因）。

我的问题：

1. 在大量文件的上下文中是否有关于MongoDB / GridFS使用情况的实际报告？
2. 是否有任何其他可靠，易于配置且水平可扩展的选项？

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

（*）可能只有几万到几十万，但希望有一天能有数百万......

谢谢！

Answer 1

鉴于我对GridFS一无所知，我只会放下几年前在一个相当大的（2.5亿个文件@ 10kb到数百mb）系统中看到过的东西。

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

文档存储本身包括一个Web服务器，一个数据库和一个（安静复杂的）文件系统（带有SATA，SCSI和磁带的SAN）。

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

要添加一些水平可伸缩性，您可能只需要找到一种机制来在服务器之间分配负载（a.k.a存储库，分片）。

根据我的经验，这些文档存储中文件的检索和加载速度与您使用的存储类型高度互连。根据您的要求，RAID系统，SAN，内存文件系统或RAMSAN是必须的。

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

Answer 2

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

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

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