feat(hash): Support hash field expiration #2402

jjz921024 · 2024-07-11T12:26:09Z

This pr want to close #2269

Encoding
To implement hash expiration by field level, we encode the expiration time into the first 8 bytes of value.
For example:
```
                     +-------------------------+
key|version|field => | expire (8 byte) | value |
                     +-------------------------+
```
And we use the second bit of the flags in metadata to indicate whether encode the expiration into value.
If all the fields in the hash have no encode expiration time, the flags will be 1 0 0 0 | 0 0 1 0.
If any field in the hash is encoded into the expiration time, the flags will be 1 1 0 0 | 0 0 1 0.
Flags conversion
For the HEXPIRE command, it will set an expiration on one or more fields.
If we execute hexpire command on a hash key that has not been set to expire, this will set the secode bit of flags and encode expiration for all fields (fields that not appear in the command will be set to 0)
Add commands
According to https://redis.io/docs/latest/commands add a series of related commands:
- HEXPIRE , HPEXPIRE , HEXPIREAT , HPEXPIREAT
- HEXPIRETIME , HPEXPIRETIME , HTTL , HPTTL
- HPERSIST

PragmaTwice · 2024-07-11T12:40:35Z

And we use the second bit of the flags in metadata to indicate whether encode the expiration into value.

As we specified in https://kvrocks.apache.org/community/data-structure-on-rocksdb#encoding-version-and-data-type, the first and second (and maybe more bits from the MSB) of flags is used to represent the "encoding version". flags 1 1 0 0 | 0 0 1 0 indicates that the encoding version is 3.

So it should not be used for field expiration. (Also, not all data types need the field expiration feature.)

Instead, you can add a new enum value of data type, or add a new field in the metadata of hash.

git-hulk · 2024-07-11T14:59:33Z

@jjz921024 Thanks for your contributions. As @PragmaTwice mentioned, we cannot put the expired flag in the version field and we also need to adopt the SubkeyFilter in compact_filter.cc to recycle expired subkeys.

jjz921024 · 2024-07-12T08:33:08Z

we also need to adopt the SubkeyFilter in compact_filter.cc to recycle expired subkeys.

@git-hulk Thanks for you reminding. I have added this feature in latest commit.

About encoding, my previous thought was to use each bit for a different meaning, rather than as an incremental version.
For example:

For all type, the first bit indicate use 64bit or 32bit encoding
For hash type, the second bit of the flags to indicate whether encode the expiration into value (not affect for other types)

I see this issues #2292. Maybe we should finish it first?

PragmaTwice · 2024-07-12T10:59:26Z

For all type, the first bit indicate use 64bit or 32bit encoding
For hash type, the second bit of the flags to indicate whether encode the expiration into value (not affect for other types)

No. It's too ad hoc and will introduce additional maintanance effort. (the encoding of HASH will be inconsistent with other types, which brings huge understanding, maintanance cost and additional code logic)

And also, it breaks our whole design of "encoding version", e.g. HASH cannot have encoding version larger than 1.

You can consider these options, as I mentioned before.

Instead, you can add a new enum value of data type, or add a new field in the metadata of hash.

-1 for this change if no further commits.

jjz921024 · 2024-07-12T14:44:18Z

@PragmaTwice Got it, i will change it.

src/commands/cmd_hash.cc

src/types/redis_hash.cc

src/storage/redis_db.cc

src/storage/redis_metadata.h

src/storage/redis_db.cc

torwig · 2024-07-14T09:53:42Z

@ jjz921024 Please let me know if I'm wrong. If the data structure contains at least 1 key that can be expired, we set a special bit to true and later check it.

src/types/redis_hash.cc

src/types/redis_hash.h

jjz921024 · 2024-07-15T14:28:02Z

@ jjz921024 Please let me know if I'm wrong. If the data structure contains at least 1 key that can be expired, we set a special bit to true and later check it.

Yes. Due to the expiration time is encoded in the field, the time complexity of some commands changes from O(1) to O(n), such as type and hlen. If we can check this flag before execution, then the some commands complexity will remains the same when
this feature is not used

jjz921024 · 2024-07-16T02:35:36Z

For all type, the first bit indicate use 64bit or 32bit encoding
For hash type, the second bit of the flags to indicate whether encode the expiration into value (not affect for other types)

No. It's too ad hoc and will introduce additional maintanance effort. (the encoding of HASH will be inconsistent with other types, which brings huge understanding, maintanance cost and additional code logic)

And also, it breaks our whole design of "encoding version", e.g. HASH cannot have encoding version larger than 1.

You can consider these options, as I mentioned before.

Instead, you can add a new enum value of data type, or add a new field in the metadata of hash.

-1 for this change if no further commits.

@PragmaTwice Hi, I fix it about encoding version. and add a new field in the metadata of hash to indicate whether the expiration time of field is encoded. please review. thank

src/storage/redis_metadata.h

src/storage/redis_db.cc

src/storage/redis_metadata.h

src/storage/redis_metadata.cc

src/types/redis_hash.cc

src/commands/cmd_hash.cc

src/types/redis_hash.cc

src/storage/redis_metadata.h

src/types/redis_hash.h

src/storage/compact_filter.cc

src/types/redis_hash.cc

jjz921024 · 2024-07-19T02:35:36Z

@git-hulk Hi, I had renamed the decodeFieldAndTTL to decodeExpireFromValue, encodeFieldAndTTL to encodeExpireToValue. And rewrite the IsFieldExpired() to make it clearer. please review.

src/config/config.h

PragmaTwice · 2024-08-11T10:09:06Z

Seems we need to solve the conflict first?

jjz921024 · 2024-08-12T08:38:14Z

Seems we need to solve the conflict first?

rebase this pr on the latest commit of unstable branch.

jjz921024 · 2024-08-13T01:28:45Z

Seems there are failure in CI. I will check it up

src/storage/redis_metadata.cc

sonarqubecloud · 2024-08-13T09:25:52Z

Quality Gate passed

Issues
40 New issues
0 Accepted issues

Measures
0 Security Hotspots
60.9% Coverage on New Code
4.8% Duplication on New Code

See analysis details on SonarCloud

git-hulk · 2024-08-15T07:41:23Z

@jjz921024 I will take another pass in a few days, thanks for your contribution.

ltagliamonte · 2024-12-18T16:49:56Z

@jjz921024 @git-hulk @PragmaTwice I'm looking forward to this feature, is there anything I can help with to help here?

PragmaTwice · 2024-12-19T04:08:21Z

@jjz921024 @git-hulk @PragmaTwice I'm looking forward to this feature, is there anything I can help with to help here?

Thank you for your input. I'll take a look at this weekend.

jjz921024 · 2024-12-20T10:26:59Z

rebase this branch on the HEAD

PragmaTwice · 2024-12-21T04:35:35Z

src/storage/redis_db.cc

+  // if type is hash, we still need to check if the all of fields expired.
+  if (metadata->Type() == kRedisHash) {
+    HashMetadata hash_metadata(false);
+    s = hash_metadata.Decode(*raw_value);
+    if (!s.ok()) return s;
+    redis::Hash hash_db(storage_, namespace_);
+    if (!hash_db.ExistValidField(ctx, ns_key, hash_metadata)) {
+      return rocksdb::Status::NotFound("no element found");
+    }
+  }


This will make almost all operation of HASH inefficient, we should consider how to do this in another way.

It requires at least O(N) IO accesses for every HASH operation. And if you think about it: not all operations require to check that all elements are expired before the actual operation.

It seems that only hset and hmset does not need to check the expire of the field？But we don't know the the command type in the GetMetadata()

aleksraiden · 2025-01-09T15:41:24Z

Awesome work, @jjz921024

Maybe we need some benchmark - before include this feature and after? Тo test the impact of new logic on basic HSET's command (and prevent or minimize it)?

jjz921024 · 2025-01-11T11:40:54Z

@git-hulk @ltagliamonte Hi, I don't know how to commit code on the new pr #2717 , so I just keep working here.

For the first point you mentioned on #2717 (comment), I had finish. please review.

And the second point, do you mean that the ExistValidField() function should contain the following code? This code is repeated many times. I think the ExistValidField() is a dedicated function to check if it has any valid fields.

HashMetadata hash_metadata(false);
s = hash_metadata.Decode(rocksdb::Slice(pin_values[i].data(), pin_values[i].size()));
if (!s.ok()) continue;
redis::Hash hash_db(storage_, namespace_);

jjz921024 · 2025-01-11T11:47:08Z

Awesome work, @jjz921024

Maybe we need some benchmark - before include this feature and after? Тo test the impact of new logic on basic HSET's command (and prevent or minimize it)?

@aleksraiden Hi, After optimization of 473db0c, the expire fields should have no effect on HSET command. Should we add some bench test for read command of hash type (like hgetall)?

aleksraiden · 2025-01-11T12:12:27Z

Awesome work, @jjz921024
Maybe we need some benchmark - before include this feature and after? Тo test the impact of new logic on basic HSET's command (and prevent or minimize it)?

@aleksraiden Hi, After optimization of 473db0c, the expire fields should have no effect on HSET command. Should we add some bench test for read command of hash type (like hgetall)?

I have a test by standard redis-bench yesterday (before your commit) - and at quick look is there NO any impact to performance. But standard test looks only to GET/HSET as I see.

Great job!

git-hulk · 2025-01-11T12:49:58Z

@git-hulk @ltagliamonte Hi, I don't know how to commit code on the new pr #2717 , so I just keep working here.

@jjz921024 Perhaps you can suggest your change in the new PR due to this PR is overload for discussing. What do you think?

I have a test by standard redis-bench yesterday (before your commit) - and at quick look is there NO any impact to performance. But standard test looks only to GET/HSET as I see.

@aleksraiden Great!

jjz921024 · 2025-01-12T11:49:21Z

Perhaps you can suggest your change in the new PR due to this PR is overload for discussing. What do you think?

I'm pleasure to do it and I will try my best to finish this feature if i can.

git-hulk · 2025-01-12T11:53:36Z

I'm pleasure to do it and I will try my best to finish this feature if i can.

@jjz921024 Thank you! We will take care of PR #2717 to keep the original commit information while merging.

jjz921024 force-pushed the hfe branch from c16d864 to 7854e04 Compare July 11, 2024 12:31

jjz921024 changed the title ~~Support hash field expiration~~ feat(hash): Support hash field expiration Jul 11, 2024

jjz921024 marked this pull request as ready for review July 11, 2024 12:36

jjz921024 force-pushed the hfe branch from 7854e04 to dfdb385 Compare July 12, 2024 08:33