大家好，我是负责腾讯云关系型数据库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系列产品能力介绍与场景推荐，谢谢大家。