关于tidb:TiDB-60-的元功能Placement-Rules-in-SQL-是什么

37次阅读

共计 3092 个字符，预计需要花费 8 分钟才能阅读完成。

TiDB 有一些性能和其它性能不一样，这类性能能够作为构建其它性能的根底，组合出新的个性，这类性能称之为：Meta Feature。
<p align=”right”>《对于根底软件产品价值的思考形式》– 黄东旭 </p>

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

当你在同一个 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 能力，你设置搁置策略将区域数据的所有正本指定到特定区域的特定机房内，所有的数据存储，治理在本地区内实现，缩小了数据跨地区复制提早，升高流量老本。你须要做的仅仅是，为不同数据中心的节点打上标签，并创立对应的搁置规定：

CREATE PLACEMENT POLICY 'east_cn' CONSTRAINTS = "[+region=east_cn]";
CREATE PLACEMENT POLICY 'north_cn' CONSTRAINTS = "[+region=north_cn]";

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

ALTER TABLE orders PARTITION p_hangzhou PLACEMENT POLICY = 'east_cn'；ALTER TABLE orders PARTITION p_beijing PLACEMENT POLICY = 'north_cn'；

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

假如你负责大型互联网企业的数据平台，外部业务有 2000 多种，相干业务采纳一套或多套 MySQL 来治理，然而因为业务数量太多，MySQL 实例数靠近 1000 个，日常的监控、诊断、版本升级、平安防护等工作对运维团队造成了微小的压力，且随着业务规模越来越大，运维老本逐年回升。你心愿通过缩小数据库实例数量来缩小运维治理老本，然而业务间的数据隔离、拜访平安、数据调度的灵活性和治理老本成为你面临的严厉挑战。

借助 TiDB 6.0，通过数据搁置规定的配置，你能够很容易灵便的集群共享规定，例如业务 A，B 共享资源，升高存储和治理老本，而业务 C 和 D 独占资源，提供最高的隔离性。因为多个业务共享一套 TiDB 集群，降级、打补丁、备份打算、扩缩容等日常运维治理频率能够大幅缩减，升高管理负担晋升效率。

CREATE PLACEMENT POLICY 'shared_nodes' CONSTRAINTS = "[+region=shared_nodes]";
CREATE PLACEMENT POLICY 'business_c' CONSTRAINTS = "[+region=business_c]";
CREATE PLACEMENT POLICY 'business_d' CONSTRAINTS = "[+region=business_d]";

ALTER DATABASE a POLICY=shared_nodes;
ALTER DATABASE b POLICY=shared_nodes;
ALTER DATABASE c POLICY=business_c;
ALTER DATABASE d POLICY=business_d;

基于 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 接口。你能够通过它对分区 / 表 / 库不同级别的数据进行基于标签的自在搁置，这开启了诸多以往不可能实现的场景。除了上述可能性，咱们也冀望和你一起摸索更多乏味的利用。