PostgreSQL改造成一款企业级数据库，该如何下手

这个话题我一年半年前在《PG离企业核心应用数据库还有多远》一文中国也谈到过，随着对PG理解的越来越深入，我发现这个话题的内容也不断在扩大。想做好一款能够支撑关键业务的企业级数据库产品并不是那么容易的事情。虽然我们有大量优秀的开源数据库，但是把开源代码改造为一个真正意义上的企业级数据库并非易事。

PG是款不错的数据库，其功能相对来说比较完善，具备作为大型企业级数据库的基本特征。但是作为一款企业级数据库而言，还有很多不足的地方，必须加以改造才能够胜任。很多国产数据库也是基于PG的源代码进行改造开发，如果要让这些数据库成为一款企业级数据库产品，也必须要关注这些问题。

不知道国产数据库厂商的产品经理有没有意识到，其实PG数据库作为一款企业级数据库还是有很多不足的地方的。今天我就给大家分享一些PG数据库缺失的一些比较重要的企业级特征。

像FREEZE和VACUUM这样的老生常谈我就不细说了，这是地球人都知道的事情，也是PG永远的痛。

作为一款企业级数据库最为重要的是数据的完整性和安全性。在这方面PG数据库存在几个比较明显的不足。首先是数据库对数据完整性的校验不够完善，以前我也写文章提出过在PG数据库里面，一张表如果比较大，需要用多个文件来存储，如果丢失了一个或者数个数据文件，目前PG的RDBS核心是没有办法感知到的。此时如果要扫描这张丢失了某些数据文件的表，RDBMS不会报错，但是会得出错误的查询结果。

这个问题我以前也写文章讨论过，当Oracle的数据文件被破坏的时候，RDBMS也不会马上感知到，但是如果扫描某张表的时候访问到了被损坏的文件或者数据块，则能够发现问题，企业级数据库系统不需要随时感知到错误(这个成本太高)，但是不能回答错误的答案。

第二个问题是PG数据库对自己的数据文件临时文件的清理工作是做的不完整的。当数据库出现一些问题的时候，或者出现一些异常的时候，是不会自动做清理工作的时间长了就会产生一些垃圾，包括一些孤儿文件。对于一个需要长期，甚至7*24运行的数据库系统来说，自动清理垃圾是必备的能力。

因为缺少PMON/SMON之类的后台进程，当BACKEND的故障的时候，无法由系统自动进行必要的清理工作，因此可能会导致数据存在不一致的可能性，PG可以采取保护措施，让PG数据库宕机。这种方式虽然是有效的，但是这种做法不是一个企业级数据库应该有的。想要让PG数据库在这方面像一个企业级数据库一样就必须建立一组新的后台进程，从而实现像oracle一样能够自如的应对各种系统故障以及进程故障。

试想如果一个企业级应用中因为某个用户进程出问题，如果使用Oracle那么我们杀掉某个进程就搞定了，而如果换成PG数据库，杀还是不杀呢?杀了如果整个实例宕了怎么办?让PG数据库能够自由杀用户进程甚至一些不影响数据库运行的后台服务进程，是让PG成为企业级数据库的不可或缺的条件。

类似RAC的能力也是企业级数据库必须就有的能力，无论什么情况下，当某个实例故障时能够快速、自动、0数据丢失地切换是企业级应用对数据库的基本要求。对于RAC，其实绝大多数用户不需要RAC的横向扩展能力，而是需要其高可用切换能力。现在很多基于PG开发的国产数据库都在做类似RAC的功能，目标都是对等访问，横向扩展。其实我觉得这么做可能是劳民伤财。ASTORE如果不改掉，想做出优秀的RAC架构的共享存储对等访问集群来，几乎是不可能的。

实际上如果PG数据库能够具备共享存储，读写分离能力，就已经足够了，类似ORACLE 两节点时的ACTIVE-STANDBY模式，这个模式在二十年前在一些核心业务系统中被我推荐使用。如果PG数据库具备类似的能力，当某个实例故障后能够在几十秒内实现业务完全切换到STANDBY实例，那么应对企业级关键应用已经足够了。前阵子在电科金仓的一个活动中，金仓给大家演示了自己的RAC系统，当时很多用户都觉得这确实是他们急需的功能。

当前基于流复制的高可用方案其缺点就是对于关键业务系统来说，快速的全自动切换实现起来十分困难。因为只有复制完成，并且数据确保0丢失情况下，对于关键系统才敢做自动化切换，而目前的流复制模式还是不够让人放心。基于RAFT/PAXOS复制组的实现，只要确保延时够低，也是可接受的。不过成本略高，而且保护能力并不完整。Oracle RAC+ADG的MAA架构已经被证明是目前最成功的的高可用架构。

本来想写篇短文，没想到才写了几个点就已经这么多了。后面我简单再列几点问题吧：

1. SQL引擎增强：PG缺少不少算子，比如HASH ANTI JOIN等，企业级应用十分复杂，如果数据量比较大，业务逻辑相对复杂，缺失算子的问题会导致某些业务无法快速执行，有兴趣的厂商可以把PG的算子与Oracle做一下比较，看看还缺点啥，缺啥补啥吧;

2. 分区表功能与能力向Oracle看齐：大型企业级应用，分区表的使用十分多，虽然PG也有分区表，但是其管理便捷性，访问性能，对于超过1万分区的大型表的支持能力都还很欠缺。另外类似分区分裂、交换分区之类的能力也尚有缺失;

3. 全局临时表性能优化：PG的全局分区表功能虽然和Oracle差不多，不过一些国内的ERP厂商已经领教过了PG的全局临时表的性能问题，前些年在分析一个全局临时表的性能问题的时候，我也读过这部分PG的源码，写得真的不怎么样;

4. 表的在线重定义：需要长期7*24运行的企业级业务系统，对于超大表的再现重定义能力十分关键，Oracle做好这个功能都花了近20年的时间，国产数据库厂商也需要下点力气来做;

5. SHARED BUFFERS越大，DROP TABLE等操作越慢的问题：这是因为PG的CHECKPOINT机制不够优化导致的，Oracle当年为了优化这方面问题，对kcbdws数据结构做了多次优化，对CHECKPOINT QUEUE，LRU-W等链表的算法做了多次重构，才达到了目前的水平，基于PG的国产数据库也必须在此做大量的优化;

6. 复制延时控制：有效控制复制延迟，优化并发回放的性能;

7. 企业级备份管理器：试过备份上百个TB的PG数据库吗?能够让几十TB的PG数据库在周末晚上的有限备份窗口中完成全备，避免影响第二天的业务高峰性能吗?如果不能，那就去优化吧。