Rename Solution

[longfar-ncy]

两种方法：

• 删掉老key数据，写入新key数据。
  • 优点：简单，不需要更改存储层结构；
  • 缺点：时间复杂度高，与 redis O(1) 复杂度差距大
• 类似软连接的方式。新 key 的 value 指向老 key，后台异步将老 key 数据挪到新 key 中。
  • 优点：rename 命令时间复杂度降低，只需要写一个简单的 kv；
  • 缺点：实现复杂，需要考虑的细节比较多，比如老数据没删之前，如果访问老 key 如何处理

[chuntaojun]

如果全部推倒重来，是不是可以考虑引入中间 key ？是不是更好解决？

[dingxiaoshuai123]

删除操作应该只是一个逻辑删除，真正的删除动作会异步进行。另外该命令也并非热点命令，目前我认为删掉老 Key 并写入新 Key 性价比更高一点。当然如果有更好实现方法也可以试试

[dobet]

删除老key，写入新key主要是会在bigkey的时候存在性能问题，其他时候都还好。

如果要重构的话，不知道rocksdb能否支持key，ptr的这种存储方式，这样保存的就是某个值的地址这种。

[dobet]

想到了另外一种解决方案，data存储时，不使用key，而是使用一个唯一的uuid，key存储时，增加一个data的uuid，这样在rename时， 就只需要写一个新key就好了，也就避免了对于data的重写。
但是这样会有个问题，可能会出现不同key之间出现相同uuid的data。

[AlexStocks]

你这个 “另外一种解决方案” 就不用考虑了，这改动属于大改动了