時間序列數據的數據存儲

我有一些科學測量數據應該永久存儲在某種數據存儲中。時間序列數據的數據存儲

我正在尋找一種方法來存儲來自100 000個傳感器的測量數據，其中多年累積的測量數據達到每個傳感器約1 000 000個測量值。每個傳感器每分鐘或少一次產生一次讀數。因此數據流量不是很大（整個系統每秒鐘大約200次測量）。傳感器不同步。

數據本身以三元組形式出現：[timestamp] [sensor＃] [value]，其中所有內容均可表示爲32位值。

以最簡單的形式，此流將按原樣存儲到單個三列表中。那麼查詢將是：

SELECT timestamp,value 
    FROM Data 
    WHERE sensor=12345 AND timestamp BETWEEN '2013-04-15' AND '2013-05-12' 
    ORDER BY timestamp

不幸的是，與列式數據庫管理系統，這將提供一個非常差的性能，數據質量大，而我們想要的數據分散幾乎各佔了進去。（試圖從數十億條記錄中挑選幾十萬條記錄）。我需要的性能方面是人類消費的合理響應時間（數據將以用戶爲單位），即幾秒鐘的數據傳輸。

另一種方法是將來自一個傳感器的數據存儲到一個表中。然後查詢將變成：

SELECT timestamp,value 
    FROM Data12345 
    WHERE timestamp BETWEEN '2013-04-15' AND '2013-05-12' 
    ORDER BY timestamp

這將提供一個良好的讀取性能，因爲其結果將是多個連續的行從一個相對較小（通常少於一百萬行）表。

但是，RDBMS應該有幾十萬分鐘內使用的100 000個表。這對於通用系統來說似乎不可能。另一方面，RDBMS似乎不是正確的工具，因爲數據中沒有關係。

我已經能夠證明，一臺服務器可以通過以下米老鼠系統與負載應對：

每個傳感器都有在文件系統中它自己的文件。
當一段數據到達時，其文件被打開，數據被追加，文件關閉。
查詢打開相應的文件，查找數據的起點和終點，並讀取它們之間的所有內容。

很少幾行代碼。性能取決於系統（存儲類型，文件系統，操作系統），但似乎沒有任何大的障礙。但是，如果我順着這條道路走下去，我最終會編寫自己的代碼進行分區，備份，將舊數據更深地移入存儲（雲）中，等等。這聽起來像是在滾動我自己的DBMS，聽起來像重新發明輪子（再次）。

有沒有存儲我擁有的數據類型的標準方式？一些聰明的NoSQL技巧？

來源

2014-06-12 DrV

是的，這不是一個真正的問題，但它很有趣。查看http://stackexchange.com/sites上的所有其他網站，例如「程序員」或「計算機科學」。我會說你想要的是非常高的性能。你可以使用像SQL Server或Oracle這樣的「vanilla」系統。但是你的速度目標很難。在3秒內排出10億個==大規模處理能力和花哨的硬件和邏輯並行性。雲系統在電線上的速度也會太慢。如果你可以放棄一些速度，那麼就像你已經知道的那樣，簡單的數據結構可以幫助你並不困難。 –

我試圖解釋這個問題來更清楚地描述問題。輸出帶寬不是問題，因爲我只需要一次從一個傳感器獲得適量的數據。典型的查詢會返回20 000個數據點。不需要花哨的硬件 - 至少初步的基準測試表明，這可以通過一臺服務器完成。 – DrV

不錯。在這種情況下，你的實現可能比哪個系統更重要。數據架構總是關鍵:)。玩的開心！ –

真的好像很容易的問題。 100億條記錄，每條記錄12個字節 - > 1.2TB，這對於現代硬盤來說並不是一個大容量。在LMDB中，我會考慮爲每個傳感器使用一個子DB。然後，您的密鑰/值僅爲32位時間戳/ 32位傳感器讀數，並且您的所有數據檢索將是密鑰的簡單範圍掃描。您可以使用LMDB輕鬆檢索每秒50M記錄的數量。（看到SkyDB傢伙只是這樣做的https://groups.google.com/forum/#!msg/skydb/CMKQSLf2WAw/zBO1X35alxcJ）

來源

2014-06-15 12:21:00 hyc

感謝您的專家意見！我喜歡LMDB的工作方式，我一直在考慮在這個應用中使用它，但我沒有想到使用子DB。我確實承認我對他們的無知，並且不得不問，在使用500個數據庫（每個200個子數據庫還是1個數據庫和100 000個子數據庫）方面是否有所不同？（5000萬條記錄/秒確實令人印象深刻，但不幸的是我的數據將在磁盤上，所以我擔心的是讀取或寫入的隨機頁面數。） – DrV

LMDB是一個單寫入器設計，所以你會考慮分成500個數據庫以支持500個併發作者。除此之外，還有一個問題需要同時打開多少個子DB - 初始的mdb_dbi_open（）實際上是在打開的DBI表中進行線性搜索，所以它可能會很慢，達到100,000。（但這也可能沒有關係，因爲開放只需要每次運行一次。）除了沒有真正的性能差異。 – hyc

InfluxDB是一個時間序列數據庫，可以使用LMDB http://influxdb.com/blog/2014/06/20/leveldb_vs_rocksdb_vs_hyperleveldb_vs_lmdb_performance.html 使用LMDB的Sorted Duplicates功能也可以節省一些空間和時間，請參閱我的評論他們的帖子。 – hyc

時間序列數據的數據存儲

回答

相關問題