事件類型行的大量數據庫日誌記錄以及優化它的方法

我們有一個儲存事件的數據庫。事件以每秒 1000 個的速率生成。我們需要在幾年內保持這些事件的可訪問性。

通常使用這些事件是從過去 1-2 個月中選擇其中一些。

每個事件對應一個resource_id（估計為5000）。

由於只需將所有這些都保存在一個表中即可進行所有維護，並且選擇速度很慢且消耗資源，因此我正在考慮以某些方式對其進行改進：

a) 將每個 resource_id 分隔到每個表中。5000 多張桌子。從多個 resource_ids（最多 100 個）中選擇將需要一些重寫和聯合或其他東西。

b) 每天分開到不同的桌子。當選擇需要多天的數據時，將需要工會或其他東西。

c）以上（我認為太極端）

d）以某種方式在時間戳索引甚至resource_id索引上進行分區。這值得麼？還是上述建議的“手動”分區更好？

數據庫是 PostgreSQL。

我們有一些類似的東西，每秒約 5000 個事件。表按月分區，我們儲存 5 年的數據。這給了我們 60 個分區，工作正常。它在 PostgreSQL 版本 9.1 上執行，在使用分區時比任何舊版本都好。

EXPLAIN 和 EXPLAIN ANALYZE是您解決問題的最佳朋友。

這是滾動分區（或滑動視窗分區）的經典案例。在重新設計數千個子表中的表並重寫程式碼之前，請嘗試分區，就像 Erwin 已經建議的那樣。

一些文章：

• 滑動視窗表分區和自動化滑動視窗維護- SQL Server 中解釋的滾動分區；
• Table Partitioning Sliding Window Case - MSDN 部落格，SQL Server 風味；
• Rolling Time-based Partitions - MySQL 風格；
• 自我管理分區範例- PostgreSQL 風格；
• 使用 Postgres 的動態每日表分區- 又是 PostgreSQL（實際上是珍珠+pgsql）；

引用自：https://dba.stackexchange.com/questions/14393