儲存時間序列系列的建議
只需幾句話描述數據：在我的應用程序中，有範例性持續時間為一秒的加速度測量值（例如在 25kHz 時）。對於該測量點，這些測量以不必要的間隔時間步長重複。（也許每五或十分鐘一次）。這是一種中斷的永久監控，以某種方式分為兩個週期：
- 短時間測量為 25.000 Hz（測量解析度）
- 每 5 分鐘進行一次長時間的周期性（不是嚴格意義上的，可能會有所不同）
這些點有20個或更多。
在處理時間序列時，第一個想法可能是使用時間序列數據庫。另一方面，對我來說，時間序列 db 的主要目的似乎是儲存標量值。當然，我的測量值是標量值。但是我不確定將每個標量值儲存為 (time/value/measpos_id)-triple 是否是一個好主意——這會導致大量條目。我認為這些條目中的一個永遠不會被評估。
另一個想法可能是將測量向量（從那一秒開始的所有值）與開始時間和 measpos_id 一起儲存。但是怎麼做呢？將所有值視為一個 blob？並非每個系統都能夠處理向量 - 也許它們的長度不同。timeseries-db 中是否有針對此類問題的概念，我不知道？
進一步用於評估（提取），我認為提取完整向量可能是最常用的情況。
如果我的描述不完整或者更多細節可以幫助找到一個好的解決方案，請隨時詢問。
你有什麼建議？NoSQL 還是關係 SQL？進一步的想法？歡迎每一個提示。提前致謝。
補充：
- 卷的粗略想法是每年大約 1 TB 的大小穩步增長
- 提供樣本並不容易 - 我將嘗試描述：
考慮每個測量（每分鐘粗略和每個測量位置）有 25000 個浮點值的 1 列，為這些列中的每一個加上時間戳（在開始時）。
- 用於大數據評估（意味著測試多種算法）；開窗數據、fft（光譜分析）、比較、聚合（如能量總和）、最大幅度值、最大幅度的 pos（頻率）等等
- 評估目的（重點）：磨損檢測，用於例如滾動設備（齒輪、發電機組、渦輪機、軸、軸承）的狀態監測
- 評估將（從今天的角度來看）關注每個單獨的列，並可能與其他列進行比較 - 但不會將列組合（堆疊）在一起。
- 數據大小範例：每 5 分鐘（每小時 12 個）20 個測量引擎的每列中有 25.000 個浮點值，導致每小時 6e6 個浮點數或每年 5.25e10 個浮點數。
我可以建議Akumuli。它是一個支持壓縮和高吞吐量數據攝取的時間序列數據庫。使用 25KHz 測量頻率和 20 個引擎，在最壞的情況下，您需要每秒寫入 500K 數據點。Akumuli 可以處理一個數量級的更大吞吐量（有記錄以來的最大吞吐量約為每秒 1600 萬個數據點）。
此外，由於壓縮，數據庫每個數據點只需要大約 3-9 個字節。每個數據點都是納秒精度 + 64 位浮點值的時間戳。只有當沒有足夠的磁碟空間來儲存新數據時，才會刪除舊數據。
您可以將來自每個引擎的數據儲存在相同的時間序列中，也可以為每個突發創建新的時間序列。
實時序列數據庫可能是一個巨大的勝利，因為您不需要使用所有這些花哨的技巧。原因有缺點。例如，沒有分群和回填。
免責聲明：我是作者，所以我有點偏見。
我相信這對於關係數據庫是可能的，但吞吐量將是一個問題。SQL Server In Memory Optimized Tables 對此非常有用。
儲存數據的最佳形式將在簡單性和儲存效率之間進行權衡。
鑑於數據量巨大，如果觀察是在同一秒進行的。我認為將每個引擎保存在自己的列中是有意義的。對於 1 秒的數據，這將導致 25,000 行而不是 500,000 行。
編輯：但是，由於觀察時間會有所不同，因此將每個系列儲存在自己的行中會更有意義。雖然這會產生大量數據，但將每個觀察值儲存在自己的欄位中將使報告和分析變得更加容易。但從長遠來看，我認為這是不可行的。
下一個挑戰是能夠利用這些數據。實際上，人類無法解釋如此大量的原始數據。所以聚合數據是有意義的，所以對於給定的樣本記錄最大值、最小值、平均值、標準偏差等。