Image 存储大量图像

我正在考虑开发自己的基于PHP的图库，用于存储大量图片，可能有成千上万张

在数据库中，我将指向图像的url，但问题是：我知道让它们都位于服务器中的同一目录是不切实际的，因为这会降低对爬网的访问速度，因此，如何存储它们？基于jpeg/png名称的某种树

你建议我用什么规则来划分图像

---

（它将重点用于cheapo dot coms，因此不会损坏服务器）

使用文件系统的层次结构。使用像001/002/003/004.jpg这样的东西识别你的图像会很有帮助。不过，分区是另一回事。可以是随机的、基于内容的、基于创建日期的，等等。这取决于您的应用程序是什么

您可以查看Apple iPod用于存储多媒体内容的策略。有一个深度级别的文件夹和标题宽度相同的文件。我相信苹果公司的员工在测试他们的解决方案时投入了大量的时间，所以它可能会给您带来一些即时的好处。

我们过去也遇到过类似的问题。找到了一个很好的解决方案：

• 为每个图像指定一个唯一的guid
• 为每个映像创建一个数据库记录，其中包含子映像的名称、位置、guid和可能的位置（缩略图、缩减大小等）
• 使用guid的第一个（一个或两个）字符确定顶级文件夹
• 如果文件夹中的文件太多，请再次拆分。更新参考资料，您就可以开始了
• 如果文件数量和访问次数太多，则可以将文件夹分布在不同的文件服务器上

我们已经体验到，使用guid，您可以获得或多或少的统一划分。它就像一个符咒

可能有助于生成唯一ID的链接：

---

如果您正在处理的图片是数字照片，您可以使用EXIF数据对其进行排序，例如按捕获日期进行排序。

您可以将图像作为BLOB（用于mssql）存储在数据库中。这样，您就不必担心存储或目录结构。唯一的缺点是，您无法轻松浏览文件，但在平衡的目录树中这将很困难。

您可以在表中设置一个DateTime列，然后将它们存储在以添加到表中的图像的月份、年份甚至月份、天、年命名的文件夹中

范例

2009年

-01

--01

--02

--03

--三十一

---

这样，您的文件夹深度就不会超过3个。

我通常只使用数字数据库id（自动增量），然后使用modulu（%）运算符来确定文件的放置位置。简单且可扩展。例如，id为12345的图像路径可以这样创建：

12345 % 100 = 45
12345 % 1000 = 345

结果是：

/home/joe/images/345/45/12345.png

或者类似的

---

如果您使用的是Linux、ext3和文件系统，那么您必须知道，目录中可以包含的目录和文件的数量是有限制的。dir的限制是32000，因此您应该始终努力保持较低的dir数量。

几年前，我在一个电子文档管理系统上工作，我们几乎按照Gamecat和wic的建议做了

也就是说，为每个图像分配一个唯一的ID，并使用该ID导出图像文件的相对路径。我们使用类似wic建议的MOD，但我们允许每个级别有1024个文件夹/文件，有3个级别，因此我们可以支持1G文件

但是，我们从文件中删除了扩展名。DB记录包含MIME类型，因此不需要扩展

我不建议将完整的URL存储在DB记录中，仅存储图像ID。如果存储URL，则在不转换DB的情况下，无法移动或重构存储。相对URL是可以的，因为这样您至少可以移动图像存储库，但是如果您只存储ID并派生URL，您将获得更大的灵活性

此外，我不建议允许从web直接引用您的图像文件。相反，提供一个指向服务器端程序（例如Javaservlet）的URL，并在URL查询中提供图像ID（

http://url.com/GetImage?imageID=1234

）

---

servlet可以使用该ID查找DB记录、确定MIME类型、导出实际位置、检查安全限制、日志记录等。

查看XFS文件系统。它支持无限数量的文件，Linux也支持它。

---

在保存与自动增量ID相关联的文件时，我使用了如下方法，创建了三个目录级别，每个目录级别由1000个目录组成，每个第三级目录中有100个文件。这支持大约1000亿个文件

如果$id=99532455444，则以下返回/995/324/554/44

function getFileDirectory($id) {
    $level1 = ($id / 100000000) % 100000000;
    $level2 = (($id - $level1 * 100000000) / 100000) % 100000;
    $level3 = (($id - ($level1 * 100000000) - ($level2 * 100000)) / 100) % 1000;
    $file   = $id - (($level1 * 100000000) + ($level2 * 100000) + ($level3 * 100));

    return '/' . sprintf("%03d", $level1)
         . '/' . sprintf("%03d", $level2)
         . '/' . sprintf("%03d", $level3)
         . '/' . $file;
}

我知道让它们都位于服务器中的同一个目录是不切实际的，因为这样会减慢对爬网的访问

这是一个假设

我设计的系统将数百万个文件存储在一个目录中，效果非常好。它也是最容易编程的系统。大多数服务器文件系统都支持这一点，但没有问题（尽管您必须检查使用的是哪一个）

---

我目前正面临这个问题，艾萨克写的东西让我对这个想法产生了兴趣。虽然我的功能有点不同

function _getFilePath($id) {
    $id = sprintf("%06d", $id);
    $level = array();
    for($lvl = 3; $lvl >= 1; $lvl--)
        $level[$lvl] = substr($id, (($lvl*2)-2), 2);
    return implode('/', array_reverse($level)).'.jpg';
}

---

我的图片只有几千张，所以我最多只能有9999999张，所以它会将其拆分为99/99/99.jpg或43524到04/35/24.jpg

我不太清楚你在这里的意思。你能举个例子吗？由于性能原因，数据库调用通常非常昂贵，尤其是对于像图像这样的二进制数据。更不用说，从数据库中提供图像意味着你几乎总是将数据发送到文件系统中，就好像你可以从文件系统中提供数据一样，你可以让浏览器/服务器处理c