如何建设一个网站站seo流量增长策略

首先必须是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的RDBS核心是没有办法感知到的。此时如果要扫描这张丢失了某些数据文件的表，RDBMS不会报错，但是会得出错误的查询结果。

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

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

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

其它问题

• SQL引擎增强：PG缺少不少算子，比如HASH ANTI JOIN等，企业级应用十分复杂，如果数据量比较大，业务逻辑相对复杂，缺失算子的问题会导致某些业务无法快速执行

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

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

• 表的在线重定义：需要长期7*24运行的企业级业务系统，对于超大表的再现重定义能力十分关键；

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

• 复制延时控制：有效控制复制延迟，优化并发回放的性能；