每年約 2.7B 行/每五分鐘 26.000 個數據點的數據庫設計
目前的情況
我們目前正在研究一種新產品，它將設備數據發回給我們進行解釋。
這些是我們正在查看的數字：
設備很可能每 5 分鐘發送一次數據
到明年年底將有 26.000 台設備
- 每 5 分鐘插入 26.000 個。我們很可能無法控制時間間隔，因此這 26.000 個 INSERTS 很可能不會均勻分佈在這 5 分鐘內。
- ~ 每年 2.733.120.000 個數據條目
每個數據包都將採用 JSON 格式，大小在 300 - 500 字節之間。
我們預計每年約有 8.000 台新設備。
我們目前為我們的內部系統管理多個數據庫，但對這樣的捲幾乎沒有經驗。我們現在使用 AWS Aurora，理論上應該支持 100.000 INSERTS p/s。
這些數據將如何使用？
這些數據將主要用於在我們的客戶門戶中創建報告：
設備指標的實時報告
歷史報告，即：
- 2019 年 2 月 2 日的設備統計資訊如何？
- 第 12 周是什麼樣的？
- 給我一個1月份指標的摘要
- 顯示特定列總和的圖表，按月分組
問題
老實說，考慮到我對這樣的數據量沒有任何實踐經驗，我發現很難做出可靠的選擇。
我們目前的堆棧
我們結合使用 AWS EC2 機器和 AWS Aurora 集群來管理我們的數據。理想的解決方案是面向 AWS 的。
我正在考慮的基礎設施：
選項 #1：為了簡單起見，將所有內容直接儲存到 Aurora 中可能是一個很好的解決方案。
選項#2：但是，為了分離我們的“實時”數據和解釋數據，也許這樣的東西更好。
實際問題
- 像 Aurora 這樣的兼容 MySQL 的數據庫管理系統是否適合這樣的事情？
- 傳入的數據將用於生成“實時”的每日、每週、每月和每年的報告，按設備匯總。是否建議為這些不同的“觀點”創建單獨的表以使查詢數據更容易，或者我是否過於復雜化了，我應該將測量結果儲存到一個表中？
- 我們應該研究表分區嗎？
- 還有什麼我沒有提到但我們應該調查的嗎？
如果所有這些都太模糊，請告訴我，以便我澄清問題。
很想听聽你的想法。
我在一家物聯網公司工作，最近使用 Kinesis 流、Spot 實例和 DynamoDB 實現了類似的東西（設備感測器數據讀數）。
Spot 實例是替換 Lambda 的一個節省成本的步驟，Lambda 正在處理流數據並批量插入到 DynamoDB，它們的成本太高了。我們將 Lambdas 更改為 EC2s，然後更改為 Spots 以節省現金。
我建議嘗試使用 Lambdas 從 SQS 獲取數據並將其放入數據庫中，但為了規模和成本，請查看 DynamoDB 進行儲存。DynamoDB 的缺點是您必須在建構表之前知道查詢路徑，但是當您使用 API 時，您可能會知道它們是什麼。
部分答案最初作為評論留下：
mustaccio : 無論你今天做出什麼選擇，都要做好遲早要重新考慮的準備。無論如何，不要讓您的設備或他們呼叫的 API 直接插入數據庫；在兩者之間放置一個消息隊列。通過這種方式，您可以更好地管理流程並獨立更換零件。
mark-s：我建議也看看非 RDBMS 解決方案。我們將Druid用於類似的項目。您可以使用 S3 作為儲存後端，使用者可以使用 SQL 訪問數據。
raphael75：我在一個網站上工作了很多年，每天添加幾 MB 的數據，雖然它比您處理的要小得多，但我們添加的排隊對於使其順利執行至關重要。我們還將 AWS 與 Aurora 結合使用。由於您不需要最新的報告（根據您的範例），我認為您現在應該可以正常工作。該影片詳細介紹了分區。這對您的項目可能是個好主意。