Need help with client-rust?
Click the “chat” button below for chat support from the developer who created it, or find similar developers for support.

About the developer

tikv
240 Stars 71 Forks Apache License 2.0 777 Commits 33 Opened issues

Description

Rust Client for TiKV.

Services available

!
?

Need anything else?

Contributors list

TiKV Client (Rust)

Docs Build Status

Nightly docs

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 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.

Getting started

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.1.0"

The minimum supported version of Rust is 1.40. The minimum supported version of TiKV is 5.0.

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).

Examples

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.

API summary

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.

Types

Key
: a key in the store.
String
and
Vec
implement
Into
, so you can pass them directly into client functions.

Value
: a value in the store; just an alias of
Vec
.

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![]..)
.

Raw requests

| Request | Main parameter type | Result type | Noteworthy Behavior | | ------------------ | ------------------- | ---------------- | ---------------------------------------------- | |

put
|
KvPair
| | | |
get
|
Key
|
Option
| | |
delete
|
Key
| | | |
delete_range
|
BoundRange
| | | |
scan
|
BoundRange
|
Vec
| | |
batch_put
|
Iter
| | | |
batch_get
|
Iter
|
Vec
| Skips non-existent keys; does not retain order | |
batch_delete
|
Iter
| | | |
batch_scan
|
Iter
|
Vec
| See docs for
each_limit
parameter behavior. The order of ranges is retained. | |
batch_scan_keys
|
Iter
|
Vec
| See docs for
each_limit
parameter behavior. The order of ranges is retained. | |
compare_and_swap
|
Key
+ 2x
Value
|
(Option, bool)
| |

Transactional requests

| Request | Main parameter type | Result type | Noteworthy Behavior | | ---------------------- | ------------------- | --------------- | ------------------------------------------------------------------ | |

put
|
KvPair
| | | |
get
|
Key
|
Option
| | |
get_for_update
|
Key
|
Option
| | |
key_exists
|
Key
|
bool
| | |
delete
|
Key
| | | |
scan
|
BoundRange
|
Iter
| | |
scan_keys
|
BoundRange
|
Iter
| | |
batch_get
|
Iter
|
Iter
| Skips non-existent keys; does not retain order | |
batch_get_for_update
|
Iter
|
Iter
| Skips non-existent keys; does not retain order | |
lock_keys
|
Iter
| | | |
send_heart_beat
| |
u64
(TTL) | | |
gc
|
Timestamp
|
bool
| Returns true if the latest safepoint in PD equals the parameter |

Development and contributing

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.

Building and testing

We use the standard Cargo workflows, e.g.,

cargo build
to build and
cargo test
to run unit tests. You will need to use a nightly Rust toolchain to build and run tests.

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

Creating a PR

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
, 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.

Getting help

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.

We use cookies. If you continue to browse the site, you agree to the use of cookies. For more information on our use of cookies please see our Privacy Policy.