## 歷史資料與儲存 目前歷史資料存放在 SQLite，隨著模擬持續運行，資料量會不斷增長。本 issue 追蹤儲存管理和查詢能力的改善。 ### 待辦項目 - [ ] **資料保留 / 清理策略（Retention / cleanup policy）** 目前 SQLite 歷史資料沒有自動清理機制，長時間運行後檔案會越來越大。需要設計一個策略，例如：保留最近 7 天的秒級資料、30 天的分鐘級資料，更早的資料自動刪除或降採樣壓縮。 - [ ] **更完善的歷史查詢篩選和分頁** 目前後端的歷史查詢 API 篩選條件較少。需要加入更靈活的時間範圍、機組篩選、Tag 篩選、以及分頁機制，避免一次查詢回傳過多資料導致效能問題。 - [ ] **更豐富的事件查詢篩選** 後端事件查詢需要支援更多條件組合，如按嚴重度、事件類型、多機組同時篩選等，讓前端可以做更細緻的事件分析。 - [ ] **儲存架構決策：SQLite vs 時序資料庫** 評估是否需要從 SQLite 遷移到專門的時序資料庫（如 InfluxDB、TimescaleDB）。SQLite 適合小規模和簡單部署，但當資料量大或需要高效的時間範圍聚合查詢時，時序資料庫會更合適。需要根據實際使用場景做決定。 相關文件：`TODO.md` — 產品/平台缺口 — 歷史與儲存
歷史資料與儲存
目前歷史資料存放在 SQLite，隨著模擬持續運行，資料量會不斷增長。本 issue 追蹤儲存管理和查詢能力的改善。
待辦項目
資料保留 / 清理策略（Retention / cleanup policy）
目前 SQLite 歷史資料沒有自動清理機制，長時間運行後檔案會越來越大。需要設計一個策略，例如：保留最近 7 天的秒級資料、30 天的分鐘級資料，更早的資料自動刪除或降採樣壓縮。
更完善的歷史查詢篩選和分頁
目前後端的歷史查詢 API 篩選條件較少。需要加入更靈活的時間範圍、機組篩選、Tag 篩選、以及分頁機制，避免一次查詢回傳過多資料導致效能問題。
更豐富的事件查詢篩選
後端事件查詢需要支援更多條件組合，如按嚴重度、事件類型、多機組同時篩選等，讓前端可以做更細緻的事件分析。
儲存架構決策：SQLite vs 時序資料庫
評估是否需要從 SQLite 遷移到專門的時序資料庫（如 InfluxDB、TimescaleDB）。SQLite 適合小規模和簡單部署，但當資料量大或需要高效的時間範圍聚合查詢時，時序資料庫會更合適。需要根據實際使用場景做決定。
相關文件：
TODO.md— 產品/平台缺口 — 歷史與儲存