Django+PostgreSQL海量行数据场景下TextField存储压缩优化问题

1. 确认PostgreSQL数据库中存储占用最高的对象 #

可以直接执行以下SQL查询，按大小排序获取所有业务表的存储占用（包含主表、索引、大字段关联的TOAST存储）：

SELECT
  schemaname || '.' || tablename AS table_name,
  pg_size_pretty(pg_total_relation_size(schemaname || '.' || tablename)) AS total_size,
  pg_size_pretty(pg_relation_size(schemaname || '.' || tablename)) AS main_table_size,
  pg_size_pretty(pg_total_relation_size(reltoastrelid)) AS toast_size
FROM pg_tables t
JOIN pg_class c ON t.tablename = c.relname AND t.schemaname = c.relnamespace::regnamespace::text
WHERE schemaname NOT IN ('pg_catalog', 'information_schema')
ORDER BY pg_total_relation_size(schemaname || '.' || tablename) DESC
LIMIT 20;

查询结果中排名靠前的就是数据库内存储占用最高的对象，其中toast_size列对应大字段的独立存储占用。

2. 是否需要自行在应用层执行字符串压缩 #

2.1 PostgreSQL自动文本压缩的说法是否正确 #

正确。PostgreSQL默认开启TOAST（超大属性存储技术）机制，当字段大小超过默认阈值（2KB）时，会自动对文本类字段使用pglz算法压缩，14及以上版本还支持压缩率更高的zstd算法。压缩后的数据会单独存储在TOAST表中，主表仅存储指针，不会影响主表查询性能，针对文本类数据默认压缩率通常在2-3倍左右。

2.2 现有Python代码是否会导致数据丢失 #

你提供的代码逻辑存在严重问题，必然会导致解压失败甚至数据丢失：
zlib.compress返回的是原始二进制bytes，直接用str()转换会将bytes的表示字符串（比如b'x\x9c...'）转为普通字符串，不仅会额外增加b'、转义符等冗余字符，导致压缩后的体积反而比原数据更大，而且转换后的字符串无法直接用zlib.decompress解压，运行时会直接抛出类型错误。

2.3 str(zlib.compress(text, 9))写法是否合法 #

语法层面不会报错，但业务逻辑完全不合法，完全无法达到压缩存储的目的，属于错误用法。

优化建议 #

1. 先执行前文的表大小查询，确认当前表的TOAST存储占用情况，评估PG自带压缩的效果。如果你的存储的是JSON格式文本，PG自带压缩已经能覆盖大部分场景，不需要额外自行处理。
2. 如果还需要进一步降低存储占用，可选两个成熟方案：
   • 升级PostgreSQL到14及以上版本，将raw_data字段的存储压缩算法改为zstd，压缩率比默认pglz高30%左右，不需要修改任何应用代码：

     ALTER TABLE 你的表名 ALTER COLUMN raw_data SET COMPRESSION zstd;
     

   • 确实需要应用层压缩的话，将Django模型的raw_data字段从TextField改为BinaryField，直接存储zlib.compress返回的原始bytes，不要做str转换，解压时直接读取bytes解压即可。

内容的提问来源于stack exchange，提问作者flice com