是否有必要重新规划hash和后面zset功能的key的组织方式

[rchunping]

不知道写在哪里，只好先写在issue里面了

首先leveldb的核心是
1）key->value，以及
2）基于key的排序

最近在实现key遍历的时候发现之前的ds_h**系列功能key的组织方式不太完善。

目前ds_h* 功能的实现方式是 用key_field 这样的方式存储在leveldb中的，(暂且叫hashkey)
这样在进行普通key遍历的时候，会碰到key_field这样的hashkey，需要跳过，反过来，在进行hashkey遍历的时候也会碰到普通的key，需要跳过。

以后要实现的set(集合)或者zset功能，本质上也只能利用leveldb的2个特性，必然也要设计和维护一组内部存储用的zsetkey

普通key,hashkey,zsetkey,... 在leveldb看来都是同等的，处于一个统一的排序状态下，而zset的某些功能必然少不了key遍历。

我的设想是，能不能在hashkey和以后的zsetkey之前带上特殊前缀，
比如 hashkey前面都带* zsetkey前面都带# ，以便让这几组不同功能的key处于各自连续的排序状态下。

主要目的还是为了在大规模数据下有更好的性能表现。

以上请项目负责人定夺，趁现在ds_h* 相关功能使用人数还不多的时候尽早规划好。

[rchunping]

或者也可以使用一些不可见字符

#define KEY_PREFIX_HASH 0xFE //定义hashkey前缀字符
#define KEY_PREFIX_ZSET 0xFD //定义zsetkey前缀字符
#define MEMBER_PREFIX 0x01 //key和member之间的分割字符

[rchunping]

没人回我就这么干了啊，急等着用

大不了以后做成配置文件自定义 -_-

[qiye]

key*field 这个是个标识。 跟前缀标识也差不多意思
zset 可以 key+field 用+来标识。 也可以的

[rchunping]

没有前缀标示的话

只能靠判断中后位置的 * 和 + 来判断类型，没法知道某一类型的key的大致范围，导致在某一类型中进行key遍历的时候会有太多无效计算，尤其是全局遍历的时候。

[miketang84]

同意这个观点。

2013/1/30 rchunping [email protected]

没有前缀标示的话

只能靠判断中后位置的 * 和 +
来判断类型，没法知道某一类型的key的大致范围，导致在某一类型中进行key遍历的时候会有太多无效计算，尤其是全局遍历的时候。

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/21#issuecomment-12877236.

Nothing is impossible.

[rchunping]

hash相关的都实现了 ，代码已经离线发给七夜
差ds_hincrbyfloat没实现，这个貌似不是很必要