适合约 250,000 张图像的最佳 Web 文件夹结构
我的网站将包含大约 200,000 张图像。 每张图像将被存储 3 次：全尺寸、缩略图、更大缩略图。 全尺寸图像约为 50Kb 至 500Kb。
普通技术：VPS 上的 Linux、Apache、MySQL、PHP。
存储这些内容以便通过浏览器快速检索和显示的最佳方式是什么？
我应该将所有内容存储在一个文件夹中吗？ 我应该将全尺寸图像存储在 1 个文件夹中，将缩略图存储在另一个文件夹中吗？ 我应该将图像存储在 1000 个文件夹中，并保留图像所在文件夹的索引吗？
感谢您的任何建议。 阿尔伯特.
I will have around 200,000 images as part of my website. Each image will be stored 3 times: full size, thumbnail, larger thumbnail. Full size images are around 50Kb to 500Kb.
Normal tech: Linux, Apache, MySQL, PHP on a VPS.
What is the optimum way to store these for fast retrieval and display via a browser??
Should I store everything in a single folder?
Should I store the full size images in 1 folder, the thumbails in another etc?
Should I store the images in folders of 1000, and keep an index to which folder the image is in?
Thanks for any advice.
Albert.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我会使用三层或四层深度的分割目录结构，其想法是将所有文件均匀地分割到多个目录中，主要是为了方便维护和快速访问。
怎么做？ 有多种替代方案：
假设我们有 IMG8993_full.jpg、IMG8993_thumb.jpg、IMG8993_smallthumb.jpg
那么我们可以有，例如：
I'd use a split directory structure, three or four levels deep, the idea being split all the files evenly across many directories, to enable mainly easy maintenance and fast access.
How to do it? There are various alternatives:
Let's suppose we have IMG8993_full.jpg, IMG8993_thumb.jpg, IMG8993_smallthumb.jpg
Then we could have, for example:
除非您的用户要访问包含图像目录列表的打开文件夹，否则我认为文件夹结构不会显着提高或降低用户的检索速度。 正如其他人所说，确保索引已打开。 但是，如果我是您，我会考虑编写（或复制和粘贴）动态提供图像的服务，而不是将它们直接存储在您的 Web 文件结构中。 考虑在 PHP 中使用 LibGD——它应该预安装在大多数 LAMP 服务器上。
缺点：
优点：
使用 URL 重写，您甚至可以将丑陋的 URL 变成
对用户来说更时尚、更透明的内容：
这将给您一个完整的外观图像的目录结构，而它们实际上以您想要的任何后端格式存储。
Unless your users are going to an open folder with a directory listing of your images, I don't think folder structure will significantly increase or decrease retrieval speeds for your users. As other people have said, make sure indexing is turned on. However, if I were you, I'd look into writing (or copying and pasting) a service that dynamically serves the images, rather than storing them directly in your web file structure. Look into using LibGD within PHP -- it should be preinstalled on most LAMP servers.
Disadvantages:
Advantages:
Using URL rewriting, you can even turn ugly URLs such as
into something sleeker and more transparent to your users:
This will give the apperance of an entire directory structure of images, whereas they're really stored in whatever backend format you'd like.
取决于您如何对它们建立索引以及如何检索它们。
没有什么特别反对将它们全部存储在一个文件夹中，但它变得难以管理。 如果您按文件名存储它们，并且文件名呈合理的正态分布，您可能希望用名称的第一个字母等分隔子文件夹。如果您按添加日期建立索引，您可能希望按该日期分隔它们。
据我所知，没有“更快”或“更慢”的方式来存储图像以供浏览器检索。
Depends on how you're indexing them, for how to retrieve them.
There's nothing particularly against storing them all in a single folder, but it becomes difficult to manage. If you're storing them by filename, and the filenames are reasonably normally distributed, you might want to have subfolders separated by first letter of the name, etc. If you're indexing by date added, you may want to segregate them by that.
As far as I know, there's no "faster" or "slower" way to store the images for browser retrieval.
无论您做什么，请确保在文件系统上启用目录索引（您应该选择支持它的文件系统 - 但它们都支持）
在实践中，例如 ext3，这不是问题，因为它在较新的系统上默认启用。 你可以通过使用tune2fs找到答案（阅读man）
Whatever you do, ensure that directory indexing is enabled on the filesystem (you should choose a filesystem which supports it - but they all do)
In practice on, say, ext3, this isn't a problem as it's enabled by default on newer systems. You can find out by using tune2fs (read the man)
对于这些类型的数字，您可能会或可能不会遇到服务器上设置的 inode 限制。 这可能会出现问题，具体取决于谁控制该盒子。
一般来说，我会想出一些方案将它们分成更易于管理的大小。 即使在如此大小的目录上运行 ls 也需要很长时间才能对其进行排序和显示。
With those kinds of numbers you may or may not run into an inode limit set on your server. That could be problematic depending upon who controls that box.
In general, I would come up with some scheme to split them up into more manageable sizes. Even running
lson a directory that size would take ages to sort and display all of it.