當LAMP服務器上有數百萬用戶時，存儲和獲取圖像的最快和最有效的方法是什么？

Question

這是我到目前為止提出的最好的方法，我想知道是否有更好的方法（我確定有！）用於存儲和獲取數百萬用戶圖像：

為了保持目錄大小不變並避免對數據庫進行任何其他調用，我使用的嵌套目錄是根據用戶的唯一ID計算的，如下所示：

$firstDir = './images';
$secondDir = floor($userID / 100000);
$thirdDir = floor(substr($id, -5, 5) / 100);
$fourthDir = $userID;
$imgLocation = "$firstDir/$secondDir/$thirdDir/$fourthDir/1.jpg";

用戶ID（ $userID ）的范圍從1到數百萬。

因此，如果我有用戶ID 7654321 ，那么該用戶的第一張照片將存儲在：

./images/76/543/7654321/1.jpg

對於用戶ID 654321 ：

./images/6/543/654321/1.jpg

對於用戶ID 54321 ，它將是：

./images/0/543/54321/1.jpg

對於用戶ID 4321 ，它將是：

./images/0/43/4321/1.jpg

對於用戶ID 321 ，它將是：

./images/0/3/321/1.jpg

對於用戶ID 21 ，它將是：

./images/0/0/21/1.jpg

對於用戶ID 1 ，它將是：

./images/0/0/1/1.jpg

這確保了最多100,000,000個用戶，我將永遠不會擁有超過1,000個子目錄的目錄，因此它似乎可以保持干凈和高效。

我使用以下“哈希”方法對此方法進行基准測試，該方法使用PHP中可用的最快哈希方法（crc32）。 此“哈希”方法將第二個目錄計算為用戶ID哈希值中的前3個字符，將第三個目錄計算為下一個3個字符，以便隨機分布文件，但如下所示：

$hash = crc32($userID);
$firstDir = './images';
$secondDir = substr($hash,0,3);
$thirdDir = substr($hash,3,3);
$fourthDir = $userID;
$imgLocation = "$firstDir/$secondDir/$thirdDir/$fourthDir/1.jpg";

但是，這種“哈希”方法比我前面描述的方法慢，所以它沒有用。

然后，我進一步發現了一個更快的方法來計算我的原始示例中的第三個目錄（ floor(substr($userID, -5, 5) / 100); ）如下：

$thirdDir = floor(substr($userID, -5, 3));

現在，這改變了存儲前10,000個用戶ID的方式/位置，使得一些第三個目錄具有1個用戶子目錄或111而不是100，但它具有更快的優勢，因為我們不必除以100，所以我認為從長遠來看這是值得的。

一旦定義了目錄結構，這里是我計划存儲實際單個圖像的方式：例如，如果用戶上傳第二張圖片，它將與第一張圖片位於同一目錄中，但它將被命名為2.jpg 。 用戶的默認圖片總是只有1.jpg ，所以如果他們決定將他們的第二張圖片作為默認圖片，那么2.jpg將被重命名為1.jpg而1.jpg將被重命名為2.jpg 。

最后但並非最不重要的是，如果我需要存儲同一圖像的多個大小，我會按如下方式存儲它們用於用戶ID 1（例如）：

1,024像素：

./images/0/0/1/1024/1.jpg
./images/0/0/1/1024/2.jpg

640像素：

./images/0/0/1/640/1.jpg
./images/0/0/1/640/2.jpg

就是這樣。

那么，這種方法有什么缺陷嗎？ 如果是這樣，你能指出來嗎？

有更好的方法嗎？ 如果是這樣，你能描述一下嗎？

在我開始實現這一點之前，我想確保我擁有最好，最快，最有效的方法來存儲和檢索圖像，這樣我就不必再次更改它了。

謝謝！

Answer 1

不要在意calculting路徑的小速度的差異， 也沒關系 。 重要的是圖像在目錄中的分布有多好和均勻，路徑生成的時間有多短，推斷命名約定有多難（讓我們將1.jpg替換為2.jpg哇，它正在工作......） 。

例如，在哈希解決方案中，路徑完全基於userid，這將把屬於一個用戶的所有圖片放在同一目錄中。

使用整個字母（大寫字母，如果您的FS支持它），而不僅僅是數字。 檢查其他軟件的功能，檢查哈希直接名稱的好地方是google chrome，mozilla，...最好有短目錄名稱。 查找速度更快，占用html文檔的空間更少。