我有一个站点,在单个目录中包含超过 100k 的静态文件(总共 600k+ 目录和文件)。我想我可以在没有 inode 问题的情况下获得一个 VPS 来托管它,但它不会是一个高流量的网站,所以我宁愿使用便宜的虚拟主机。
我正在考虑将文件存储在由 URL 路径索引的 MySQL 表中并通过 PHP 提供服务。有更好的方法吗?
编辑:澄清一下,这与在数据库上存储图像不同。我说的是 HTML 页面。
我认为您最好的方法不是一开始就将它们存储在数据库中。在存储和服务文件方面,这是文件系统最擅长的。没有任何可能的原因表明数据库可以比普通文件系统更有效地执行此操作。
如果您要将它们存储在数据库中,那么考虑到大小限制,您将希望使用 BLOB 字段(例如 TEXT)并为了提高效率,对 URL 进行哈希处理并将其存储在列中,而不是索引一些巨大的 VARCHAR 字段。
但是,正如您所说,它们是静态的,这实际上没有任何意义——因为它们是静态的,因此您的网络服务器会向页面添加一些长缓存标头,以便将它们存储在本地,以备将来来自同一客户端的命中。
[编辑1-回应评论]
我用给出的信息回答了这个问题,并在 OP 没有提供信息的地方保持通用。
这取决于您索引的 VARCHAR 的多少——这与您要索引的存储数据的长度(URL/路径/页面名称)有关。
如果您只为 100k 行索引少于大约 45 个字符,我想这真的不会有太大的区别,哈希将使用更少的内存,但对于一个小集合的大小和性能可能不会真正产生太大的影响。
我在 OP 询问数据库时回答了这个问题,但仍然看不出有任何理由首先要将它们放在那里 - 它会比使用文件系统慢。0 为什么要连接到数据库,处理网络性能(除非它们在同一个盒子上——不太可能在 Web 主机中)查询索引,获取一行,通过数据库提供程序运行该数据并将输出流式传输到响应流,当 Web 服务器可以执行相同的结果时更少的 CPU 周期和与数据库相比内存使用量的一小部分?
是的 - 文件系统是数据库。我在过去 10 年中遇到的所有文件系统都可以轻松地在一个目录中容纳这么多文件 - 并且这些目录被实现为树(有些使用 B-Trees - 但是具有更大扇出的结构,例如 H-Trees更适合这种应用程序)。
(实际上,考虑到 coice,我建议将其构建为目录层次结构 - 例如,将 dirs 用于文件名的前 2 个字母或内容的 md5 散列 - 它可以在不影响性能的情况下更轻松地管理内容) .
关系数据库都是关于存储小块结构化数据的——它们不是管理大型可变大小数据的有效方法。
我手头没有任何基准,但就像我会选择一辆旅行车在运动摩托车上快速移动数 PB 的数据一样,我会使用合适的文件系统(例如 BTRFS 或 Ext4 - ZFS 会做工作也是如此,但在 Solaris 以外的任何东西上它都不是一个好的选择——而且 solaris 是否对网络服务器有意义是值得怀疑的)。
问题是廉价的托管公司很少预先提供这种级别的信息。
请注意,文件系统行为的细微调整可能会大大提高性能 - 在您的情况下,如果在 Linux 上运行,我建议显着降低 vfs_cache_pressure。但这需要root访问权限。
另一种方法是使用文档数据库而不是关系数据库(不是键/值存储)。这些是一种无模式 (NoSQL) 数据库,旨在提供对大型数据结构的快速复制和处理。因此,这将提供一个更具可扩展性的解决方案(如果这是一个问题)。例如 RavenDB。您可以使用键/值存储,但这些存储很少针对处理大数据负载进行优化。
如果您有一个非常充分的理由,而不是您在此处描述的内容,我只会考虑 MySQL。