什麼是存儲趨勢數據的最佳方式？

Question

我目前正在構建一個應用程序，我正在爲大約15,000種產品導入（當前）統計數據。在目前，如果我要爲每天統計數據庫維護一個數據庫表，則每天將增加15,000行數據（假設每行5-10個字段主要爲float，int）。顯然，每年將超過500萬條記錄等同於一張表。

這並不關心我如何從其他來源引入數據（並因此增加了每個新來源的500萬條記錄的數據庫大小）。

現在數據是基於統計/趨勢的數據，並且每條記錄每天基本上有1次寫入，並且有很多讀取。爲了實時報告和繪圖，我需要快速訪問基於規則（日期範圍，值範圍等）的數據子集。

我的問題是，這是存儲數據的最佳方式（MySQL InnoDb表），還是有更好的方式來存儲和處理統計/趨勢數據？

其他選項我在這裏已經討論過： 1.多個數據庫（每個產品一個），每個數據源都有單獨的表。 （即Database：ProductA，Table（s）：Source_A，Source_B，Source_C） 2.一個數據庫，多個表格（每個產品/數據源一個） （即數據庫：產品，表格：ProductA_SourceA，ProductA_SourceB等） 3.所有factual或數據庫中的特定產品信息以及所有statistical數據在csv，xml，json，（平面文件）中的不同目錄中。

到目前爲止，這些選項都非常易於管理，每種選項都有其優點和缺點。在進入alpha開發階段之前，我需要一個合理的解決方案。

Answer 1

您可以嘗試使用基於列的數據庫。這些類型的數據庫在您描述的分析查詢方面要好得多。有幾個選項：

http://en.wikipedia.org/wiki/Column-oriented_DBMS

我們已經有很好的經驗，InfiniDB：

http://infinidb.org/

和Infobright的看起來不錯，以及：

http://www.infobright.com/

兩個InfiniDB Infobright擁有免費的開源社區版本，所以我必須遵守d建議使用這些來獲得您可能獲得的各種性能優勢的一些基準。

您可能還想看看對數據進行分區以提高性能。

Answer 2

這有點依賴於你的數據看起來像什麼樣的聚合/趨勢你想運行。大多數關係數據庫對這種按時間順序排列的數據工作得很好。即使擁有數十億條記錄，適當的索引和分區也可以快速查找所需記錄。像Oracle，MySQL，SQL-Server這樣的DB就屬於這個類別。

可以說你使用的產品是股票，每一個股票你每天都會得到一個新的價格（一個非常現實的案例）。新的交易所，股票，交易頻率將以極快的速度呈指數增長。但是，您可以通過交換來分割數據。或地區。

各種商業智能工具還能夠幫助，有效地達到預先彙總數據之前的檢索。這基本上是一個按照建議的面向列的數據庫。 （數據倉庫和OLAP結構可以提前協助按摩和彙總數據集）。

到數據倉庫的想法類似，如果它只是一個時間太長了聚合的事情，你可以工作過的聚合一夜之間變成這樣更快速地從查詢的結構。在我之前的例子中，您可能只需要很少檢索大塊數據，但更常見的是某些聚合，例如52周高。您可以將大量的原始數據存儲在一種格式中，然後每天晚上只有您需要的工作才能進入表格，而不是每個庫存的數千個數據點，現在有3或4個。

如果您所追蹤的趨勢確實遍佈全球或複雜的算法，完整的BI解決方案可能需要進行調查，以便您可以使用預先構建的analityic和數據挖掘算法。

如果數據結構不是很好，那麼對於像Hadoop或Mongo這樣的NoSQL數據庫來說，你可能會有更好的運氣，儘管我承認我的數據庫知識更關注於關係格式。