去年根据小说《输赢》改编的同名神剧开播，网上吐槽者众。
剧中，陈坤饰演的周锐完全不按套路出牌，敢说敢做，之前就有人说该剧天雷滚滚，笔者看过后深信不疑。
剧外，2021岁末，三家公有云分布式数据库大厂也在某世界500强保险集团激战正酣，杀红了眼。
DB江湖，万变不离其宗
如今，看过一轮主流分布式数据库之后，觉得下面这张图可以清晰展现大厂的产品线。
这一点TDSQL跟GaussDB很像，“开源行，我就行！”。
至于HTAP，听听就好，千万别当真。
TDSQL品种虽多，但要真凿墙（去IOE），还得用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，叫什么不重要，重要的是谁在用。
对于了解GaussDB架构的人来说，腾讯的TDSQL架构也是CN、DN和GTM这些组件
和套路。
- Coordinator（简称 CN）：协调节点，无状态计算节点，负责分布式数据库业务请求的接入，以及数据分发和执行计划，节点间对等，只存元数据，不存实际业务数据。
- Datanode（简称 DN）： 数据节点，执行CN分发的执行请求，存储业务数据的分片。DN是一个逻辑概念，多个DN可以部署在相同或不同的物理节点上，但主备DN间需要物理隔离。
- Global Transaction Manager（简称 GTM）：全局事务管理器，通过两阶段提交（Two Phase Commit）和全局时钟戳（Global Timestamp）策略来保证在分布式事务的一致性，同时管理序列（Sequence）等全局对象。
腾讯官方称TDSQL-PG的SQL语法完全兼容PostgreSQL，同时也兼容相当大部分的Oracle语法。
而GaussDB也脱胎于PostgreSQL内核，二者有点血缘关系。想当年PGSQL在国内挺冷清，到如今这般盛况，TDSQL也是功不可没。
综合看，TDSQL更像是从原来分库分表的业务模式中升级而来，再通过Sharding配合GTM实现了分布式，从而降低了应用开发的复杂度。
TDSQL的几个重要特性
特性之一：ShardMap
TDSQL除了跟GaussDB很像外，跟中兴的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）和容灾这样的功能留到后期再分享吧。
磨刀不费砍柴工
买房装修，墙不能随便凿，要先看看户型图知道哪儿是承重墙，然后再下手，潭主凿墙（去IOE）也一样。
TDSQL提供了一个叫DBBridge的工具，用于与Oracle的兼容性评估和性能评估。
有了DBBridge，就可以快速评估数据库迁移的工作量和风险，看看到底有多少“坑”，在正式开工前把坑都填平。
虽说目前很多技术问题都有了比较标准的解决案，但迁移评估与用户环境紧密相连，需要Case by Case处理。
迁移评估也是整个项目最开始，最重要的一环，这个环节做扎实了，后面就能运筹帷幄。
不干核心非好汉
售前讲产品，通常是王婆卖瓜，自卖自夸。但真落到具体项目上，其实有一大堆的前提条件，其中最大的难点就在于应用改造。
而对于分布式迁移改造，用户不同，诉求不同。
对于关键系统去Oracle，主要方式分两类：
- 平切换库
应用架构不做大的改动，只在数据库层面完成分布式数据库对传统集中式数据库的替换，项目通常由DBA负责牵头。
过程中最重要的技术点在于分布式数据库对于源端数据库的兼容性，兼容性越高，应用改造越少，可行性越大。
但可行性与否，全看用户源端的应用和数据库使用情况，完全是个性化的。
该方式看似简单，实则暗礁重重。
- 系统重构
兼容性之外，用户现有应用架构是另一个重要因素。
如果应用架构较陈旧，是否跟数据库一并配套迁移改造？如果一起做分布式改造，可能还会涉及企业架构改造，牵一发动全身。
当然也可以先换库，再做应用的分布式改造，这要看用户自己的策略。
此外，对于使用封闭技术栈的传统核心应用，这种迁移项目可能会演变成新核心上线，性质也就变了。
如果平切换库是个IT基础设施的项目，那系统重构通常就成了应用研发主导的大工程。
系统重构的项目周期，成本和风险都比平切换库高很多，同时新架构的应用和运维，对于现有组织也是很大的技术挑战。
收益与风险并行，该方式属于典型的先负重前行，再轻装上阵。
不过，系统重构项目也有其好处，迁移测试和系统割接更平滑可控，麻烦的是战线过长。
当从技术角度审视，云原生、分布式、多租户，随便那么拿出来都是降本增效的卖点。
从目前的情况看，几大分布式数据库厂商对于Oracle的兼容性都做了很多研发投入，产品之间的差异并不明显。
只要思想不滑坡，想法总比困难多
去IOE这件事本身就不是一件轻松愉快的事，关键是通过去IOE可以优化和提升现有系统的架构。
落实云原生，比肩云计算，敏捷，弹性，降本增效都是IT的工作主题。
况且，现在金融行业的信创之弓已开，看弓没有回头箭。
前期技术调研的时候，获知PICC和CPIC两家头部保险公司在自己的数据库系统替换上都不约而同的选择的TDSQL，足以证明TDSQL产品在功能、性能和可靠性上可以满足保险行业的业务需求。
当下我们正处于一个从闭源商业软件向企业开源软件转型的时期，开源软件优势在于效率、成本和自主可控，对最终用户而言上述目标还有点高不可攀，但开源造就的生态对于用户来说，增加了一定的透明度、选择权，也局部缓解了“厂商绑架”的问题。
总之，向前一步，无论好坏都会有个结果，最关键的还是行动。
从之前的产品了解来看，目前几家厂商的产品虽有差异，但是在去Oracle这件事上，都已万事俱备，只欠用户的东风！
第一次交流TDSQL时，腾讯在分享容灾和多活案例时提到了国内某保险公司的南北双活。
虽说这是Oracle十多年前在讲的东西，但侧面也反映出现其实在客户需求其实变化也不是很大。
过往之事，再无新奇!
