我們在SQL表中有數百萬和數百萬條記錄，並且我們對這些數據運行非常複雜的分析以生成報告。數據緩存技術/提示/ AppFabric
隨着表增長，被添加額外的記錄，計算時間不斷增加，用戶具有網頁加載之前要等待很長的時間。
我們想使用分佈式緩存像AppFabric的加載數據時，內存加載應用程序，然後運行我們關閉內存中的數據報告。由於現在數據在內存和磁盤中，這應該稍微改善響應時間。
在我們拿出plundge並實現它之前，我想檢查並找出別人正在做什麼以及哪些是在內存中加載數據，緩存等最好的技術和實踐。當然，您不只是加載整個表在內存中有數百萬記錄......
我也尋找到OLAP /數據倉庫，這可能給我們帶來更好的性能，而不是緩存。
我們有一個SQL表中的記錄萬元，數以百萬計，
政策利空。平面文件更好。
，我們對這些數據運行非常複雜的分析來生成報告。
在某些情況下，您會更樂意將相關子集加載到SQL中。
隨着表增長，被添加額外的記錄，計算時間增加
這是使用數據庫來實現太多的結果。少用它。
我們想使用分佈式緩存AppFabric中一樣的...
也許。但是，平面文件比RDBMS更快，更具可擴展性。
也尋找到OLAP /數據倉庫
好的計劃。立即購買Kimball的書。你不需要更多的技術。您只需要更好地使用平面文件作爲主要和SQL作爲用戶的即席查詢（針對子集）的位置。
我覺得「糟糕的政策，平面文件更好。」有點徹底的陳述。你能配合嗎？在RDBMS表中看到1億行是很常見的，並且它表現良好：索引，分區和索引視圖可以讓人想起... – 2010-08-10 01:21:01
@Mitch Wheat。平面文件比任何RDBMS更簡單（因此速度更快）。如果數據是簡單的積累和分析，那麼這就是平面文件最適合的。請購買Kimball的書。 DW最簡單的方法是使用平面文件進行批量處理，並使用SQL進行即席查詢。 – 2010-08-10 01:36:01
@ S.Lott：我已經有了Kimball的書。其中有幾個...... – 2010-08-10 01:51:57
解決複雜的報告是預先計算，所以你在正確的道路上，如果你正在尋找OLAP。
您是否考慮過對數據庫進行分區？我們爲我們最大的數據庫做這件事。
說了這麼多，使用的應用程序緩存面料正確，將大大增加對那些IO最重的應用程序的性能。
索引？........ – 2010-08-10 01:06:10
僅索引方法不能解決我們的問題，我們已經爲我們的查詢定義和調整了索引。 – ace 2010-08-15 04:00:01