我制作了我的Django模型，在将测试/虚拟记录插入PostgreSQL数据库后，我意识到我的数据对于每条记录都非常大。所有字段中的数据总和将为每条记录约700 KB。我估计我将有大约500万条记录，所以这将在3350 GB标记附近变得非常大。我的大部分数据都是大型JSON转储（每个字段大约70+ KB）。
我不确定PostgreSQL在通过Django框架处理时是否会自动压缩我的数据。我想知道在将数据输入数据库之前是否应该压缩数据。
问题：
在使用Django模型字段类型x时，PostgreSQL是否使用一些TextField压缩算法自动压缩我的字符串字段？
我是否应该依赖PostgreSQL并事先压缩我的数据然后将其输入数据库？如果是这样，我应该使用哪个压缩库？我已经在Python中尝试了zlib并且看起来很棒，但是，我已经读过有gzip库，我很困惑哪个最有效（就压缩和解压缩速度而言）以及压缩的百分比。）
编辑：我正在阅读this Django snippet for CompressedTextField，这引起了我对使用哪个压缩库的困惑。我看到有些人使用zlib而有些人使用gzip。
编辑2：This stackoverflow question表示PostgreSQL会自动压缩字符串数据。
编辑3：PostgreSQL使用pg_lzcompress.c进行压缩，这是LZ压缩系列的一部分。是否可以安全地假设我们不需要在zlib本身使用其他形式的压缩（gzip或TextField），因为它的数据类型为text （DB中的可变长度字符串）？
答案 0 :(得分：2)
是的，postgresql将压缩大型文本字段，完全独立于您使用它的任何框架。
使用名为TOAST的内容存储大字段值。这些属性可能会被压缩，如果太大而无法在列中嵌入，则它们会在称为TOAST表的特殊文件中存储。
正如您已经确定的那样，使用了LZ压缩。这并没有像其他算法那样提供高压缩比。但是，为了获得收益，我怀疑在将数据发送到数据库之前压缩应用程序中的数据是值得的，如果磁盘空间是您主要关心的问题。
您可以通过设置列的存储模式来影响属性的存储。请参阅ALTER TABLE手册页上的SET STORAGE。
PLAIN必须用于固定长度值，例如整数和 内联，未压缩。 MAIN用于内联可压缩数据。外部 用于外部未压缩数据，EXTENDED用于外部， 压缩数据。 EXTENDED是大多数数据类型的默认值 支持非PLAIN存储。
TEXT的默认值为EXTENDED。
但是，您应该考虑如何使用您的数据。将使用什么类型的查询来访问数据？将使用什么过滤标准？它必须通读所有这些大型TOAST属性来访问WHERE子句中使用的值，然后性能可能会很差。