image - 有效存储许多缩略图的方法

Question

因此，当前我将所有缩略图存储在一个目录中，文件名作为全尺寸图像的完整路径的md5哈希。但是我在这里读到，当目录达到数千个文件时，这会导致问题。 linux文件系统将它们放得越来越慢。
考虑到只能按原始图像路径找到缩略图，我有什么选择？日期是最好的选择，例如year/month/day/md5_hash.jpg，但这需要我从某个地方存储和读取日期，因此将添加一些额外的步骤。
我正在考虑拆分md5，例如前两个字符=子文件夹名称，其余=文件名。那会给我15 * 15个子文件夹，但是我想听到更好的选择，谢谢!

我刚想到的另一个想法是:创建一个单独的服务器来组织缩略图。服务器将跟踪缩略图计数，并在达到一定限制时创建其他文件夹，并在删除拇指时重新使用旧文件夹。缺点是我需要一个单独的数据库，该数据库将哈希映射到缩略图路径:(

Answer 1

我们使用的是FreeBSD(文件系统UFS)，而不是Linux，因此某些细节可能有所不同。
背景
我们在此系统上有数百万个文件，需要从网站上尽快提供这些文件，以供个人访问。在过去的16年中，我们一直在使用的系统运行良好。
服务器1(名为:Tom)具有主要用户网站，该网站具有相当标准的Apache设置和MySQL数据库。没什么特别的。
服务器2(名为:Jerry)是存储用户文件的位置，并且已对其进行了自定义，以快速交付这些小文件。
Jerry的硬盘在创建过程中进行了调整，以确保我们不会用尽inode-创建数百万个小文件时需要考虑的事项。
对Jerry的Apache配置进行了调整，以使其连接时间非常短，并且每个连接可以访问单个文件。没有这些调整，您将坐在那里浪费了资源而拥有开放的连接。该Apache配置完全不适合主系统(Tom)，并且会引起许多问题。
在提供“缩略图”而不是单个请求时，您可能需要稍微不同的结构。老实说，我对您的需求了解不足，无法真正建议最适合您的Web服务器配置的东西。
从历史上看，我们在许多服务器上使用了多个SCSI驱动器。目前，我们有一台具有300MB/s驱动器的服务器。一段时间以来，这项业务一直处于下滑状态(这要归功于Facebook)，但我们每天仍在处理超过200万个文件请求。在我们的顶峰时期，每天的访问量更接近1000万。
我们的结构(可能的答案)
杰里(Jerry)上的所有内容都针对小文件传递进行了调整，仅此而已。
Jerry是一个网络服务器，但我们将其视为数据库。不需要的所有内容都将被删除。
每个文件都有一个4个字符的ID。 ID是字母数字(0-9，a-z，A-Z)。这将为您提供61 * 61 * 61 * 61组合(或13,845,841个ID)。
我们也有多个域，因此每个域最多具有13845841个ID。在Facebook出现之前，我们已经非常接近流行的“域名”，并且我们已经准备好计划允许5个字符的ID，但最终并不需要它。
如果您知道文件的完整路径，则文件系统查找非常快。仅当您需要扫描文件匹配项时，它才很慢。我们充分利用了这一点。
每个4个字符的ID是一系列目录。例如，aBc9是/path/to/a/B/c/9。
仅4个目录中的唯一ID数量非常多。每个目录最多具有61个子目录。创建快速查找而不淹没文件系统索引。
必需的元数据文件和原始数据文件位于./9目录(ID中的最后一个目录)中。元数据是已知的文件名，数据文件也是。每个文件夹中还有其他已知文件，但是您可以理解。
如果用户正在更新或检查元数据，则ID是已知的，因此将返回对元数据的请求。
如果再次请求数据文件，则ID是已知的，因此将返回数据。不执行扫描或复杂检查。
如果ID无效，则返回无效结果。
没什么复杂的，一切都是为了速度。
我们的问题
当您谈论数百万个小文件时，可能会用尽inode。确保从一开始就将此因素纳入服务器的磁盘创建中。未雨绸缪。
我们禁用和/或编辑了许多FreeBSD系统检查。维护cronjobs不适用于文件太多的系统。
Apache配置需要反复尝试才能使其正确。当您获得它时，可得到的缓解很大。 Apache的mod_status非常有帮助。
首先要做的是禁用所有日志文件。接下来，禁用所有内容并仅重新添加您需要的内容。
用于元数据和原始数据的传递(和保存)的代码也非常优化。忘记代码库。多年来，每一行代码都经过检查并重新检查了速度。
结论
如果确实有很多缩略图，请分割系统。因此，从经过优化的专用服务器中提供小文件。调整主系统以获得更多标准用法。
只要您不需要扫描文件，基于目录的ID系统(即随机的4个字符或MD5的一部分)就可以很快。
您需要对基本操作系统进行调整，以便系统检查不会占用系统资源。
禁用Web服务器日志文件创建。您几乎永远不需要它，它会在文件系统上造成瓶颈。如果您需要统计信息，可以从mod_status获得总体概述。
老实说，关于您的个案和需求的信息确实很少。我不确定我的个人经验是否会有所帮助。
祝你好运!