使用blob與否，性能問題

Question

首先，我不是數據庫專家，而是承包商。我聘請了一位（優秀）程序員，但由於我們遇到的一些問題以及我正在閱讀的所有信息，現在對數據庫設計的某個部分有些懷疑。開始吧。

我們建立了一個房屋網站，它使用解析器來處理所有數據並將其存儲在ms-sql數據庫中。每天飼料中都包含大約70,000條記錄，其中大部分都附有照片（平均3張）。圖片大小從30kb到400kb不等。 該數據庫具有大約相同數量的記錄。大約有400個新對象需要處理。這意味着每天都必須輸入數據庫中的所有記錄，以查看數據是否已更改，對象是否已被刪除，或者是否爲新對象，因此必須插入。 圖片存儲在數據庫中。這些訂閱源在具有32GB內存和SSA磁盤的雙核四核機器上進行處理。該數據庫現在大小爲600GB。

目前，我們每天約有3000位用戶查看6個房屋，平均每個用戶查看10個圖像。

這就是我們所遇到的： - 整個解析過程大約需要13個小時。 - 我們在日誌中發現了很多超時錯誤 - 我們得到了一些死鎖錯誤 - Google抱怨超時錯誤，結果索引的頁面不多。 - 由於某些目錄的加載時間超過10秒，Google對該網站的評分較慢。

我個人認爲它與數據庫中的圖片和一些不好的查詢有關。但在我開始向我的程序員抱怨之前，我想聽聽你對此的看法。 預先感謝您的時間。

來自我的程序員的更新： 以下是關於表格結構的一些信息。有2個圖像表，一個叫做imageinfo，用於在圖像上進行查詢（例如獲取imageid和content-type的列表）以及一個包含圖像id和BLOB的圖像表。 imageinfo表具有與圖像表（1：1關係）相同的id，並且具有一些額外的信息，例如圖像的名稱，類型和散列。該分析程序使用該散列來確定圖像是否已更改。因此，觸摸圖像表的唯一時間是從解析器插入/更新/刪除並且站點訪問圖像的時間。 訪問和下載一個圖像所需的時間約爲350毫秒。

Answer 1

您告訴我們兩個問題：

1. 導入緩慢
2. 瀏覽該網站是緩慢

（2）很簡單：你可能需要了解您的讀取查詢和索引他們。這絕對是可以解決的。

（1）如果沒有更具體的說明，就更難說了。我知道你需要比較大量的斑點 - 除了實際數據之外，您可以存儲這些博客的精簡散列。這樣您就不需要爲了比較目的而檢索blob，甚至可以對散列進行索引。

你應該在數據庫中有圖像嗎？

最大的優點是：一致和簡單的備份，開發人員的方便。最大的con是潛在的濫用。一般來說，你不能說圖像屬於文件系統。數據庫通常對他們來說很好，除非有具體和具體的原因將它們放在別的地方。

我的猜測是您誤用這些博客的用法，如果這些文件存儲在文件系統中，您也會遇到同樣的問題。

Answer 2

你真的需要衡量性能傷害你的位置。不知道什麼是緩慢的，你不能希望開始修復它。

但是，如果您正在尋找關於從何處開始測量的想法，那麼我會說看看導入過程，並且看看它在RBAR樣式中做了什麼。 RBAR代表'Row By Agonizing Row'，它恰當地描述了一次操作單行的過程，當時它們將更有效率地工作。

我會檢查的另一件事是，你實際上沒有檢查每個圖像的內容，以確保它沒有改變。如果你正在對這些數據進行二進制比較，我可以想象它會非常緩慢。如果計算校驗和並比較校驗和，則

a）您可以計算SQL Server進程之外的校驗和，最好是在另一個盒子上。
b）您將能夠以更精益的過程檢查更新的圖像，特別是如果該校驗和是合適索引上的INCLUDE列。

但是，正如所評論的那樣，將圖像存儲在數據庫中並不是最聰明的想法。