看到这个题目，可能很多PG爱好者就会有些不爽，PG数据库在一些金融核心系统中都已经上线了，为啥还提出“离企业核心应用数据库还有多远？”这样的话题呢？作为一个在数据库应用领域工作了三十多年的老兵，经历了数据库从简单的只是简单的存储数据（比如VMS/RMS数据库），到数据库成为应用的核心，再到应用的互联网化改造，从而解放数据库，再到现在的信创替代。在这三十年里，Oracle的发展思路是让数据库尽可能去解决应用中的痛点，让用户可以关注在应用本身，IT基础设施的复杂性尽可能让数据库来解决。这造就了Oracle现在的成功，其实也给了企业级核心系统需要的数据库打了一个模板，我们在选择企业级关键应用系统的数据库的时候，往往也会对比着Oracle来做分析。
这些年里，互联网企业的技术输出十分猛烈，他们带来了一种新的思路，那就是我们不需要过多的依靠强大的数据库，而应该让复杂的业务逻辑回归于应用本身，让数据库回归到主要是持久化数据这条路上。在自己的IT业务领域上，互联网公司的IT建设无疑是十分成功的，不过他们的经验其实无法被大多数传统企业真正地借鉴。传统企业的核心是业务，IT规模和IT的重要性也远没有互联网企业那么明显，因此企业在IT上的投入是偏低的，应用开发队伍的能力是偏低的，他们往往无法很好的掌握互联网企业玩得很好的那一套。在我见过的一些学习互联网IT建设模式的企业里，大多数都是学了个四不像。
在目前，以及可见的未来，数据库依然会在企业信息系统中承担核心作用，很多业务逻辑依然要依靠数据库和SQL来解决，因此如果今后企业关键应用系统依然需要依靠数据库来解决问题。目前虽然已经出现了一些利用开源或者国产数据库完成了Oracle数据库替代的成功案例，这些案例无不是一些IT技术能力较强，IT投入巨大的大型金融企业完成的。通过应用的大量改造，将大量的业务逻辑从数据库中剥离出来由应用系统自己来控制，从而避免一些因为数据库系统的问题而导致的业务不可控的问题。这些成功的案例背后是大量的建设投资和更大的运维成本。因此哪怕在这些企业里，这样的系统改造也只能局限在一部分核心系统中，而无法在企业IT里全面推广这种应用架构。这里主要的问题还是成本问题。
既然大量的企业核心业务系统依然还是要依靠数据库，那么目前PG数据库能不能承担这个光荣的任务呢？我个人觉得虽然如果硬上，也不是不可用，不过PG数据库离作为企业核心业务系统的数据库，还差那么一点点。主要差在哪里呢？
首先必须是XID 64，一个在极端环境下会FREEZE的数据库无论如何都无法承担关键业务系统的重任的，我们可以通过各种配置，提升硬件的性能，通过各种IT管控措施来尽可能避免在核心系统上面临FREEZE的风险，不过并不是每个企业都能做得很好，作为一个通用数据库产品，我们面向的是各种技术能力的客户，他们都会把数据库用在企业的关键业务上，因此作为数据库厂商，我们必须要在PG中解决这个问题。PG社区这些年也在努力解决这个问题，俄罗斯POSTGRESQLPRO的企业版数据库已经上线了XID64，我想这个问题在可见的未来一定会圆满的解决。
其次，提高LWLOCK的效率，LWLOCK是解决PG数据库内存并发访问的问题的，和Oracle的LATCH十分类似。LWLOCK的效率高低决定了SQL执行的效率，LWLOCK的代码优化是提高数据库整体性能的关键工作，哪怕在LWLOCK的核心代码中减少一两条语句，都会带来数据库性能与稳定性的提升。PG数据库是学院派风范的数据库，在设计上还遵循了对象数据库的思路，因此在内部数据结构上有些繁琐，访问这些数据结构的成本也就相对较高，优化LWLOCK的代码实际上是在为这种带来较大额外开销的底层设计买单。
第三，提高SHARED_BUFFERS的访问效率，以便于采用大型数据库缓冲来减少DOUBLE BUFFERS的影响。如果在一个关键业务系统中，同样一条SQL两次执行速度可能会差很多，甚至差数倍，对于应用开发人员和企业业务人员来说都是一件挺头疼的事情，不过这种事情如果出现在PG数据库里，那是很正常的。这是因为double buffers引起的。数据库的IO不是直接IO，而是BUFFERED IO，因此PG数据库是需要依靠OS的IO BUFFER来为IO访问提速的。包括预读机制等，大多依靠操作系统。DOUBLE BUFFERS虽然让数据库的IO 变得更简单了，但是对于应用来说并不友好，甚至因为DOUBLE BUFFERS的存在，我们不敢把SHARED BUFFERS设置的太大，怕因为OOM导致进程被杀。提高SHARED BUFFERS的访问效率，要从两方面入手，一方面是对于SHARED BUFFERS的管理相关算法的优化，对于BUFFER HEAD，HASH 链表等的管理需要更加高效，在SHARED BUFFER的HASH BUCKET管理上，消除ASTORE带来的负面影响，更高效的访问SHARED BUFFER，减少因为热块冲突而导致的LWLOCK争用。另外一方面是改造IO子系统，全面引入DIO，采用自己的预读算法，更为充分高效地使用操作系统的物理内存。
第四，优化BACKEND异常退出时的RECOVERY，PG数据库中有一个十分头疼的老毛病，那就是BACKEND进程是不敢随便杀的，如果被杀的BACKEND进程带有未提交事务，那么数据库在RECOVERY的时候对整个数据库的影响是很大的。当然我们也可以通过在应用中针对这个问题优化代码来避开这个坑，不过能够从数据库角度来解决问题，那不是更好吗。当然，要想在发生类似问题时处理得像Oracle那么平稳并非易事，需要对PG数据库的核心做大量改造，PG数据库缺少类似Oracle shared Pool的机制，让这个问题的彻底解决变得有些困难。
第五，极致高可用。核心业务系统的目标肯定是极致高可用的。Oracle数据库这三十年的MAA做得越来越极致。我们无法确保某个数据库随时都是不出问题的，大多数核心业务系统也能够忍受分钟级的系统不可用，以及十分钟内的故障切换。证券交易类的系统是无法忍受这种不可用的，这种情况下只能通过应用系统层面去解决。另外电力调度系统也是如此，电力调度系统是依靠双系统热备的模式来解决高可用的问题的，主备系统都在做相同的业务处理，只是备用系统产生的调度指令不执行而已。除了这些系统外，大部分系统只要在数分钟内恢复正常工作就问题不大了。不过这需要实现类似Oracle的MAA、GDS这样的高可用框架。
第六，0数据丢失。对于大部分业务系统来说，如果能实现0数据丢失是最好的，0数据丢失意味着主备切换的时候，应用系统不需要考虑数据丢失的问题。当然这个问题大部分还是能够通过应用来解决的，难度也不是很大。
第七，提升资源管理能力，特别是内存管理能力。PG数据库的内存管理能力还只相当于Oracle的8i时代，通过设置WORM_MEM等来控制BACKEND的内存使用，从而确保数据库系统运行的问题。引入类似Oracle PGA自动管理的模式，可以让数据库充分的，更高效的利用现代硬件提供的大内存，同时避免出现OOM，这一点对于核心业务系统来说十分关键。
第八，也是最重要的，是提升CBO优化器的功能。我之所以把这一条放到最后一条来写，那是因为这一点是最难的。和Oracle的CBO相比，PG的CBO优化器虽然比MYSQL要复杂的多，也强大不少，但是对于用户来说还是十分不友好，在很多情况下，用户不得不改写SQL来满足业务性能方面的需求。
PG数据库这些年发展很快，进步也十分迅速，大量用户对PG数据库用得爽的和用得不爽的地方也很多。我个人的一些看法也不一定能覆盖这些用户的需求，大家有什么需求，也可以通过留言和我探讨。目前很多国产数据库基于PG开源代码研发，或者和PG有着各种各样的渊源，我们的数据库厂商如果能够在这些领域做些优化，那么能够提供给用户的数据库产品就会让用户用得更好。我特别不喜欢一些数据库厂商对这些问题的态度，他们总是说这是因为你不会用数据库，或者说你可以多从应用优化上去做些工作。数据库厂商只有让自己的产品在用户使用时更加简单，才能算是自己产品做得很成功了。
