存儲時間序列數據的簡單方法

我每天有大約10億次事件。我需要將這些事件存儲在過去30天的數據庫中，因此大約有300億行。存儲時間序列數據的簡單方法

假設它是運動員數據庫，每排只有4列（運動員名字，運動員紀律，運動員等級，日期）。我只需要通過運動員姓名和日期來檢索數據。例如，爲特定運動員製作過去30天的圖形。

起初我用谷歌大查詢，這是偉大的工具，非常便宜，每天分片開箱和線性可擴展性，但具有一些缺點。查詢30億張桌子大概需要5秒，對我來說太多了。當插入數據時，它會出現在「數據流緩衝區」中，並且無法查詢一段時間（大約5-10分鐘）
另一種方法使用Postgres並將所有數據存儲在具有適當索引的一個表中。此外，我可以使用每日分片（在一天開始時自動創建新表）但我擔心Postgres是否可以處理數十億行。另外，如果我想獲取最近30天的歷史數據，那麼在以這種方式對數據進行分片時，必須進行30次SELECT查詢。

我不想打擾像Cassandra這樣的過於複雜的解決方案（儘管從來沒有嘗試過）。另外我不認爲我會從使用面向列的數據庫中獲得任何好處，因爲我只有4列。

尋找類似於Big Query的東西，但沒有提到缺點。我認爲數據可以存儲在一個節點中。

來源

2017-06-18 user12384512

您不需要30次選擇查詢最近30天。如果查詢總是30天，那麼無論如何您都不需要進行分區。在這種情況下唯一的優點是可以用一個簡單的「drop table」丟棄前一天。我不確定你瞭解Postgresql的分區。 –

最好的解決方案取決於完整的情況和確切的要求。每日分區*可能會有用。 –

@ClodoaldoNeto我的意思是30個選擇查詢，當我沒有分區手動創建表。我需要查詢1到30天的範圍。 – user12384512

只能使用一個節點存儲數據。實際上，每天10億行並不多。它只有大約32K次寫入/秒。爲進行比較，Akumuli可以在具有SSD的m4.xlarge AWS實例上處理大約150萬次插入/秒（幾乎是使用默認設置的EBS卷的一半，但您可以提供更多IOPS）。要存儲30B數據點，您將需要少於200GB的磁盤空間（這取決於您的數據，但假設數據點在磁盤上的佔用少於5個字節是安全的）。

數據模型在你的情況下很簡單。該系列的名稱應該是這樣的：

athlet_rank name=<Name> discipline=<Discipline>

您可以通過名稱來查詢數據：

{ 
    "select": "athlete_rank", 
    "range": { "from": "20170501T000000", 
      "to": "20170530T000000" }, 
    "where": { "name": <Name> } 
}

你不應該選擇Akumuli如果你有大的基數（許多獨特的系列）。它每個系列消耗大約12KB的RAM，例如，要處理100萬系列的數據庫，您將需要一臺至少具有16GB RAM的服務器（實際數量取決於系列大小）。這將最終得到改善，但目前這是我們所得到的。

聲明：我是Akumuli的作者，所以我有點偏見。但我很樂意獲得任何反饋，無論好壞。

來源

2017-06-19 14:31:32 Lazin

存儲時間序列數據的簡單方法

回答

相關問題