meta version conflict in heavy set/delete workload

[dongdongwcpp]

meta version will conflict in heavy set/delete workload,the code was:
https://github.com/OpenAtomFoundation/pika/blob/unstable/src/blackwidow/src/base_meta_value_format.h#L31

  int32_t UpdateVersion() {
    int64_t unix_time;
    rocksdb::Env::Default()->GetCurrentTime(&unix_time);
    if (version_ >= static_cast<int32_t>(unix_time)) {
      version_++; // step1: borrowing the future version
    } else {
       //step2: next second, the new gen version will conflict with previous one
      version_ = static_cast<int32_t>(unix_time);
    }
    SetVersionToValue();
    return version_;
  }

Minimal reproduce step

just set and delete and set a hash with five fields;

how to fix

I will submit a pr to fix this

[AlexStocks]

good job.

[AlexStocks]

@Mixficsol

[AlexStocks]

blackwidow 现在是 storage ，那里面 ttl version 都是 4 个字节，这 ttl 四个字节也不合理，到 2038 年也会超时，后面也得改进。

[Mixficsol]

blackwidow 现在是 storage ，那里面 ttl version 都是 4 个字节，这 ttl 四个字节也不合理，到 2038 年也会超时，后面也得改进。

好的

[AlexStocks]

blackwidow 现在是 storage ，那里面 ttl version 都是 4 个字节，这 ttl 四个字节也不合理，到 2038 年也会超时，后面也得改进。

好的

相关 issue #1099

社区已经给出一个解决方案 https://github.com/OpenAtomFoundation/pika/pull/1413/files

你先学习下， 这个是限制下时间长度，不要溢出。也不能算作最终的解决方法。

尽量在不改动字段长度的情况下，解决这个问题。

保持对老版本数据格式的兼容度很重要。

[AlexStocks]

大概有如下解决方案：

1 一劳永逸的把 ttl 和 version 改为 int64，但是怎么 “保持对老版本数据格式的兼容” 是个难题；

2 我在想这么一种解决方案，在不改动 version 和 ttl 目前长度是 4B 的情况下，pika 内置一个特殊 kv {key: “pika_start_up_time", value: "pika 第一次启动时间”}

不管 pika 重启多少次，都保持第一次启动的值。假设是 20 0000 0000

如果当前 ttl 和 version 值小于 20 0000 0000，显然其正确值应该是 ttl + max_int32 和 version + max_int32；如果大于 20 0000 0000 ，那就没问题。在物理时间长度来说，可以保持 50 年内没啥差错

3 通过 Pika 版本号来解决这个问题。那就在 pika 数据中内置一个 {key: “pika_start_up_version", value: "pika 第一次实例的版本号“}，毕竟使用当前数据的 pika 实例可能不是这个数据的第一个生产者。

[wanghenshui]

大概有如下解决方案：

1 一劳永逸的把 ttl 和 version 改为 int64，但是怎么 “保持对老版本数据格式的兼容” 是个难题；

2 我在想这么一种解决方案，在不改动 version 和 ttl 目前长度是 4B 的情况下，pika 内置一个特殊 kv {key: “pika_start_up_time", value: "pika 第一次启动时间”}

不管 pika 重启多少次，都保持第一次启动的值。假设是 20 0000 0000

如果当前 ttl 和 version 值小于 20 0000 0000，显然其正确值应该是 ttl + max_int32 和 version + max_int32；如果大于 20 0000 0000 ，那就没问题。在物理时间长度来说，可以保持 50 年内没啥差错

3 通过 Pika 版本号来解决这个问题。那就在 pika 数据中内置一个 {key: “pika_start_up_version", value: "pika 第一次实例的版本号“}，毕竟使用当前数据的 pika 实例可能不是这个数据的第一个生产者。

首先这个主题内的这个问题和你版本号是4 是8没关系，本质是时间戳不唯一，用户一边写一边删，就会有看见旧数据的问题

dongdongwcpp 反馈重放log可能存在一边写一边删的场景

其次时间戳长度切换，value = 实际用户value + ttl 4B + version 4B ，扣掉用户value剩下的长度做个判断 等于8就是旧的，新的value改ttl为8，这样就区分开了

[AlexStocks]

        * 0617 henshui：rocksdb不好处理该问题，等raft成熟后再解决
            * 子问题：4字节时间戳 src/storage 数据格式升级，可能对性能有影响
            * henshui：metavalue 判断下
            * 0624显荣
            * 0701 显荣设计下方案，protobuf设计改造下。
            * 0708 显荣设计方案中

[yaoyinnan]

显荣：暂时搁置