在保存 PostgresQL 之前压缩字符串是否值得？

Question

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

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

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

---

我的扩展答案

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

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

这是结果：

• 源文件 - ~1GB
• 每行压缩的文件 - 4.45MB
• 列textSTORAGE EXTENDED - 表大小13MB
• 列textSTORAGE EXTERNAL - 表大小1MB + toast 1027MB
• 列 bytea 带有预 gzdeflated 数据 - 表大小 5.2MB

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

结论：

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

Answer 1

详情请见the documentation。

PostgreSQL 的压缩算法很快，但不是很好，所以你可以在保存数据之前通过压缩数据来节省空间。

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