this repo has no description
Commit path
+38
-3
+38
-3
internals/overview.md
+38
-3
internals/overview.md
···
39
39
The client chooses a `BeginBuffer` server and sends a `get_read_version()` request.
40
40
41
41
The `BeginBuffer` batches a set of requests before sending its own request for a read version to the `Sequencer`.
42
-
The `Sequencer` replies with a strictly monotonic read version guaranteed to be higher than any committed version
42
+
The `Sequencer` replies with a read version guaranteed to be greater than or equal to any committed version
43
43
(this ensures strict serializability of transactions).
44
44
Additionally, the `BeginBuffer` sends requests to the fellow `TLog` servers from its generation asking whether any of them have been locked,
45
45
which would indicate a recovery taking place.
···
49
49
50
50
Before performing a read, the client needs to ask a `CommitBuffer` for information about the relevant shard and where it's stored.
51
51
This shard information can be aggressively cached as shards are moved rarely.
52
-
If a Storage server turns out to no longer be serving the requested shard (i.e. the cache is stale),
52
+
If a `Storage` server turns out to no longer be serving the requested shard (i.e. the cache is stale),
53
53
the client will ask the `CommitBuffer` for updated shard information.
54
54
55
55
To perform reads, the client sends read requests to `Storage` servers.
···
57
57
which is needed to prevent reads of uncommitted data following a recovery.
58
58
Reads are effectively performed against a consistent snapshot of the database at the read version.
59
59
60
-
Reads which cross shard boundaries are split and sent to their respective Storage servers.
60
+
Reads which cross shard boundaries are split and sent to their respective `Storage` servers.
61
61
The results are joined.
62
62
63
63
When reads are performed, the keys or key ranges read are tracked interally as read conflicts.
···
71
71
This may seem redundant (we already have the writes themselves),
72
72
but in some cases advanced clients may choose to manipulate the write conflicts independently to improve performance or selectively weaken consistency guarantees.
73
73
However, such manipulation is dangerous and not generally recommended.
74
+
75
+
## Committing
76
+
77
+
To commit a transaction, the client gathers up the read version, read conflicts, write conflicts, and writes and sends them to a `CommitBuffer`.
78
+
79
+
The `CommitBuffer` batches committed transactions.
80
+
Once a batch is ready, it first requests a commit version from the `Sequencer`.
81
+
The `Sequencer` replies with a commit version which is guaranteed to be greater than any previous committed version (strictly monotonic).
82
+
83
+
The `CommitBuffer` then sends the transactions' read versions, commit versions, read conflicts, and write conflicts to the `Resolver`.
84
+
The `Resolver` performs concurrency control;
85
+
specifically, for each transaction it checks whether the keys and ranges read by that transaction at its read version are unchanged at its commit version.
86
+
If any of the data read by the transaction was changed (by another transaction) during its execution, that transaction is rejected.
87
+
This ensure strict serializability of transactions.
88
+
89
+
Mutations from the surviving transactions are then combined into a single batch,
90
+
as from this point on the distinction between transactions within a batch no longer exists.
91
+
The transactions are then sliced:
92
+
the CommitBuffer consults its shard map (which is always perfectly consistent)
93
+
and determines which `Storage` teams are responsible for each mutation.
94
+
Each mutation is tagged with the `Storage` teams it's destined for,
95
+
and the mutations are then grouped together by their corresponding `TLog` teams.
96
+
97
+
A commit request containing the relevant tagged mutations and the commit version is sent to each `TLog` server.
98
+
An empty request is still sent to a `TLog` even if it has no mutations, as it still needs to learn of the committed version.
99
+
The requests are sent in parallel.
100
+
101
+
Once *every* TLog has returned,
102
+
the `CommitBuffer` accordingly returns to all of the clients in the batch.
103
+
104
+
## Storage peeks logs
105
+
106
+
Outside of the commit path,
107
+
`Storage` servers "peek" logs for their team by sending peek requests to their corresponding `TLog` servers.
108
+
The `Storage` servers receive logs in perfect commit version order and apply them to their storage engines so that they can serve reads.