docs: RFC for keyspace

[ystaticy]

Signed-off-by: ystaticy y_static_y@sina.com

What problem does this PR solve?

Issue Number: ref #40425

Problem Summary:

What is changed and how it works?

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No code

Release note

Please refer to Release Notes Language Style Guide to write a quality release note.

None

[ti-chi-bot]

[REVIEW NOTIFICATION]

This pull request has not been approved.

To complete the pull request process, please ask the reviewers in the list to review by filling /cc @reviewer in the comment.
After your PR has acquired the required number of LGTMs, you can assign this pull request to the committer in the list by filling /assign @committer in the comment to help you merge this pull request.

The full list of commands accepted by this bot can be found here.

Reviewer can indicate their review by submitting an approval review.
Reviewer can cancel approval by submitting a request changes review.

[sre-bot]

All committers have signed the CLA.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 81.2399%. Comparing base (341503b) to head (16d9467).
Report is 191 commits behind head on master.

❗ Current head 16d9467 differs from pull request most recent head bb2efa7

Please upload reports for the commit bb2efa7 to get more accurate results.

Additional details and impacted files

@@               Coverage Diff                @@
##             master     #39685        +/-   ##
================================================
+ Coverage   72.4329%   81.2399%   +8.8069%     
================================================
  Files          1491       2638      +1147     
  Lines        428997     717923    +288926     
================================================
+ Hits         310735     583240    +272505     
- Misses        99002     111483     +12481     
- Partials      19260      23200      +3940     

[ti-chi-bot]

@AmoebaProtozoa: adding LGTM is restricted to approvers and reviewers in OWNERS files.

In response to this:

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[bb7133]

Could you please add a raw list of the HTTP and RPC interfaces?

[ystaticy]

Sounds good, I added links to the two interfaces below.

[djshow832]

So users need to call the HTTP/RPC interfaces or use pd-ctl instead of SQL?

[bb7133]

It would be great if you can describe some plans about the observability(metrics, Grafana...) here.

[ystaticy]

Thanks, I've added the relevant descriptions below. PTAL~

[bb7133]

LGTM

[djshow832]

So users need to call the HTTP/RPC interfaces or use pd-ctl instead of SQL?

[djshow832]

Can the GC parameters (e.g. tidb_gc_life_time) by set by each tenant separately? If so, by what kind of interface? HTTP/RPC?

[ystaticy]

Can the GC parameters (e.g. tidb_gc_life_time) by set by each tenant separately? If so, by what kind of interface? HTTP/RPC?

Keyspace users can set tidb_gc_life_time directly using the SET SQL command just as before. This is because the system variables for each keyspace user are isolated.

[ystaticy]

In the keyspace scenario, all SQL operations remain the same as without a configured keyspace.

[ystaticy]

So users need to call the HTTP/RPC interfaces or use pd-ctl instead of SQL?
@djshow832 Yes, users need to call PD to create keyspace instead of use SQL, because When using SQL, it is always connected to a specific TiDB, which must belong to either the Null keyspace or a specific keyspace. The Null keyspace corresponds to a TiDB cluster that is not configured with a keyspace.

[djshow832]

So users need to call the HTTP/RPC interfaces or use pd-ctl instead of SQL?

@djshow832 Yes, users need to call PD to create keyspace instead of use SQL, because When using SQL, it is always connected to a specific TiDB, which must belong to either the Null keyspace or a specific keyspace. The Null keyspace corresponds to a TiDB cluster that is not configured with a keyspace.

It's fine for serverless, but it's not friendly to end users IMO.

Why can't you connect to any TiDB?

[ystaticy]

So users need to call the HTTP/RPC interfaces or use pd-ctl instead of SQL?

@djshow832 Yes, users need to call PD to create keyspace instead of use SQL, because When using SQL, it is always connected to a specific TiDB, which must belong to either the Null keyspace or a specific keyspace. The Null keyspace corresponds to a TiDB cluster that is not configured with a keyspace.

It's fine for serverless, but it's not friendly to end users IMO.

Why can't you connect to any TiDB?

An active TiDB instance is either in a Null Keyspace or configured with a specific keyspace. However, we should not create new keyspaces through any existing keyspace, as no keyspace has a 'manager' or higher-level status.

@baiyuqing What are your thoughts on this question?

[baiyuqing]

So users need to call the HTTP/RPC interfaces or use pd-ctl instead of SQL?

@djshow832 Yes, users need to call PD to create keyspace instead of use SQL, because When using SQL, it is always connected to a specific TiDB, which must belong to either the Null keyspace or a specific keyspace. The Null keyspace corresponds to a TiDB cluster that is not configured with a keyspace.

It's fine for serverless, but it's not friendly to end users IMO.
Why can't you connect to any TiDB?

An active TiDB instance is either in a Null Keyspace or configured with a specific keyspace. However, we should not create new keyspaces through any existing keyspace, as no keyspace has a 'manager' or higher-level status.

@baiyuqing What are your thoughts on this question?

Keyspace is aim to introduce ability to provide tenant-isolated space on single TiKV, different tenant's TiDB is invisible to eatch other. All keyspaces are basically equal, without hierarchy design. This doc is mainly about it.

In the real-world, people is able to leverage keyspace mechanism to build multi-tenant db system on single TiKV cluster and hierarchical feature by existing http/grpc interface. SQL is easy to use indeed in most cases. However to provide SQL approach needs another new design and investigation.

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: AmoebaProtozoa, baiyuqing, bb7133, djshow832

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [bb7133,djshow832]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[ti-chi-bot]

[LGTM Timeline notifier]

Timeline:

• 2024-10-29 06:15:07.365786797 +0000 UTC m=+330420.204942343: ☑️ agreed by bb7133.
• 2024-10-30 11:03:45.481669102 +0000 UTC m=+434138.320824633: ☑️ agreed by djshow832.

[djshow832]

LGTM

[tiprow]

@ystaticy: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
tidb_parser_test	9d7af9e	link	true	/test tidb_parser_test
fast_test_tiprow	9d7af9e	link	true	/test fast_test_tiprow

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.