TiDB 6.0 的「元功能」：Placement Rules in SQL 是什么？PlacementRules in SQL初试

本文讲述了TiDB 6.0 的「元功能」：Placement Rules in SQL 是什么？PlacementRules in SQL初试

对一款分布式数据库而言，数据如何分散存储在不同节点永远是个有趣的话题。你是否有时会期望能具体控制数据具体存储在哪些节点？

当你在同一个 TiDB 集群上支持多套业务以降低成本，但又担心混合存储后业务压力互相干扰

当你希望增加重要数据的副本数，提升关键业务的可用性和数据可靠性

当你希望把热点数据的 leader 放到高性能的 TiKV 实例上，提升 OLTP 性能

当你希望实现热冷数据分离（热数据存放在高性能介质，冷数据反之），降低存储成本

当你希望在多中心部署下，将数据按照实际地域归属和数据中心位置来存放，以减少远距离访问和输你也许已经知道，TiDB 使用 Placement Driver 组件来控制副本的调度，它拥有基于热点，存储容量等多种调度策略。但这些逻辑以往对于用户都是近似不可控的存在，你无法控制数据具体如何放置。而这种控制能力就是 TiDB 6.0 的 Placement Rules in SQL 数据放置框架希望赋予用户的。TiDB 6.0 版本正式提供了基于 SQL 接口的数据放置框架（Placement Rules in SQL）。它支持针对任意数据提供副本数、角色类型、放置位置等维度的灵活调度管理能力，这使得在多业务共享集群、跨 AZ 部署等场景下，TiDB 得以提供更灵活的数据管理能力，满足多样的业务诉求。让我们来看几个具体的例子。

跨地域部署降低延迟

想象下你是一个服务供应商，业务遍布全球，早期架构为中心化设计，随着业务跨地域开展后，业务拆分全球化部署，中心数据访问延迟高，跨地域流量成本高。随着业务演进，你着手推动数据跨地域部署，以贴近本地业务。你的数据架构有两种形式，本地管理的区域数据和全局访问的全局配置数据。本地数据更新频次高，数据量大，但是几乎没有跨地域访问的情况。全局配置数据，数据量少，更新频率低，但是全局唯一，需要支持任意地区的访问，传统的单机数据库或单地区部署数据库无法满足以上业务诉求。

以下图为例，用户将 TiDB 以跨中心的方式部署在三个数据中心，分别覆盖华北，华东和华南的用户群，让不同区域的用户可以就近访问本地数据。在以往的版本中，用户的确可以将以跨中心的方式部署 TiDB 集群，但无法将归属不同用户群的数据存放在不同的数据中心，只能按照热点和数据量均匀分布的逻辑将数据分散在不同中心。在高频访问的情况下，用户访问很可能会频繁跨越地域承受较高的延迟。

通过 Placement Rules In SQL 能力，你设置放置策略将区域数据的所有副本指定到特定区域的特定机房内，所有的数据存储，管理在本地区内完成，减少了数据跨地区复制延迟，降低流量成本。你需要做的仅仅是，为不同数据中心的节点打上标签，并创建对应的放置规则：

并通过 SQL 语句控制数据的放置，这里以不同城市分区为例：

这样，归属不同城市的订单数据副本将会被「固定」在对应的数据中心。

业务隔离

假设你负责大型互联网企业的数据平台，内部业务有 2000 多种，相关业务采用一套或多套 MySQL 来管理，但是因为业务数量太多，MySQL 实例数接近 1000 个，日常的监控、诊断、版本升级、安全防护等工作对运维团队造成了巨大的压力，且随着业务规模越来越大，运维成本逐年上升。你希望通过减少数据库实例数量来减少运维管理成本，但是业务间的数据隔离、访问安全、数据调度的灵活性和管理成本成为你面临的严峻挑战。

借助 TiDB 6.0，通过数据放置规则的配置，你可以很容易灵活的集群共享规则，例如业务 A，B 共享资源，降低存储和管理成本，而业务 C 和 D 独占资源，提供最高的隔离性。由于多个业务共享一套 TiDB 集群，升级、打补丁、备份计划、扩缩容等日常运维管理频率可以大幅缩减，降低管理负担提升效率。

基于 SQL 接口的数据放置规则，你仅仅使用少数 TiDB 集群管理大量的 MySQL 实例，不同业务的数据放置到不同的 DB，并通过放置规则管理将不同 DB 下的数据调度到不同的硬件节点上，实现业务间数据的物理资源隔离，避免因资源争抢，硬件故障等问题造成的相互干扰。通过账号权限管理避免跨业务数据访问，提升数据质量和数据安全。在这种部署方式下，集群数量大大减小，原本的升级，监控告警设置等日常运维工作将大幅缩减，在资源隔离和性价比上达到平衡，大幅减少日常的 DBA 运维管理成本。

主从多机房 + 低延迟读取

现在你是一个互联网架构师，希望通过 TiDB 构建本地多数据中心架构。通过数据放置规则管理，你得以将 Follower 副本调度到备中心，实现同城高可用。

CREATE PLACEMENT POLICY eastnwest PRIMARY_REGION="us-east-1" REGIONS="us-east-1,us-east-2,us-west-1" SCHEDULE="MAJORITY_IN_PRIMARY" FOLLOWERS=4;
CREATE TABLE orders (order_id BIGINT PRIMARY KEY, cust_id BIGINT, prod_id BIGINT) PLACEMENT POLICY=eastnwest;

与此同时，你让对于一致性和新鲜度不高的历史查询通过基于时间戳的方式读取（ Stale Read ），这样避免了跨中心数据同步造成的访问延迟，同时也提高对从机房的硬件利用率。

SELECT * FROM orders WHERE order_id = 14325 AS OF TIMESTAMP '2022-03-01 16:45:26';

总结

TiDB 6.0 的 Placement Rules In SQL 是一个很有趣的功能：它暴露了以往用户无法控制的内部调度能力，并提供了方便的 SQL 接口。你可以通过它对分区 / 表 / 库不同级别的数据进行基于标签的自由放置，这开启了诸多以往不可能实现的场景。除了上述可能性，我们也期望和你一起探索更多有趣的应用。

1.概述

TIDBQ 4.0版本开始推出Placement Rule放置规则)功能，是用于控制redion本调度的一套规则系统，通过lacementrule可以控制某连续数据的副本数、位置、region类型等，以满足不同的数据分布需求，默认集群初始化完成后会有一个默认的控制副本数的placementrule。5.0版本前该功能为默认关闭，且官方建议仅在tiflash.上使用。

Placement rule使用时需要ison格式的配置文件，并通过pd-ct工具设置和查看，需要设置好规则的应用顺序，操作较为繁项目不便于理解,比如要设置某个表的放置规则时需要使用key range作为条件，当有多个小表位于同一region时可能会影响其他表。

2. PlacementRules in SQL

2.1 如何使用

Tidb 5.3版本开始支持直接使用SQL配置放置规则(placement rule in SQL)，以更加灵活、方便的控制表的放置策略，避免使用pd-ctlI工具配置的复杂性，放置规则的设置依赖label标签，可通过show placement labels查看当前的label设置和具体值.

使用放置规则时有2种方式

(1)直接放置

直接放置是指在create table时或使用alter table方式直接在表的DDL语句中使用放置选项，从而达到设置表的放置规则目的

Create table t (id int) primary region='beijing' folllowers=4

(2)放置策略

使用放置策略时首先通过create placement policy建立放置策略，然后在create table或alter table中直接指定放置策路，放置策略在删除时必须没有对象在引用该策略，否则无法删除。

Create placement policy bj policy primary region=beijing' folllowers=4.

Alter table t placement policy bi policy.

放置规则不仅可以用于表级设置，也可以对分区和库设置，当设置库级放置策略后，默认库下的所有表都会继承库级规则，库级和表级同时设置时表级规则生效。分区和索引继承表的放置规则，但不能单独对索引设置规则。

放置选项根据实现的功能复杂度可以分为基本选项和高级选项

PRIMARY REGION、REGIONS、SCHEDULE 选项不可与 CONSTRAINTS 选项同时指定，否则会报错.

2.2查看方式

放置规则配置后会将相关信息存于tikv内，可通过show placement域information schema.placement rule查看，同时在informatio schema.tables/partitions里记录了表直接放置选项和放置策略，Dd会根据规则设置进行调度以满足要求.

Target: 表示放置选项应用的对象，包括表、分区、库、策略等

Placement; 放置选项的具体内容

Schedule state: 当前对象上放置规则的应用状态NULL: policy的状态一直是null。

INPROGRESS: 正在根据放置策略进行region调度，当实际环境不满足调度要求时会一直处于该状态.SCHEDULED: 已经按放置规则完成调度

PENDING: 放置规则没有语法错误，但是在当前集群拓扑无法调度

3.测试结果

本次测试环境如上，有3个数据中心，分别设置region标签为: bj、xian、xn

使用过程中发现目前5.3.0版本存在以下限制情或非预期情况:

当前默认不允许对表设置放置规则，需全局启用变量tidb enable alter placement

2.

数据放置依赖tikv的label标签，使用PRIMARY REGION、REGIONS放置选项，标签中必须设置region作为一个层级(此处region可以

看做一个数据中心)。

3.使用高级放置选项时label标签不需要必须设置region层级标签

4、PRIMARY REGION中只能设置一个region标签值，且该标签值必须在REGIONS设置，否则会报错。高级放置规则中LEADER CONSTRAINTS同层级的label只能设置1个，否则会产生冲突，该限制导致不将eader根据数据中心级标签放到2人数据中

5.使用高级放置规则时必须设置FOLLOWERS数量否则只有1个raft region

注: 此处测试时xn,xian 有3个tikv的disk标签为hdd，但无法完成调度满足1 leader+ 2 followers的需求.

6、设置FOLLOWER CONSTRAINTS必须同时设置FOLLOWERS数量，且raft region follower数量不能大于 FOLLOWERS指定的数量

7、测试过程出现以下非预期情况

(1) followers=4时，设置非leader region中心存储2个副本可以完成调度，设置followers=6时不能完成调度，:

(2)设置follower=3，leader为region=bj,follower按如下

a.设置bj=1,xian=2,不能完成调度。

b.设置xn=1.xian=2.不能完成调度

c.设置xn=1,xian=1,能完成调度

d.设置bj=1,xian=1,能完成调度

(3)设置label为2个中心，其中xian中心4disk=hdd标签，放置规则仅在hdd上，follower=2，系统不能完成调度，查看pd日志，region在目标abel主机创建oee和tansfer leader后不再产生调度，导致此时有3o0wer，通过leader constaints/fowlower constraintst无法将region全部放到同一数据中心。

4.总结

PacementRule in SQL增加了配置放置规则的灵活性，通过放置规则可以实现类似存储分层、数据中心就近读取、关键表增加副本数等实用性功能，作为实验特性还有一些不完善的地方，出现非预期情况，另外建议官方文档中的充完善相关描述，比如具体的调度规则和限制、和PD间的关系和实现、事务执行和提交时如何使用和处理PlacementRule。

上文就是小编为大家整理的TiDB 6.0 的「元功能」：Placement Rules in SQL 是什么？PlacementRules in SQL初试。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。