马上就春节了，潭主在这里给读者朋友们拜个早年！
祝大家新春快乐，已已如意！
前两天，在朋友圈看到一篇PingCAP的推文，《TiDB分布式数据库多业务资源隔离应用实践》。
看过后，潭主改变了对TiDB的一些看法。
本期专栏文章，潭主分享一下学习与思考，希望对大家有帮助。
你给TiDB打什么标签？
TiDB，作为国产分布式数据库五朵金花之一，相信搞信创和数据库的都知道。
潭主对TiDB算略知一二，更愿意给她的一个“Big MySQL”的标签。
不过，从信创角度讲，潭主觉得TiDB有两大硬伤：一个是只兼容MySQL协议，另一个则是不支持“多租户”。
言归正传，来看看TiDB是通过什么技术实现资源隔离的。
一图搞懂TiDB的“多租户”
如上图所示，可以清晰看到案例中应用隔离的架构部署。
方案简述：
利用Placement Rules in SQL特性，通过对业务资源打Label，规避了TiKV层面的I/O和CPU资源争用
在应用接入层，通过负载均衡实现TiDB引擎的业务和资源隔离
引入TiFlash对OLAP进行加速，进行HTAP混布
TiDB这个隔离方案的核心是Placement Rules，也是本文的切入点。
什么是Placement Rules？
Placement Rules是PD（Placement Driver）在V4.0引入的一套副本规则系统，用于指导PD针对不同类型的数据生成对应的调度。
Rules来指定不同数据范围的副本数量、Raft角色、放置位置等属性，使Region副本的分布与规则定义一致，实现数据在不同数据中心之间的合理分布和高可用性。
在TiDB V5.0版本后默认开启，可通过pd-ctl命令开关。
pd-ctl config placement-rules enable/disable复制
而Placement Rules in SQL（简称PRS），则是TiDB V6.5版本提供的一种基于SQL规则的数据放置策略，当多个系统共用一套TiDB集群时，可轻松实现数据级别的物理隔离。
即用户通过SQL语句来配置数据在TiKV集群中的放置位置，可将集群、数据库、表或分区的数据部署到不同的地域、机房、机柜、主机。
前者侧重从集群整体角度进行控制，后者则侧重通过SQL对数据库、表和分区设置放置规则。
其实，Placement Rules这个概念潭主并不陌生，早年间的Ceph也是通过它来控制存储分布的。
PRS使用备忘：
使用CREATE PLACEMENT POLICY创建放置策略，并在CREATE或ALTER数据库、表和分区时绑定策略。
SHOW PLACEMENT FOR DATABASE/TABLESHOW PLACEMENT LABELS复制
Resource Control，意外的流控升级
原本以为搞定PRS就结束了，没想到TiDB的隔离花样很多，还有Resource Control的流控。
TiDB在V7.1版本引入了基于流控的Resource Control隔离方案，目的是简化分布式架构中资源管理的复杂度。
如上表所示，Resource Control不仅能够实现多系统、多负载的隔离，还可以进行 SQL语句和后台任务层面更精细化的控制。
言归正传。
分布式数据库相对传统集中式，架构复杂，比较“重”。
通常，用户搞信创，用一套换一套的模式替核心库还行，但对中小库显然不适用。
这就必然涉及多系统共用一套分布式集群，既要资源独立，做好隔离，又要实现集约化管理。
虽然也可以通过多Database或Schema模式实现，但绝算不上最佳实践。
TiDB则通过Placement Rules in SQL可以实现不同方式的数据物理隔离，一种是控制Zone，另一种则是控制Host。
SQL> CREATE PLACEMENT POLICY policy_order constraints="[+zone=order]";SQL> CREATE PLACEMENT POLICY policy_server1 leader_constraints="[+host=host1]";复制
什么是Resource Group
TiDB的资源管控，就是通过定义资源组 (Resource Group)，为资源组限定资源配额。
TiDB支持TiDB流控和TiKV的优先级调度两种资源管理能力，两种能力可单独或同时开启。
从V7.4开始，TiDB支持管控TiFlash资源。
SQL> CREATE RESOURCE GROUP rg_tenant1 RU_PER_SEC = 1000000 PRIORITY = HIGH BURSTABLE;SQL> ALTER USER user1 RESOURCE GROUP rg_tenant1;复制
这里又引出另一个概念，Request Unit （RU）， 是TiDB对CPU、IO等系统资源的统一抽象的计量单位，用于表示对数据库的单个请求消耗的资源量。
此外，TiDB在V7.2的资源管控中引入了Runaway Queries功能，涉及两个参数。
QUERY_WATCH：对问题SQL进行限流或熔断，事中或事后手动处理
QUERY_LIMIT：对不符合预期的SQL，自适应识别处理
RG使用备忘：
可在SELECT语句中使用Hint，/*+ RESOURCE_GROUP(rg1) */，或使用QUERY WATCH语句。
SQL> QUERY WATCH ADD RESOURCE GROUP default ACTION COOLDOWN SQL TEXT EXACT TO ...SQL> QUERY WATCH ADD RESOURCE GROUP default ACTION KILL SQL DIGEST ...复制
对于执行时间超过阈值的SQL，也可通过RG中QUERY_LIMIT参数调降优先级限流。
SQL> CREATE RESOURCE GROUP rg_auto_cooldown RU_PER_SEC = 100000 QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=COOLDOWN);复制
最后，TiDB在V7.4增加了对后台任务的资源控制管理，任务类型包括lightning、br、ddl、stats等。
SQL> ALTER RESOURCE GROUP default BACKGROUND=(TASK_TYPES='ddl', UTILIZATION_LIMIT=30);复制
TiDB vs OceanBase
TiDB的知识更新完，接下来就是友商PK环节。
这期文章，潭主最大的收获就是通过资源隔离这个点，批量更新了对TiDB New Feature的认知，对TiDB的看法也更加积极。
熟悉的人都知道，潭主属于OceanBase黑转粉。
作为OBCP持证人，潭主自然对OceanBase更熟悉一些。
相较之下，潭主还是更喜欢，或者说是更认可OB的多租户方案。
当然，这种认可，或者说是接受度，也是一种综合考量。
如今，总算搞懂了TiDB的套路，结合自身经验，潭主更愿意将TiDB的资源隔离称作“伪租户”。就好像，潭主戏称自己是“伪DBA”一样。
在了解了Placement Rules in SQL之后，潭主觉得PRS实现的数据物理隔离方案跟GaussDB的逻辑集群（Logical Cluster）更类似。
数据库选型、规划和设计，关键是贴合需求，鞋合不合适，只有自己的脚知道。
2024，夏天的那个约会
去年8月，潭主参加了TiDB在北京颐堤港亚马逊Office举办的一场AI Workshop。
当天，TiDB携手亚马逊和智谱AI，一个云、一个大模型、再加一个分布式向量数据库，阵容也算豪华。
除了TiDB的Vector Search，主办方还分享了两个项目：
TiDB Cloud Serverless
TiDB Chat2Query
潭主后来才知道，TiDB Cloud跑在AWS上，难怪AWS提供场地支持。
当天的收获之一，成功体验了在AWS上搭建了一个基于TiDB Vector和智谱LLM构建的GraphRAG。
学不完，根本学不完
现如今，技术更新和产品迭代的速度太快，目前TiDB都已经到了V8.5版本。
如果不是长期实践，或持续跟踪，潭主感觉很难保持知识的新鲜度。
只有不断学习，才能具备动态看待实物的眼光。
还好，兴趣是最好的老师。
这次无意间搞懂了TiDB的资源隔离方案，也算是局部完成了对TiDB的知识同步。
其实，潭主对TiDB还有不少兴趣点，以后再找机会分享吧。
最后，做个小调查，感谢大家的捧场！
- END -
感谢阅读。如果觉得写得还不错，就请点个赞或“在看”吧。
公众号所有文章仅代表个人观点，与供职单位无关。
推荐阅读
