对于较大的应用程序和数据库来说,在将文本数据插入到数据库之前,GZIP文本数据是不是很常见?
我猜,在再次解压缩之前,在实际文本字段上的任何全文搜索都将不起作用?
发布于 2010-04-29 21:20:03
我还没有看到很多这样的事情,因为它基本上阻止了人们在MySQL端对数据进行任何操作:
like
,没有=
,没有其他manipulation...不过,如果您使用数据库只是为了存储数据,而不是对其进行操作,那么它可能会很有趣。
注意:您可能想要做一些基准测试,以测量这可能产生的性能影响,因为压缩/解压缩需要CPU!
之后,问题是:您是在客户端(PHP)还是在服务器端(MySQL)处理压缩?
在第二种情况下,您可能会对MySQL提供的函数感兴趣。
发布于 2010-04-29 21:25:18
如果在较新版本的MySQL中使用InnoDB表类型,则可以启用compression on an InnoDB表本身。
它是在低层管理的,所以不会改变你的查询或任何东西。据我所知,通过减少磁盘IO并允许将更多数据存储在内存的缓冲池中,可以抵消压缩的轻微开销。但是,您确实提到了InnoDB不支持的全文搜索,因此这可能不是一个选项。
MySQL中也有一个Archive表类型,但我相信除了主键之外,您还会失去索引功能。
另一种选择是“打包”一个MyISAM表,但我认为这会使该表成为只读的,并且不会像其他选项那样压缩。
发布于 2010-04-29 21:18:31
馊主意。当磁盘空间小于$1 GB时,为节省一些空间而进行的额外处理不会抵消为此所需的额外编程时间(不仅仅是最初的编程时间,还要记住维护)。
这可能会使数据库访问变慢,因为数据需要解压缩/压缩。索引在压缩数据上不能正常工作,因为您需要进行表扫描,解压缩数据,然后进行比较。而且全文搜索也被淘汰了。
如果您必须这样做,请不要使用gzip。使用内置的COMPRESS函数。
https://stackoverflow.com/questions/2740819
复制相似问题