Django：数据库级别或代码级别的TextField（字符串）数据压缩

Question

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

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

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

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

编辑：我正在阅读这个用于CompressedTextField的Django片段，这引发了我对使用哪个压缩库的困惑。 我看到有些人使用zlib而有些人使用gzip 。

编辑2： 这个stackoverflow问题说PostgreSQL会自动压缩字符串数据。

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

Answer 1

是的，postgresql将压缩大型文本字段，完全独立于您使用它的任何框架。

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

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

您可以通过设置列的存储模式来影响属性的存储。 有关ALTER TABLE的信息，请参见手册页上的SET STORAGE。

PLAIN必须用于固定长度值，例如整数，并且是内联的，未压缩的。 MAIN用于内联可压缩数据。 EXTERNAL用于外部未压缩数据，EXTENDED用于外部压缩数据。 EXTENDED是支持非PLAIN存储的大多数数据类型的默认值。

TEXT的默认值为EXTENDED。

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