解決方案來處理頻繁變化的數據

Question

我目前正在試圖找出一個解決方案，以便最好地優化數據，以便頻繁更改。該服務器正在運行IIS/SQL Server，它是一個ASP.NET Web API應用程序。我的表結構是類似如下：

用戶表： 用戶名PK

狀態表： StatusID PK， 標題爲varchar

UserStatus表： 用戶名PK（集羣）， StatusID FK （非羣集）， 日期DateTimeOffset（POSSIBLY INDEXED） - 這將用作到期。舊記錄變得無關緊要。

用戶表中將有大約5000+條記錄。狀態表將有大約500條記錄。 UserStatus表會在任何​​給定時間以0-1000個用戶的任何地方頻繁更改（每5-30秒更改一次）StatusID和日期字段。這個UserStatus表還將頻繁地執行SELECT查詢，並過濾掉具有舊/不相關日期的記錄。

• 我也考慮過用一記填充UserStatus表
  每個用戶，只進行更新。這將意味着
  總是現在的預期記錄，並且它將限制存在的檢查
  。我擔心的是性能以及索引的所有碎片
  。然後我會在表格中查詢 日期的記錄，這些記錄會在當前時間的幾分鐘內完成。
• 我已經考慮過只將相關記錄插入到 UserStatus表中，在用戶存在時進行更新，並且運行 清理舊/不相關數據的任務。這種方法會使記錄數量減少 ，但在執行任務之前，我將不得不檢查記錄的存在性，並且索引可能會禁止 的性能。
• 最後我考慮了一個MemoryCache或類似的東西。 I 對Web API中的緩存瞭解不多，但從我對 的瞭解中可以看出，我很快就決定不這樣做，因爲在迭代緩存時潛在的 併發問題。

有沒有人有像這樣的情景推薦？我還沒有考慮另一種方法嗎？

Answer 1

鑑於您正在談論的記錄數量，我會使用tsql合併器來更新現有記錄並添加一個有效語句的新記錄。

鑑於你提到的設計，你應該能夠運行一個定期的maint腳本來修復任何碎片問題。

該解決方案可以縮放。如果記錄得到了一些放緩發生的地步，我會考慮SSD的碎片不是問題。

如果SSD的缺點使得不合需要，您可以查看內存中的OLTP。