Postgresql 9.1新特性

著名的开源关系型数据库PostgreSQL本年度的发行版，也就是PostgreSQL 9.1的第一个beta版本，于五月二号正式出炉。而新版本所包含的许多新特性肯定会令世界上的数据库发烧友们欣喜若狂的。新特性如此之多，我们肯定不能在这篇文章中全部介绍，因此我挑选了四个比较有意思的新特性呈现给大家：

事务控制的同步复制

去年，PostgreSQL 9.0首次在PostgreSQL中引入了“异步二进制复制”。基于这个概念，9.1版本也包含了一个同步复制的选项。“同步复制”意味着直到被主服务器和复制服务器均接收完事务时，事务才会返回给应用程序。这点就确保了即便在主服务器永久下线的情况下，任何已提交事务的数据都不会丢失。

通过NTT的开源和2ndQuadrant的努力，经过长达三年的开发，终于使这个特性最终达到顶峰，而这将使得日本的通信巨头NTT最终会把他们的大多数的Oracle服务器替换为PostgreSQL。PostgreSQL的集群项目PostgresXC是这个替换工作的另外一部分。

对于同步复制来说，事务在返回前需要被写到两个服务器的磁盘上，因此会在响应时间上带来很大的损失。为了缓解这种情况，PostgreSQL除了像其它数据库系统一样提供同步复制功能外，还额外提供一个可以基于每一次事务提交而做出同步或异步复制的控制功能。这将使应用开发者通过把一些不可丢失的关键数据（比如财务交易）和那些响应时间上要求高的不太关键的数据区分开，来优化系统系统的性能。

每一个复制节点（或“standby”）连接主机的时候，都会在它的recovery.conf文件中给自己指定一个名称：

    primary_conninfo = 'host=master01 user=replicator application_name=replica1'

然后主机会在它的postgresql.conf文件中为同步复制机设置一个优先级列表：

    synchronous_standby_names = 'replica1'

然后你就可以以同步或异步的方式提交事务了：

    -- commit synchronously to the standby
    SET synchronous_commit = 'on';
    UPDATE user_balance SET balance = 573.29 WHERE user_id = 40021;
    -- messages are not important, send asynchronously to the standby
    SET synchronous_commit = 'local';
    INSERT INTO user_messages VALUES ( 40021, 57843, 'HI!' );

PostgreSQL也支持一个同步复制节点的优先级列表，也因此支持更高可用性的配置。新的pg_stat_replication数据库视图允许数据库管理员(DBAs)监控数据库复制节点的状态，而其他的管理设置控制如果复制节点离线时做什么。PostgreSQL计划在未来的版本中支持不同的同步模式，比如拥有“quorum”同步的能力。后者是为了在改善相应时间的同时而不降低数据的完整性，即“同步五分之二的服务器”的复制。

Unlogged 表

迅速风靡的非持久型“NoSQL”数据库，比如Redis和MongoDB以及信誉卓著的Memcached，已经证明了存在着这样一类数据——比起响应时间来，崩溃之后的数据损失显得并不是那么很重要。EnterpriseDB开发者Robert Haas在PostgreSQL中加入了一个专门处理此类数据的功能：unlogged 表。

词语“unlogged”主要是参照保证了持久性写的transaction log而得出来的。如果数据库服务器关闭再重启后，unlogged表将被清空。然而，不像往磁盘中写数据那样漫长，你写到unlogged表的速度比你往持久性存储的表写数据的速度快20倍。你也可以把它想象成为一个全局的临时表或者“内存表”。

unlogged表旨在存储大容量但不是很有价值的数据。比如，许多PostgreSQL用户当前登录网站的用户会话记录在Memcached。unlogged表在数据仓库批处理过程中用来存储大量原始装载数据同样也是十分有效的。这些用途通过在用户的应用程序栈中减少单纯使用数据库目的的数据库来使PostgreSQL用户变得更轻松。

SELinux集成
另一个经过多年开发而第一次出现在PostgreSQL 9.1中的新特性是PostgreSQL和 SELinux的数据访问控制的一致性。NEC程序员Kaigai Kohei花了三年的时间开发了SE-PostgreSQL，它把label-based的数据访问规则的概念集成到了PostgreSQL之中。PostgreSQL是第一个拥有这个级别集成度的SQL数据库系统。

这个特性目的在于高安全性的环境，甚至于数据库管理员都对数据的访问有限制，比如国家安全数据库。安全策略是构建在系统或者网络层的，而通过SELinux现在可以被应用在表、视图、函数、列等等的权限控制上。这就使得不管这个数据是存放在文件中还是存放在数据库中，我们只需构建一个一致性安全策略就可以了。

LWN的长期读者一定注意到了SE-PostgreSQL在集成到主流的PostgreSQL时有许多的麻烦。其实，9.1 beta版本中的SE-PostgreSQL相对于原来的版本来说，基本上是完全重写的。首先，Kohei在其他黑客们的帮助下重写了所有的权限查询调用，加入了SELinux hook，这个特性可以在PostgreSQL编译的时候选择是否被启用。如果是non-SE-enabled模式就不会有任何SELinux的影响。第二，SE-PostgreSQL所有的管理和工具都移到了一个可选的加载模块当中。

最后，由于难以实现，某些控制从Mandatory Access Control中删除了。这其中主要的就是行级的访问控制，因为在如何实现它这方面还存在着许多未解决的理论问题。当然，这意味着Kohei还有许多工作要做。

扩展和PGXN
谈论可选模块时，PostgreSQL一个主要优势就是它的扩展能力。用户和开发者定义了数据类型、操作、函数并且集成到一起来支持许多类型的特定数据，包括基因，库存，数学，天文学，时间序列，地质学等数据。还有很多插件，比如支持队列的集成，同其它数据库系统兼容，和许多实验性的新特性。PostgreSQL中最著名的插件可能就要数PostGIS地理数据库了。

然而，PostgreSQL的大多数插件都很难被找到、安装、备份或者升级，这就限制了它们的使用，有时甚至使用户不得不重复开发它们好几次。这个情况在9.1中改变了。

首先，2ndQuadrant的Dimitri Fontaine创建了一个打包的概念，而这在PostgreSQL 9.1中被称之为扩展。通过把一系列的数据库对象打包为一个扩展，插件的增删管理，以及最重要的升级，都变成了轻松的脚本化工作。用户甚至可以根据机构内的数据库的定制需要来创建自己的扩展。

第二，PostgreSQL专家David Wheeler创建了PGXN(PostgreSQL EXtension Network)，“PostgreSQL扩展网络”。PGXN是仿照编程语言的扩展仓库，比如perl的CPAN和Ruby GEMs。PGXN给PostgreSQL用户提供了一个搜索和下载那些未同核心数据库一同发布的PostgreSQL插件的中心。当前正在开发的是一个包含了依赖跟踪的下载和安装一体化的工具，就像CPAN和apt-get一样。

PostgreSQL 开发

Postgresql的项目已经尝试在过去的几十年,改变其开发周期，补丁审查和版本发布。项目中最大的问题来源常常是提交新特性的人比代码检查者比例提高快很多。举例来说，在9.1版本中，将包含的新特性比9.0版的多，照理也比8.4版的多。

结果，项目参与者频繁讨论和修改开发周期来优化评论者，贡献者和开发者的时间。最近的讨论就围绕这个话题。