數據庫與文件系統中的圖像

Question

我們正在開展一個項目，我們將構建一個完整的后端CMS系統，該系統將通過一個軟件包為整個外聯網和內部網提供支持。 我一直試圖找到答案的問題是哪個更好：在數據庫中存儲圖像（SQL Server 2005），以便我們可以擁有完整性，單一復制計划等或存儲在文件系統上？

我們遇到的一個問題是我們有多個服務器負載均衡，需要始終擁有相同的數據。 截至目前，我們有SQL復制處理，但文件復制似乎有點困難。 我們的另一個問題是我們希望擁有相同圖像的多個分辨率，我們不確定在文件系統上創建和存儲每個版本是最好還是可以動態地拉動並創建我們想要的分辨率圖像。

我們關注的是以下內容：

• 數據的完整性
• 數據復制
• 多種分辨率
• 數據庫與文件系統的速度
• 數據庫與文件系統的負載
• 數據管理和備份

有沒有人有類似的情況或對推薦的內容有任何意見？ 在此先感謝您的幫助！

Answer 1

微軟研究院發布了一篇很好的研究論文，名為To Blob，或者不是Blob ，他們研究了各種變量和影響。

他們最終的發現：

• 大小高達256 KB，blob比文件系統更有效地存儲在數據庫中
• 對於1 MB或更大，文件系統更有效
• 在它之間是一個折騰

自該論文發布以來，SQL Server 2008還添加了FILESTREAM屬性，該屬性使得在文件系統中存儲東西，但在事務控制下，這是一個現實。 強烈建議你檢查一下！

Answer 2

這個問題經常出現 - 請參閱此 SO搜索結果。

沒有一個正確的答案 - 這取決於具體情況。

個人 - 保留數據庫中的文件路徑和文件系統上的文件。 每個人都有自己的優勢。 您可以備份文件和數據庫。 這也是這個管理數據TB的人的結論。

Answer 3

靜態文件的復制可能難以管理，特別是在許多服務器上。 它實際上歸結為管理，監視和調試復制問題與數據庫大小和負載之間的權衡。

我想我可能會選擇數據庫方法，如果加載成為問題，請考慮在圖像調用周圍設置某種緩存層。

在數據庫中存儲路徑的建議缺少真正的問題，即在多台計算機上復制此問題。

Answer 4

你的擔憂分為兩個陣營。 以下問題有利於在數據庫中存儲文檔：

• 數據的完整性
• 數據復制
• 多種分辨率
• 數據管理和備份

這些擔憂（可能）有利於在文件系統上存儲文檔：

• 數據庫與文件系統的速度
• 數據庫與文件系統的負載

因此，決定最重要的事情並相應地做出選擇。

Answer 5

好吧，如果您的前兩個需求是完整性和復制，那么答案肯定是DB。

你還有其他要點：

• 完整性 - 數據庫，這就是數據庫存在與平面文件系統的原因。

• 復制 - 不確定您是否意味着圖像復制，但如果是這樣，那么顯然是DB，因為您肯定不會對此進行負載平衡。

• 可以從DB映像執行多個分辨率，但是這增加了處理成本。 此外，分辨率越高，大小越大，網絡等待的時間越長。 多種分辨率以空間換取速度。

• 速度 - 根據對圖像的訪問，它可以忽略不計。 如果您在文件共享中拍攝圖像，則無論如何都必須在網絡上等待，並且網絡幾乎總是瓶頸。

• 開銷 - 坦率地說，這取決於您對開銷的定義以及您如何訪問圖像。

• 管理，DB，放下手。 奇異存儲=不用擔心，在任何情況下都應始終在數據庫上運行備份。 多個服務器上的文件系統備份在很多方面都很昂貴。

Answer 6

辯論的任何一方都有有效的擔憂，所以總是提出你的要求。 有多少數據，有多少圖像，有多大？

內聯/ BLOB存儲

優點 ：簡化架構和實施，簡化系統的備份和恢復或遷移; 只需執行轉儲，備份，導出（無論您的DB風格如何），並將其移動到新數據庫。 版本控制/一致性由DB處理，因此允許進行時間點恢復。 安全/訪問控制也更清晰，因為訪問圖像BLOB是訪問整個行所固有的。 將圖像移出數據庫並讓HTTP服務器獲取它，同時更好地實現並發性和可伸縮性，可能會遇到問題，確保人們無法破解URL並請求他們不擁有的圖像。 如果您將它們放在數據庫之外，請確保您的安全策略涵蓋用戶之間圖像的訪問控制。 您的HTTP服務器身份驗證必須與整個系統的身份驗證集成，或者提供映像的HTTP服務器程序使用某種會話機制來確保HTTP請求有效。 這是多租戶數據庫中非常重要的問題。 單一用途，單租戶系統中的問題較少，具有簡單的身份驗證。

缺點 ：對於真正非常大的數據庫，備份和恢復變得令人沮喪，甚至成問題和代價高昂，因為如果你可能有一個小的核心數據集，你可能有很多GB或TB的圖像數據。 從完整性的角度來看，將它作為一個一致的數據庫處理是好的，但是對於備份是不好的，除非您使用具有企業質量的DBMS，數據倉庫調整的備份和恢復（例如Oracle RMAN和滾動備份）。

始終考慮在任何系統中恢復的時間。 如果您的存儲要求<幾千兆字節，甚至50-100GB，並且您有足夠的備份空間，則內聯存儲更加清晰。 除此之外，關注點的分離和讓文件系統完成其工作成為關鍵優勢。 沒有什么比嘗試恢復，恢復和打開一個巨大的數據庫更糟糕的是為了小數據錯誤。 恢復時間將是我最關心的問題。

Answer 7

通常，就CMS而言，DB中的持久圖像數據可能不如FileSystem有效。 有時您可能只想靜態顯示圖像，有時您希望圖像設計師可以使用該圖像進行更新等。

考慮每次要使用它時檢索圖像所涉及的處理開銷。

有幾點你應該考慮FileSystem

1. 瀏覽器完成所有工作，您可以從圖像的代理緩存等中受益
2. 作為上述的分支，您可以輕松使用內容交付網絡（CDN）
3. 使用rsync等工具可以輕松復制圖像數據
4. 處理（即CPU）時間得到了極大的優化

Answer 8

假設您處於Windows環境中，則沒有充分的理由使用該文件系統。 您可能需要小心如何將圖像存儲在表中以避免不必要的頁面拆分，但這是性能調整，而不是一個大問題。

缺少文件系統

- 不會自動復制

- 通過為每個實例提供不同的物理位置，可能會使復制變得復雜

- 減少大量文件

文件系統的優勢

- 如果你要存儲一些非常大的文件，它會表現得更好一些。

Answer 9

我會;

1）為每個圖像分配唯一標識符（GUID）2）使用該GUID標記/命名圖像3）在OS（文件系統）中存儲GUID 4）在數據庫中存儲完全限定文件名（FQN）指針。

在存儲和維護方面，將數據存儲在數據庫中太昂貴了。 僅存儲FQN指針將提供更好的解決方案。 您還可以通過觸發器和一些存儲過程構建后端完整性檢查。

Answer 10

我不會出於某種原因將數據存儲在數據庫中（我的答案來自sql server）：

我不希望SQL Server數據緩存由網站的簡單圖像填充。 我希望數據緩存實際上有數據。 此外，如果你有一個多層架構，它傳遞一個圖像的URL要比一團二進制數據更容易。 如果您只想讓某些人看到圖像（安全性），那么您遇到問題的地方。