一、PostgreSQL引擎核心能力
PostgreSQL功能图
在MyBase中，PG引擎除了包含RDS所有的能力，还包含GIS、分词搜索、精准营销、复杂SQL、Oracle兼容扩展和图像识别等核心能力。
1.GIS
GIS是一个地理信息系统，随着移动的终端还有带GPS传感器的普及，实际很多的业务里都有经纬度的信息。
以共享单车为例，车内装有GPS系统，方便用户查看自己的行驶轨迹，同时后台可以做行为轨迹的分析，共享单车使用的热点等都与GIS相关。
针对GIS这块功能，我们有一个强大的时空内核研发团队在做支持，目前GIS相比较于开源的版本有50倍的性能提升，这里面主要体现在移动对象处理。
移动对象处理通常使用在*缉查等方面，例如*锁定了某位嫌疑人之后，可以通过移动对象信息查询到他的轨迹，根据嫌疑人的轨迹迅速锁定相似轨迹或有密切接触的对象，有效提高*办案效率，是一个具有特殊社会价值的功能。
2.分词搜索
分词搜索是PG引擎里的一大特色。
分词搜索目前广泛存在于各个业务场景，如文档系统，社交聊天系统等。单独建一个搜索引擎需要很大的成本，包含硬件成本，软件成本，维护成本等。
对于企业来说，首先本身数据库的数据量并不算很大，其次单独建立一个搜索引擎，意味着要将数据库的数据同步到搜索引擎，将会引出许多问题，例如同步的延迟，如果是异构数据库的话可能导致数据不一致，因此单独建立一个搜索引擎对企业来说，性价比十分低。
PG引擎内置的分词搜索解决了企业的这个难题，且相较于传统关系型数据库，性能提升了1000倍。
3.精准营销
精准营销常见于销售业务相关场景。
精准营销通常涉及根据用户行为构造用户画像，然后查询用户的兴趣点，根据用户的兴趣点进行搜索，这里我们支持了向量相似的索引。
我们根据用户本身的特征或商品的特征进行数字化，就会储存浮点向量。然后我们基于浮点向量做相似检索，这种方式相较于全盘扫描，性能上有提升了1500倍，在千万级别的向量里可以做到毫秒级的相似召回。
4.复杂SQL
随着业务的发展，如今的业务已经不像以前那样 简单的增删改查，完全没有连表的查询。如今的业务，特别是企业上云，许多企业的ERP系统、CRM系统里的关系都特别复杂，可能存在几十上百张表的关联。
PG引擎针对这一块做出许多优化，相较于其他引擎，PG的性能提升20倍以上。
5.Oracle兼容扩展
目前PG在数据库领域的地位与Oracle旗鼓相当，是一个功能全面的产品，因此PG引擎内置Oracle兼容扩展包，可以兼容最常见的一些数据类型、函数和package。
6.图像识别
PG引擎与蚂蚁联合推出的图像识别插件：pase，这个插件相较于暴力计算的图像识别，性能提升了2万倍，已经被广泛应用于新零售商店、银行网点。
二、使用云数据库服务给DBA带来的问题
（一）问题一：架构、监控、优化等
-
解决这些问题主要存在以下几个困难：
- 当无法解决架构问题时，许多用户会选择放弃原有数据库，选择其他类型的数据库产品重新构建数据库，这样往往导致原有的机器堆积，耗费高昂的人力、资源与精力，并且不一定能解决问题；
- 公司选择培养对应方面的人才来解决问题，但存在学习时间周期长，并且人才流失情况严重，对公司造成一定损失；
- 如果招聘相应的高端人才来解决问题，除了在招聘上的难度，还需要配备1对1的Backup防止特殊情况发生，这会造成工作强度不饱和，成本较高；
- 求助搜索引擎或者社区，响应时间过长，无法及时解决问题。
-
针对以上问题，使用PostgreSQL有以下几个优点：
- 上千位资深PostgreSQL专家组成的资源池，7*24技术咨询；
- DBA可以将更多时间投入到业务优化、架构设计等关键事务，消除能效比较低的重复劳动，为企业创造更多价值。
（二）问题二：Bug
Bug分为社区内核Bug与插件Bug。
-
常见的社区Bug解决方法：
- 报告给社区，用时1天左右；
- 等待社区修复，用时2~5天左右（理想情况）；
- 下载社区Patch，自行验证，用时5天左右；
- 制定升级计划，升级，用时1天左右。
-
常见的插件Bug解决方法：
- 报告插件作者，用时1天左右；
- 等待作者修复，用时5天以上，时长无法保证；
- 下载Patch，自行验证，用时5天左右；
- 升级插件，用时1天左右。
-
针对Bug问题，使用阿里云PostgreSQL有以下好处：
- AliPG兼容开源PostgreSQL，阿里云专业内核团队为AliPG代码兜底；
- AliPG与公共云一套源码，大量商业用户应用的选择，有BUG尽早修复；
- 用户可在云端点升级版本按钮，或配置自动升级任务解决问题。
（三）问题三：无法满足业务需求
当前开源数据库在某些情况下可能无法满足业务需求，用户需要有内核研发能力才能自己添加功能，例如以下常见的社区版本无法满足的安全问题：
- DBA、SA有权查看、篡改、删除敏感数据；
- 普通用户可以通过Security Invoker属性来设置陷阱函数；
- 敏感信息（例如用户密码）可能明文出现在SQL审计日志、历史SQL命令、共享内存（例如会话状态、pg_stat_statements跟踪会话）、DBlink视图、外部表User Mapping的定义中。
-
针对以上问题，使用PostgreSQL有以下几个优点：
- AliPG拥有大量商业用户，覆盖众多行业，AliPG围绕行业痛点，不断扩展实用功能；
- 自研插件18款（详见产品手册），覆盖GIS，冷热分离，分词搜索，图像识别，安全加固等场景。
三、PostgreSQL在MyBase的核心能力
阿里云提前洞察行业需求，用技术帮助客户突破商业边界。PostgreSQL核心能力主要体现在三个部分：更快的业务体验价值、更稳和更安全的核心业务必要能力，以下进行详细拆解分析。
（一）提升更快的业务体验价值：更快
阿里云在研发产品的同时一直与客户保持沟通与交流，了解行业场景存在的问题，阿里云基于这些场景问题做出如下优化：
- 图像识别、向量相似搜索
- 实时营销、用户画像
- 短视频、实时推荐
- GIS MOD移动对象处理
阿里云PostgreSQL使用了蚂蚁集团的人脸识别技术，在数据库里使用了新的索引结构。我们知道，如果要做到快速查询，需要在查询前做好预计算，或者让数据库存储适合查询。因此我们使用了两种图像搜索的算法，重新组织图像的特征值（即浮点），使得性能提升了20000倍。
我们通过与短视频或社交类行业的公司接触，根据用户的喜好在内核做了优化，在向量相似搜索方面取得了上千倍的性能提升。
实时营销中会有跟用户画像相关的数据组织，在移动对象的处理如协助*办案等方面也有一个性能的大幅提升。
（二）核心业务必要能力：更稳
- 更稳体现在Paas多租户场景：
大并发大量元数据、大量连接优化；
资源隔离优化。
在数据库中特别是在PG里面，如果连1万个连接再去跑TPCB的话，存在许多更新、插入的操作，导致性能直线下降。AliPG针对这个问题做了大量连接、进程内耗的优化。
所谓的租户业务场景如SaaS类的业务包含了许多企业，在这种数据库里会有上千万个Scheme，有许多原数据。这里可能出现资源之间相互争抢，某一企业使用时将资源全部用光，从而影响其他的企业。我们通过将资源隔离优化，从而使得企业在使用数据库时不会与其他企业产生资源争夺的情况。
（三）核心业务必要能力：更安全
-
安全加固场景：
1）敏感信息加密, 函数调用陷阱规避；
2）SGX全加密；
3）最大保护、最高可靠、最高可用模式；
4）Slot Failover。
PG的社区版本存在函数调用陷阱的问题，例如某用户创建了一个视图，视图后面调用的Fuction设置为Security Invoke，表示判断这个函数的权限时是以调用这个函数的用户的权限判断的。当该用户为普通用户时，他执行Drop Database操作时，系统会报没有权限。但是如果用户将drop database封装到一个函数，并且把权限设置为上述模式，同时用户将它伪装为一个常见视图，当某位权限较大的用户，如DBA管理员上线看见这个视图并被迷惑且同意该操作后，则会完成Drop Database操作，造成重大损失。
阿里云PG解决了这样的问题，这样的函数陷阱在阿里云云端数据库是不存在的。
我们还支持保护模式，最高可靠、最高可用模式，这些在PG社区版本里面是不支持的。这意味着我们可以在两节点里实现全同步、半同步以及异步的效果，满足了不同行业对数据库可靠性的要求。
关于Slot Failover。用户在用一个开源数据库时，通常会用数据库的流复制做HA，在主节点里创建Slot做逻辑复制，例如业务里的某些表希望同步到另外的B业务中，只需要同步若干表而不是所有的数据。包括做增量的数据迁移、数据同步或异构同步，比如我要把你数据库里的数据同步到我们的消息队列，然后再通过消息队列同步到其他业务，这是目前业界非常通用的做法。
如果是以上情况，在PG社区版本一旦主备发生切换，Slot位点会丢失，因为在从库里没有那个位点，从而导致业务上的故障。
阿里PG在主库里面创建Slot会同步到从库，从而保证发生HA时Slot的信息不会丢失，从而解决了把数据库里的数据增量同步到其他业务的问题。
（四）MyBase
有些用户担心使用RDS后不过*，那么PG引擎的MyBase是个不错的选择，它开放了OS权限，允许用户原来的系统整合到新系统，堪称RDS PLUS。
- MyBase具备以下特点：
1）既要: 全自动（DB全生命周期管理，自动化运维、诊断），解放双手
-救DBA于水火
2）又要: 自主可控，随心所欲
-开放OS权限开放数据库ROOT用户
-开放调度策略，自定义超卖，实现超高性价比
3）还要：低成本、可定制、有内核兜（背）底（锅）
-内核Bug快速Fix，提新功能需求有研发支持。