为什么人们不使用序列号进行图像存储


Why people don't use sequential numbers for image storage?

我一直在环顾四周,我看到,例如,Instagram使用大字符串来命名他们的图像(例如instagram/p/BB-cCvtje4k),Facebook也是如此。像这个用户/1,下一张图片命名这个用户/2等有什么缺点吗?还是在我的服务器端代码上做类似下面的事情是不好的做法?

$i=1;
while(file_exists('thisuser/'.$i)) {
    i++;
}
$image_path = 'thisuser/'.$i;

谢谢!

Instagram或Facebook规模上为网站使用基数10位字符的缺点是URL可能太长了。请记住,Facebook每周会收到大约10亿张新照片上传。所以这是很多数字。使用类似以 36 为基数的字母表可能会减少字符数。在这种规模下,效率在多个方面都很重要。

但是,您可能没有考虑到的是,这些URL及其含义背后有一个非常独特的设计,并且与顺序或非顺序数字无关。

例如,根据Facebook关于Haystack中的一根针的白皮书:Facebook的照片存储,他们指出URL是这样组成的http://(CDN)/(Cache)/(Machine id)/(Logical volume, Photo)其中URL的每个部分都代表一个不同的物理/逻辑标识符,该标识符可以精确定位在其照片存储机制中可以从中检索照片的位置。

当用户访问页面时,Web 服务器会使用目录 为每张照片构建一个 URL。网址 包含多条信息,每条对应 到从用户 浏览器联系 CDN(或缓存)以最终检索 商店中机器的照片。一个典型的 将浏览器定向到 CDN 的 URL 看起来像 以后: http://(CDN)/(Cache)/(Machine id)/(Logical volume, Photo)

Sherif的回答很好地描述了这个问题。简而言之,这完全取决于您的期望 - 总共或每天将有多少图像,您是否将使用它们将其显示给用户。

例如,如果每天要上传大量图像,则可以隔离文件夹年/月/日/-image_name.img-,其中图像名称可以是随机的uuid。对于少量文件,当您不关心用户是否能够访问他不应该访问的图像时,序列号命名就可以了。