Conversation
Signed-off-by: Jay Lee <BusyJayLee@gmail.com>
Signed-off-by: Jay Lee <BusyJayLee@gmail.com>
| - key set the original key without any encoding or version | ||
| - value set the same value in write cf but include the corresponding version. | ||
|
|
||
| For example, insert k1 with version v0 and value dummy will insert two keys |
There was a problem hiding this comment.
This will double the write amplification, not only by size but also by key value pairs.
There was a problem hiding this comment.
Yes, it's addressed in the drawback section.
|
|
||
| Because all existing cfs are updated just as before, so there are no major compatibility issues. | ||
|
|
||
| But using latest cf should be triggered explicitly by client. Client should ensure only when it updates all keys with latest cf will it ask TiKV to query using latest cf. |
There was a problem hiding this comment.
It is a bit of complicated.
There was a problem hiding this comment.
Usually it won't as the client already needs to manage different ranges, just like table in TiDB or key space.
|
|
||
| ## Alternatives | ||
|
|
||
| unistore separates the latest version and other versions by adjust file format. So when flushing or compacting, it will make latest versions key be the first part, and the rest in the second part. This approach doesn't have write overhead, but is not backward compatible in TiKV. |
There was a problem hiding this comment.
How about create a history cf to store as many history version as it can, the write cf store the latest several versions, and background thread like GC thread move existed history versions to history cf.
For point get, using RocksDB's user timestamp feature to get the latest version can see, this also can prevent creating iterator.
There was a problem hiding this comment.
There is no compatibility issue for this solution.
There was a problem hiding this comment.
Compaction filter is not reliable, we have seen issue caused by not having compaction in time like tikv/tikv#12729. This proposal doesn't depend on the user timestamp, which is not used in production yet. And can be landed table by table instead of the whole cluster, have less impact on existing code. And this proposal should have better scan performance than relying on compaction filter.
There was a problem hiding this comment.
Added as an alternative with more argument.
There was a problem hiding this comment.
Using history cf doesn't need the compaction filter, gc just check the history cf sst file's max ts to determine wether to drop the whole sst file.
There was a problem hiding this comment.
Compaction filter is not used for dropping history sst, but for moving data from write cf to history cf.
There was a problem hiding this comment.
Compaction filter is not necessary, I think version statistics-based GC is much better.
Signed-off-by: Jay Lee <BusyJayLee@gmail.com>
|
|
||
| As explained, the reason why seek is necessary is because TiKV has no idea what versions are available. Otherwise it can just use `get` to query the specific key, which is a lot cheaper. | ||
|
|
||
| ## Detailed design |
There was a problem hiding this comment.
How about lightning, cdc, br, tiflash's compatibility?
There was a problem hiding this comment.
They are not part of TiKV. I would like to talk about them in another doc.
|
|
||
| TiKV doesn't need to know all existing versions of keys. In fact, most of the time, v0 is larger than any existing versions of keys in TiKV if there is more read than write. So it should be enough to just let TiKV knows the latest version of all keys. | ||
|
|
||
| The RFC propose to add a new cf named "latest". When a key is inserted using transaction API, it should update write cf (and default cf) as current does. In addition, it also insert a key to latest cf with |
There was a problem hiding this comment.
this double write may also double the total disk size in some scenarios.
There was a problem hiding this comment.
Maybe for those new table(new range) in the existing cluster and the new created cluster we can use the new mechanism(only write latest cf, move the old version to write cf only when the older version existed) is a better choice?
There was a problem hiding this comment.
It would work, though it loses the ability to upgrade existing table to new format online.
There was a problem hiding this comment.
Or we can introduce 3 formats. One is the original one, second is double write, third is move on update. They can be upgraded online one by one. For new tables, third format is used by default.
Signed-off-by: Jay Lee <BusyJayLee@gmail.com>
|
Although I updated the RFC to write latest CF first, and then move keys between CFs, I suggest to always double write in POC as it has less compatibility issues. |
| For example, supposing there is no key in latest cf. Inserting k1 with version v0 and value foo will insert one key: | ||
| - to latest cf, k1 -> (foo, v0 and other meta) | ||
|
|
||
| Inserting v1 again with version v1 and value bar will insert two keys: |
There was a problem hiding this comment.
| Inserting v1 again with version v1 and value bar will insert two keys: | |
| Inserting k1 again with version v1 and value bar will insert two keys: |
Is it k1?
ti-chi-bot
added
needs-cherry-pick-release-6.5
and removed
needs-cherry-pick-release-6.5
labels
4 participants
Add a cf (column family in RocksDB) named "latest" to store the latest version of keys in MVCC.