在SQL中存儲/更新基於時間間隔的數據的最有效方法是什麼？

我有一個數據庫表，大約有700萬行加上（按指數規律增長）基於時間的數據。在SQL中存儲/更新基於時間間隔的數據的最有效方法是什麼？

字段：

PK.ID, 
PK.TimeStamp, 
Value

我也有其他的3個表分組該數據到天，月，年，其包含用於在該時間段的每個ID的值的總和。這些表每晚由一個SQL作業更新，出現這種情況的原因是，當基表中的數據更新時，這些表需要隨時進行更新，然而，一次最多可以有250萬行（不是很通常情況下，通常在200-500k之間，最多每5分鐘一次），這是可能的，而不會導致大規模的性能命中，或者實現這一目標的最佳方法是什麼？

每日，每月，每年的表是可以改變的，如果需要，他們被用來加快查詢，如「獲取這5個IDS每月總計過去5在原始數據中，這是大約1300萬行數據，從每月的300行。
我確實有SSIS提供給我。
我不能在這個過程中鎖定任何表。

來源

2011-04-14 Euclid

當你說你的700M行正在呈指數級增長時，你的意思是你期望這張表增長到數十億行嗎？這改變了你需要的答案種類 - 如果規模穩定，那麼你需要優化當前的情況，它快速增長，然後你需要其他的東西。 – Elad 2011-04-14 14:57:57

我的確希望它能夠保持平穩，因爲大於5年的數據將被刪除，但這種情況不會發生一段時間（5個月），但到那時可能會被制動到數十億。 – Euclid 2011-04-15 09:57:19

5個月內700M記錄者平均5年內8.4B（假設數據流入量不增長）。歡迎來到大數據的世界。這是令人興奮的，我們歡迎越來越多的新居民每天:)

我會介紹三個增量步驟，你可以採取。前兩個只是暫時的 - 在某些時候，你會有太多的數據，將不得不繼續前進。但是，每個人都需要更多的工作和/或更多的錢，因此一次只能採取一步就有意義。

步驟1：更好的硬件 - 規模達

更快的磁盤，RAID，以及更多的RAM將帶你一些方法。正如所謂的擴大規模最終會崩潰，但如果數據呈線性增長而不是指數增長，那麼它會讓你浮動一段時間。

您還可以使用SQL Server複製在另一臺服務器上創建數據庫的副本。複製通過讀取事務日誌並將其發送到副本來實現。然後，您可以運行在輔助服務器上創建您的聚合（每日，每月，每年）表的腳本，這些腳本不會影響主表的性能。

第2步：OLAP

由於您在您的處置有SSIS，開始討論多維數據。通過良好的設計，OLAP Cubes將帶給你很大的幫助。他們甚至可能足以管理數十億條記錄，並且您可以在那裏停留數年（在那裏完成了這項工作，並將它運送了兩年左右）。

步驟3：向外擴展

由分佈在多臺計算機中的數據和其處理處理更多的數據。正確完成後，您可以幾乎線性縮放 - 獲取更多數據，然後添加更多機器以保持處理時間不變。

如果您有$$$，請使用Vertica或Greenplum的解決方案（可能有其他選項，這些是我熟悉的）。

如果您更喜歡開源/ byo，請使用Hadoop，將事件數據記錄到文件，使用MapReduce處理它們，將結果存儲到HBase或Hypertable。這裏有許多不同的配置和解決方案 - 整個領域還處於初級階段。

來源

2011-04-15 11:51:23 Elad

爲什麼不創建月度表格，只是爲了保存您在那個月需要的信息。這就像模擬多維表格一樣。或者，如果您有權訪問多維繫統（oracle，db2等），只需使用多維度即可。對於像你這樣的時間問題，這很好。目前我沒有足夠的信息給你，但你可以通過Google搜索學到很多東西。

就像一個想法。

來源

2011-04-14 11:26:01 elvenbyte

Indexed views.

索引視圖將允許你存儲和索引彙總數據。他們最有用的方面之一是，你甚至不需要直接引用任何查詢中的視圖。如果有人查詢視圖中的聚合，查詢引擎將從視圖中提取數據，而不是檢查基礎表。

您將花費一些開銷來更新數據更改視圖，但從您的情況下，這聽起來像是可以接受的。

來源

2011-04-14 12:54:27 JNK

在SQL中存儲/更新基於時間間隔的數據的最有效方法是什麼？

回答

相關問題