標籤
PostgreSQL , Greenplum , HybridDB for PG
背景
數據庫空間不夠用怎麼辦？
HDB PG是分佈式數據庫，空間不夠用，擴容唄。但是用戶如果不想擴容呢？還有哪些處理方法？
例子
1 查看當前已使用空間
查看數據庫空間使用，表的空間使用，索引的空間使用等。
postgres=# select datname,pg_size_pretty(pg_database_size(datname)) from pg_database order by pg_database_size(datname) desc;
datname | pg_size_pretty
-----------+----------------
postgres | 32 MB
template1 | 31 MB
template0 | 31 MB
(3 rows)
postgres=# select relname,relkind,pg_size_pretty(pg_relation_size(oid)) from pg_class order by pg_relation_size(oid) desc limit 20;
relname | relkind | pg_size_pretty
---------------------------------+---------+----------------
pg_proc | r | 1920 kB
pg_rewrite | r | 1824 kB
pg_depend | r | 1344 kB
pg_attribute | r | 1248 kB
pg_depend_reference_index | i | 1248 kB
pg_depend_depender_index | i | 1248 kB
pg_proc_proname_args_nsp_index | i | 864 kB
pg_attribute_relid_attnam_index | i | 576 kB
pg_statistic | r | 576 kB
pg_description | r | 576 kB
pg_description_o_c_o_index | i | 480 kB
pg_proc_oid_index | i | 480 kB
pg_operator | r | 384 kB
pg_attribute_relid_attnum_index | i | 384 kB
pg_type | r | 288 kB
gp_persistent_relation_node | r | 288 kB
pg_class | r | 288 kB
pg_authid_oid_index | i | 192 kB
pg_authid_rolname_index | i | 192 kB
pg_amproc_oid_index | i | 192 kB
(20 rows)
2 配置雲監控
通過配置雲監控，用戶可以隨時掌握數據庫的已使用空間，剩餘空間的情況。
3 空間不夠用的策略
提供三種建議：
1、drop table, truncate table , 最簡單直接
2、DELETE ，版本被保留。所以需要delete+vacuum 。
如果是列AO表，delete後 可以用VACUUM收縮。
如果是HEAP表，delete後 VACUUM無法收縮， 需要VACUUM FULL，但是VACUUM FULL需要雙倍空間，並且會堵塞所有讀寫該表的操作，請慎用。
3、查看是不是有膨脹，可以清理垃圾減少膨脹。
《Greenplum 列存表(AO表)的膨脹、垃圾檢查與空間收縮(含修改分佈鍵)》
《如何檢測、清理Greenplum膨脹、垃圾(含修改分佈鍵) - 阿里雲HybridDB for PG最佳實踐》
4、如果表有PARTITION，可以TRUNCATE分區
5、創建OSS外部表，將不經常訪問的數據表（或分區）寫入OSS外部表。然後刪除HDB PG裏面對應的TABLE與PARTITION
詳見：
https://help.aliyun.com/document_detail/35457.html
注意HDB PG沿用了GPDB的外部表框架，讀寫外部表操作是分開的。
導出需要創建可寫外部表，然後將本地表的數據寫出。
如果需要讀取OSS中大數據，需要創建可讀外部表。
6、使用壓縮表（列存，大BLOCK壓縮效果好，還可以使用聚集提高壓縮比）。
Command: CREATE TABLE
Description: define a new table
Syntax:
CREATE [[GLOBAL | LOCAL] {TEMPORARY | TEMP}] TABLE table_name (
[ { column_name data_type [ DEFAULT default_expr ] [column_constraint [ ... ]
[ ENCODING ( storage_directive [,...] ) ]
]
| table_constraint
| LIKE other_table [{INCLUDING | EXCLUDING}
{DEFAULTS | CONSTRAINTS}] ...}
[, ... ] ]
[column_reference_storage_directive [, ... ]
)
[ INHERITS ( parent_table [, ... ] ) ]
[ WITH ( storage_parameter=value [, ... ] )
[ ON COMMIT {PRESERVE ROWS | DELETE ROWS | DROP} ]
[ TABLESPACE tablespace ]
[ DISTRIBUTED BY (column, [ ... ] ) | DISTRIBUTED RANDOMLY ]
[ PARTITION BY partition_type (column)
[ SUBPARTITION BY partition_type (column) ]
[ SUBPARTITION TEMPLATE ( template_spec ) ]
[...]
( partition_spec )
| [ SUBPARTITION BY partition_type (column) ]
[...]
( partition_spec
[ ( subpartition_spec
[(...)]
) ]
)
where storage_parameter is:
APPENDONLY={TRUE|FALSE} // aO表，支持COLUMN存儲
BLOCKSIZE={8192-2097152} // 塊大小
ORIENTATION={COLUMN|ROW} // 列存壓縮比高
COMPRESSTYPE={ZLIB|QUICKLZ|RLE_TYPE|NONE}
COMPRESSLEVEL={0-9} // 選擇壓縮比
CHECKSUM={TRUE|FALSE}
FILLFACTOR={10-100}
OIDS[=TRUE|FALSE]
《一個簡單算法可以幫助物聯網,金融 用戶 節約98%的數據存儲成本 (PostgreSQL,Greenplum幫你做到)》
7、查看是否是數據傾斜造成的磁盤滿。
《分佈式DB(Greenplum)中數據傾斜的原因和解法 - 阿里雲HybridDB for PostgreSQL最佳實踐》
8、如果是系統表膨脹，需要vacuum系統表，特別是大量使用臨時表可能導致pg_attribute膨脹。
建議後臺調度，在空閒時間vacuum pg_attribute .
vacuum pg_attribute ;
vacuum pg_attribute_encoding ;
vacuum gp_relation_node ;
vacuum pg_class ;
如果發現元數據表以及膨脹得很厲害，需要VACUUM FULL清理，（找空閒時間，因爲會堵塞所有操作）。
vacuum full pg_attribute;
reindex table pg_attribute;
vacuum full pg_attribute_encoding ;
reindex table pg_attribute_encoding;
vacuum full gp_relation_node ;
reindex table gp_relation_node;
vacuum full pg_class ;
reindex table pg_class;
《大量使用臨時錶帶來的系統表如pg_attribute膨脹問題，替代方案，以及如何擦屁股 - Greenplum, PostgreSQL最佳實踐》
9、如果以上都做不了，建議升級實例