在 PostgresSQL 上保存之前压缩字符串值得吗？

Question

我们将加密的文件内容存储在 PostgresSQL 数据库中。我们储存了很多。目前我们无法将此内容写入任何其他地方（例如 FTP 或内部存储）。尽管如此，我们的数据库仍在快速变得越来越大。

我已经知道 PostgreSQL 默认情况下会压缩字符串数据，所以我的问题是：在将其插入数据库之前是否值得在应用程序端进行字符串压缩。这会节省空间吗？

也许您知道如何调整 PostgreSQL 或任何其他方法来在 PostgreSQL 表中存储文件时节省一些空间。

---

我的扩展答案

因为我想了解更多，所以我做了一些实验。

• 我创建了20000 行的源文件，其中1 行 = 50000 个随机字符。
• 创建文件，其中 1 行是源文件中的压缩行，使用gzdeflate
• 我创建了包含一列的表格，并将每一行插入为 1 行。
• 尺寸比较

这是结果：

• 源文件 - ~1GB
• 每行压缩的文件 - 4.45MB
• 列text STORAGE EXTENDED-表大小13MB
• 列text STORAGE EXTERNAL- 表大小1MB + Toast 1027MB
• 包含预 gzdeflated 数据的列bytea- 表大小5.2MB

我想指出的是，预压缩数据并将其存储为文本STORAGE EXTENDED是可能的，结果是700kb表大小，但预压缩数据包含大多数字符集调色板之外的字符。检索此类数据是不可能的。

结论：

• 如果您更喜欢将数据存储为text，每 1GB 内容约 13MB 是非常好的比率。
• 如果您需要更好的压缩并且不介意将数据存储为 blob/bytea 并创建其他脚本来管理插入/检索的数据...好吧...考虑一下这几 MB 是否值得。
• 另请记住：默认情况下 PostgreSQL 正在压缩字符串>2kb。如果您的字符串少于 2000 个字符，您必须更改此设置或自行压缩数据。

Answer 1

有关详细信息，请参阅文档。

PostgreSQL 的压缩算法很快，但不是很好，因此您可以通过在保存数据之前对其进行压缩来节省空间。

但是，您应该更改表以使用EXTERNAL列的存储策略。否则，PostgreSQL 将通过压缩已经压缩的值来不必要地浪费 CPU 周期，结果却发现它们不会变小并按原来的方式存储它们。