在 SQL Server Azure 數據庫中儲存實時時序數據
我有一個 SQL Server Azure 數據庫，正在嘗試儲存從多個感測器獲取的時間序列數據。
數據來源：- 通過 API 獲取 5 分鐘數據。
目前表結構：-
Timestamp | ComponentId | Parameter1 | Parameter2 | Parameter3每個感測器都有一個唯一的 ComponentId。我在 Timestamp 和 ComponentId 上有一個非聚集索引來消除重複項，並且在整個表上還有一個聚集列儲存索引（它壓縮數據並節省空間。還可以提高聚合查詢的性能）。python腳本用於通過API獲取數據，pyodbc庫用於將這些數據推送到表中。該腳本每 10 分鐘執行一次，並將數據插入表中。
某些查詢（例如僅在一天內獲取特定組件的數據）似乎需要 5 秒。這是正常的嗎？
詢問：-
SELECT Timestamp,ComponentId,ParameterId FROM TABLE WHERE ComponentId=1 AND Timestamp BETWEEN '2021-05-01' AND '2021-05-02'
IO 統計數據：表“原始數據”。掃描計數 2，邏輯讀取 10164，物理讀取 3，頁面伺服器讀取 0，預讀讀取 10146，頁面伺服器預讀讀取 0，lob 邏輯讀取 2766，lob 物理讀取 12，lob 頁面伺服器讀取 0，lob 讀取-預讀為 4877，lob 頁面伺服器預讀為 0。表“RawData”。段讀取 2，段跳過 10。
這種獲取/推送數據的方式好嗎？請讓我知道它是否可以改進，以及是否有更好的方法可以做到這一點。
使用這種設計，預計查詢需要對列儲存進行全面掃描。在這種規模下應該非常快，但是 IO 統計數據顯示您正在從磁碟讀取。如果您查看實際執行計劃的等待統計資訊，您應該會看到 IO 等待比 CPU 使用率多。
您可以擴展數據庫以獲得更多記憶體記憶體，或者可以通過 componentId 或時間戳對列儲存進行分區。每當您對列儲存進行分區時，您都希望確保分區至少有 1M 行。
我認為 Clustered Columnstore 可能對您的情況和對您不利。
鑑於數據量和您嘗試查詢的方式，您應該只做一個正常的聚集索引（
(ComponentId, Timestamp)如果您想節省空間/減少磁碟 i/o，則主鍵並啟用頁面壓縮。關於列儲存要記住的一點是，它會物理分解您的數據，通常以不適合時間序列分析/查詢的方式進行。對於廣泛的“非規範化”數據，它是一個很好的工具，但是對於您試圖通過搜尋整個列儲存以重新組裝您需要的幾行所帶來的成本而言，不值得您從一些聚合查詢中獲得任何潛在的好處.