整体介绍

历史：

  • 2002年成立
  • 2004年开始MySQL项目(手动分表)
  • 2008年用于腾讯充值
  • 2009年开始PG版
  • 2010年用于财付通，并有自动分表
  • 2013年部署到微众银行
  • 2015年用于公有云
  • 2018年，适配分布式共享存储、自研存储引擎
  • 2020年，和更多的厂商对接
    image

目前服务的企业有：

  • 张家港农商银行
  • 国家统计局
  • 国家医疗保障局
  • 中国银行
  • 平安银行

全球6个研发中心，
北京、上海、成都、西安、深圳、硅谷
团队600+ ，内核研发260+

腾讯云数据库产品家族：
image
从上图看，是基于MySQL、PG为底座，在上面做了大量开发，变成了分布式版
之后又增加了很多基础性工作，如灾备、迁移、备份、告警、故障迁移、调度等
另外还加入了NoSQL系列、并做了国产OS、CPU适配
还有一体机

输出形态：

  • 公有云
  • 私有云
  • 独立部署
  • 一体机

售卖模式：

  • 按物理节点
  • 按CPU核数
  • 一体机
  • 战略合作

国产化战略
image

TDSQL mysql版本，自研代码 150W行，超过总量50%
2020年通过 工信部 认证的 创新解决方案企业 上下游企业互认证、参与国家标准制订、相关专利研发等

合作伙伴：
金蝶、文思海辉、金仕达 10+

产研生态
image

案例

微众银行核心交易系统
image

部署架构
image

张家港银行
image

平安银行
image

第七次人口普查
image

中国农业银行
image

中国银行
image

数据库迁移

迁移过程 image

迁移解决方案
image

迁移步骤
image

迁移架构
image

售后体系

交付过程
image

交付体系
image

交付能力
image

人才储备
深圳、北京总部：100+交付服务领域专家
区域：400+资深项目专家、技术专家、售后顾问，
其中技术专家包含9大技术栈，涵盖云主机、存储、网络、中间件、容器、数据库……
本地化：2500+本地工程师，按项目需求进行本地化布局，覆盖19个省份，主要分布在在北京、上海、广州、深圳、成都等一、二线城市

服务流程
image

总结

  • TDSQL发展过程跟阿里的oceanbase很类似，差别是TDSQL基于开源修改的，阿里是从零开发的
  • TDSQL有单机版和分布式版，单机版完全兼容mysql和PG协议，分布式版不完全兼容，增加了一些语法
  • 从文档看目前mysql更完善，修改源码150W+(总占比超过50%)
  • TDSQL基本的架构基本没有变，应该是增加了非常多的辅助功能，包括自动分片，自动扩容，同步性能优化，以及非常多的运维、监控相关逻辑
  • TDSQL先是内部试用到推广、再到上云、最后跟企业合作(银行类较多)，现已通过工信部认证，并跟国产OS、CPU做了兼容
  • TDSQL的发展路线也是国产化，并去Oracle，这点跟我们的很类似，只是他们比较偏OLTP方向

MySQL版

面临的问题：

  • 数据一致性
  • 服务可用性
  • 扩展性
  • 安全性
  • 数据库优化

部署方式：

  • 公有云
  • 专有云
  • 独立部署
  • 一体机

兼容性
集中式数据库实例：完全兼容MySQL5.7、8.0或MariaDB 10.1 10.4等版本
分布式数据库实例：高度兼容MySQL5.7、8.0或MariaDB 10.1协议或语法

架构

整体架构如下： image
一个 Set 类似一组分片，包含主从，一主多从，agent负责监控
请求先发给负载均衡，可以用 F5、或者 nginx等搭建
负载均衡 -> SQL引擎，这个引擎有点类似的 GreenPlum的主节点，无状态，可以部署多个
然后解析SQL并发送到具体的 Set，可能会有SQL拆分动作，另外这个SQL引擎还支持分布式事务
架构引入了 Zookeeper ，这个像是管理元数据表的，请求先拿到元数据表获取具体的位置，然后再请求真实的表
Zookeeper应该是还负责对元数据表的修改，保持强一致性
文档上说配置管理和决策调度是基于 raft协议的

其他的还有 采集监控、系统管理、数据库同步、备份、审计等功能
从这个架构看，改动很大，基本上就接近NoSql了

云数据库虚拟化是介于 “服务器虚拟化”和“共享软硬件资源”之间的一种方案
一体机，通过国产适配

强同步复制

这是对原生MySQL的增强
原生的复制方式：

  • 异步复制
  • 半同步复制

TD-SQL增加了，并行化的强同步复制，保证数据一致性
image

强同步情况下，主库同步过程中会卡主
22

intel 做的性能测试对比
23 他们还做过一个测试，每秒随机插入2W行数据，然后直接杀掉主库，切换到备库，数据验证完全一致

基于raft做的强同步复制机制

  • 基于Set机制的同步机制：TDSQL同步均是在Set之内实现，每个Set之内存在多个主从数据节点，而 Raft算法中的Leader即此处的主节点，Follower即从节点。工作时，主(Leader)节点接收来自客户端的请求，并向Follower同步请求日志（Binlog）。
  • Leader选举：TDSQL的计算/存储节点本身无法直接参与选举的，在TDSQL是通过Scheduler模块来负责选举的。如果主机发生故障，Scheduler会从两个备机中，选择一个数据较新的备（MySQL的 Binlog日志是严格有序的，所以哪个同步主机binlog的偏移量更大，谁的数据就更新，对应的也会被选为主机。
  • TDSQL的每一个分片都支持基于强同步的高可用方案，如果主数据库故障时，系统将立即自动选举出最优备机顶替工作，切换过程对用户透明，且不改变访问IP，并且对数据库和底层物理设备提供7X24小时持续监控。如果发生故障时，系统将自动重启数据库及相关进程；如果节点崩溃无法恢复，将通过备份文件自动重建节点

24

在开启强同步复制的情况下，故障自动转移相关指标如下：

  • 同城单中心，RPO=0，RTO≤30s（含故障检测时间，可配置调整）
  • 同城双中心，RPO=0，RTO≤40s（含故障检测时间，可配置调整）
  • 异地多中心，RPO≤15s（异步复制），RTO≤5min（含故障检测时间，异地需手工切换）

弹性扩展

新增分片扩容过程
image

TDSQL的整个迁移过程：

  • 迁移存量数据
  • 迁移增量数据
  • 数据检验
  • 再追增量
  • 切换路由 -清理

image

闲时超用，在一台物理机器上A、B两个应用，当B空闲时，允许A抢占B的资源(CPU、IO)，但不能超过B的底线

读写分离

  • 只读帐号（推荐方案）：您仅需要在创建帐号时，标记为只读帐号，系统将根据只读策略向将读请求发往从机；只读策略可以根据主从延迟等维度进行灵活配置。
  • /slave/注释（推荐方案）：您可以在编程过程中，通过注释/slave/，系统将把该条语句发往从机，常用于编程阶段将特殊的读逻辑嵌入代码。
  • 全局自动读写分离：您可以开启全局自动读写分离，该配置会自动将SQL中的读请求发向从机，且能识别事务、存储过程中的读语法并灵活处理。当然如果从机延迟较大，全局自动读写分离并不具备策略。
  • 只读实例：您也可以自建或申请只读实例，只读实例是专用于读请求的一种实例，不参与高可用切换。

热点数据更新/插入时，有一个全局hash表，频繁更新时，不会触发 innod的行锁，而会卡主hash表上
27

安全

对于管控系统，TDSQL对每一个功能操作均设计权限，并通过角色能力进行控制；并默认内置系统管理员、安全管理员、审计管理员形成三权分立的管理格局；身份认证与访问控制均符合等级保护三级或以上要求

提供定期高可用灾备，定期对数据做校验 表空间加密、字段加密 符号国家安全标准，TD-SQL是跟 北京炼石网络技术有限公司 合作的 数据传入加密
SQL防火墙，对SQL进行预先解析

审计日志

  • 服务器操作审计，腾讯云自研的铁将军系统提供
  • 数据库SQL审计，腾讯云数据库审计系统完成
  • 系统操作日志，赤兔运营系统的操作日志提供

数据库SQL审计需要额外配置Elasticsearch

基于内核层面的安全改动：

  • 慢速删除：当用户执行drop table或alter table … drop partition 指令时，数据库没有立即删除表空间文件，而是将其重命名，将其在后台逐步缩小并最终删除。
  • 防止误删元数据：只允许已授权用户登录系统，删除存储元数据的库表，以防止用户误操作导致业务不可用
  • 禁止非授权用户安装插件
  • 禁止非授权用户访问物理服务器文件系统
  • 延迟复制：TDSQL提供主从之间延迟复制配置

运维

提供两套平台
赤兔系统
云数据库管理系统
提供TDSQL的全部运维功能， 可管理TDSQL集群的物理资源、调度决策系统、备份与恢复系统、可用区管理、实例管理、智能性能分析与监控告警等，主要用于公有云腾讯内部。
特点

  • 拥有完善的运营操作体系：平台可以管理TDSQL不同版本，封装接口近“五百”个。赤兔总共支持100多项运营操作，覆盖超过95%的运营场景，贯穿TDSQL整个运营生命周期。
  • 全面的监控告警策略：平台对TDSQL所有关键模块，例如db、proxy、zookeeper、manager等的运行指标采集，并扩充了服务器的性能指标
  • 高效的性能分析工具：基于海量的运营数据，结合DBA智能诊断系统(扁鹊，貌似跟机器学习结合了)，能够快速帮助业务预防、发现、定位并解决问题；通过分析锁、事务、SQL、表结构等信息，得出优化SQL的建议
  • 支持庞大的云数据库集群运维：赤兔运营系统，不仅在内部的公有云中使用，还为客户的私有云服务；支撑各类海量的业务系统数据库和云数据库集群

运维能力

  • 实例管理：用户可以创建TDSQL的集中式实例、分布式实例、分析型实例，并在实例列表页面查看、变更配置、隔离并销毁实例等操作
  • 系统监控与告警
  • 参数管理：用户可以利用控制台的参数设置，管理数据库引擎配置
  • 备份与恢复：TDSQL提供将数据库定时备份到指定存储位置的能力，备份方案支持物理备份、逻辑备份、增量备份等多种方案。备份系统可支持HDFS，NAS，COS（腾讯对象存储）等方案。
  • 在线修改表结构：TDSQL在赤兔运营系统中支持对数据库的表在线修改表结构

智能性能分析（又名扁鹊、DBBrain）是TDSQL提供包括数据采集、自动处理、性能检测、SQL性能检测、业务诊断等多种智能工具的集合，并根据分析结果提供智能优化建议

  • 性能检测与健康评估，结合了深度学习
  • 实时检测
  • 慢查询分析
  • SQL优化

数据库智能管家（TencentDB for DBbrain，DBbrain）是腾讯云推出的一款为用户提供数据 库性能、安全、管理等功能的智能运维平台

  • 提升数据库稳定性：7 * 24小时智能运维守护数据库
  • 提高管理效率：自助式智能服
  • 增强数据库安全
  • 节省运维成本

兼容性和分片

集中和分布式

  • 集中式实例：可以理解为MySQL/MariaDB主从高可用架构的数据库，因此其完全兼容MySQL/MariaDB。
  • 分布式实例：像使用普通MySQL一样使用分布式数据库。淡化水平拆分的概念，无需手动配置分表逻辑，无需额外部署管理中间件，只需要在建表时指定分表关键字即可。分布式实例也高度兼容MySQL

字符集，支持主流的
支持时区
数据类型，兼容全部MySQL数据类型，还支持部分Oracle的数据类型
函数，支持超过200个，看起来有些是不兼容的

TDSQL默认采用Hash方式进行分散，以求相对的数据均衡；同时支持Time和Range分表方案。
TDSQL分布式实例在创建表的时候，要求SQL语句中显示指定拆分建Shardkey

1

create table tb1 ( user_id int not null,age int not null, place char(20) not null,primary key(user_id, age) ,unique key(user_id, place)) shardkey= user_id

写入过程 28

根据 shard-key 读取过程
29

读取过程

  • 如果SQL语句有明确带Shardkey字段值，数据将直接从对应的分片取出，此时效率最高
  • 如果SQL语句没有带Shardkey字段值，SQL命令的请求将发往所有分片，并在SQL Engine中聚合在反馈给业务，此时效率会略差。

如下是 逻辑表，物理表
30 SQL为用户提供了三种类似的表：分表，广播表及单表

  • 分表：分表即自动水平拆分的表（Shard表），水平拆分是基于分表键（Shardkey）采用类似于一致性 Hash 方式
  • 广播表：广播表又名小表广播功能，创建广播表后，每个节点都有该表的全量数据，且该表的所有操作都将广播到所有物理分片（Set）中
  • 单表：即无需拆分的表，又叫做普通表，目前单表都放在第一个物理分片

拆分键的限制

  • Shardkey需要是主键以及所有唯一索引的一部分
  • Shardkey字段的类型必须是int,bigint,smallint/char/varchar
  • Shardkey字段的值不能为中文，因为Proxy不会转换字符集，所以不同字符集可能会路由到不同的分区
  • 不要Update Shardkey字段的值
  • Shardkey=a 放在SQL语句的最后
  • 访问数据尽量包含shardkey字段，否则不带Shardkey字段的SQL语句会路由到所有节点

分布式事务 一个事务不会操作全部分片，仅需操作1~2个分片（如转账业务），再加上TDSQL的MPP架构的原因，因此一个分布式实例操作多个分片的分布式事务性能可以叠加。 image
对于涉及跨分片的分布式事务，我们建议业务开发时，可以平衡性能和开发难度，或将事务进行拆解，巧妙设计或引入一些等待机制，以优化用户体验

分布式Join分为可下推和不可下推
可下推Join，是指可在存储层直接Join的情况，通常包括

  • 同纬度（拆分建）的Join：两张表采用相同的拆分键，例如：SELECT * FROM user JOIN user_order ON user.user_id=user_order.user_id；由于user与user_order均以user_id为拆分键，因此同一用户（User_ID）的记录位于同一分片上，Join直接由底层完成，此时性能最高
  • 分表与广播表的Join：由于所有分片中都存在一个完整的广播表副本，因此分表与广播表的Join也可下推到存储层执行。

不可下推的Join，是指需要由存储层和SQL引擎层共同完成的Join，通常包括单表与分表的Join，分表与分表且不同字段的Join等，腾讯云优化不可下推的分布式Join。
分布式实例也支持子查询、函数等复杂语句

物理分片等同于SET数，但不一定等于逻辑分表
了普通的分区表（partition）外，TDSQL支持在分表的基础上再次进行分区，简称又名二级分区，提供包括range、list、time等分区方案。无论哪种方案，均可继承分区表的多种优势，诸如提高历史数据删除效率、提高某维度的统计效率等

优化
支持 RBO 和 CBO
内置了 18种 CBO 规则

TDSQL全局唯一数字序列（以下简称Sequence，使用的是unsigned long类型，8个字节长），使用方法与MySQL的AUTO_INCREMENT类似。目前TDSQL可以保证该字段全局唯一和有序递增，但不保证连续性

其他

兼容 JSON
对比 MongoDB
32

支持 RocksDB 引擎
DTS-DBbridge，支持异构数据库 和 同构数据库之间迁移
比如 Oracle -> TD-SQL

专有部署

整体架构
33

模块介绍

  • SQL引擎层/DB：可以混合部署在同一物理机中，也可分离部署；此模块对CPU和磁盘性能要求较高，建议采用较高配置的CPU和SSD存储，如考虑高可用性能需2台起部署。
  • 赤兔运营系统：可部署在虚拟机或物理机中，建议为1/3/5等基数台部署。
  • 负载均衡模块：提供虚拟IP，数据库负载；目前支持LVS、腾讯云网关TGW、腾讯私有网络VPC等开源或类似于F5等商用负载
  • 云数据库管理系统：云数据库管理系统需与腾讯专有云TCE合并安装。用于提供类似于集团云、行业云、政务云等场景下的租户端使用。
  • 数据备份系统：目前支持分布式文件存储系统HDFS，腾讯云对象存储COS，网络存储NAS等系统进行备份。
  • OLAP扩展：指分析型数据库扩展，通常需要≥3台物理机。
  • 支撑组件：指数据库审计、数据同步等其他功能，若不安装不影响数据库核心功能。具体需求请咨询腾讯相关工作人员
  • 数据同步/迁移功能：支持两个数据源之间的数据实时同步，可应用于本地数据灾备、查询与报表分流、商业智能分析（BI）及实时数据仓库等多种业务场景

中档配置
34

中高档配置
35

同城双主架构
36

两地三中心
两地三中心即在同城双中心的基础上，增加一个灾备中心。
37

产品优势和案例

强同步复制，保证数据不丢失
监控、运营、恢复体系
基于云的数据库，闲时超用策略，读写分离方案、RocksDB、热点更新等
符合国家安全认证、国产适配兼容

腾讯云合规性
产品团队建设了完善的产品、研发、测试、交付、运维等组织架构
产品销售团队覆盖金融、保险、政务、泛互等多个行业及覆盖全国所有一线城市

案例

  • 第七次人口普查，支持了十亿级用户数据、七百万个终端和百万级峰值TPS
  • 平安银行，将核心系统从IBM Z系列大型机架构迁移至国产分布式系统，信用卡业务系统在新的设计规划也同样采用分布式和单元化拆分等新技术。
  • 富士康米大师，基于腾讯TCE+TDSQL数据库的工业互联网平台

政务行业常见业务场景

  • 政务数据向市省部级汇聚，各个烟冲项目
  • 智慧城市数据平台，同上
  • 网上政务服务平台，覆盖广、需求多、弹性大等

金融行业常见业务场景

泛企业行业常见业务场景

  • 电子商务与生活互联类场景
    • 国内外绝大部分规模电子商务、生活互联（O2O）平台都是基于分布式数据库，当科技公司、零售制造、创业公司等筹建相关网站时，就应该考虑到该网站未来面对的性能、容量弹性和诸如秒杀、抢购等业务挑战
    • 拼多多的核心数据库全部用的是TD-SQL
  • 交通/运营商/文旅/教育类场景，具有明显的峰值峰谷特征，例如上下班、节假日、寒暑假时的业务量是日常情况的数倍
  • 物联网IOT等场景
  • 游戏场景，历史记录，交易记录扩展问题，TDSQL可解决类似全区全服的扩展
  • 去Oracle
  • 混合云业务，可支持跨云同步

物联网场景，有点跟 MatrixDB 类似

在工业监控和远程控制、智慧城市的延展、智能家居、车联网等物联网场景下，传感监控设备多、采样率高、数据> 存储要求高、数据规模存储规模问题凸显。TDSQL容量的线性扩展不仅可有效解决容量问题，其支持和 JSON 也 能让开发者用自己熟悉的协议开发系统。同时可扩展 LSM树方案，解决数据超量写入，以及让数据压缩率低至20% 以下，二级分区让冷热数据有效快速的分离处理，极大的降低了数据存储成本和冷数据处理效率。

总结

  • 从架构看，是完全为分布式、上云改造的数据库，跟普通的MySQL差别很大了
  • 从LB到SQL引擎，这块有点像Impala和GreenPlum
  • 主从同步是基于raft协议做的，并有强同步功能，同时性能还不差，这也是它宣传的亮点
  • 增加了Zookeeper做元数据管理，还有配套的数据备份机制，自动扩展机制，实现起来代码量应该不小
  • 审计、数据加密、内核层面的安全优化、跟国产OS、CPU适配
  • 运维系统，提供大量API方便管理，扁鹊系统基于机器学习提供监控评估、SQL优化，数据库管家基于扁鹊实现数据库自治
  • 单机完全兼容MySQL，分布式基本兼容MySQL，基于shard-key做分区
  • 对分布式事务做了改进，分布式JOIN同分片支持下推，内置多种CBO，支持RocksDB引擎
  • 提供公有云、私有云、定制部署、一体机方案
  • 在银行、政务、物联网、电商项目上运行多年，目前看总体比较成熟、稳定

腾旭给出的文档

TDSQL_整体介绍_-20210916.pdf
TDSQL-mysql技术白皮书.pdf
TDSQL-PG_技术白皮书.pdf