TiKV Rust Client RFC

[sunxiaoguang]

trafficstars

Introduces the API design for a Rust client for TiKV.

[siddontang]

PTAL @tikv/pingcap-i18n

[Hoverbear]

Great job @sunxiaoguang, thanks for tackling this huge task! My hero. :joy:

[gregwebs]

I really like the API now :) With data types being built up for operations there is a future possibility of supporting push-down computation from a DSL. A next version though :)

[Hoverbear]

@gregwebs Yup, let's keep this RFC minimal and mergable. :)

[Hoverbear]

I think we can move into the final comment period. If you have concerns please start a discussion here about it before Friday. We'll then let all existing discussions close before merging.

Thanks for your participation in this process. :)

[Hoverbear]

@crazycoder1988 Hi! Thanks for your input/review! :)

[Hoverbear]

Since we have some final feedback which may impact the API I'm putting merging this on hold until it is addressed. :)

[sunxiaoguang]

Keyspace would make more sense than TiKV cluster. That is, if your program owns a key prefix I assume it is fine to use the Raw API with that key prefix. That reminds me that it is very useful for the API to have a concept of a prefix. But I think we can add this in a future revision and probably in a non-breaking way.

Right, it should be possible if people use it carefully.

Talking about prefix, I like this idea. Just like chroot concept in many systems. How about we add it now? It could be a very simple change to Config. What do you think @Hoverbear @siddontang @overvenus ?

[gregwebs]

This is an important concept, but I would still recommend that key prefixes be tackled in a next iteration because it requires some study and though.

FoundationDB is where I have seen this idea in use the most and we would have to verify whether those concepts map well to TiKV. Notably they recommend usage of a directory abstraction that has logical hierarchies that has a different physical representation. I think we would want to spend some time studying this and make a separate RFC for adding prefix related abstractions.

FoundationDB links

• Namespace
• Subspace
• Directory

[sunxiaoguang]

This is an important concept, but I would still recommend that key prefixes be tackled in a next iteration because it requires some study and though.

FoundationDB is where I have seen this idea in use the most and we would have to verify whether those concepts map well to TiKV. Notably they recommend usage of a directory abstraction that has logical hierarchies that is represented differently. I think we would want to spend some time studying this and make a separate RFC for adding prefix related abstractions.

FoundationDB links

• Namespace
• Subspace
• Directory

Agree. It's always easy to add simple key prefix in the future. However real multi tenancy requires thorough design and verification. Let's leave it for future.

[Hoverbear]

Hi friends! Are there any remaining points anyone would like to see addressed in this PR? We will likely amend this RFC in the future to reflect the final function signatures etc in the implemented code. That will be a different PR.

[Hoverbear]

Now that we've seen https://github.com/tikv/client-rust/pull/14 merged we can revisit & update this document.

[Hoverbear]

Trying to resolve the DCO problem on this PR. :)

[zhangjinpeng87]

@sunxiaoguang Seems this RFC is out-of-date with existing tikv/rust-client, would you mind to update it or just clost it?