在 MariaDB / MySQL 中儲存實時時間序列的最佳解決方案是什麼？
案例：測量創建給定數量的圖像。對於每個圖像，我們需要儲存一小組質量指標（浮點數、雙精度數）以及圖像整數
$$ 1 …N $$，一個時間戳和一個或兩個外鍵值。然後應該在 Web 應用程序 (PHP) 中“實時”繪製，供使用者評估。 每個 Web 客戶端每 5 秒輪詢一次數據庫。理想情況下，每組質量指標的儲存 + 檢索時間應小於 2 秒（大約）。在最壞的情況下，可能有大約 30 個同時 Web 客戶端輪詢，並且可能同時寫入大約 10 個測量值，導致大約 10 個寫入突發。每秒1000組質量指標。
在程式語言中，這種數據可能儲存在數組或列表中。由於我不知道 MariaDB / MySQL 世界中有任何類似的東西，我只是使用一個正常的 InnoDB 表，上面提到的每個值都有一個列。這已經有 90+ 百萬行，預計在未來幾個月內增長更快。
InnoDB 總體上是最好的儲存引擎，還是我應該考慮其他？最好的做法是在一段時間後存檔數據，也許是在處理完所有測量圖像後？是否有助於啟用壓縮，或者這會對性能產生非常負面的影響？
僅使用 MySQL/MariaDB，我將採用：
- 高速攝取：http: //mysql.rjweb.org/doc.php/staging_table
- 匯總表（使獲取數據更快）：http: //mysql.rjweb.org/doc.php/summarytables
- 我什至會考慮不儲存原始數據；而是總結數據，然後折騰它。如果這是可行的，它可以避免你提出的大部分問題。
- （如果需要清除數據）：快速刪除舊數據：http: //mysql.rjweb.org/doc.php/partitionmaint
FOREIGN KEYS由於額外的成本，我會避免。（相反，我會調試 SQL。）- 我不會使用 UUID 鍵；在巨大的表格中，性能會嚴重下降。( http://mysql.rjweb.org/doc.php/uuid )
AUTO_INCREMENT我會避免使用額外的索引——如果其他一些列是唯一的，請不要使用。- 你提到空間——請詳細說明。2D 查找很棘手；
SPATIAL是一種方法；這是另一個：http: //mysql.rjweb.org/doc.php/latlng你的最後一段拋出了問題的廚房水槽（Toku、MyRocks、存檔、壓縮、歷史表）。我很驚訝這個文章沒有因為“太寬泛”而被殺。請詳細說明您的數據和查詢是什麼樣的；否則，我們所能做的就是扔一個裝滿解決方案的廚房水槽。
你說“實時”，但你需要“千/秒”。你能允許實時延遲 1 分鐘嗎？1秒？你不能得到 1ms；1s將很難實現。爆發持續多長時間？什麼是每分鐘爆發？1K/sec 可能會在接下來的幾秒鐘內溢出。6K/分鐘也不是很麻煩。
有多少客戶端正在儲存數據？一些解決方案適用於單個客戶端；多個客戶需要不同的解決方案。
請記住，基準測試是為了炫耀一件事而調整的，很少與現實生活相匹配。