Refine placement rules in sql#6766
Conversation
|
[REVIEW NOTIFICATION] This pull request has been approved by:
To complete the pull request process, please ask the reviewers in the list to review by filling The full list of commands accepted by this bot can be found here. DetailsReviewer can indicate their review by submitting an approval review. |
|
/verify |
|
/verify |
morgo
left a comment
There was a problem hiding this comment.
LGTM, any reason this is still a draft?
| Placement Rules in SQL is a feature that enables you to specify where data is store in a TiKV cluster using SQL interfaces. Using this feature, consecutive data is scheduled to a specific regions, data centers, racks, or hosts, with a specified replica count. This is useful for scenarios including optimizing a high availability strategy with lower cost, ensuring that local replicas of data are available for local stale reads, and adhering to compliance requirements. | ||
|
|
||
| The detailed user scenarios are as follows: | ||
|
|
||
| Placement Rules allow you to configure where data will be stored in a TiKV cluster. This is useful for scenarios including optimizing a high availability strategy, ensuring that local copies of data will be available for local stale reads, and adhering to compliance requirements. | ||
| - Place data across regions to improve the access performance in a specific region | ||
| - Merge multiple databases of different applications to reduce the cost on database maintenance | ||
| - Increase replica count for important data to improve the application availability and data reliability | ||
| - Store new data into SSDs and store old data into HHDs to lower the cost on data archiving and storage | ||
| - Schedule the leaders of hotspot data to high-performance TiKV instances | ||
| - Separate irrelevant data to different storages to improve availability |
There was a problem hiding this comment.
@morgo PTAL thanks! This is provided by the PM in v5.3.0 release notes.
There was a problem hiding this comment.
LGTM. Only one we need to be careful about is "Place data across regions to improve the access performance in a specific region", since this is only true for access (aka stale read) scenario. For modification there are problems because the user will also need local transaction, which is a separate feature.
If PM is happy to leave this in, then I have no problems with it.
There was a problem hiding this comment.
Currently Placement Rules only solve data locality challenges. We'd better only mention read performance instead of access performance.
There was a problem hiding this comment.
"compliance" is also a big topic. Maybe we can use "data locality requirements" instead of "compliance requirements", until we figure out all the compliance requirements from real world users.
@morgo What do you think?
There was a problem hiding this comment.
Yeah, I think that is good. We mention compliance in known limitations below, so it is good not to claim it in the description for now.
There was a problem hiding this comment.
I have replaced "compliance requirements" with "data locality requirements". PTAL
Co-authored-by: Morgan Tocker <tocker@gmail.com>
Co-authored-by: Enwei <jinenwei@pingcap.com>
Co-authored-by: Morgan Tocker <tocker@gmail.com>
|
/remove-status LGT1 |
|
/merge |
|
This pull request has been accepted and is ready to merge. DetailsCommit hash: 1661f05 |
What is changed, added or deleted? (Required)
Refine placement rules in sql
Which TiDB version(s) do your changes apply to? (Required)
Tips for choosing the affected version(s):
By default, CHOOSE MASTER ONLY so your changes will be applied to the next TiDB major or minor releases. If your PR involves a product feature behavior change or a compatibility change, CHOOSE THE AFFECTED RELEASE BRANCH(ES) AND MASTER.
For details, see tips for choosing the affected versions.
What is the related PR or file link(s)?
Do your changes match any of the following descriptions?