處理大數據
我有一個 MySQL 數據庫，每秒將插入 2000 條新行。這些行表示感測器在該特定時刻的值。
計劃是使用 chart.js 將這些數據轉換為圖形表示。當然，顯示每個數據點是沒有意義的，這將是一個非常慢的查詢。
我的問題是，在這種情況下採取什麼合適的路線？這是我的想法：
假設所需的數據解析度是一天中1 分鐘間隔、15 分鐘間隔、30 分鐘間隔、1 小時間隔和全天的值的執行平均值。
- 創建一個 cron-job 腳本來解析兩個時間段之間可用的值。將上述間隔儲存在與原始值分開的數據庫中的5 個相應表中。
- 當 cron-job 腳本執行其平均工作以確定間隔的值時，從生產數據庫中清除/歸檔原始值。
使用這種方法，事情可以保持整潔，並且可以很容易地以圖形表示形式顯示數據。這是我看到問題的地方：
- 如果我們要過濾圖表以查看上個月的日期值，我們必須檢查 31 個表以顯示要顯示的值。
- 隨著解析度變小和周期變長，問題呈指數級增長。
我可能在兔子洞裡太深了。我會讀你可能有的任何好書。
對您的設置的一些建議
數據庫設置
- 使用臨時（暫存）表來收集新記錄。最好您應該使用插入時間戳
range以您最好的聚合間隔（例如分鐘）對該表進行分區。插入時間戳，與測量的時間戳（稱為感測器時間戳）相反，對於區分很重要 - 請參閱下面的討論。- 使用感測器時間戳作為分區鍵定義具有相同分區模式的詳細表。
- 如果需要，定義**聚合表，**在感測器時間戳上分區。仔細檢查您需要的級別。這不是由請求的報告定義的，但您可以通過性能查詢數據。
例如， 30 分鐘級別似乎有點過頭了，因為您可以從15 分鐘級別有效地查詢它。
加工
每分鐘執行一次的後台作業處理聲明表的一個分區（即一分鐘delta）和
- 在明細表中插入所有行
- 使用從階段表計算的增量更新所有聚合表
你應該在這裡小心。計數、總和和平均值都沒有問題，但是對於
distinct計數，您必須使用HyperLogLog的某些實現，它只會產生估計數據。您還應該檢查您是否必須處理延遲的數據條目，即在您的增量中還有具有較舊感測器時間戳的數據的情況。您必須刷新與這些時間戳相關的所有聚合間隔。
範例：在 10:01 插入的過程數據中，最早的感測器條目是 09:59，因此您必須刷新三分鐘聚合（09:59、10:00 和 10:01）和兩個 15 分鐘聚合（9:45 和10:00）等。
每日收盤
為了解決增量處理可能不准確的問題（請參閱上面的 HyperLogLog，但包括所有其他類型），您可以定期丟棄聚合的最後一部分，並從詳細資訊表中準確地重新計算它們。
這將消除“錯誤累積”的問題——這個概念也被稱為Lambda 架構。
保留歷史
所有表都有一個定義的滾動視窗策略——即數據將保留多長時間。
匯總表由報告要求控制。
詳細資訊表僅在出現問題時用作備份，您有（有限的）恢復聚合數據的可能性。所以只要有經濟意義就設置它。
僅使用刪除舊數據
DROP PARTITION（不使用刪除）。您可以對聲明表應用循環分區，即您只使用時間作為分區鍵，而不是日期部分。這將簡化分區維護 - 您將使用它
TRUNCATE PARTITION來刪除數據。報告
您的聚合將每分鐘完成一次，這意味著最低聚合始終是一致的。相反，最後 15 分鐘的聚合通常是不完整的，僅包含幾分鐘的數據。
您應該設計一些規範化概念來處理這個問題。看到成功事件的數量在最後一刻鐘內顯著下降，這並不好。
祝你好運！