ltagliamonte-dd commented on PR #3269:
URL: https://github.com/apache/kvrocks/pull/3269#issuecomment-3715621178
@dashjay I understand the motivation behind encoding the TTL in the key, but
I believe it introduces significant performance regressions for several reasons:
- Breaks Point Lookups ($O(1)$): If the TTL is part of the key, the exact
key is no longer known. To find a field, we would have to use an iterator to
scan a range of keys rather than a direct Get. This turns every read into a
much more expensive operation.
- Expensive TTL Updates: In RocksDB, keys are immutable. To update only the
TTL, we would be forced to Delete the old key and Put a new one. This doubles
the write amplification and creates unnecessary tombstones.
- Key Bloat: Sub-keys (fields) are already repeated for every entry. Adding
an 8-byte timestamp to every key significantly increases the index size and
memory pressure on the Block Cache/Memtables.
- Data Consistency: It becomes harder to ensure atomicity. If a TTL update
fails or is interrupted, you could potentially end up with two versions of the
same field (the old TTL and the new TTL) existing simultaneously in the
keyspace.
@git-hulk @PragmaTwice to fix the ambiguity what about adding a new cmd
option to HSET/HMSET, etc.. that sets an `ExHash` flag in the key metadata.
**The flag will work ONLY on new hash keys**.
When set all the fields value will have TTL encoded: [0x01] [Timestamp]
[Value]
The only downside of this is that HEXPIRE will work only on new hashes and
not be backward compatible with existing hash keys.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
