在 LAMP 站点上使用长目录路径/名称和 URL 有哪些缺点？
LAMP 站点上较长的目录路径/名称和 URL 有何缺点？
我试图尽可能高效地组织网站上的图像，并且热衷于使用许多嵌套目录，这样子目录就不会超过 1,000 个子目录，这样目录就可以轻松地在许多用户之间维护。
在最坏的情况下，图像将被存储为如下所示：
./images/76/543/7654321/640/1.jpg
与这样简单的子目录相比，拥有如此多的子目录是否有任何严重的缺点：
./i/a7/c3/5e.jpg
我想服务器必须挖掘更多的子目录，花费的时间越长，目录结构越长，URL 就越长，因此 HREF 在 HTML 文档中占用的空间就越大。但这会产生多大的影响呢？假设我们扩展到数百万用户，这是我需要考虑的事情（短目录结构与长目录结构）还是可以使用较长的目录结构？
谢谢！
Possible Duplicate:
What are the downsides of longer directory paths/names and URL's on a LAMP site?
What are the downsides of longer directory paths/names and URL's on a LAMP site?
I am trying to organize images on my sites as efficiently as possible, and I'm keen on using many nested directories so that no sub-directory has more than 1,000 sub-directories and so that the directories are easy to maintain across many users.
In a worst-case scenario, images would be stored looking something like this:
./images/76/543/7654321/640/1.jpg
Are there any serious downsides to having so many sub-directories vs. something simpler like this:
./i/a7/c3/5e.jpg
I suppose the more sub-directories the Server has to dig in to, the longer it's going to take, and the longer the directory structure is, the longer the URL will be, so the more space the HREF will take up in the HTML doc. But how much of a difference will that make? Let's say we scale up to millions of users, is this something I need to take into consideration (short dir structure vs long dir structrue) or is it fine to go with the longer directory structure?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可以使用根据您的需求和经验“增长”的存储。
假设您根据图像本身创建图像的文件名，例如对其内容使用 SHA1，例如
b494ad9057e09277fd02e811bb8e86b322a5166b.jpg可以是名称。然后图像存储在文件系统的“images”目录中。
用于访问该文件的 URI 始终为
images/b494ad9057e09277fd02e811bb8e86b322a5166b.jpg。现在，奇迹发生在 Apache 的 mod_rewrite 内部。请求的资源可以按照您想要的任何方式拆分，例如拆分为
images/b494ad9057e09277fd02/e811bb8e86b322a5166b.jpg（请注意哈希的第 20 个字符后面的斜杠），然后从那里加载。一旦您从文件系统专家那里得到答案，您就可以更改 URI 的分割方式并将所有文件移动到新的预期位置，因为始终可以通过遍历目录层次结构来构建“原始”文件名。
此外，一个好的哈希应该在哈希中创建“均匀分布的字符”，因此您的目录应该或多或少以平衡的方式填充。
You could use a storage that "grows" with your needs and experience.
Let's assume you create the filename of the image based on the image itself, for example by using SHA1 on its content, e.g.
b494ad9057e09277fd02e811bb8e86b322a5166b.jpgcould be the name.The image then is stored on the file system inside "images" directory.
The URI you use to access the file always is
images/b494ad9057e09277fd02e811bb8e86b322a5166b.jpg.Now, the magic happens inside mod_rewrite of your Apache. The requested resource could be split in any way you want, for example into
images/b494ad9057e09277fd02/e811bb8e86b322a5166b.jpg(note the slash after the 20th character of the hash) and then loaded from there.Once you got an answer from a file system expert, you can change the way the URI is split and move all files to their new expected location, as it always is possible to build the "original" filename by traversing the directory hierarchy.
Furthermore, a good hash should create "equally distributed characters" in the hash, so your directories should fill up in a balanced way, more or less.