2021 work to do

[ekexium]

As we're going to release 0.1 soon, I'm trying to build a brief roadmap of the project towards its GA (1.0). There can be 3 steps:

1. Collect possible future work
2. Give each task a priority
3. Sort them and build a timeline

In terms of the future work, I have some preliminary ideas. And I'm asking for ideas from the community. Please leave the comment if you have any thought.

In my opinion, the project aims at providing a reliable, performant and easy-to-use TiKV client, so the following things can be done to help achieve the goal.

• User friendliness

  • Better error handling

    • "Drop active transaction" is sometimes annoying
    • TiKV version compatibility check. Some features require specific TiKV versions. The client should support older versions of TiKV as it evolves.

  • Better logging Logging #267

  • More from users' feedback

  • Documentation & Example

    • I think it's good for now. We should maintain it.

  • CLI tool

    • It would be a convenient tool to explore and debug TiKV.
    • Besides usual requests, it can also provide functionalities for easier operational work (like those provided by pd-ctl or tikv-ctl)

  • We are bound to tokio now. Shall we make it compatible with any async reactor?

• Features

  • Async commit and 1PC
  • Large transaction
  • Fully functional GC (part of the TiKV GC mechanism changes)
  • Region cache
  • Parallelize multi-region request

• Reliability

  • Improve unit test
    • Currently we have low coverage (~45%, from tarpaulin)
    • We have functionalities that are not well tested, e.g. TLS
  • Improve integration test: We already have integration tests, but don't have enough coverage
    • Jepsen
    • Elle
    • Multi-region test
    • Test with nemesis or fault injection
    • Test with uncommon workload, e.g. extremely large transactions
  • Robustness
    • Don't panic if the error can be recovered by users. Only panic if it's the crate's mistake. This is done for now. We should keep it.

• Performance

  • Build an automatic benchmark script/tool
  • Provide benchmark results for each release
    • Compare with other clients if possible: java/go/python/TiDB

[ekexium]

@andylokandy @nrc Do you have anything to comment?

[nrc]

I think that our work should mostly be driven by our users post-0.1. That doesn't mean doing what people ask for or complain about, but we should find people using (or trying to use the client) and find out what they are trying to do with it. Then, we should set goals based on what people are doing.

I think our overarching goal should be getting to 1.0. Of course, that leads to the question of what 1.0 should look like. I like your breakdown of areas we could focus on. I would break out feature completeness from reliability though. I think user friendliness and feature completeness should be our primary goals. It would be good to know what our performance constraints should be. I don't think there are issues at the moment, because what we do is so simple, but it would be good to think about some more complex cases to make sure we are doing things right. For reliability, I think we should be careful we focus on our own correctness and don't try to prove correctness of TiKV.

[ekexium]

For reliability, I think we should be careful we focus on our own correctness and don't try to prove correctness of TiKV.

I agree. But I think end-to-end tests with simulated workload give us the best confidence in the correctness of the client. Jepsen for TiKV is a standalone project which uses client-rust to test TiKV.

[andylokandy]

I have some suggestions for sorting the importance:

1. The most important one is to settle down the API shape. It's very important to reach a consensus among all clients on how TiKV will be used and how features will interact with each other. By stabilizing (to some degree) the API, each client could do further internal improvement without breaking the assumption among clients. This should include the error handling, gc, large transaction, raw TTL, raw CAS etc. FYI, the project 'extract go client from TiDB' has reached the stage of refactoring user API.

2. The second important thing could be correctness. We may focus on adding more unit tests and set up the CI etc.

3. The last thing is performance improvement. This can even be done in post-1.0 because the initial users of rust client usually don't put TiKV in production, and performance improvement can be released afterward without breaking compatibility.

[nrc]

I think that each client should have somewhat different APIs, because each should have an API which is idiomatic for the language it is written in, i.e., the Go client's API should be idiomatic Go and the Rust client's API should be idiomatic Rust. My belief is that there will not be that much overlap of users between languages, so there is not much need for uniformity - nobody will migrate their project from the Go client to the Rust client :-)

[andylokandy]

@nrc Partially agree. Your opinion is based on the idea that go client and rust client have the same feature set, and they can choose different ways to provide them. But that's not true.

Besides, although clients should follow the language idiom in detail, they have better share the same structure. For example, batch_get should be at the same level as get, which is not true in go client.

[andylokandy]

One more thing: in go client, a key is considered not exist if the value is empty. 😄

[nrc]

Your opinion is based on the idea that go client and rust client have the same feature set, and they can choose different ways to provide them. But that's not true.

Which part is not true?

One more thing: in go client, a key is considered not exist if the value is empty. 😄

Oh dear, we should fix this sort of thing.

[andylokandy]

Which part is not true?

They don't share the same feature set. Rust client supports RawTTL RawCas, and go client supports follower read, etc.

[tisonkun]

Hi guys, now we have a forum as proposed before to hold such discussion, and I've created a kvclient category already. Would you mind to migrate the discussion there since we do have multilingual clients and it is hard to just choose one of them and let all discussions happen in one place.

[tisonkun]

This is for the rust client only, so I think the topic should stay here. Though I'm hesitating whether it should be an issue or a discussion.

@ekexium ok, I get it. Given that we have TiDB Internals forum for open-ended discussion, I'd prefer move discussion there and supersede GitHub Discussion. We don't have to maintain two channels though. For a specific roadmap of a project, it can be an issue if you think it is detailed enough or just like it, like ClickHouse since a discussion cannot be converted to an issue. But it is up to you after all.

[tisonkun]

Besides, I suggest to use a title RoadMap for Rust Client 2021 instead of Q2/Q3 which looks like an enterprise private concept.

[ekexium]

Yeah, it's redundant to maintain too many places for discussion. If we're going to use the internal forum to discuss client-rust specific content, would it be better to have a separate category, or just use the kvclient one?

This thread only discusses possible work in the next months. I'm drafting a roadmap which also includes priorities and a timeline.

[tisonkun]

I think we don't create a category with an over subdivided name. I don't use client because it is too general to be regraded as MySQL Client / MPPClient / KVClient and so on. kvclient is specific and clear for TiKV Client, distinguish the server side. I think the Go Client and the Rust Client are the most active developing ones and able to share the same concept at the moment.

[ekexium]

All right. Let's keep it simple for now and see how it works.

[nrc]

Another thing to consider is if/how we should provide a non-async API

[nrc]

See for example MongoDb's client which supports async with Tokio or async-std, or sync: https://github.com/mongodb/mongo-rust-driver

[ekexium]

It seems like MongoDB's sync client just block_on each async operation.

[nrc]

We could do that to start with, but should have something better for the long term

[andylokandy]

@nrc I think before anyone complains about the sync not available we don't need to care about it.

[nrc]

The thing about sync is that it is easier to get started, so I think that if we don't have it, people are more likely to just not try out the client, rather than complain. It should be very easy to provide a not very efficient sync API just by wrapping everything in block_on