2011-09-07 52 views
1

我必須做一個應用程序,將檢查每秒35項變化。每個項目有3個值,每個項目可放入5個字節,因此每個項目有15個字節。值不會改變每一秒,但沒有一個模式,也許他們連續改變或者拖延一段時間...如何高效地存儲這麼大量的數據?數據庫還是什麼?

所以我做了一個小的計算和我得到的存儲所有領域各第二對關係數據庫(SQL)我將有:

35 * 15個字節* 60秒*的60分鐘* 24小時* 365 = 16.5一年GB。

這對於SQL數據庫來說太多了。你會怎麼做,以減少數據的大小?我在考慮只在存在變化時才存儲數據,但是當變更完成時需要存儲數據,並且如果數據變化太頻繁,這可能需要比其他方法更多的空間。

我不知道除SQL數據庫之外是否還有其他存儲庫更符合我的要求。

您認爲如何?

編輯:更多信息。

除了我爲了節省空間而創建的數據之外,數據之間沒有任何關係。我只需要存儲這些數據並進行查詢。這些數據可以像(把它們都放在一個表,並保存數據每秒):

Timestamp Item1A  Item1B  Item1C  Item2A Item2B .... 

    whatever  1.33  2.33  1.04  12.22  1.22 
    whatever  1.73  2.33  1.04  12.23  1.32 
    whatever  1.23  2.33  1.34  12.22  1.22 
    whatever  1.33  2.31  1.04  12.22  1.21 

我能感覺到那一定是更好的解決方案,而不是這種形式給出...

編輯2:

我通常會查詢有關該產品的隨時間,通常我不會從多個項目中查詢數據的值的數據...

+0

我會補充一點:它不包括記錄和索引的開銷,你可能會想要放一個時間戳! – xanatos

+0

你需要什麼數據?僅用於存儲嗎?你需要做分析嗎?它的「關係」部分在哪裏?它只是一個有一些分區的大桌子嗎? – xanatos

+1

不知道數據是什麼樣的,你會用它做什麼,它不可能正確回答你的問題。 –

回答

2

這是太多的SQL數據庫

從什麼時候開始太多了?
對於幾乎所有的RDBMS(每年大約17GB數據),這確實是花生。

MySQL能做到這一點,這樣可以PostgreSQL的火鳥和其他很多但不是的SQLite喜歡。我會自己選擇PostgreSQL。

有數百個數據TB的SQL數據庫是不是不太常見了,所以17GB沒什麼可想的,真的。 10年(更多的時候是機器)更不用說170GB了。

即使它得到一年的30GB考慮其它的數據和索引,這仍然是一個SQL數據庫確定。

編輯
考慮您的結構,即在我看來固體,你所需要的最小的東西已經存在,並且沒有額外你不需要。
你不可能比這更好,而不會使用比缺點更多缺點的技巧。

+0

那麼,我只使用Microsoft SQL服務器,它只能使用10Gb的最新版本(SQL2008R2)數據庫進行處理。舊版本處理4Gb和2Gb。 –

+1

您使用免費版本的Microsoft SQL Server Express。這是一個很大的區別。只要去找一些免費的東西來完成這項工作。 –

+0

或支付完整的MS SQL :-) – xanatos

0

我目前正在考慮使用壓縮文件而不是SQL數據庫。我會保留與我得到的信息升級後。

相關問題