2009-04-24 39 views
1

我有一個恆定的數據通量。所有數據都必須用時間戳存儲到數據庫中。這些數據是在一個間隔5分鐘,以及選擇的最新數據是在相同的時間間隔製成,僞SQL代碼:數據庫表複製指導

SELECT * FROM TB_TABLE WHERE TIMESTAMP = MAX(TIMESTAMP) 

由於此表的增長非常大(千兆字節),我做了一個不成熟的優化將其分爲兩個表格:一個用於所有數據(僅用於插入),另一個用於最新數據(用於插入,刪除和選擇)。

我不知道這種重複是否是一件好事,因爲我沒有指標來證明它改善了我的應用程序性能。作爲一般準則,你會推薦我做了什麼?

更新 BTW我使用MS SQL Server 2005和.NET C#的LINQ到SQL

+1

你測量了結果嗎? – 2009-04-24 19:39:55

+0

不,我沒有測量結果 – 2009-04-24 23:40:08

回答

1

我不知道表分區會有幫助。我沒有親身使用它,所以不能從經驗中發言,但這聽起來像是在使用它的適當情況。

2

具有高輸入卷拆分表到寫入優化「近期」表和讀優化的「檔案」表格通常是一個相當不錯的優化。它確實增加了複雜性,所以你不想在不需要它的地方做它,但是如果你確定有問題的表會得到大量的數據,這是合理的。

2

我不會推薦你採取的方法。如果意圖是提高應用程序性能,那麼首先收集性能指標會更合適。如果趨勢表明數據量增長時性能下降,那麼很明顯,某些數據庫更改是適當的。

假設您主要關心的是對大表進行選擇的性能,那麼應用好的索引和將「select *」替換爲僅需要列的步驟可能比跨多個表複製數據更合適。如果您的查詢有大量連接,我可以看到這會對您的表現產生負面影響。在這種情況下,創建一個額外的表來消除查詢中對連接的需求將是一個很好的優化。

1

你沒有提到你正在使用的數據庫,但我可以想到幾個可能的快速優化。我們在談論多少千兆字節?

1)考慮到大量的行,計算max(時間戳)可能是昂貴的。您可能已經知道這個值是什麼,將它存儲在不同的表或配置文件或其他東西中。這可能是你最大的優化。

2)添加另一列來標記最近的更新。當你開始你的更新時SET recent = false WHERE recent = true,用最近的= true寫你所有的記錄。您可能可以通過添加where條件來限制索引的大小 CREATE INDEX foo_index on「TB_TABLE」(recent)WHERE recent = true;

3)確保您的數據庫服務器已正確優化。確保您的鍵和排序緩衝區的大小適合您的數據集。大多數開源數據庫都是針對開發人員的工作站進行預調整的,而不是生產工作負載。

4)重新考慮你的模式。你確定你需要你所有的記錄嗎?你是否記錄了所有的數據,而不僅僅是被更改的數據?在這種情況下,我已經很好地使用了兩個時間戳,最後一次加載的時間戳和最後一次更改的時間戳。

+0

5GB /月。 sql server 2005 – 2009-04-24 23:50:45