我有一个项目将生成大量图像。开始时大约有 1,000,000 张。它们不是大图像，所以我会在开始时将它们全部存储在一台机器上。
您建议如何有效地存储这些图像？（目前为 NTFS 文件系统）
我正在考虑一个命名方案...首先，所有图像都会有一个从 1 开始的增量名称，我希望这可以帮助我在以后需要时对它们进行排序，并将它们放在不同的文件夹中。
更好的命名方案是：
a/b/c/0...z/z/z/999
或者
a/b/c/000...z/z/z/999
对此有什么想法吗？
答案1
我建议使用常规文件系统而不是数据库。使用文件系统比数据库更容易，您可以使用常规工具来访问文件，文件系统就是为这种用途而设计的，等等。NTFS 作为存储系统应该可以很好地工作。
不要将实际路径存储到数据库中。最好将图像的序列号存储到数据库中，并具有可以从序列号生成路径的函数。例如：
File path = generatePathFromSequenceNumber(sequenceNumber);
如果您需要以某种方式更改目录结构，则处理起来会更容易。也许您需要将图像移动到不同的位置，也许您用完了空间，您开始将一些图像存储在磁盘 A 上，将一些存储在磁盘 B 上，等等。更改一个功能比更改数据库中的路径更容易。
我将使用这种算法来生成目录结构：
- 首先用前导零填充序列号，直到至少有 12 位数字的字符串。这是文件的名称。您可能需要添加后缀：
12345->000000012345.jpg
- 然后将字符串拆分为 2 或 3 个字符块，每个字符块表示一个目录级别。目录级别数量固定（例如 3）：
000000012345->000/000/012
- 将文件存储到生成的目录下：
123因此 ，序列号为 的文件的完整路径和文件名为000/000/012/00000000012345.jpg- 对于具有序列 id 的文件，
12345678901234路径将是123/456/789/12345678901234.jpg
关于目录结构和文件存储需要考虑的一些事项：
- 上述算法为您提供了一个系统，其中每个叶目录最多有 1000 个文件（如果文件总数少于 1 000 000 000 000 个）
- 目录可以包含的文件和子目录的数量可能会受到限制，例如Linux 上的 ext3 文件系统每个目录最多可包含 31998 个子目录。
- 如果每个目录中有大量文件（> 1000），常规工具（WinZip、Windows 资源管理器、命令行、bash shell 等）可能无法很好地工作
- 目录结构本身会占用一些磁盘空间，所以你不会想要太多的目录。
- 通过上述结构，如果您碰巧弄乱了目录结构，您只需查看文件名就可以找到图像文件的正确路径。
- 如果您需要从多台机器访问文件，请考虑通过网络文件系统共享文件。
- 如果您删除大量文件，上述目录结构将不起作用。它会在目录结构中留下“空洞”。但由于您没有删除任何文件，所以应该没问题。
答案2
我要提出一点自己的看法，那就是：不要使用数据库。
多年来，我一直在处理图像存储数据库：大型（1 MB 到 1 GB）文件，经常更改，文件有多个版本，访问频率相当高。存储大型文件时遇到的数据库问题非常繁琐，写入和事务问题非常棘手，而且会遇到可能导致严重事故的锁定问题。我编写 dbcc 脚本和从备份中恢复表的经验比任何普通人都要多曾经有。
我使用过的大多数新系统都将文件存储推到了文件系统中，并且仅依靠数据库进行索引。文件系统的设计可以承受这种滥用，它们更容易扩展，并且如果一个条目损坏，您很少会丢失整个文件系统。
答案3
我认为大多数必须处理此问题的网站都会使用某种类型的哈希来确保文件均匀分布在文件夹中。
假设您有一个文件的哈希值，如下所示515d7eab9c29349e0cde90381ee8f810
您可以将其存储在以下位置，并且可以使用所需的深度级别，以保持每个文件夹中的文件数量较少。
\51\5d\7e\ab\9c\29\349e0cde90381ee8f810.jpg
我见过很多次采用这种方法。您仍然需要一个数据库来将这些文件哈希映射到人类可读的名称以及您需要存储的任何其他元数据。但这种方法的扩展性相当好，因为您可以开始在多台计算机和/或存储池之间分配哈希地址空间等。
答案4
无论你做什么，都不要将它们全部存储在一个目录中。
根据这些图像名称的分布，您可以创建一个目录结构，其中有单个字母的顶级文件夹，其中还有另一组用于第二个字母的图像的子文件夹等。
所以：
文件夹img\a\b\c\d\e\f\g\将包含以“abcdefg”开头的图像等。
你可以介绍你自己所需的适当深度。
此解决方案的优点在于目录结构实际上就像一个哈希表/字典。给定一个图像文件名，您将知道其目录；给定一个目录，您将知道存放在该目录中的图像子集。