在保存在PostgresSQL上之前压缩字符串是否有价值?

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

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

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

我的延伸答案

我想了解更多,所以我做了很少的实验.

>我用20000行创建了源文件,其中1行= 50000个随机字符.
>使用gzdeflate创建的文件,其中1行是来自源文件的压缩行
>我创建了具有一列的表格,并将每一行插入为1行.
>比较大小

结果如下:

>源文件-约1GB
>每行压缩的文件-4.45MB
>列文字存储扩展-表大小13MB
>栏文字STORAGE EXTERNAL-表格大小1MB吐司1027MB
>具有预gzdeflated数据的列bytea-表大小5.2MB

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

结论:

>如果您希望将数据存储为文本,则每〜1GB内容约13MB是一个很好的比率.
>如果您需要更好的压缩,并且您不介意将数据存储为blob / bytea并创建其他脚本来管理插入/检索的数据…那么……考虑一下这几MB是否值得.
>还请记住:默认情况下,PostgreSQL压缩的字符串大于2kb.如果字符串少于2000个字符,则必须自己更改此设置或压缩数据.

解决方法:

有关详细信息,请参见the documentation.

PostgreSQL的压缩算法很快,但是效果不是很好,因此您可以在保存数据之前通过压缩数据来节省空间.

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

上一篇:linux – ncompress压缩文件到99.99%的速率?


下一篇:Linux:从管道将命名文件添加到zip存档中