前阵子，根据小说《输赢》改编的同名神剧开播了，网上吐槽者众。

剧中，陈坤饰演的周锐，完全不按套路出牌，敢说敢做，之前就有人说该剧天雷滚滚，潭主看过后深信不疑。

剧外，2021岁末，三家公有云分布式数据库大厂在某世界500强保险公司激战正酣，杀红了眼。

在揭晓 花落谁家 之前，潭主先跟你聊聊“凿墙”（去IOE）三部曲的最后 一个主角，腾讯的 TDSQL 。

DB江湖，万变不离其宗

如今，看过一轮主流分布式数据库之后，觉得下面这张图可以清晰展现大厂的产品线。

这一点TDSQL跟GaussDB很像，“ 开源行，我就行！ ”。

至于HTAP，听听就好，千万别当真。

TDSQL品种虽多，但要真凿墙，还得用 TDSQL for PostgreSQL 。

工具都是管理套路

TDSQL-PG的工具体系：

• 面向开发（TStudio）： 类似Oracle的PL/SQL Developer ，基于Web的图形工具。
• 面向迁移（DBBridge）： 负责源端库与TDSQL的 兼容性评估 ，源端库到TDSQL之间的 数据 迁移和同步 ， 类似OceanBase的OMS 。
• 面向运维（OSS）： Web的管理平台 ，实现多租户，租户内多集群的部署、升级和扩容等功能。

这个OSS本身也是一个小型的分布式系统：

OSS虽说不是TDSQL的技术核心，但却是管理核心，包括4个组件：

• Etcd： OSS的底座 ，负责Center和Confdb选举，同时存储高可用的关键信息。
• Center： OSS控制中心 ，接受并处理用户从Web界面对TDSQL集群及其节点操作，并通过各个Agent与节点会话，负责定时任务的调度执行。
• Confdb： 类似CMDB （可以多集群共用），管理整个TDSQL的 metadata ，背后是一个单机版 PostgreSQL数据库，通过 stolon 实现主备的高可用。

• Agent： 代理程序 ，部署在每台TDSQL的物理服务器节点上，响应Center下发的执行请求，提供采集的监控指标。

  注：Stolon是一个基于Cloud-Native的PostgreSQL的高可用管理工具，主要包括stolon-keeper、stolon-proxy和stolon-sentinel三个服务组件 。

TDSQL，长得像谁？

TDSQL（ Tencent Database SQL ），前身叫TBase，叫什么不重要，重要的是谁在用。

看过“ 凿墙 ”三部曲中篇的读者，对于Ga u ssDB中的CN、DN和GTM这些组件应该并不陌生。

没错，TDSQL也是这个套路。

• Coordinator（简称 CN）： 协调节点 ， 无状态计算节点 ，负责分布式数据库业务请求的接入，以及数据分发和执行计划，节点间对等，只存元数据，不存实际业务数据。
• Datanode（简称 DN）： 数据节点 ，执行CN分发的执行请求，存储业务数据的分片。DN是一个逻辑概念，多个DN可以部署在相同或不同的物理节点上，但主备DN间需要物理隔离。
• Global Transaction Manager（简称 GTM）： 全局事务管理器 ，通过两阶段提交（Two Phase Commit）和全局时钟戳（Global Timestamp）策略来保证在分布式事务的一致性，同时管理序列（Sequence）等全局对象。

腾讯官方称TDSQL-PG的SQL语法完全兼容PostgreSQL ，同时也兼容 相当大部分 的Oracle语法。

而Ga u ssDB也脱胎于PostgreSQL内核，二者有点血缘关系。想当年 PGSQL 在国内挺冷清，到如今这般盛况，华为G au ssDB功不可没。

综合看，TDSQL更像是从原来 分库分表的业务模式中升级而来，再 通过 Sharding配合GTM实现了分布式，从而降低了应用 开发的复杂度 。

下面介绍几个TDSQL的重要特性。

特性之一：ShardMap

TDSQL除了跟Ga u ssDB很像外，跟中兴的GoldenDB更像一个模子里刻出来的。

这也让潭主想到了“ 分形 ”，细看TDSQL的每个Shard，其实都是一个独立的、基于PGSQL的一主多从架构。

为了应对分布式和大数据，TDSQL引入了ShardMap机制，解决了集群扩展问题。

ShardMap功能实现在TDSQL里叫“Shard Group” ，需要为每个NodeGroup建立对应的ShardMap。

ShardMap用于维护ShardID和DN之间的映射关系， 根据算法，不同的ShardID被分配到不同DN上，当集群扩容增加DN时，只需改变ShardMap中的对应关系就能实现数据重分布。

特性二：均衡分布与冷热分级

实际场景中，大数据量在Hash时可能会出现分布不均的情况，TDSQL可以设置特殊分布逻辑，比如在Hash取模后，再增加一个时间偏移量来均衡数据分布。

而OceanBase分区表的技术细节中，可以 直接 通过表达式（字段+偏移量）来进行Hash分区，表面上看差不多，但本质上却完全不同，一个是ShardMap，一个是Table Partition。

TDSQL建表时使用的是Partition by和 Distribute by Shard关键字，而OceanBase则是Partition和Subpartition。

再说冷热分级，在传统数据库中，比如基于时间的范围分区和不同存储介质类型表空间的组合就可轻易实现冷热分离，并 对用户无感知。

到了分布式数据库，专用存储被干掉了，虽说本质上还是SSD和SATA的事，但在TDSQL中 却表现为冷热节点组的选择 了。

在建表时设定时间界限并指定两个分区组来区分冷热，剩下的就交给后台任务，定时根据用户配置规则自动进行数据迁移。

特性三：TDSQL的多租户管理

目前看，几家公有云大厂的分布式数据库在细节上差异不小，TDSQL的 整个物理资源均由OSS系统控制，租户即账户，租户之下才是TDSQL的实 例 。

TDSQL-PG版的多租户功能，就是TDSQL的多实例管理，体现更多的是腾讯的云化管理能力。

在对 TDSQL-PG版进行实例化 之前，要做好相应规划，比如通过 IDC管理设置数据中心（ AZ ） 和地域（ Region ），对物理服务器进行初始化，创建资源模板和资源池等。

TDSQL的实例化过程，就像创建一个Oracle SID，过程中会设定字符集，实例版本、主备模式以及对应的资源池，之后再通过资源模板对CN、DN和GTM进行分布式部署。

篇幅有限，像FDW（Foreign Data Wrappers）和容灾这样的功能留到后期再分享吧。

过往之事，再无新奇

第一次交流TDSQL时，腾讯在分享容灾和多活案例时提到了国内某保险公司的南北双活。

这是Oracle十多年前在讲的东西，但对方竟不知道Oracle在美国银行的双活经典案例， OMG！ 侧面 也反映出现在鹅厂技术人员的专业背景和见识有一定的局限性。

在“ 凿墙 ”这事上，不仅是目标端分布式数据库技术有多好，这只是基础，更重要的是跟Oracle和DB2的兼容性做的如何。

自上而下，大刀阔斧的搞改革创新固然好，但天时、地利、人和更难得。

目前，工作尚 处于前期准备阶段，未来凿墙路上，满是荆棘，任重而道远。

潭主后期会适时更新凿墙实战系列，敬请期待！

差一点就忘了揭晓答案： 去年底厂商血拼之后，今年初听闻OceanBase以微弱优势中标，率先拿到了一张世界500客户的入场券。

- END -

---感谢阅读。如果觉得写得还不错，就请点个赞或“在看”吧。

文章仅代表个人观点，与供职单位无关。