TDSQL-C for MySQL 版产品新特性

大家好，我是负责腾讯云关系型数据库 PG 系的唐阳，PG 和 MySQL 这两大开源数据库是全球开源数据库的扛把子，但是 PG 和 MySQL 最流行的开源数据库是有很大区别的，实际上从后端实现和整体的一个逻辑来看，它们都是关系型数据库。那么它们的区别到底在哪里呢？

**PG 大家都是只闻其名，不见其身，少见其使用。有一个原因应该就在于 PG 它实现非常严谨，PG 的实现严谨就带来了整体功能之后和它的使用会比 MySQL 会有一些不一样。再加上 PG 并未赶上互联网的快车，在互联网兴起的时候相关互联网 行业关注的功能并未实现，才有了现在的境地。

但 PG 的能力强大是毋庸置疑的，可以说是数据库中的瑞士军刀，这个瑞士军刀体现在何处？就在于它的插件能力上，它是一个一专多长的全栈式数据库。在可观的规模之内，什么都可以做，什么都能做。什么叫在可观规模之内？就是在一定数据量级之下，使用 PG 就能满足绝大多数的用户需求。

从业界上使用角度看，MySQL 经常会用于一些需要高性能处理的 TP 场景，也就是常见的在线业务，在比如说电商、直播、游戏的数据存储，MySQL 满足的是基本数据存储和使用能力。而 PG 常用于复杂查询场景下的业务功能，这个就是 PG 和 MySQL 在用户层最能够感受到的直接区别。

目前 PG 从自身能力来说，就可以称之为企业级数据库，本身功能也非常成熟。稳定性和性能都是相对比较线性的，线性在哪？就是可以充分的利用好系统，操作系统和服务器的资源，可以很线性的增加。比如我们的一个表，使用 MySQL 的话，达到一定量级别情况下，第一是性能下跌时间比较靠前，第二是扩容也不会太好的改善这个问题。但是 PG 不一样，它是呈倍数和线性增长，表的增加，但随着计算和存储规模再扩上去之后。性能下跌的曲线不会那么快，且下跌时间相对更滞后一些。

PG 本身的功能相对而言较多，运维细节会和其他数据库会有一些不一样，云上功能就是帮助用户把这些不熟悉的能力尽量简易化。

# PG 和 MySQL 的区别

**引擎：**

PG 在引擎方面是个堆表结构，和 oracle 一样，oracle 当然也支持堆表、支持索引表、支持其它的数表，但是 PG 在当前只支持堆表。MySQL Innodb 是索引组织表。

对于堆表而言，它就是像一个房子，存放物品只需要挨着顺序扔就好了。所以说在创建主键或者其他索引，所有的索引全部是二级索引，同每一个索引的开销都是同样的。但是带来一个缺点就是所有的索引查询都需要两次 IO，第一次查索引，索引之后查到之后再去查实际的表引擎，这个是 PG 引擎的特点。

MySQL 它是默认 Inndodb 的索引组织表，主键查询非常快，范围查询效率比较高，缺点就是插入性能没有 PG 好，主键不能太大，还有索引分裂问题，这个就是引擎上的一个区别。

**进程结构:**

PG 也是多进程结构，而 MySQL 是多线程结构，整体来讲，进程结构的优点是在多 CPU 的场景下利用率要比线程结构利用率要高，在 PG 和 MySQL 之间的区别就是 128 核的服务器上 MySQL 最大就用到这么多，但是 PG 可以再进行增加。至于其它的区别，比如说刚才讲到了多表连接查询，PG 的性能肯定是稳稳超过 MySQL 的，目前 MySQL 都不是很建议去做大量表连接。

协议上 MySQL 为 GPL 协议，PG 为 BSD 协议，BSD 协议更加开放，用户可以随便拿去用。

在线 DDL

在线 DDL 是 MySQL 引过来的一个概念，因为 MySQL 在线 DDL 很痛苦，PG 不一样，PG 和 oracle 类似，它的表结构是存在元数据的，如果说我们需要去改表结构。比如说加一个列减一个列，修改某一个列，不需要去搬迁数据的一些动作，只需要改元数据就好。

**数据同步方面**

我们当前默认采用是同步模式，必须得要求是 slave 接收到日志并落盘成功后，才返回信号给主节点的事务引擎，才表示事务结束。那么这个优势在于什么？就是我们数据是百分之百的完整保护，不会出现任何数据丢失。当然我们也支持修改为异步，修改异步之后性能相对来说就提高了，但是在它的某些极端场景下会导致数据丢失，这个就是区别。

**慢日志**。可以在实时的在控制台上看到我们 SQL 执行的一个情况，当出现了一些慢日志，马上就可以刷新到 SQL 列表当中。

**逻辑复制和订阅**。PG 本身是直接 wal 日志写到磁盘里面，但是 wal 日志是没办法自己拿出来使用的，而 PG 本身又支持了 logical replication，所以说我们是把 logical replication 这个功能放开给用户自己去用，用户可以去通过这个建立一个复制槽，去订阅我们的某一张表，某一个 Database 或者某一个 schema 里的一些相应对象。

**安全能力**。目前来说安全是控制台安全和数据安全两方面，一个通过我们 CAM 和安全组功能来避免我们的实例被其他外部的访问去攻破，也可以通过我们为今年下半年即将支持的数据加密功能提供相应的数据加密的数据安全的一些增强。

喜好推荐系统。这个是在两个版本 PG 都会有，就是 Roaringbitmap，这个在直接搜喜好推荐系统或者是搜 Roaringbitmap 就可以在我们的网上搜索到很多类型文章，可以说这是一个插件，这个能力是现阶段超大上亿级十亿级数据规模场景下，一个数据推荐系统的最好的数据存储解决方案了。

再说一下我们 TDSQL-C PG 版，TDSQL-C PG 版是我们功能的一个核心要点，也是 128TB 以内最优 HTAP 解决方案。生态上这个功能可能会说得比较靠后了一点，但是给大家展望一下未来的方向。

**首先第一个生态上要联动云函数做的事件总线就 EB 这个产品**，再加上 Serverless 做我们的最优报表系统场景。可以想象的是，当用户平时只有数据存储到我们这里，如果说没有任何的 SQL 查询的时候是不收任何计算存储的钱，只收存储的钱，这对于用户来说成本也是很低的。

当用户每天晚上或每周只需要去执行一个超复杂的 SQL，生成一个数据报表，通过我们的 BI 产品来进行一个呈现，用户只需要查询一下就可以了，对他来说成本、功能，再加上整个数据，结合 PG 本身数据大数据量查询的一个优势就可以解决掉这个用户查询了。所以说这个是我们希望结合云函数和 EB，再结合我们 Serverless 的一个产品形态来对用户提供更多的可能性。

说下 EB 这个能力，EB 在这所起到的一个重要的能力是什么呢？举个例子，当用户有一个通过账号表过来注册的一个新用户，他就可以通过我们数据库触发器，触发到我们事件总线，事件总线就可以发一个新邮件给用户。这个动作完全不需要用户在业务层开发，只需要数据库配置一下就可以。

底层存储，刚才也讲到了存算在我们存算分离的架构之上，实现一个容量的最大化，结合我们 RDMA 的相应管网的一些技术，提高我们的性能，最关键是加上分级存储功能，能够降低我们整体存储成本。

在计算层，我们基于 PG 单一引擎做 HTAP 提供更大的计算资源，刚才也讲到 PG 的一个优势能力就在于什么呢？能够更好地利用我们系统资源，CPU128 核以上正常可以使用性能也是线性扩展。

所以说计算资源也要支持很大，96 核、768 的一个内存计算节点都是可以支持的，至少是支持上百万的 QPS，单节点上百万。用户只需要再扩展一个只读加层就可以，直接就 200 多万，再加一个只读就是 300 多万，可以想象一下这个性能，涵盖 99.9%的业务场景都是 OK 的。

今天的介绍大概就是这些，以上就是 PostgreSQL 系列产品能力介绍与场景推荐，谢谢大家。