首先,從早先的答案和交談,我會說,不擔心數十億行,直到你遇到問題爲止。如果你只是在設計一些全新的服務,那麼很可能不用擔心你將如何管理數十億的圖像。試圖處理可提供數十億文件的高可用性,低延遲服務是世界上一些最優秀的工程師可能需要數年才能設計和實施的設計挑戰。
也許把重點放在低幾個數量級來考慮你將如何處理數百萬甚至上千萬的記錄,或者是什麼是你需要在未來一兩年內處理的實際水平的對象。在這種情況下,確實沒有理由,例如,具有設計良好的索引的MySQL安裝無法處理具有數百萬行並具有良好響應時間的表的查詢,特別是如果您瞭解訪問模式並且能夠經常緩存請求文件元數據。
至於關係數據庫是否是存儲文件元數據的最佳方式,實際上取決於您將要存儲的數據的層次結構以及訪問模式將會是什麼(例如,您將如何查看數據)。你給出了一個非常簡單的例子,說明你的文件將如何組織,並建議可能存在一些組織結構,其中每個圖像都以多種分辨率存儲。
是否你的應用程序需要了解所有的分辨率選項的圖像,並決定最好的一個基於某些標準來服務,否則你將永遠知道你會得到完全相同的形象?
在第一種情況下,你可能要爲你的元數據的NoSQL類型的存儲,這樣就可以查找圖像組,並使用應用程序邏輯來選擇從組最佳的圖像文件。在後一種情況下,可能會更好地使用關係數據庫或者甚至像SimpleDB或類似的高度可用的鍵值存儲來獲取文件元數據。此外,關於實際投放了圖像
,你可能要考慮實際使用的Cloudfront以滿足您的S3文件,因爲這會給你一些延遲優勢。
至於你關於S3「文件夾」的問題,是要明白,有沒有真正的S3文件夾中是很重要的。人們通常稱爲他們與類似文件夾的命名方案的文件或許暗示剷鬥內文件的一些層次分組,但實在是沒有物理目錄結構,也不做通常與目錄結構相關的東西(如列表中的所有文件的能力目錄)。所有文件只存在於存儲桶級別。
這裏有一個files
表(如果使用SQL或變體):
file_id folder_id file_path
1 1 http://s3.aws.amazon.com/my-bucket/folder1/img1a.jpg
2 1 http://s3.aws.amazon.com/my-bucket/folder1/img1b.jpg
3 2 http://s3.aws.amazon.com/my-bucket/folder2/img2a.jpg
4 2 http://s3.aws.amazon.com/my-bucket/folder2/img2b.jpg
這裏的file_id將與自動增量場和folder_id主鍵將與指數提供一個簡單的方法來查找所有int列文件在某個文件夾中。
謝謝@Mike,那是一個很好的答案! –
- @邁克,我沒有索引表之前,我的'CREATE INDEX ...'代碼是否正確? –
對於所有這四個記錄,'file_id'都不是'1',然後是'files_id'來給出'autoinc'索引? – jcolebrand