distributed/talent-plan-tinykv
1
0
Fork 0
mirror of https://github.com/talent-plan/tinykv.git synced 2024-12-26 12:50:11 +08:00
Code Issues Packages Projects Releases Wiki Activity

fix doc timestamp bug (#210)

Browse Source 
According to Percolator paper page 5, I found that `default` CF should append to the store with *start* timestamp  in `KvPrewrite` ,and  `write` CF with *commit* timestamp in `KvCommit`, which should be swapped.

Co-authored-by: Nick Cameron <nrc@ncameron.org>
This commit is contained in:
miamiaoxyz 2020-06-29 05:13:25 +08:00 committed by GitHub
parent cb91131143
commit 0a3cb4d128
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc/project4-Transaction.md
View File

@ -34,7 +34,7 @@ The raw API you implemented in earlier projects maps user keys and values direct
Implementing MVCC means representing the transactional API using a simple key/value API. Rather than store one value per key, TinyKV stores every version of a value for each key. For example, if a key has value `10`, then gets set to `20`, TinyKV will store both values (`10` and `20`) along with timestamps for when they are valid.
TinyKV uses three column families (CFs): `default` to hold user values, `lock` to store locks, and `write` to record changes. The `lock` CF is accessed using the user key; it stores a serialized `Lock` data structure (defined in [lock.go](/kv/transaction/mvcc/lock.go)). The `default` CF is accessed using the user key and the *commit* timestamp of the transaction in which it was written; it stores the user value only. The `write` CF is accessed using the user key and the *start* timestamp of the transaction in which it was written; it stores a `Write` data structure (defined in [write.go](/kv/transaction/mvcc/write.go)).
TinyKV uses three column families (CFs): `default` to hold user values, `lock` to store locks, and `write` to record changes. The `lock` CF is accessed using the user key; it stores a serialized `Lock` data structure (defined in [lock.go](/kv/transaction/mvcc/lock.go)). The `default` CF is accessed using the user key and the *start* timestamp of the transaction in which it was written; it stores the user value only. The `write` CF is accessed using the user key and the *commit* timestamp of the transaction in which it was written; it stores a `Write` data structure (defined in [write.go](/kv/transaction/mvcc/write.go)).
A user key and timestamp are combined into an *encoded key*. Keys are encoded in such a way that an ascending order of encoded keys orders first by user key (ascending), then by timestamp (descending). This ensures that iterating over encoded keys will give the most recent version first. Helper functions for encoding and decoding keys are defined in [transaction.go](/kv/transaction/mvcc/transaction.go).