qyb的博客

PostgreSQL 9.1的新特性

New features in PostgreSQL 9.1
by Josh Berkus
May 2, 2011
翻译:王鑫

著名的开源关系型数据库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一样。

====
后面有部分内容没有完成翻译,感兴趣可去原文自行参考:http://lwn.net/Articles/440666/

Topic: sohulinux

Raw events and the perf ABI

http://lwn.net/Articles/441209/
By Jonathan Corbet
May 3, 2011
翻译:刘晓佳

====
The perf events subsystem often looks like it's on the path to take over the kernel; there is a great deal of development activity there, and it has become a sort of generalized event reporting mechanism. But the original purpose of perf events was to provide access to the performance monitoring counters made available by the hardware, and it is still used to that end. The merging of perf was a bit of a hard pill for users of alternative performance monitoring tools to swallow, but they have mostly done so. The recent discussion on "offcore" events shows that there are still some things to argue about in this area, even if everybody seems likely to get what they want in the end.

perf events 子系统貌似将在内核中全面应用:相关的开发非常活跃,并且已经形成一种通用的事件报告机制。不过 perf events 的原始设计是为了访问硬件所提供的性能监控计数器,而且现在仍然被用于该用途。对于使用其它性能监控部件的开发者,转向到 perf 子系统是一剂难以吞咽的苦药,好在基本上都转的差不多了。但最近关于 "offcore" events 的讨论,显示该领域仍然存在争议,even if everybody seems likely to get what they want in the end.

====
The performance monitoring unit (PMU) is normally associated with the CPU; each processor has its own PMU for monitoring its own specific events. Some newer processors (such as Intel's Nehalem series) also provide a PMU which is not tied to any CPU; in the Nehalem case it's part of the "uncore" which handles memory access at the package level. The off-core PMU has a viewpoint which allows it to provide a better picture of the overall memory behavior of the system, so there is interest in gaining access to events from that PMU. Current kernels, though, do not provide access to these offcore events.

性能监控单元(PMU)通常是和CPU联系在一起的。每个处理器都有自己的 PMU 用以监控自己的特定事件。一些最新的处理器(如Intel的 Nehalem系列)还提供了一个没有和任何CPU关联的 PMU,该例子里,PMU 是 "uncore" 的一部分,负责在包层面来处理内存访问的性能计数。这个 offcore PMU 能够为系统的内存行为提供更好的全貌,从这个 PMU 获得事件的访问会很有趣。然而,当前版本的内核并不提供对这些 offcore 事件的访问。

====
For a while, the 2.6.39-rc kernel did provide access to these events, following the merging of a patch by Andi Kleen in March. One piece that was missing, though, was a patch to the user-space perf tool to provide access to this functionality. There was an attempt to merge that piece toward the end of April, but it did not yield the desired results; rather than merge the additional change, perf maintainer Ingo Molnar removed the ability to access offcore events entirely.

依赖于 Andi Kleen 在三月份提供的一个补丁,2.6.39rc 版内核提供了这些事件的访问方式。有人尝试在四月末提供一个让用户空间的 perf 工具来访问该功能的补丁,但没有完成。因为任何相关的改变已经没有意义,perf维护者Ingo Molnar将访问 offcore 事件的能力全部移除了。

====
Needless to say, that action has led to some unhappiness in the perf user community; there are developers who had already been making use of those events. Normally, breaking things in this way would be considered a regression, and the patch would be backed out again. But, since this functionality never appeared in a released kernel, it cannot really be called a regression. That, of course, is part of the point of removing the feature now.

自然不必说,这种行为必然会导致 perf 开发社区的不快;有些开发者已经在用那些事件了。通常,这会被视为一个 regression,相关最新补丁被迫回滚。但是由于这些功能并未出现在正式发行中,所以也不能报告 bug 说发生了 regression,只是我们移除了一个特性而已。

====
Ingo's complaint is straightforward: the interface to these events was too low-level and too difficult to use. The rejected perf patch had an example command which looked like:

    perf stat -e r1b7:20ff -a sleep 1

Non-expert readers may, indeed, be forgiven for not immediately understanding that this command would monitor access to remote DRAM - memory which is hosted on a different socket. Ingo asserted that the feature should be more easily used, perhaps with a command like (from the patch removing the feature):

    perf record -e dram-remote ./myapp

Ingo抱怨道,这些事件的接口太底层了,用起来特别难。被移除的perf补丁有一个命令的例子:

    perf stat -e r1b7:20ff -a sleep 1

对非专家读者来说,无法理解这条命令是指示监控 remote DRAM(memory which is hosted on a different socket,貌似是关联在其它CPU插槽上的内存)访问。Ingo认为这些特性应该更容易使用才对,比如像下面这条命令:

    perf record -e dram-remote ./myapp

====
He also said:

But this kind of usability is absolutely unacceptable - users should not be expected to type in magic, CPU and model specific incantations to get access to useful hardware functionality.
The proper solution is to expose useful offcore functionality via generalized events - that way users do not have to care which specific CPU model they are using, they can use the conceptual event and not some model specific quirky hexa number.

他同时说道,这种不易用性绝对无法令人接受。用户不应该被期望能够通过键入魔术般地、CPU级的、特定模式的咒语去访问有用的硬件功能。合适的方案是通过广义的事件来揭示 offcore 功能。这种方式下,用户不必去关心自己用的CPU模式,可以使用集中的事件而不是靠离奇的十六进制数指定的模式。

====
The key is the call for "generalized events" which are mapped, within the kernel, onto whatever counters the currently-running hardware uses to obtain that information. Users need not worry about the exact type of processor they are running on, and they need not dig out the data sheet to figure out what numbers will yield the results they want.

关键是定义出广义事件("generalized events"),它们在内核中被映射为计数器,正在运行的硬件用之来获得那些信息。用户不用去关心他们运行的处理器的型号,不必去通过挖掘数据表来确定出哪些数字将给出他们想要的结果。

====
Criticism of this move has taken a few forms. Generalized events, it is said, are a fine thing to have, but they can never reflect all of the weird, hardware-specific counters that each processor may provide. These events should also be managed in user space where there is more flexibility and no need to bloat the kernel. There were some complaints about how some of the existing generalized events have not always been implemented correctly on all architectures. And, they say, there will always be people who want to know what's in a specific hardware counter without having the kernel trying to generalize it away from them. As Vince Weaver put it:

Blocking access to raw events is the wrong idea. If anything, the whole "generic events" thing in the kernel should be ditched. Wrong events are used at times (see AMD branch events a few releases back, now Nehalem cache events). This all belongs in userspace, as was pointed out at the start. The kernel has no business telling users which perf events are interesting, or limiting them!

批评主义者已经采取了一些行为。广义事件,是一个很好的东西,但是却无法反应所有的怪异的,每个处理器可以提供的特定硬件的计数器。这些事件应该在用户空间被管理,这样会更灵活,而且不必使内核膨胀。有些抱怨是关于为何已经存在的一部分广义事件并不能在所有的体系结构下总是被正确执行。而且,总是有人想去直接使用特定的硬件计数器而不是内核提供的抽象层。正如Vince Weaver所说:

阻止访问 raw events 并不是个好主意,甚至整个内核中的通用事件都应该被丢弃。(现况导致了)时而出现不合适的事件应用(比如以前一些版本里 AMD 的 branch events,现在的 Nehalem的 cache events)。这些都应该在最开始就明确是属于用户空间的事件。内核没必要告诉用户哪个 perf events 是感兴趣的,或者限制它们。

====
Ingo's response is that the knowledge and techniques around performance monitoring should be concentrated in one place:

Well, the thing is, i think users are helped most if we add useful, highlevel PMU features added and not just an opaque raw event pass-through engine. The problem with lowlevel raw ABIs is that the tool space fragments into a zillion small hacks and there's no good concentration of know-how. I'd like the art of performance measurement to be generalized out, as well as it can be.

Ingo回应到性能监控的相关知识和技能应该集中在一个地方:

我认为用户需要我们增加有用的,高层的 PMU 特征,而不仅仅是提供不透明原始事件传递的引擎。仅有最底层的原始ABIs的问题是,这将功能分割成无数的小的hack,而没有一种好的集中方式。我希望性能衡量的艺术更一般化,而且也可以做到。

====
Vince, meanwhile, went on to claim that perf was a reinvention of the wheel which has ignored a lot of the experience built into its predecessors. There are, it seems, still some scars from that series of events. Thomas Gleixner disagreed with the claim that perf is an exercise in wheel reinvention, but he did say that he thought the raw events should be made available:

The problem at hand which ignited this flame war is definitely borderline and I don't agree with Ingo that it should not made be available right now in the raw form. That's an hardware enablement feature which can be useful even if tools/perf has not support for it and we have no generalized event for it. That's two different stories. perf has always allowed to use raw events and I don't see a reason why we should not do that in this case if it enables a subset of the perf userbase to make use of it.

Vince同时宣称perf是一个重复的革新,它忽略了前辈的大量的经验。似乎看起来仍旧有些那些一系列事件的疤痕。Thomas Gleixner不同意这种perf是重复创新的实践,但是他也认为原始事件应该可被用(译者注:从ABI的层面被暴露出来?):

The problem at hand which ignited this flame war is definitely borderline,我并不同意 Ingo 所说没有必要提供原始事件接口。那是一个有用的硬件可实施的特性,即使perf 还没有支持它,而且我们也没有普遍的事件支持它。那是两种不同的故事。perf总是允许使用原始事件而且我也并没有看到一个我们不应该那样做的理由,如果它使得一部分用户群体利用它。

====
It turns out that Ingo is fine with raw events too. His stated concern is that access to raw events should not be the primary means by which most users gain access to those performance counters. So he is blocking the availability of those events for now for two reasons. One of those is that he wants the generalized mode of access to be available first so that users will see it as the normal way to access offcore events. If there is never any need to figure out hexadecimal incantations, many user-space developers will never bother; as a result, their commands and code should eventually work on other processors as well.

The other reason for blocking raw events now is that, as the interface to these events is thought through, the ABI by which they are exposed to user space may need to change. Releasing the initial ABI in a stable kernel seems almost certain to cement it in place, given that people were already using it. By deferring these events for one cycle (somebody will certainly come up with a way to export them in 2.6.40), he hopes to avoid being stuck with a second-rate interface which has to be supported forever.

讨论最后,Ingo 也认为原始事件很好,不过他的立场是大多数用户访问性能计数器不应该以访问 raw events 作为主要手段。现在他阻止这些事件的可获得性基于两个原因。一个是他想首先实现通用的访问模式,这样用户能以很普通的方式来访问 offcore 事件。如果没有任何必要去理解十六进制的咒语,许多用户层面的开发者将不再烦恼。同时他们的命令和代码也能在其他处理器上也正常工作。

另一个原因是,当这些事件的接口彻底地想清楚时,暴露给用户层的ABI需要去改变。在稳定的内核版本上发行第一版ABI几乎肯定要在某些方面加强,然而考虑到用户已经在用它了。靠推迟这些事件一个周期(2.6.40版),他希望避免推出一个二流的接口却不得不永远支持它。

====
There can be no doubt that managing this feature in this way makes life harder for some developers. The kernel process can be obnoxious to deal with at times. But the hope is that doing things this way will lead to a kernel that everybody is happier with five years from now. If things work out that way, most of us can deal with a bit of frustration and a one-cycle delay now.

无疑以这种方式来管理这个特性对一些开发者来说很难。Linux 内核开发过程的处理难免可恶。这种方式是希望五年之后有一个每个人都很满意的内核。

Topic: sohulinux

开始 sohulinux 计划

----当你落后的时候,最简单就是从翻译开始

无数人在做类似的事情,从严复陈独秀起就是这样了

我希望搜狐的技术团队能更开放一点儿,离开源社区更近一点,大家研究的东西稍微深那么一点儿

这是一个挺麻烦的过程,不仅仅自个儿要努力,还需要得到别人的认同。。。形成良好的正反馈,才是长久之路

于是我决定组织我的训练营翻译 LWN.net 上的文章,我觉得这上面的东西绝对符合开源社区口味,内容基本还挺有深度,而且一周一期,非常与时俱进。

这就是 sohulinux.blog.sohu.com,请大家订阅.. 当然最开始一段时间我自己也会不断刊发

希望最后成长出若干个牛逼的搜狐技术博客出来,我就去做搜狐最本行的职业,一个编辑吧,哈

Topic: sohulinux

为什么要登山

PS: 张老板先后写过两篇登山论了:(1)(2),基本上不太有人能总结得更好了。

去四姑娘的路上,吃饭的时候闲聊,老孔知道我是国米球迷后,问我对魔力鸟时代的战术、后防线的黄牌怎么看。

我说不管国米是什么教练,什么球员,什么战术,什么成绩,都不妨碍我是国米的球迷。

老孔很奇怪问我是怎么成为的国米球迷

以前还没有人这么认真的问我这个问题,我仔细想了一下,回答是因为我大学时代穿着国米的队服踢了四年球。因为有这个仪式感存在,所以产生了深厚的感情,和什么罗尼老爹魔力鸟关系已然不大。

好比你从小开始对着国旗行了N年的注目礼举手礼,虽然现在对那五颗星的寓意已然很鄙视了,但当认真听到义勇军进行曲响起看着国旗缓缓展开的时候,还是会不由自主的激动。

仪式感确实很重要

登山除了是去重新体会人和大自然的关系外。它也是一个特殊的旅程,是人生的一段特殊的仪式,完成一个特殊的目的——我的梦 都装在那行囊中

Topic: 运动

一件很囧的事情

话说前几天送邱可心去上学。

我正开车呢,一转脸看到邱可心正津津有味的看报纸

我觉得很奇怪,车上哪里来的报纸。。。随即又恍然大悟——可能是前一天春游外出用来垫东西带的

等红绿灯的时候,我又好奇的去看邱可心究竟在看什么

!!!!

“固元养生”!!!“前列腺”!!!“□□增大”!!!

我立刻就很崩溃的把报纸夺了过来,很严肃的对达达说,上面都是骗人的信息

然后我问她,报纸哪里来的

达达说这个是从门把手上取的

原来是前两天早上在保福寺桥右转的时候,被发小广告的人强插的!

虽然在副驾驶门把手上平时也眼不见心不烦,不及时清理也不行啊

====

观看少儿不宜内容,邱可心第一次被她老爹抓现行的事情就这么发生了

Topic: dada

要准备出发去四姑娘了

- 5月7日(周六) 全体队员由北京出发到成都,宿成都;
- 5月8日(周日) 全体队员由成都乘车前往日隆镇,宿日隆镇;
- 5月9日(周一) 全体队员前往大本营(4,400米);
- 5月10日(周二) 大本营适应训练;
- 5月11日(周三) 冲顶组前往C1营地(海拔4,800米),其他人留守大本营;
- 5月12日(周四) 冲顶组登顶后下撤,全体队员集体下撤到日隆镇
- 5月13日(周五) 全体队员由日隆镇返回成都

- 5月14日(周六) 全体队员由成都飞北京

Topic: 生活

Size Matter

用了一个很火爆的标题,但并不想说男人的size或者女人的size。。。而是关于组织的size

延伸阅读:Why I Run a Flat Company

昨天,部门里一个同事和我聊到:关于本次加薪,大家有传言,某某team的加薪幅度比其他team要高一大截。

这则传言让我很震惊,也促进我反思最近工作中遇到的几起不顺心的事件是否反映出组织中的一些结构性硬伤:

  • 如何在小团队中引入自管理?

  • 小团队能做多大的事情?

  • 大既是好吗?

  • 团队变到多大的时候就必须引入层级管理?

  • 从小变大的时候,怎么避免官僚主义和政治?

这涉及员工、组织文化、目标管理三方面。关于文化尤其复杂,中国的等级文化和目前的社会竞争状态使得"小"这个概念极难生存

某人问:即使做成了人人、开心又如何?虽然RenRen现在估值几十亿美元了,但其实这真是一个好问题

====

怎么样让一个超过70人的团队继续保持高效率,这个坎一定要迈过去

Topic: 商业

技术社区和商业组织

预计下午的CPyUG本次活动我得准备一个开场白,打的腹稿大概是这样:

世界上有两种工作模式,一个是变革驱动,一个是运营驱动

模式无所谓好坏,这是一个正常的发展规律,当日常运营遇到困境,内外部环境都发生变化,组织必须顺势而变,寻找新的运营流程。

运营->变革->运营...不仅仅是商业组织,每个个人也是在这两种模式中周而复始的切换的。

那些积极参与技术社区活动的同志,都是希望超越日常工作/学习环境,超越自己的 daily operating,去寻求变化的。这导致了技术社区成为一个变革汇聚的地方,其中蕴藏着改变世界的能量。

当一个商业组织不满足于现有的运营驱动模式,必须积极从内部或者外部寻找推动变革的力量。外部而来的力量会更强大,内部自发形成的变革力量较容易管理控制。

所有参与技术社区活动的商业组织,无一例外的都是希望能从社区里汲取外部动力。或者是招募新的人才,或者是尝试新的代码/框架,或者是希望碰撞出新的火花产生新的业务模式

以前组织CPyUG北京地区活动的几个公司,比如豆瓣,目前好像在社区中都比较沉寂,这也导致本年度直到4月份才第一次聚会。我个人大胆猜测它们可能从变革驱动转向了运营驱动(至少在技术这个层次上)。这也很正常,以前搜狐基本上长期处于运营驱动的状态,技术方面和外界沟通比较少,印象上是比较封闭。

现在搜狐邮件中心已经有不少同学是通过CPyUG招聘进来的了,我们这次赞助并组织社区活动,一方面是回馈社区,另一方面也是希望向社区,包括我们内部,传递一个清晰的信号:“搜狐邮件中心正处于变革驱动的状态,我们希望借助社区,从人才招募、软件外包、业务合作等等各个方面寻找机会,达到组织和社区的双赢”

Topic: 商业 技术
订阅 RSS - qyb的博客