TiDB 有一些功能和其它功能不一样，这类功能可以作为构建其它功能的基础，组合出新的特性，这类功能称之为：Meta Feature。
《关于基础软件产品价值的思考方式》 – 黄东旭
对一款分布式数据库而言，数据如何分散存储在不同节点永远是个有趣的话题。是否有时会期望能具体控制数据具体存储在哪些节点？
· 在同一个 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 接口。可以通过它对分区 / 表 / 库不同级别的数据进行基于标签的自由放置，这开启了诸多以往不可能实现的场景。除了上述可能性，期望一起探索更多有趣的应用。
