JAVA 字符串压缩 或 编码，以节省存储空间

[imasmallbird]

由于需要将一个较大的参数值 进行数据库存储，
而存储后在进行读取时会由于该表的存储量很大，这个值会导致加大IO

我们在JAVA中能否使用一个比较高压缩的方式或进行编码、加密也可，或者某种手段将这个字符串的长度进行压缩
比如一个字符串的长度为300，在进行压缩后会变为150或更少

试了ZIP压缩不太理想，使用BASE64反而会增大，3DES的方式也不太好

想请教各位，有关这方面可用的技巧或思路！

[李狗蛋52635]

http://topic.csdn.net/t/20060214/14/4555387.html

不知这个帖子对lz有没有帮助

[imasmallbird]

[Quote=引用 1 楼 的回复:]

http://topic.csdn.net/t/20060214/14/4555387.html

不知这个帖子对lz有没有帮助
[/Quote]
那个是 .net 的

[李狗蛋52635]

小弟从网上找了个，觉得还是不错的...

	main{
		try
		{
			String str = "中国中国中中国中国中中国中国中中国中国中中国中国中中国中国中中国中国中中国中国中中国中国中中国中国中"
				 		+ "中国中国中中国中国中中国中国中中国中国中中国中国中中国中国中中国中国中中国中国中中国中国中中国中国中"
				 		+ "中国中国中中国中国中中国中国中中国中国中中国中国中中国中国中中国中国中中国中国中中国中国中中国中国中"
				 		+ "中国中国中中国中国中中国中国中中国中国中中国中国中中国中国中中国中国中中国中国中中国中国中中国中国中"
				 		+ "中国中国中中国中国中中国中国中中国中国中中国中国中中国中国中中国中国中中国中国中中国中国中中国中国中"
				 		+ "中国中国中中国中国中中国中国中中国中国中中国中国中中国中国中中国中国中中国中国中中国中国中中国中国中";
			String comp = compress(str);
			System.out.println(str.length());
			System.out.println(comp.length());
			String umComp = uncompress(comp);
			System.out.println(umComp);
		}
		catch (IOException e)
		{
			e.printStackTrace();
		}
	}

	 // 压缩
	  public static String compress(String str) throws IOException {
	    if (str == null || str.length() == 0) {
	      return str;
	    }
	    ByteArrayOutputStream out = new ByteArrayOutputStream();
	    GZIPOutputStream gzip = new GZIPOutputStream(out);
	    gzip.write(str.getBytes());
	    gzip.close();
	    return out.toString("ISO-8859-1");
	  }

	  // 解压缩
	  public static String uncompress(String str) throws IOException {
	    if (str == null || str.length() == 0) {
	      return str;
	    }
	    ByteArrayOutputStream out = new ByteArrayOutputStream();
	    ByteArrayInputStream in = new ByteArrayInputStream(str
	        .getBytes("ISO-8859-1"));
	    GZIPInputStream gunzip = new GZIPInputStream(in);
	    byte[] buffer = new byte[256];
	    int n;
	    while ((n = gunzip.read(buffer)) >= 0) {
	      out.write(buffer, 0, n);
	    }
	    // toString()使用平台默认编码，也可以显式的指定如toString("GBK")
	    return out.toString();
	  }

结果:
300
38
中国中国中中国中国中中国中国中中国中国中中国...

[yukun314]

如果字符串比较大，是否考虑把字符串存储到文件中，在数据库中存储该文件的路径！

[imasmallbird]

[Quote=引用 3 楼 的回复:]

小弟从网上找了个，觉得还是不错的...

Java code

main{
try
{
String str = "中国中国中中国中国中中国中国中中国中国中中国中国中中国中国中中国中国中中国中国中中国中国中中国中国中"
+ "中国中国中中国中国中中国中国中中国中国中中国中国中中……
[/Quote]
压缩的本身就是对一些重复字符串处理
你可以试一下，不是这么规律的压缩的效果 。。

[imasmallbird]

[Quote=引用 4 楼 的回复:]

如果字符串比较大，是否考虑把字符串存储到文件中，在数据库中存储该文件的路径！
[/Quote]

谢谢，这个没有大到那个程度，而且需求上不能这么做～

[MiceRice]

比如一个字符串的长度为300，在进行压缩后会变为150或更少
——规模太小了，压缩时生成的头信息都会消耗不少空间

试了ZIP压缩不太理想，使用BASE64反而会增大，3DES的方式也不太好
——BASE64根本就不是压缩，必然要增大；3DES是加密，不增大就算你运气很好了。

由于需要将一个较大的参数值 进行数据库存储
——如果可以，给出该参数值的形式，也许可以通过研究该参数值的规律来进行压缩。

不过说句心里话，才300字节，不要纠结了，这个IO简直可以忽略不计，实在不值得去压缩。。。。。

如果你很希望保证数据块内尽可能多存放数据行以提升list查询性能的话，可以将值用扩展表存储。

[dracularking]

zip压缩是大于150吗

不是很确定，可能还真的得看被压缩对象的内容而定
比如用16进制字符串代替2进制字符串存储，就更省空间
进制差越大，压缩率越高
可能这也是压缩的其中一种方法吧

[imasmallbird]

[Quote=引用 11 楼 的回复:]

直接借助现成的压缩技术真的意义很小，因为你的规模太小了。如果不能有效扩大规模，头信息的开销太不值得了。

举例来说，假设你的数据内容都是 字母数字：
◎ 那么首先压缩算法会先根据内容生成压缩字典，那么这个字典可能就要占用大约100～200字节的信息。接下来300字节的正文如果按20%压缩比的话，可以压缩成60字节。最后的总规模就是160～260。你看，不是压缩比不够好，而是字典浪费太多空间……
[/Quote]
1、固定压缩算法，也就是研究你值的特征，然后直接手工生成压缩字典并固化在程序中，也就是每个字段的值里面不再保存这100～200字节的字典内容了；压缩和解压时都必须使用该唯一字典；
>>恩，这个正在尝试中，但还需要测试入库前压缩与取出后解压所带来的性能消耗，是否能满足要求
否则压缩的方式进行放弃。
2、如果有条件的话，采用“列式数据库”，启用数据库字段级压缩，能得到很好的收益，因为这个相当于数据库会针对该字段生成所有数据行所公用的压缩字典。
>>这点也进行了考虑，也考虑过行级的compress，但是这个表的几十亿数据会频繁的删除与插入，会导致数据库也要进行反复的压缩与解压缩，与DBA沟通后放弃了

[dracularking]

关键能实现一个高压缩比算法，等实现后降低压缩比可提高性能

[imasmallbird]

[Quote=引用 7 楼 的回复:]

比如一个字符串的长度为300，在进行压缩后会变为150或更少
——规模太小了，压缩时生成的头信息都会消耗不少空间
》表中几十亿的数据，能省一点都会影响到吞吐，所以要尽可能的改少存储
试了ZIP压缩不太理想，使用BASE64反而会增大，3DES的方式也不太好
——BASE64根本就不是压缩，必然要增大；3DES是加密，不增大就算你运气很好了。
》是的，只是进行了尝试，可以尝试一下它们的组合
由于需要将一个较大的参数值 进行数据库存储
——如果可以，给出该参数值的形式，也许可以通过研究该参数值的……

[/Quote]
多谢～

[imasmallbird]

[Quote=引用 8 楼 的回复:]

zip压缩是大于150吗
》只是打个比方，压缩的程度一定和数据的内容有关，不一定大于150
不是很确定，可能还真的得看被压缩对象的内容而定
比如用16进制字符串代替2进制字符串存储，就更省空间
进制差越大，压缩率越高
可能这也是压缩的其中一种方法吧
[/Quote]

现在正在看一看有关于7-zip的压缩方式lzma～

[MiceRice]

直接借助现成的压缩技术真的意义很小，因为你的规模太小了。如果不能有效扩大规模，头信息的开销太不值得了。

举例来说，假设你的数据内容都是 字母数字：
◎ 那么首先压缩算法会先根据内容生成压缩字典，那么这个字典可能就要占用大约100～200字节的信息。接下来300字节的正文如果按20%压缩比的话，可以压缩成60字节。最后的总规模就是160～260。你看，不是压缩比不够好，而是字典浪费太多空间了。导致实际收益才 10% ～ 20%
◎ 如果你的规模是 300MB，那么字典大小仍然是100～200字节，压缩比20%，总规模就是60MB+200字节，这个实际收益多高！基本上就是 80% 收益。

所以，我认为用通用压缩算法不能取得好的结果。我建议两种路线：
1、固定压缩算法，也就是研究你值的特征，然后直接手工生成压缩字典并固化在程序中，也就是每个字段的值里面不再保存这100～200字节的字典内容了；压缩和解压时都必须使用该唯一字典；
2、如果有条件的话，采用“列式数据库”，启用数据库字段级压缩，能得到很好的收益，因为这个相当于数据库会针对该字段生成所有数据行所公用的压缩字典。