关于替换dc_encode, dc_decode

[Marlon Yao]

Hi, Davis

beansdb默认的key压缩算法可能不太适合于我们网站，如果要替换的话，据我这两天看源代码的结论，应当只需要替换这两个函数就行了，是吗？另外看起来，数据和hint文件记录的是原始key，就其说，我可以随便什么时候替换这两个函数并重新编译beansdb就可以了， 只要dc_decode(dc_encode(key)) == key，就不会任何影响？

--
Marlon Yao

[Davies Liu]

是的，随时可以改变，

你们打算怎么做？

2012/11/27 Marlon Yao <yaol...@gmail.com>

--
 - Davies

[Marlon Yao]

多谢！

基本思想是应用层做一些配合，比如凡是被替换的部分都会以_开头，对于被替换的内容也有一些硬性规定，比如只能是32位/64位整数，8位/16位连续16进制数（历史遗留图片会对url作md5作为key），这样空间利用率会高一些，并且dc_encode, de_decode实现也会简单些。由于改变key成本很高，得预先作一些规划，所以就问了这个问题。既然什么时候都可以，倒不急，反正现在图片量不是太大。

我没怎么看dc_encode的代码，我测了一下，它不会对 "312.189/deal/a389189c493df234.jpg" 进行压缩，其中312.189表示缩略图的长宽，但是会对"deal/a389189c493df234.jpg"进行压缩，觉得比较诡异。如果我在应用层配合做一些改变，将被替换的部分以_开头，原来的url可以写成:

"312.189/deal/_a389189c493df234.jpg"，这样我可以更加精确的指定哪部分被替换，比如url: "/deal/_47245_78.jpg"替换两个数字，这样效率更高，坏处是和应用绑定在一起了，需要事先规划。

[Davies Liu]

目前可是识别10进制和16进制的数字为可变参数，这部分有一些参数根据根据自己情况进行微调，比如最少几个数字进行参数化等

一个key里面可变部分最好只有一个，否则转换后仍然比较长，压缩效果有限。

2012/11/27 Marlon Yao <yaol...@gmail.com>

--
 - Davies