PostgreSQL简介

上个周末,无聊的时候关注了一下PostgreSQL。第一次尝试去安装PostgreSQL,还是好几年前的事了,那是8.0版本刚出来,终于开始原生的支持windows了,所以在自己电脑上折腾了一个。不过那时候也仅限于安装了一次而已,甚至psql的命令行都不知道怎么用。

同样作为开源关系型数据库,MySQL在这几年获得了更多的关注。大量的互联网公司都基于MySQL来构架系统,也导致MySQL DBA开始火热,一大堆年轻有为的同学投入到其中,渐成燎原之势。MySQL数据库火热了,MySQL AB公司却被sun收购,现在又随着sun要投入Oracle的怀抱,而且欧盟已经无条件批准这个收购,只剩下中国和俄罗斯,大局已定。作为商业数据库的绝对老大,Oracle的这次收购,让MySQL的支持者感到了威胁,其创始人甚至发起了一场保护MySQL(有墙),阻击Oracle收购的运动。

这也是PostgreSQL的机会,最近PostgreSQL的开发节奏很快,8.5已经连续出到了alpha3版,在这个版本中,最吸引我的是hot standby,类似于Oracle11g的active data guard,hot standby也可以在恢复的同时提供读服务,而以往版本,PostgreSQL的物理备库warm standby,则只能处于恢复状态,一旦open,则需要重做,比较痛苦。PostgreSQL的很多特性,都和Oracle相当的类似,甚至有一家商业化的公司EnterpriseDB,在致力于将PostgreSQL打包,使得应用程序从Oracle迁移到PostgreSQL更方便,据说80%的Oracle应用代码甚至不需要做修改就能在PostgreSQL运行。因此,我在twitter上说,如果PostgreSQL在人机交互的工具和配置部分,能够更加友好一点,完全是一个影子版本的Oracle。

PostgreSQL也支持mvcc多版本一致性控制。不过其实现的机制和Oracle的不一样。Oracle是将变化的前映像记录到单独的undo段中,而PostgreSQL则只是将前映像(Tuples)上做个标记,如果是delete,则相当于是逻辑删除,实际的数据还是在原来的段中,如果是insert,相当于先delete,再insert,而且会在原来的记录上加一条指向新记录的指针,形成一个链表,查询的时候需要沿着这个链表找到一致的数据。这样会造成一个问题,一段时间以后,dml操作使得数据段和索引段中都有大量的前映像信息存在,会严重影响数据查询的效率。PostgreSQL的mvcc的这种实现方式,带来的一个好处是回滚非常快,只需要修改前映像上的几个标志位即可,而不像oracle需要从undo段将前映像再复制回来。但是,这种方便回滚,却会损失查询性能的设计思路,真的比较诡异。PostgreSQL中有一个专门用来清理这些旧版本数据的程序,叫做vacuum。在以前的版本中,需要定期执行vacuum来优化数据存储结构。这对于DBA来说,无疑是一件痛苦的事情。直到8.1版本,引入了autovacuum,系统可以自动来进行这些清理工作,终于人性化了一点点。

在8.3版本,引入了一个新的特性HOT(Heap Only Tuples),主要的目的是努力避免update造成的性能低下的问题。其实这个HOT,说白了很简单,对于update,要实现mvcc,其机制还是一样的,区别在于select,在沿着链表找一致性数据的过程中,如果发现这个检查过的版本已经没有任何事物在引用了,就会顺便把清理工作做掉,而不是像以前要等vacuum来做。因此这会加大一点select的压力,但前人栽树,后人乘凉,接下来需要访问这些数据的其他select就会快很多了,这和Oracle的延迟块清除其实有些类似的,当然两者的设计目的并不一样。



无觅相关文章插件,快速提升流量

6条评论

  • At 2010.01.23 11:48, P.Linux said:

    PostgreSQL属于学院派风格很重的数据库,Oracle属于商业风格很重的数据库。
    因而Postgre非常注重性能、算法方面的设计,人机交互上不太注重。Oracle则很注重商业效果,制造很多概念,人机交互上也做得比较好,注重的是使用者的喜欢。

    • At 2010.01.27 22:19, 八神 said:

      oracle的UNDO方式,对于查询的影响也比较严重,总是要根据ITL事务槽,对应到回滚段头,找到相应的UNDO块,这个也是IO的跳转,一个事务反复更新的话,UNDO链表也是很长,查询回溯引起的逻辑读也相当惊人
      不过PG这种现场标签的方式,回滚起来确实比较快

      • At 2010.01.27 22:30, NinGoo said:

        是的,mvcc不管用什么方式实现,update导致的链表肯定是存在的,否则没法实现不加锁的一致性读。Oracle可以通过设置undo的保留时间来更加灵活的清理已经没有事务需要的旧映像,而且原表所在的segment不会因为旧映像多而撑大。一个事务反复更新,这是一种极端情况了,呵呵。

        • At 2010.01.27 23:35, Marty said:

          还是微软安逸,根本就不支持一致读,省得伤脑筋

          • At 2011.03.24 00:08, InnoDB的多版本一致性读的实现 said:

            […] InnoDB是支持MVCC多版本一致性读的,因此和其他实现了MVCC的系统如Oracle,PostgreSQL一样,读不会阻塞写,写也不会阻塞读。虽然同样是MVCC,各家的实现是不太一样的。Oracle通过在block头部的事务列表,和记录中的锁标志位,加上回滚段,个人认为实现上是最优雅的方式。 而PostgreSQL则更是将多个版本的数据都放在表中,而没有单独的回滚段,导致的一个结果是回滚非常快,却付出了查询性能降低的代价。 […]

            • […] InnoDB是支持MVCC多版本一致性读的,因此和其他实现了MVCC的系统如Oracle,PostgreSQL一样,读不会阻塞写,写也不会阻塞读。虽然同样是MVCC,各家的实现是不太一样的。Oracle通过在block头部的事务列表,和记录中的锁标志位,加上回滚段,个人认为实现上是最优雅的方式。 而PostgreSQL则更是将多个版本的数据都放在表中,而没有单独的回滚段,导致的一个结果是回滚非常快,却付出了查询性能降低的代价。 […]


              (Required)
              (Required, will not be published)