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