SSDB_KEY_LEN_MAX 设置更大，会影响性能吗

[weizetao]

hi ideawu 如果把SSDB_KEY_LEN_MAX 设置为 1K 或者 8K 使用zset有序集合，对查询效率会有影响吗？

[ideawu]

你好, 不能设置超过255, 因为内部是使用一个字节来表示key的长度.

[weizetao]

hi ideawu 我的场景是需要一个有序的消息集合，每条消息内容不止255个字节，score为消息序列号。 zset name key score SSDB_KEY_LEN_MAX限制了zset 的 name 和 key 的长度，尤其是name，内部使用了一个字节来存放，细看源代码中encode_zscore_key 是将key放到了最后，内部没有字节限制。 所以我单独增加了SSDB_SUB_KEY_LEN_MAX=8K，来单独限制zset的子键长度，实测没有问题。

if(name.size() > SSDB_KEY_LEN_MAX ){
    log_error("name too long!");
    return -1;
}
if(key.size() > SSDB_SUB_KEY_LEN_MAX){
    log_error("key too long!");
    return -1;
}

业务场景基本都是通过score 来操作，所以即使key比较大，也不会带来其它（hash）的额外开销，我这样理解是否OK？

[ideawu]

根据你的使用场景, 建议你 zset 存储 object_id => score, 然后在某个 hash 里存储 object_id => object, 这样, object 的长度可以达到 30M.

[weizetao]

在另一个关于SSDB_KEY_LEN_MAX是否可配置的issue里看到你也提过这个建议。 但这样的话每次查询都需要至少两次交互，这一点是我不太希望看到的； 不过我上述的改法确实有问题，leveldb的key太长对性能还是有影响的； 那只能花点时间实现一个类似 zhash 的结构，有序的hash，就能满足我的需求了

[weizetao]

@ideawu 根据一些调整，我实现了一个有序的nset，可完美解决如上问题，请参见pull #750

[ideawu]

如在 pull request 里的讨论, 此需求可以用 hash 来解决:

key = sprintf("%020d", seq);
hset(name, key, val);