處理大量事務數據表的最佳實踐
我有一個儲存大量交易數據的交易表。只有一個月的最新數據才能實時用於交易用途。較新的數據只能用於報告生成或離線分析。
處理此類交易數據的最佳做法是什麼？
我是否應該創建一個具有相同列的歷史表並將年齡超過一個月的數據從事務表移動到具有批處理作業的歷史表？我應該每年創建一個歷史表嗎？還是只使用一個歷史表來託管所有過去的數據？
或者我應該使用數據庫分區而不是歷史表嗎？
或者我應該創建一個數據倉庫並將數據移動到其中？
您應該指定您使用的數據庫系統和版本，因為這將影響您對如何建構和管理數據的實際選擇。
您在上下文中提到大意味著每天有 100,000 條新記錄，所以讓我們計劃一個更大的數量級，每天 100 萬條記錄。一個月內有 3000 萬條新記錄，一年內約有 3.6 億條記錄。雖然 3.6 億條記錄開始變得有些龐大，但在大多數現代數據庫系統中，這絕不是無法管理或需要特殊處理的事情。
這將取決於您正在執行的實際查詢、寫入與讀取的伺服器的並發性以及報告數據的可接受執行時間，但是一年中3.6億條記錄不應該用現代****RDBMS嚇到您。我管理過包含數十億條記錄的表，並直接從它們中報告出來，通常在相當適中的硬體上在 10 秒內一次查詢大約 100 萬條記錄。
如果您想減少報告的並發性，那麼您可以考慮歸檔較舊的數據（即任何早於最後一個月的數據）或將其遷移到數據倉庫中。根據正在執行的查詢類型以及您使用的數據庫系統，您可能擁有列儲存索引和過濾索引等可用功能，這些功能可以幫助您直接從表本身改進報告，而無需存檔。
正確地建構架構和索引數據將在提高報告能力方面發揮最大作用。
最後，正如 Jonathan Fite 所提到的，分區不會直接提高您的查詢性能，但它可以用來改善您對錶的管理，因為您可以智能地將數據劃分為分區，從而允許您管理不太活躍的數據，同時管理更活躍的數據分區正在使用中。當您需要執行諸如歸檔數據（通過分區交換）或索引維護之類的事情時，您會看到降低並發性的改進。
如果您對每天 100,000 行的估計是準確的，並且您預計未來幾年實際上不會有任何有意義的增長，那麼您每年只看到 3600 萬行。那時我什至不會考慮分區或歸檔。對架構良好的模式進行正常索引應該為您提供非常快速的查詢執行時。但我個人喜歡計劃比我實際預期的更多的數據，就像上面一樣。