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