我制作了我的Django模型,在将测试/虚拟记录插入到PostgreSQL数据库后,我意识到我的数据对于每条记录都非常大.所有字段中的数据总和将为每条记录约700 KB.我估计我将有大约500万条记录,所以这将在3350 GB标记附近变得非常大.我的大多数数据都是大型
JSON转储(每个字段大约70 KB).

我不确定PostgreSQL在通过Django框架处理时是否会自动压缩我的数据.我想知道在将数据输入数据库之前是否应该压缩数据.

问题：
在使用Django模型字段类型TextField时,PostgreSQL是否使用某种x压缩算法自动压缩我的字符串字段？

我不应该依赖PostgreSQL并事先压缩我的数据然后将其输入数据库吗？如果是这样,我应该使用哪个压缩库？我已经在Python中尝试了zlib并且看起来很棒,但是,我已经读过gzip库也是如此,我很困惑哪个是最有效的(在压缩和解压缩速度方面以及压缩百分比方面).

编辑：我正在阅读this Django snippet for CompressedTextField,这引起了我对使用哪个压缩库的困惑.我看到有些人使用zlib而有些人使用gzip.

编辑2：This stackoverflow question说PostgreSQL会自动压缩字符串数据.

编辑3：PostgreSQL使用pg_lzcompress.c进行压缩,这是LZ压缩系列的一部分.是否可以安全地假设我们不需要在TextField本身上使用其他形式的压缩(zlib或gzip),因为它本身就是数据类型文本(可变长度字符串)？

最佳答案 是的,postgresql将压缩大型文本字段,完全独立于您使用它的任何框架.

使用名为TOAST的东西存储大字段值.这些属性可能会被压缩,如果太大而无法在列中嵌入,则它们会在称为TOAST表的特殊文件中存储.

正如您已经确定的那样,使用了LZ压缩.这并没有像其他算法那样提供高压缩比.但是,为了获得收益,我怀疑在将应用程序中的数据发送到数据库之前压缩数据是否值得,如果磁盘空间是您主要关注的问题.

您可以通过设置列的存储模式来影响属性的存储.有关ALTER TABLE的手册,请参见SET STORAGE.

PLAIN must be used for fixed-length values such as integer and is
inline, uncompressed. MAIN is for inline, compressible data. EXTERNAL
is for external, uncompressed data, and EXTENDED is for external,
compressed data. EXTENDED is the default for most data types that
support non-PLAIN storage.

TEXT的默认值为EXTENDED.

但是,您应该考虑如何使用数据.将使用什么类型的查询来访问数据？将使用什么过滤标准？它必须通读所有这些大型TOAST属性来访问WHERE子句中使用的值,然后性能可能很差.