我們有一個應用程序（規則引擎），它在內存中有很多表來執行特定的業務規則。此引擎還用於在需要時寫回數據庫。內存數據高速緩存在.Net應用程序中的性能
數據庫結構是非規範化的，我們有5個事務表，有時還需要查詢報表。
這裏的問題是，我們想要緩存應用程序中的數據，所以它在App啓動時加載，然後只在DB更改時纔會更改。
有什麼建議嗎？
我們傾向於創建一個數據庫服務，它將處理所有插入，更新和刪除操作，並將它們排隊以減少數據庫服務器上的負載（事務表也具有負載索引）。此外，我們正在考慮將數據庫服務放在最前面，並提供所有需要直接訪問數據庫的報告/其他應用程序。
這裏的目的是減少每個請求的Select查詢的DB命中數，並優先處理事務。此外，爲了確保訪問應用的用戶不會關閉數據庫服務器。
規則引擎是一個C＃桌面應用程序，報告和其他應用程序是基於Web的。
什麼是最好的方式去做這件事？我也想過從我的事務表中刪除所有索引，並將觸發器插入到一個新的表中，該表是一個副本，但是索引用於報告檢索。
我已經做了類似於一個猥瑣的複雜規則引擎。最終，我設置它以便數據集中式序列化（通過一個進程來釋放新的更改，導致新副本被序列化並且blob存儲在某處可訪問）。在加載期間，每個應用程序服務器將檢查它們是否具有最新版本的blob，並且如果不獲取它（並且將其存儲在本地）。
然後它所要做的就是將數據反序列化到內存中。沒有數據庫命中，除了偶爾抓住新的blob。這也意味着應用程序服務器可以在數據庫服務器處於脫機狀態時工作（只要它具有該數據塊的緩存副本）。當然，它也會在運行時定期輪詢新的更新 - 但僅限於「是否有新的blob」代碼（它仍然不需要打到主表）。
這也是一種可能性，也可以通過在表格更改上寫入時間戳文件以及可能的其他方式，但是整個想法是不要投票。 一種方法可能是，用時間戳寫入文件的觸發器僅在文件上的時間戳更改時加載數據。因此，對於由規則引擎引用的每個表，我只是創建一個0B文件，並檢查代碼中的文件名以加載更改，儘管這仍然不是非常優雅。 我希望SQL服務器或.net有一些方法讓我知道表值已更改。緩存真的不是問題。 – 2010-08-26 06:39:45
您可能會感興趣this article它使用xml來存儲數據庫的只讀副本（在內存中）。和XPath進行查詢。當然，你現在更喜歡用linq查詢。
謝謝 - 但這仍然不能幫助我確定如何更改表格值更改時應用程序中的數據集（緩存）。緩存數據並不是真正的問題，問題是確保最少的選擇查詢，但確保數據始終是最新的。 – 2010-08-26 06:47:33
你試圖解決什麼問題？目前的性能痛點是什麼？ – 2010-08-26 06:19:24
繪製點爲： 1.表鎖定問題與太多的寫/讀來自同一個表。 2.數據檢索在檢查每個業務事務的規則時很慢，規則基於DB中的其他表，因此對於每個業務事務，這可能意味着對5個不同表的5個不同選擇查詢。爲相同的表查詢SQL服務器只是我想避免的一個成本。 3。上面＃2中提到的數據可能會改變，並且輪詢/數據緩存過期似乎並不「優雅」 – 2010-08-26 06:37:12