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

Question

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

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

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

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

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

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

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

Answer 1

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

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

正如您已经确定的，使用了 LZ 压缩。这不会提供像其他一些算法一样高的压缩比。然而，对于您可能获得的收益，如果磁盘空间是您主要关心的问题，我怀疑在将应用程序中的数据发送到数据库之前压缩数据是否值得。

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

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

TEXT 的默认值是 EXTENDED。

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