PostgreSQL/LightDB分割槽表之常見問題

為什麼要分割槽

PostgreSQL的單表最大允許32TB（預設值8KB的情況下），單表太大會引入很多問題（當然這裡是基於預設的情況，：

1、表越大，索引建立的時間越久 (create index concurrently，慢，而且需要2遍以上的掃描，還可能留下invalid的索引)

2、垃圾清理，單表的垃圾回收vacuum (ShareUpdateExclusive鎖，自斥) 目前只支援序列，所以單表越大，垃圾回收的時間越長。筆者遇到很多次幾個TB的單表跑了幾天的autovacuum，還沒有完 - -

3、年齡回收，和單表序列vacuum類似，表越大，掃描的越慢，對於9.6以前的版本更加惡劣 (vm檔案還沒有引入all_frozen的標記位，凍結過的也要掃描)

4、一個邏輯上的大表，可能佔滿檔案系統，使用 分割槽表之後可以將不同的表放置在不同的物理空間上 ，從而達到冷資料放在廉價的物理機器上，熱點資料放置在效能強勁的機器上。

當然還有一些其他的限制，比如（參考原始碼定義，

 •識別符號長度：63

•單表上的索引數量：無限制

•單個索引的列個數：32

•單資料庫下物件的數量：1,431,650,303

•函式最多可以用的引數個數：#define INDEX_MAX_KEYS 32

•一個索引可以允許的最多列個數：#define PARTITION_MAX_KEYS 32

•分割槽表允行的分割槽列數：#define NUM_SPINLOCK_SEMAPHORES 128

•元組的列個數：#define MaxHeapAttributeNumber 1600 /* 8 * 200 */

分割槽的好處

1.拆分成一個個子表，那麼就可以實現邏輯意義上的"並行"vacuum，多個vacuum程式可以同時作用於多個子表，包括年齡凍結、死元組回收、建立索引等維護性動作

2.通過分割槽，可以實現類似冷熱分離的效果，對於不常訪問的子表，可以將其放在一般的媒介上面，比如SATA，對於頻繁訪問的熱表，可以放在SSD上

3.批量的載入和刪除可以用刪除或者detach子表實現，還可以避免大量刪除導致的vacuum，源自官網：Bulk loads and deletes can be accomplished by adding or removing partitions, if the usage pattern is accounted for in the partitioning design. Dropping an individual partition using DROP TABLE, or doing ALTER TABLE DETACH PARTITION, is far faster than a bulk operation. These commands also entirely avoid the VACUUM overhead caused by a bulk DELETE.

4.通過分割槽裁剪，可以定位到具體某一個子表，掃描的資料是分割槽前資料的一部分，可以有效提升效能，同時也意味著可以有更高的緩衝命中率