This crate provides an easy-to-use client for TiKV, a distributed, transactional key-value database written in Rust.
This crate lets you connect to a TiKV(>= v5.0.0) cluster and use either a transactional or raw (simple get/put style without transactional consistency guarantees) API to access and update your data.
The TiKV Rust client is an open source (Apache 2) project maintained by the TiKV Authors. We welcome contributions, see below for more info.
Note that the current release is not suitable for production use - APIs are not yet stable and the crate has not been thoroughly tested in real-life use.
The TiKV client is a Rust library (crate). To use this crate in your project, add the following dependency to your Cargo.toml:
[dependencies]
tikv-client = "0.3"rust>=1.56.1, required forhashbrown-v0.12.1
The general flow of using the client crate is to create either a raw or transaction client object (which can be configured) then send commands using the client object, or use it to create transactions objects. In the latter case, the transaction is built up using various commands and then committed (or rolled back).
Raw mode:
use tikv_client::RawClient;
let client = RawClient::new(vec!["127.0.0.1:2379"], None).await?;
client.put("key".to_owned(), "value".to_owned()).await?;
let value = client.get("key".to_owned()).await?;Transactional mode:
use tikv_client::TransactionClient;
let txn_client = TransactionClient::new(vec!["127.0.0.1:2379"], None).await?;
let mut txn = txn_client.begin_optimistic().await?;
txn.put("key".to_owned(), "value".to_owned()).await?;
let value = txn.get("key".to_owned()).await?;
txn.commit().await?;Since the TiKV client provides an async API, you'll need to use an async runtime (we currently only support Tokio). See getting-started.md for a complete example.
The TiKV Rust client supports several levels of abstraction. The most convenient way to use the client is via RawClient and TransactionClient. This gives a very high-level API which mostly abstracts over the distributed nature of the store and has sensible defaults for all protocols. This interface can be configured, primarily when creating the client or transaction objects via the Config and TransactionOptions structs. Using some options, you can take over parts of the protocols (such as retrying failed messages) yourself.
The lowest level of abstraction is to create and send gRPC messages directly to TiKV (and PD) nodes. The tikv-client-store and tikv-client-pd crates make this easier than using the protobuf definitions and a gRPC library directly, but give you the same level of control.
In between these levels of abstraction, you can send and receive individual messages to the TiKV cluster, but take advantage of library code for common operations such as resolving data to regions and thus nodes in the cluster, or retrying failed messages. This can be useful for testing a TiKV cluster or for some advanced use cases. See the client_rust::request module for this API, and client_rust::raw::lowering and client_rust::transaction::lowering for convenience methods for creating request objects.
The rest of this document describes only the RawClient/TransactionClient APIs.
Important note: It is not recommended or supported to use both the raw and transactional APIs on the same database.
Key: a key in the store. String and Vec<u8> implement Into<Key>, so you can pass them directly into client functions.
Value: a value in the store; just an alias of Vec<u8>.
KvPair: a pair of a Key and a Value. It provides convenience methods for conversion to and from other types.
BoundRange: used for range related requests like scan. It implements From for Rust ranges so you can pass a Rust range of keys to the request, e.g., client.delete_range(vec![]..).
| Request | Main parameter type | Result type | Noteworthy Behavior |
|---|---|---|---|
put |
KvPair |
||
get |
Key |
Option<Value> |
|
delete |
Key |
||
delete_range |
BoundRange |
||
scan |
BoundRange |
Vec<KvPair> |
|
batch_put |
Iter<KvPair> |
||
batch_get |
Iter<Key> |
Vec<KvPair> |
Skips non-existent keys; does not retain order |
batch_delete |
Iter<Key> |
||
batch_scan |
Iter<BoundRange> |
Vec<KvPair> |
See docs for each_limit parameter behavior. The order of ranges is retained. |
batch_scan_keys |
Iter<BoundRange> |
Vec<Key> |
See docs for each_limit parameter behavior. The order of ranges is retained. |
compare_and_swap |
Key + 2x Value |
(Option<Value>, bool) |
| Request | Main parameter type | Result type | Noteworthy Behavior |
|---|---|---|---|
put |
KvPair |
||
get |
Key |
Option<value> |
|
get_for_update |
Key |
Option<value> |
|
key_exists |
Key |
bool |
|
delete |
Key |
||
scan |
BoundRange |
Iter<KvPair> |
|
scan_keys |
BoundRange |
Iter<Key> |
|
batch_get |
Iter<Key> |
Iter<KvPair> |
Skips non-existent keys; does not retain order |
batch_get_for_update |
Iter<Key> |
Iter<KvPair> |
Skips non-existent keys; does not retain order |
lock_keys |
Iter<Key> |
||
send_heart_beat |
u64 (TTL) |
||
gc |
Timestamp |
bool |
Returns true if the latest safepoint in PD equals the parameter |
We welcome your contributions! Contributing code is great, we also appreciate filing issues to identify bugs and provide feedback, adding tests or examples, and improvements to documentation.
We use the standard Cargo workflows, e.g., cargo build to build and cargo test/nextest to run unit tests. You will need to use a nightly Rust toolchain to build and run tests. Could use nextest to speed up ut, install nextest first.
cargo install cargo-nextest --locked
Running integration tests or manually testing the client with a TiKV cluster is a little bit more involved. The easiest way is to use TiUp (>= 1.5) to initialise a cluster on your local machine:
tiup playground nightly --mode tikv-slim
Then if you want to run integration tests:
PD_ADDRS="127.0.0.1:2379" cargo test --package tikv-client --test integration_tests --features integration-tests
We use a standard GitHub PR workflow. We run CI on every PR and require all PRs to build without warnings (including clippy and Rustfmt warnings), pass tests, have a DCO sign-off (use -s when you commit, the DCO bot will guide you through completing the DCO agreement for your first PR), and have at least one review. If any of this is difficult for you, don't worry about it and ask on the PR.
To run CI-like tests locally, we recommend you run cargo clippy, cargo test/nextest run, and cargo fmt before submitting your PR. See above for running integration tests, but you probably won't need to worry about this for your first few PRs.
Please follow PingCAP's Rust style guide. All code PRs should include new tests or test cases.
If you need help, either to find something to work on, or with any technical problem, the easiest way to get it is via internals.tidb.io, the forum for TiDB developers.
You can also ask in Slack. We monitor the #client-rust channel on the tikv-wg slack.
You can just ask a question on GitHub issues or PRs directly; if you don't get a response, you should ping @ekexium or @andylokandy.