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