-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TiKV Keyspace #97
Open
ystaticy
wants to merge
1
commit into
tikv:master
Choose a base branch
from
ystaticy:tikv_keyspace
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
TiKV Keyspace #97
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,91 @@ | ||
# Title | ||
|
||
Keyspace encode and metadata management | ||
|
||
## Summary | ||
|
||
We hope to store data of multiple applications in a TiKV cluster. | ||
A common solution is to add a prefix in front of the key to distinguish the data of multiple applications. | ||
So we introduce a new concept 'Keyspace' to describe the logical of the isolation with different business scenarios in a TiKV cluster. | ||
|
||
## Motivation | ||
|
||
We need support multiple applications store data in a TiKV cluster to cut the cost. Keyspace is what must be done to realize logical isolation. | ||
|
||
## Detailed design | ||
|
||
### Key Encode | ||
|
||
#### Key mode | ||
If ```Keyspace``` is enabled, the key will be starting with `keymode`, it stored in the first byte of the key: | ||
1. `m` or `t`: It's represent TiDB key. | ||
2. `x`: It represent TxnKV key. | ||
3. `r`: It represent RawKV key. | ||
|
||
#### Keyspace ID | ||
After first byte, it take 3 bytes to store `keyspaceID`, the default keyspaceID is `[0, 0, 0]`. | ||
The max keyspace id is 16777216; | ||
|
||
#### Client view | ||
|
||
To enhance readability, client is initialized with a keyspace name instead of `keyspaceID`. | ||
When it first connects to the TiKV system, it will set keyspace id in connection or get keyspaceID by keyspace name from PD. | ||
PD need check for the existence of the keyspace name and either return keyspaceID to client or return `keyspace not found` error if it does not exist. | ||
The client connection can only operate on one key spaces, but normally one application will have one key space. | ||
|
||
### Metadata design | ||
|
||
#### Metadata store | ||
Keyspace metadata need store in etcd of PD. | ||
Specific metadata information is as follows: | ||
|
||
```protobuf | ||
message KeyspaceMeta { | ||
uint32 id = 1; | ||
string name = 2; | ||
KeyspaceState state = 3; | ||
int64 created_at = 4; | ||
int64 state_changed_at = 5; | ||
map<string, string> config = 7; | ||
} | ||
|
||
enum KeyspaceState { | ||
ENABLED = 0; | ||
DISABLED = 1; | ||
ARCHIVED = 2; | ||
} | ||
``` | ||
|
||
keysapce state machine: | ||
|
||
![keyspace state machine](../media/keyspace.png) | ||
|
||
|
||
There is few etcd path to store keyspace metadata: | ||
```shell | ||
// Store KeyspaceMeta protobuf in etcd | ||
/keyspaces/meta/{keyspace_id} | ||
|
||
// Store the mapping from name to id in etcd | ||
/keyspaces/id/{keyspace_name} | ||
|
||
// Store keyspace alloc_id info in etcd | ||
/keyspaces/alloc_id | ||
|
||
``` | ||
|
||
#### Metadata managment | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To avoid this document being too complicated, the design details of PD will be in another RFC pr. |
||
Add keyspace managment capability in PD. It contains several basic capabilities: | ||
1. Allocate keyspace id by keyspace name; | ||
2. Create a new keyspace by keyspace meta; | ||
3. Update keyspace meta and configuration; | ||
4. Manage keyspace state machine; | ||
5. Get keyspace metadata from PD; | ||
|
||
#### More resource divided by keyspace | ||
|
||
1. The gc safepoint,service safepoint,txn safepoint store in etcd of PD, it's need to divide into different etcd path by keyspace. | ||
2. Add a GC worker processor to update safepoint by keyspace | ||
|
||
|
||
|
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.