Odoo PostgreSQL分庫分表性能優化方向方案

一、專案背景

目前的 Odoo18 系統運行於單一 PostgreSQL 執行個體上，總資料庫大小約為 4.5TB。核心業務資料表的資料量持續成長，且個別資料表的大小正逼近效能極限。

隨著業務擴展與使用者數量增加，資料庫會面臨：

• 查詢效能下降；
• 索引膨脹；
• VACUUM overload;
• 備份與復原時間過長；
• 歷史資料難以歸檔。

計劃透過分片 + 分區解決方案系統性地最佳化現有架構，以確保未來三年的資料庫效能與可維護性。

II. 整體計畫目標

1. 建立高效能、高可擴展性的 PostgreSQL 資料架構；
2. 控制單一資料表的資料量，以提升查詢與寫入效能；
3. 優化資料庫儲存結構以降低維護成本；
4. 支援 Odoo18 未來三年的業務成長需求。

III. 整體技術方法

4. 分片與分割設計方案

1️⃣ 分割策略

核心概念：依時間或公司維度對最大且成長最快的資料表進行分割。

技術解決方案：

• 使用 PostgreSQL 原生分割表；
• 自動建立新的分割區 (pg_partman);
• 分割區命名慣例：sale_order_y2025_q1;
• 歷史分割區會設定為唯讀，並進入冷儲存歸檔區域。

2️⃣ 分片方案

目標：透過邏輯資料庫分片降低單一執行個體負載。

架構圖：

主要執行個體 (作用中資料)      歷史執行個體 (封存資料)
 ├── sale_db             ├── sale_db_archive
 ├── stock_db            ├── stock_db_archive
 ├── account_db          ├── account_db_archive

5. 資料移轉與實作步驟

6. 資料庫層技術最佳化內容

1. 參數最佳化
   • 調整 shared_buffers、work_mem、maintenance_work_mem、effective_cache_size；
   • 獨立 WAL 磁碟、最佳化 checkpoint_timeout、wal_compression；
   • 啟用 autovacuum 以調整頻率並避免資料表膨脹。
2. 指數策略
   • 為高頻欄位建立 GIN/BTREE 複合索引；
   • 清理多餘的索引以降低寫入壓力；
   • 定期執行 REINDEX CONCURRENTLY。
3. 資料表結構調整
   • 壓縮並儲存歷史資料表；
   • 對日誌類型的資料表使用 UNLOGGED，以減少 WAL 壓力；
   • 大型欄位（JSON/文字）使用 TOAST 壓縮。
4. 監控與維護系統
   • 部署 pg_stat_statements、pg_partman_bgw、pg_cron；
   • 整合 Grafana + Prometheus 以顯示查詢時間、IO 與快取命中率；
   • 定期輸出「效能監控報告」。

7. 風險與控制措施

8. 乙方交付的內容

1. PostgreSQL 分片架構設計文件
2. 資料庫移轉與驗證計畫
3. 資料庫效能調校報告
4. 監控與警示系統部署指南
5. 專案摘要與績效評估報告

9. 專案價值

• 單表查詢效能提升 40%+；
• 主資料庫資料量控制在 500GB 以內，VACUUM 效率提升 60%；
• 備份週期縮短至 1/3；
• 系統架構具備在三年內持續擴充的能力；
• 為 Odoo 應用層升級提供長期支援。