Consultation on Issues with TiKV Stored Data DB File Instances

Translated
1

Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: tikv存储的数据db文件实例问题请教

| username: TiDBer_CozPRH8J

To improve efficiency, please provide the following information. Clear problem descriptions can be resolved faster:
【TiDB Usage Environment】

【Overview】 I would like to ask about the differences between using TiKV and standalone RocksDB data files.

【Application Framework and Business Logic Adaptation】

【Background】 What operations have been performed

【Phenomenon】 Business and database phenomena

【Question】 We are currently using standalone RocksDB, where different data types instantiate multiple different DB files to operate on data, and there is a domain ID distinction. Different domain IDs generate different files like 100_accountdb.db to isolate data. In different domains, the same key might be operated on. However, if we switch to TiKV, does this concept no longer exist? For developers, there are no different DB file instances to operate on; it’s transparent, and you can only distinguish by different keys (e.g., prefixing with domain ID-key). All operation mechanisms are flattened, and you can’t isolate operations like with standalone RocksDB. Could someone familiar with TiKV’s underlying mechanisms please explain? Thank you.

【Business Impact】

【TiDB Version】

【Attachments】 Relevant logs and monitoring (https://metricstool.pingcap.com/)

For questions related to performance optimization or troubleshooting, please download the script and run it. Please select all and copy-paste the terminal output results for upload.

2
| username: xfworld | Original post link

I understand that these are different scenarios.

image
image703×320 21.1 KB

Looking at the image above, if you need distributed capabilities, you can use TiKV to meet that need.
However, if you require the isolation capabilities of RocksDB (which I understand is predetermined when planning the scenario), this may not be suitable.

If you can isolate the combination method of Keys to meet a distributed solution, it is also feasible (with built-in high availability and multiple replicas).

Reference documentation:

3
| username: TiDBer_CozPRH8J | Original post link

Okay, thank you for the clear and understandable answer. :+1::+1:

4
| username: TiDBer_CozPRH8J | Original post link

Let me ask again, which is the most mature TiKV client API at present? I see that client-java and client-go are the most fully updated and maintained? Client-c and client-cpp don’t seem ready for production. Our project is in C++. How can we integrate and be compatible with TiKV to replace other storage? Thanks a lot.

5
| username: tidb狂热爱好者 | Original post link

You can directly use the MySQL client, there’s no difference. TiDB is fully compatible with MySQL 5.7.

6
| username: xfworld | Original post link

It should be the Go and Java client versions, with the Go version being more feature-complete.

You can only consider using the gRPC protocol to help you with this part of the scheduling and integration.

Currently, Rust, which is more compatible with C++, also doesn’t have an official version and is not recommended for production use…

7
| username: TiDBer_CozPRH8J | Original post link

Uh, mainly because I was directly operating RocksDB’s key-value operations before, without using tables and such. I used TiKV for minimal cost compatibility.

8
| username: system | Original post link

This topic was automatically closed 1 minute after the last reply. No new replies are allowed.