由于需要将一个较大的参数值 进行数据库存储,
而存储后在进行读取时会由于该表的存储量很大,这个值会导致加大IO我们在JAVA中能否使用一个比较高压缩的方式或进行编码、加密也可,或者某种手段将这个字符串的长度进行压缩
比如一个字符串的长度为300,在进行压缩后会变为150或更少试了ZIP压缩不太理想,使用BASE64反而会增大,3DES的方式也不太好想请教各位,有关这方面可用的技巧或思路!
而存储后在进行读取时会由于该表的存储量很大,这个值会导致加大IO我们在JAVA中能否使用一个比较高压缩的方式或进行编码、加密也可,或者某种手段将这个字符串的长度进行压缩
比如一个字符串的长度为300,在进行压缩后会变为150或更少试了ZIP压缩不太理想,使用BASE64反而会增大,3DES的方式也不太好想请教各位,有关这方面可用的技巧或思路!
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
中国中国中中国中国中中国中国中中国中国中中国...
——规模太小了,压缩时生成的头信息都会消耗不少空间试了ZIP压缩不太理想,使用BASE64反而会增大,3DES的方式也不太好
——BASE64根本就不是压缩,必然要增大;3DES是加密,不增大就算你运气很好了。由于需要将一个较大的参数值 进行数据库存储
——如果可以,给出该参数值的形式,也许可以通过研究该参数值的规律来进行压缩。不过说句心里话,才300字节,不要纠结了,这个IO简直可以忽略不计,实在不值得去压缩。。如果你很希望保证数据块内尽可能多存放数据行以提升list查询性能的话,可以将值用扩展表存储。
比如用16进制字符串代替2进制字符串存储,就更省空间
进制差越大,压缩率越高
可能这也是压缩的其中一种方法吧
现在正在看一看有关于7-zip的压缩方式lzma~
◎ 那么首先压缩算法会先根据内容生成压缩字典,那么这个字典可能就要占用大约100~200字节的信息。接下来300字节的正文如果按20%压缩比的话,可以压缩成60字节。最后的总规模就是160~260。你看,不是压缩比不够好,而是字典浪费太多空间了。导致实际收益才 10% ~ 20%
◎ 如果你的规模是 300MB,那么字典大小仍然是100~200字节,压缩比20%,总规模就是60MB+200字节,这个实际收益多高!基本上就是 80% 收益。所以,我认为用通用压缩算法不能取得好的结果。我建议两种路线:
1、固定压缩算法,也就是研究你值的特征,然后直接手工生成压缩字典并固化在程序中,也就是每个字段的值里面不再保存这100~200字节的字典内容了;压缩和解压时都必须使用该唯一字典;
2、如果有条件的话,采用“列式数据库”,启用数据库字段级压缩,能得到很好的收益,因为这个相当于数据库会针对该字段生成所有数据行所公用的压缩字典。
>>恩,这个正在尝试中,但还需要测试入库前压缩与取出后解压所带来的性能消耗,是否能满足要求
否则压缩的方式进行放弃。
2、如果有条件的话,采用“列式数据库”,启用数据库字段级压缩,能得到很好的收益,因为这个相当于数据库会针对该字段生成所有数据行所公用的压缩字典。
>>这点也进行了考虑,也考虑过行级的compress,但是这个表的几十亿数据会频繁的删除与插入,会导致数据库也要进行反复的压缩与解压缩,与DBA沟通后放弃了