需求反馈
【需求涉及的问题场景】
-
控制 table 使用不同副本数。某些重要的 table 使用更多的副本数，提升安全性；而一些临时表（比如跑批用，跑完就 drop 掉）使用更少的副本数提升性能；又或者是给热点 table 添加副本并开启 follower read 来提升减轻热点。
-
控制 table/index/partition 的地理位置。根据自己的实际情况，使数据的分布符合业务的需要，同时兼顾容灾能力和性能。
-
database/table 数据隔离。把不同 database / table 的数据放到相互隔离的 TiKV（通过给 TiKV 打 label）。
-
归档数据处理。针对单表或分区表设计数据归档方案，比如历史归档数据可以设计为一个副本并放置在磁盘性能差容量大的几个 TiKV 节点上 ，允许一定的数据丢失。
【期望的需求行为】
提供 SQL 接口定义 Placement Rules，期望提升一些场景的易用性：
- 控制 table 使用不同副本数
- 控制 table/index/partition/database 的地理位置以减少跨地域访问，降低查询延时
- database/table 数据隔离
- 冷热数据分离，冷数据存到更廉价的设备上
- 多租户场景，单个 database 在同一个 region
【需求可替代方案】
- 使用 pd-ctl 运维管理 Placement Rules，对一般用户不够友好
【背景信息】
Placement Rules 已在 4.0 发布，但易用性不足，主要体现在：
- 用户需要自己算出 start_key, end_key
- 使用 pd-ctl 导入配置文件，不符合用户习惯
- 执行部分 DDL 后，相应 placement rules 需要手动修改
- 因为 rules 之间会覆盖、rules 可能非常多，查看单张表的 rule 不方便
目前 5.0 跨中心部署功能中已支持 Partition 分区级别的 SQL 控制