问题:在保存到 PostgresQL 之前压缩字符串是否值得?

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

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

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

我的扩展答案

当我想知道更多时,我做了一些实验。

• 我创建了带有 20000 行 的源文件,其中 1 行 u003d 50000 个随机字符。

• 创建文件,其中 1 行是使用gzdeflate从源文件压缩的行

• 我创建了一列的表,并将每一行插入为 1 行。

• 比较尺寸

这是结果:

• 源文件 - ~1GB

• 文件,每行压缩 - 4.45MB

• 列text``STORAGE EXTENDED- 表大小13MB

• 列text``STORAGE EXTERNAL- 表大小 1MB + toast 1027MB

• 列bytea与预 gzdeflated 数据 - 表大小 5.2MB

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

结论:

• 如果您更喜欢将数据存储为text,则每 ~1GB 内容 ~13MB 是非常好的比例。

• 如果您需要更好的压缩,并且您不介意将数据存储为 blob/bytea 并创建额外的脚本来管理插入/检索的数据......好吧......考虑一下这几 MB 是否值得。

• 还要记住:默认情况下 PostgreSQL 正在压缩字符串>2kb。如果您的字符串少于 ~2000 个字符,您必须自己更改此设置或压缩数据。

解答

详见文档。

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

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