我有一個軟件根據某些文件進行繁重的處理。 我不得不在SQL Server中查詢一些表的過程，這就是查殺數據庫和應用程序的性能。 （其他應用程序使用相同的表格）。減少SQL Server開銷緩存查詢結果
優化查詢和代碼後，獲得更好的結果，但不夠。經過研究，我達成了解決方案：緩存一些查詢結果。我的想法是緩存正在處理的文件所需的一個特定表（標識爲開銷）行。我認爲在使用AppCache Fabric（我在MS堆棧中）時，做了一些測試，發現它對於小對象（appcache服務具有〜350MB的ram用法，沒有對象）有很大的內存使用量。但我需要在這些結果表中的某些查詢（如搜索姓氏，SSN，生日等）
我的第二個選擇是MongoDB中的緩存存儲。我對此進行了研究，大多數人閱讀推薦使用memcached或Redis，但我使用的是Windows服務器，並且它們不受官方支持。
在這種情況下使用mongo作爲緩存存儲這是一個好方法？或者AppFabric Caching +標籤搜索更好？
很難說什麼更好，因爲我們對瓶頸不夠了解。很大程度上取決於您正在討論的數據的質量。如果數據是非常靜態的，並且不會經常調用，但編譯數據集非常耗時，那麼最好的解決方案可能是使用物化視圖。如果經常調用此數據，則比您更好地將其緩存在某個服務器上（例如應用結構）。 有許多技術和可能性。但是你真的需要考慮網絡流量，需求，規模等等。在不知道所有細節的情況下，很難回答這個問題。 看起來你是正確的，但可能你需要的只是一個參數化查詢。很難說。但是我會將Materialized視圖添加到剛剛發佈的名單中。可能您需要的僅僅是從您需要的所有數據構建此視圖並訪問其內容。
我給你的問題是你的應用程序的長期目標或估計是什麼？如果這是您要花費的最高負載，那麼調整數據庫或使用MVL將是一個答案。但長期解決這個問題的方法是分佈式緩存，並且您已經在考慮這些方面。您的數據需求就是我們所稱的「參考數據」或「查找數據」，一旦您使用有限的數據庫資源進行多次查詢，就會出現性能問題，您的數據庫將成爲性能瓶頸。
因此，您已經想到的解決方案是將此「參考」數據緩存到緩存中，而無需轉到數據庫，同時保持緩存與數據庫同步。
Appfabric我不會太確定，因爲它會有你提到的相同的支持問題。你的預算是什麼樣的？你可以考慮花費在諸如NCache?
等cachisng解決方案上的數據不會經常更改。真正的問題是我需要根據文件行查詢SQLServer的時間量+我所做的查詢類型（我的搜索主要在varchar列中）。此查詢阻止其他應用程序，並且花費太長的時間來處理文件。今天，我在1.07小時內處理了一批（每個文件大約1MB）260MB，在不久的將來，我將處理GB文件，並且處理時間不會超過一天。 – Zingui 2013-04-28 20:52:57
如果數據非常靜態，並且只關注構建結果集需要很長時間，則可以創建「實體化視圖」（Sql Server中的「索引視圖」）。看到這裏：http：// msdn。microsoft.com/en-us/library/dd171921%28SQL.100%29.aspx 您可能需要創建其他表格等來創建搜索功能。然後，一些進程將填充所有這些。然後您的數據將在Sql Server上高度可用。如果這不符合您的條件，您可以隨時使用您選擇的緩存機制的服務器內存。 – 2013-04-29 16:45:42
索引視圖現在可以工作並且可以節省一段時間的成本，但是將來我必須使用緩存（在專用服務器中）來減少這種開銷。謝謝@ T.S。 – Zingui 2013-05-02 14:34:46