【问题标题】:Hosting large amounts of binary data (Images) on Windows Servers在 Windows 服务器上托管大量二进制数据(图像)
【发布时间】:2013-07-21 17:08:47
【问题描述】:

免责声明:根本不可以使用 Amazon S3 或 Azure Blob 存储等云服务。

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

我的问题:

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

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

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

谢谢!

【问题讨论】:

  • 不确定 SAN 是否适合您,但如果是,您可能需要研究一下。在我工作的地方,我们目前使用 SAN 将超过 1000 万个二进制文件(PDF 文件)存储在一个目录中! SAN 的文件系统通过 1 gigE 专用 LAN 安装在 Windows 2008 R2 服务器上。
  • 谢谢,听起来不错。无论如何,我更喜欢基于 Windows 的(软件)解决方案,以便能够只租用几台服务器。

标签: nosql cdn ntfs gridfs windows-server


【解决方案1】:

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

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

文档存储本身由一个 Web 服务器、一个数据库和一个(非常复杂的)文件系统(带有 SATA、SCSI 和磁带的 SAN)组成。

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

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

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

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

【讨论】:

    【解决方案2】:

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

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

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

    【讨论】:

    • 哇。听起来很神奇。感谢分享!
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2019-05-09
    • 1970-01-01
    • 2017-06-07
    • 1970-01-01
    • 2014-02-06
    • 2021-11-07
    • 1970-01-01
    相关资源
    最近更新 更多