作者：[美]Gregory Smith 著
出版社：人民邮电出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
PostgreSQL 9.0性能调校试读：
前言
从传统的企业数据库到最新的Web应用程序，PostgreSQL逐渐成为一个为应用数据提供存储服务的日益成熟的数据库平台。但要充分发挥PostgreSQL的性能却没那么容易。用户需要从一些经验法则入手，使用全方位的监控和维护来保障系统的正常运行，为故障排除提供相应的建议，为附加工具提供信息以便向那些无法尝试自行处理的核心数据库添加功能。本书主要内容
第1章“PostgreSQL版本”，介绍了PostgreSQL最近几个版本的性能提升情况，并通过新版本与稍早的版本之间的漏洞和执行速度的对比说明新版本的实用性。
第2章“数据库硬件”，讨论了服务器硬件环境当中的一些主要部件，包括处理器、内存和硬盘等，需要仔细选择可靠的数据库存储并平衡预算。尤其是当不小心使用了易失性回写缓存的磁盘控制器和驱动的时候，这将容易导致数据库的损坏。
第3章“数据库硬件基准评测”，主要讨论不同数据库硬件性能方面的量化标准，即在系统当中，内存和裸设备的速度究竟有多快？性能是否随着驱动器数量的增多成比例变化？
第4章“磁盘设置”，主要研究现行主流的文件系统选择方案，并对权衡硬盘中数据库布局的多种方式提出建议。此外，还讨论了一些常见的、有效的文件系统的调整问题。
第5章“数据库高速缓存内存”，研究数据库是如何存储在磁盘、内存当中，以及检查点进程如何保证双方的一致性。另外，还讨论了如何去具体查看数据库缓存的数据，以确认内存中所存储的数据与事先所期望的内容是否一致。
第6章“服务器配置调整”，介绍了postgresql.conf配置文件当中的一些重要设置选项，这些选项的含义以及如何去设置这些选项等内容。同时，还指出了一些会引起故障的设置。
第7章“日常维护”。本章首先解释PostgreSQL如何确定什么样的客户端能够显示什么样的数据信息。可见性信息存储的方法需要一个名为VACUUM的清理进程来妥善处理的重新利用剩余的空间的问题。此外，一些常见问题及针对的一般常见调整措施，以及始终运行auto vacuum的方法在本章中也有介绍。最后，本章介绍了数据库日志中数据量的调整方法，以及对结果进行查询日志分析来找出造成查询瓶颈的症结所在。
第8章“数据库基准评测”，研究如何从PostgreSQL所包含的pgbench测试程序中获得有用的基准测试结果。
第9章“数据库索引”，介绍在响应一个查询时，索引是如何能够减少读取数据块数量。这种方法可以用于彻底研究一些常见问题，诸如一个查询为什么会使用顺序扫描而不是使用一个功能强大的索引。
第10章“查询优化”，本章作为PostgreSQL优化器的指南，展示了根据用户需求以及数据库参数设置的不同，样例查询所采取的不同的执行方式。
第11章“数据库活动和统计信息”，介绍数据库内的统计信息，以及这些信息中，哪些有助于查找问题。此外，还讨论了查看索引活动和锁定行为的方法。
第12章“监控与趋势预测”，本章一开始就介绍如何使用基本的操作系统监控工具来确定数据库正在进行什么操作。接下来，给出可按照时间对信息进行图形化表示的趋势预测软件的相关建议。
第13章“池化与高速缓存”，说明了在同一时间内对数据库进行大规模连接的时候所遇到的问题与困难。提出两种类型的软件包的解决方案来解决这些问题：对请求进行更好的排序连接池以及可以回应用户请求而无需连接数据库的缓存。
第14章“扩展复制”，介绍解决跨越多个节点进行数据复制引起系统高负载的方法，典型的方法是一组只读的节点与单一的可写主节点进行同步。
第15章“数据分区”，探讨数据如何分区成有效的子集，这样查询就可以只对数据库的一小部分进行检索。讨论的方法包括标准单一节点数据库表分区以及使用与它相关的工具集PL/Proxy在多个节点之间建立分片数据库。
第16章“应该避免的一些常见问题”，主要讨论那些通常看起来会困扰那些数据库新手的PostgreSQL问题，例如，批量装载、对记录计数、外键处理等。本章最后回顾了从PostgreSQL 8.1版到9.0版的那些与性能相关的功能变化。有时候，避免一些常见的问题的最好方法是升级到新的版本，因为它可能再也不会出现那些问题。阅读本书所需基础
要很好地利用本书，读者必须至少能够访问到一台允许在服务器执行查询的PostgreSQL客户端。如果是服务器管理员则更为理想。在http://www.postgresql.org/download/
上提供了当前主流操作系统下的PostgreSQL完整客户端和服务器程序包的下载。
本书的所有例子都是在命令行下执行，通常运行于psql程序当中，这样可以使它们用于大多数的平台。它可以简单地执行很多操作，而不需要使用像pgAdminIII这样的面向PostgreSQL的GUI工具。
一些脚本是用bash脚本语言编写的。如果你使用的是Windows环境，可以在http://www.cygwin.com/cygwin
获取套件，该套件提供在Windows环境下的类似bash的UNIX工具。本书适合的读者
本书旨在帮助那些使用或计划使用PostgreSQL的中高级数据库管理员。其中部分内容对那些寻求构建或监控PostgreSQL安装的系统管理员以及对影响程序的高级数据库内部构造感兴趣的开发者也很有用。体例
在本书中，将会发现一些用来区分不同的信息所使用不同样式的字体。以下是这些样式的例子，并附有说明。
在文本中的代码单词表示如下：“如果正在对数据进行排序，那么work_mem参数将会决定何时允许这些排序在内存当中执行”。
下面的代码块的样式设置如下。
当需要引起对特殊代码段的注意时，我们将相关的行或条目设置为粗体显示，如下所示。
命令行内的输入或者输出加粗显示，如下所示。读者反馈
我们一直欢迎读者的回馈。它可以让我们了解到用户对于这本书的看法，如喜欢什么而不喜欢什么。用户反馈有助于我们改进本书的的内容，而这将会获得更大的收获。
可以通过发送E-mail至feedback@packtpub.com提交反馈信息，请务必在邮件主题当中提及本书的书名信息。
如果你有需要或者想出版的图书，请在网站www.packtpub.com中的推荐信息表单（SUGGEST A TITLE）当中填写信息，或发送E-mail给我们。
如果你在某一领域内有专长，并且有兴趣将其写成书或参与书的编写，请查阅网站www.packtpub.com/authors的作者指南信息。用户支持
现在，你已经是Packt图书的用户，我们有许多的方式可以满足你的需求。下载本书例子的代码用户可以在Packt网站http://www.PacktPub.com下载以
用户本人账号所购买的书籍中实例的代码。如果是在别处购
买了本书，可以访问http://www.PacktPub.com/support并填
写相关信息，将有电子邮件指引用户进行注册。勘误表
尽管我们非常仔细地确保内容的准确性，但错误是在所难免的。如果你发现我们书本中的错误（文本错误或者代码错误）并将错误反馈给我们，我们将非常感激。这样，你可以防止其他人也阅读到这个错误，并帮助我们在本书的后续版本中改进。如果你发现了任何的勘误内容，请访问http://www.packtpub.com/support
，选择书本，点击链接errata submission form，输入具体的勘误内容。一旦你的勘误内容得到确认，你提交的内容将会上传至我们的网页或者增加到现有的勘误表中（列在勘误表一节的末尾）。在http://www.packtpub.com/support中可以通过选择主题查看现有的勘误表信息。版权声明
在Internet上各种媒体的版权材料盗版已经是层出不穷。而在Packt公司我们会严肃地对待版权和授权的保护，如果你在Internet上获取到我们著作的任何形式的非法拷贝，请立即向我们提供地址或网站名称，这样我们才能采取一些补救措施。
请通过copyright@packtpub.com与我们联系有关涉嫌盗版材料的链接。
我们真心感谢你对保护作者所提供的帮助，我们将有能力为你提供更有价值的内容。问题
你可以通过questions@packtpub.com与我们联系，如果你有任何关于本书的疑问，我们将竭尽全力处理你的问题。译者序
PostgreSQL是“对象/关系”型数据库管理系统，它具有开放源码、支持多平台、免费使用等特点。它最初由美国加州大学伯克利分校计算机科学系开发和维护。因为来自于学术机构，它具有许多非常先进的、开创性的特性，这些特性现在已经被许多商业数据库系统所采用（如Informix）。目前PostgreSQL由一批自由软件爱好者维护，它的功能还在不断增强。
有关PostgreSQL的最新中文书仍关注于7.0的版本。在这10余年间，PostgreSQL版本经过了一个质的跨越，提供了诸多令人振奋的功能。所有涉及到的内容在本书当中都会有涉及。全书共分成16章内容。从相关的PostgreSQL版本到数据库基准评测，再到一些常见问题分析以及版本之间的更新内容对比等，这些内容都极具有参考价值。
本书针对正在使用或计划使用PostgreSQL的中高级数据库管理员。部分内容也会引起系统管理员的关注，包括建立或监控PostgreSQL安装等，对于开发人员，关心的则是影响应用程序设计的高级数据库内部组织。
本书的翻译由吴骅组织完成，参与本书翻译的还有王学昌、韩潼瑜、周娟、刘红军、王玲、郑正正、冯伟强、陶日然、李泽榆等人。全书由吴骅负责统一定稿。虽然译者多年从事DB2数据库的管理工作，但是本书对于译者来说也是一个全新的挑战，它介绍了大量的技术和特性，因此其中一些术语尚无固定的名称。由于水平有限，译文中的不当之处在所难免，恳请同行及各位读者朋友不吝赐教，联系方式wuhua@gxun.cn。译者2012年9月于相思湖畔作者简介
Gregory Smith是国际数据库专业服务公司2ndQuadrant的首席顾问，并且是公司在美国的第一个办事处的创始人。
编著PostgreSQL是他进军数据库性能调整教学领域的第二个扩展。在1995年，Greg（格里格）写了一本较小的免费电子书《Progress Performance FAQ》，主要内容是如何使Progress 4GL和相关数据库能够运行更快。2001年，他专注于PostgreSQL 7.0，一直关注复杂性问题，该数据库的发行版都能够解决这些问题。
从PostgreSQL 8.3开始，他对每个PostgreSQL版本都做出了贡献，添加附加的功能。他还为数据库编写了一些额外的工具集，目前包括有pgtune、pgbench-tools、peg和2warm等。“我能够很好地专注于本书内容，完全是因为Simon
Riggs和2ndQuadrant全球其他员工的支持。在过去一年中，
发现并解决一些令人关注的问题，以及提供解决这些问题的
资源，是2ndQuadrant员工为客户提供PostgreSQL性能改进
服务的理念。按照写作计划，在交付时要包含对一个新的主要数据库
版本的支持，这是一件相当繁重的事情。没有家人（Judy、
Jerry和Amanda）的支持，我不可能有为了这本书连续这么
多个星期每星期都工作7天的时间。最后，感谢PostgreSQL项目的众多参与者为这本书提
供了很多的资料。在过去几年中，没有pgsql-performance和
pgsql-hacker等邮件列表的共享精神，我也无法收集这样广
泛的性能问题。无论是对自己问题的回答，还是仔细考虑回
答别人的问题，这些邮件列表上的互动已经成为本书理念的
关键。”第1章PostgreSQL版本
众所周知，PostgreSQL具有丰富的功能集和非常稳定的软件版本。其默认的安全配置既被安全人员称赞又因其复杂的学习过程而被诟病。SQL规范的一致性和数据完整性只允许通过严格的方式与数据库进行交互，这会使那些时常使用相对宽松的桌面数据库软件的用户感觉到非常不适应。但是所有的一切都有其自身一定的道理。
运行速度慢是另外一个让PostgreSQL出名的原因。时至今日，仍然有一些事实能证明这一点。往往有很多使用“正确的方法”数据库操作会比用其他的方法的操作需要更长的时间。例如，对于“2009年2月29日”这样一个日期而言，由于2009年不是闰年，因此这一天并没有任何意义。在实际生活中，不可能有这一天，而且也不会在这一天发生任何事。如果要让数据库向标准的日期字段中写入这个值，那确实可以，也很快速。或者，数据库可以检测这个日期是否能够有效存入目标字段，注意到在常规的日历里，没有这样的日期，它可以拒绝用户的修改。这样数据库执行的速度就稍微慢一些。PostgreSQL由一些不想抄近路做事的人设计，并且是为了这些人而设计，他们希望能够把事情做得更快和更简单。在用户只能通过一种方法来正确处理某个事物的情况下，那可能是惟一可用的方法。
然而，一旦进行了合理的实施之后，还可以回过头对它进行优化。在过去的几年中，这已经成为PostgreSQL的模式。PostgreSQL经常通过解决这些小问题来大幅提高数据库性能。其中一部分很好的设计远胜过更简单的方法，这当中由于复杂性的引入甚至付出了相当的开销。这是一种相当新的现象，一定程度上解释了为什么PostgreSQL相比其他竞争对手而言，是个速度较慢的数据库。1.1 PostgreSQL历史版本的性能
2005年11月，PostgreSQL发布了其8.1版本。该版本中包含了众多内部结构的改进，其中一些期望能够提高多个活动客户端在多处理器系统下的数据库性能。其结果是在处理沉重工作负荷时，数据库能力得到成比例的提高。在如今的硬件设备上进行的基准评测，突出地显示了其对先前版本的跨越。可以在
http://suckit.blog.hu/2009/09/29/postgresql_history看到György Vilmos 对8.0版至8.4版的性能横向比较。它准确地显示了性能显著提升的程度。这些测试使用由http://sysbench. sourceforge.net/网站提供的sysBench基准评测软件的联机事务处理（OLTP）测试工具。
这个测试给出了每秒处理事务数（TPS, Transactions Per Second）系统整体速度的数据值，可以在只读模式下或包含写入的模式下运行。在只读模式下，从8.0版本升级到8.1版本的性能提升4倍，而8.3版本的性能提升则再提高2倍左右。如表1-1所示。表1-1版 本只读模式下TPS峰值峰值状况下客户端数量8.0.21125648.1.175620148.2.138109188.3.713984228.4.11354622
在负载峰值情况下客户端数量的上升给出了数据库内部处理访问共享资源程度大小的一种思路。特别是8.1系列版本当中包含了一些重大的升级。而在写入模式下的性能改进与此类似，8.0版本到8.3版本之间性能几乎达到了8倍的增益，见表1-2。表1-2版 本只读模式下TPS峰值峰值状况下客户端数量8.0.2136128.1.17873108.2.131358148.3.72795188.4.1271312
在这些测试当中可以看出8.3版本到8.4版本性能有略微的降低，这是由于对数据库进行了细微的重新调整，以改善其在最糟糕情况下的性能。8.4版本中采集了更多的统计数据用于提高复杂索引的性能，并在测试中牺牲了部分不太重要排序的速度。第10章将会讲述更多关于这方面的详细内容。
尽管结果不会涵盖如此广泛的版本，但其他的测试结果也证实了性能的提升。可以很容易地看出，在2005年年底之前8.1版本交付的时候，之前所达成的关于PostgreSQL性能的结论是完全过时的。2008年8.3版本发布的时候，速度提升可以算是一个很大的飞跃。因此，8.3之前的版本并不能代表目前的性能，同时首选使用这个版本或者后续版本还有很多其他的原因。1.1.1 选择部署的版本
如果用户有较老版本的PostgreSQL系统，并想让它运行得更快一些，因为新版本的这些令人瞩目的特性，首要的事情不是考虑如何调整设置，而是应该考虑升级到最新版本的可能性。如果用户正在实施一个新的项目，用户可以考虑最新的8.3版本。除了性能提升外，该版本还有一些影响到应用程序编码变化，用户可以更容易开始项目的实施，避免后期的改进。
第16章包含一个参考指南，其内容为从8.1版本至9.0版本当中每个主要的PostgreSQL版本所加入的与性能相关功能的介绍。用户可能会发现只有在最新版本里的功能能够引起他们的注意，因此强烈建议用户使用最新的版本。在本书中将会突出这些特定版本的变化。1.1.2 升级到更新的主要版本
目前为止，从现有的PostgreSQL版本升级（例如从8.1.X版本升级到8.2.X版本）到最新的主要版本的惟一方法是dump转储和重载。使用新版本中的pg_dump和/或pg_dumpall程序将整个数据库的内容写入一个文件。采用这样的方法，如果有任何变更需要进行更新，那新的转储程序可以尝试处理它们。并不是所有的升级变更都会自动进行。随后，根据用户要转储的格式，可以运行它所生成的脚本或者是使用pg_restore程序来处理这个任务。pg_restore是在新版本的PostgreSQL中的一个较好的替代方案，具有并行存储的功能。如果用户正在使用的操作系统并不允许用户在同一时间
内运行多个PostgreSQL版本，例如现行的RedHat Linux的
RPM包，在同一时间内同时安装一个老的PostgreSQL版本
和一个新的PostgreSQL版本是很困难的。在PostgreSQL 9.0
中，对这种情况所做的一些改进也在开发当中。因此在进行
升级规划时，要将确认运行多个版本的可行性作为其中的一
个部分。
转储数据需要一定的时间，恢复数据要花的时间更久。在这种情况下，数据库可能要暂停服务，这样才能保证没有其他的任何更改被写入到转储文件中。对于大型的数据库，停机的时间可能会很长而且是让人无法接受的。
在一些要求较高的环境中，数据库要求宕机时间为0，以达到7×24小时运行。在这种情况下，转储和重载是不适用的。直到最近，针对这种环境使用所进行的PostgreSQL升级，惟一有效的方法是Slony的复制。Slony是最受欢迎的解决方案，第14章有其更详细的介绍。Slony当中的一个功能就是用户可以不在所要进行复制的所有节点都运行相同版本的PostgreSQL。用户可以提取一个新的节点来运行新版本的PostgreSQL，等待复制完毕后，一旦与源相匹配，那么将其进行切换。
现在，有一种新方法可以不需要任何的复制软件，该程序起初称为pg_migrator（见http://pgfoundry.org/projects/pg-migrator/
），可以不需要转储和重载操作来完成从8.3版本到8.4版本的升级。这个过程称为就地升级（in-place upgrading）。用户需要进行仔细的测试，在PostgreSQL的功能中既有已知的限制也有一些未知的不太受欢迎的相关特性。要确保仔细阅读升级工具的文档。从PostgreSQL 9.0开始，这个模块包含在核心数据库中，并且名称更改为pg_upgrade。由于所有就地升级都会有些风险并需要进行仔细的测试，因此在很多情况下，pg_upgrade可以带用户从8.3版本或8.4版本升级到9.0或更高的版本。
PostgreSQL开发社区目前决定将就地升级功能应用于未来的版本中。现在，TB以及更大数据量规模的PostgreSQL的安装已经很普遍，因此升级时只使用转储和重载是不实际的。1．从更早的版本升级到PostgreSQL 8.3+
8.3版本的主要内部变化是从更早版本进行升级当中不需要转储整个数据库并进行重载到更新的版本。这让8.3版本成为其发展史上的重要里程碑。与8.2版本相比较，不仅仅速度上快很多，一旦用户使用了8.3版本，从此就可以使用就地升级功能了。
从早期版本升级到PostgreSQL8.3或后续版本是比较困难的。部分较老的应用程序依赖于非字符型数据类型，被透明转换成TEXT类型，因为多种原因，这个特性在8.3版本中被删除，更多信息请浏览http://www.postgresql.org/docs/8.3/static/release-8-3.html
。
虽然升级数据库版本总是有可能会引入新的问题，尤其是对早期版本编写的应用程序升级到8.3版本或更高版本时。这也许可通过手动添加回被删除的自动类型转换功能来有解决这个问题。在http://petereisentraut.blogspot.com/2008/03/readding-implicit-casts-in-postgresql.html
有一个具体的实例。然而在应用程序中固化这个特性的替代方法是使用更强大和可持续的方法。较老的特性因为其会导致莫名其妙的应用程序问题而被取消。如果用户将其添加回来，就需要对每一个新的PostgreSQL版本做其他额外的添加步骤。关于这个主题和执行主要版本的PostgreSQL升级会遇到的问题，可以浏览http://blog.endpoint.com/2010/01/postgres-upgrades-ten-problems-and.html以获取更多信息。2．次要版本的升级
从8.4.1版本升级到8.4.2版本之类次要版本升级不需要使用转储/重载或使用类似pg_ upgrade的工具。只需要停止服务器，安装新版本，然后对现有的服务器数据文件运行新的数据库二进制更新。部分用户不愿意进行此类升级，以免数据库内的改动会让正在运行的程序产生问题。在PostgreSQL中不会产生这种情况。PostgreSQL项目的规则在http://www.post gresql.org/support/versioning
描述得很清楚。
虽然升级多少都会有些风险，PostgreSQL次要版本仅修复经常碰到的安全性和数据损坏错误，以减少升级的风险。PostgreSQL社区认为不升级比升级的风险高。
在PostgreSQL次要版本升级当中，永远不会找到会破坏应用程序的任何一种不可预期的修改。漏洞、安全和损坏性修复总会以一种最小化引入外部可视的行为变化几率的方式被执行。如果是无法避免的话，那么将会在发行说明当中详细地去解释其中的原因以及建议的解决方案。在其中将会发现一些细微的问题，这是由于某些已解决的缺陷所带来的，这甚至会在一个次要版本的更新之后得到彻底解决。从PostgreSQL邮件列表当中不难发现某个问题的报告已经在兼容该版本的一些最新的次要版本更新当中被解决，因此升级到该版本是使所有这些问题消失的主要需求。1.2 使用PostgreSQL还是其他数据库
当然也有其他的数据库解决方案会执行得好一些。例如，PostgreSQL缺失了一些在TPC-H测试套件当中较为复杂的查询能够得到较好执行的功能（具体内容详见第8章）。因此，与一部分商业数据库相比较而言它不适用于运行在较大规模的数据仓库应用程序当①中。如果用户需要进行类似TPC-H包含的高负载查询时，就可能会发现诸如Oracle、DB2、SQL Server等数据库仍然有值得付出的性能上的优势。目前也有一些由PostgreSQL衍生出来的版本，包含了能够适用于数据仓库和类似的大型系统的功能。例如，Greenplum、Aster Data和Netezza。
对于某些类型的Web应用程序而言，用户只能通过PostgreSQL所不允许的对数据完整性的功能进行剪裁的方法以获得一些可接受的性能表现。这些程序可能在类似MySQL这样的并不严格的数据库或者严格度最小的SQLite中表现得很好。与相对成熟的数据仓库市场所不同的是，这种类型的应用程序设计还是经常使用的。在本书编写之时，有关基于键值（key-value-based）的NoSQL环境（包括CouchDB、MongoDB和Cassandra）越来越受欢迎。如果对处理此类键/值存储相关的高级查询的运行时间不怎么敏感时，那么这些方法可以很容易地超越那些传统的数据库。
但对于很多在这两个极端之间的那些“正常的”数据库用例来说，PostgreSQL的性能在8.3版本当中达到了这样的一种程度：其情况很可能是在数据库成为限制因素之前需要面对的硬件或应用程序设计的限制。此外，某些PostgreSQL的传统优势，如处理复杂查询以及其深度的可编程性，这些都将继续存在。1.3 PostgreSQL工具
如果用户习惯于数据库厂商提供的那些针对数据库本身的完整工具集，这些工具集所涵盖的范围从服务器管理到应用程序开发，那么PostgreSQL可能无法满足这部分用户的需求。与很多成功的开源项目一样，PostgreSQL视图持续专注于一些它所擅长的功能。这也就是开发社区所指的PostgreSQL核心：主要的数据库服务器，相关的工具可以作为数据库本身的一个部分进行开发。当有新的功能提出时，如果它们可能被建立和发布在“核心外”，这是首选的方式。这种方式尽可能地保持数据库核心是持续性的，也就是允许这些外部的项目发布为自己的更新，而不需要与主要的数据库发布计划进行同步。
成熟的PostgreSQL部署应该能够识别众多的各自具有其特定目的附加工具，这些都需要整合到数据库核心服务器中以形成一个完整的系统。1.3.1 PostgreSQL contrib
用户也许没必要安装PostgreSQL核心的contrib模块部分（其命名是根据它们所存储的目录名称）。这些可选的工具与标准工具包一同发布，但在用户的系统上默认可以不进行安装。contrib代码作为PostgreSQL核心的一部分进行维护与发布，但不要求服务器进行操作。
从代码质量的角度上看，contrib模块在其测试时并没有遵守那么高的标准。主服务器包含对每个功能的深度回归分析测试，这会涉及在数量庞大的系统中去搜寻错误。可选的contrib模块并没有得到在相同级别上的测试覆盖。然而，代码本身是由同一个开发团队进行维护，其中的一些模块极其受欢迎，并且经过用户的良好测试。
查看所有可用的contrib模块的列表，请浏览http://www.postgresql.org/docs/current/static/ contrib.html
。1．发现系统中的contrib模块
检查是否安装有contrib模块的方法是去查看pgbench程序是否可用。pgbench是少数那些安装了完整程序的contrib组件工具的其中之一，而不仅仅是用户可使用的脚本。在UNIX中，检查pgbench是否安装的例子如下所示。
在大多数Linux系统中，如果用的是RPM或者DEB包安装的PostgreSQL，可选的postgresql- contrib包中包含所有的contrib模块以及与它相关的安装脚本。如果尚未安装相关功能的话，就需要使用yum、apt-get或者类似的机制来添加安装包。在Solaris系统中，这个包的名称为SUNWpostgr-contrib。
如果用户不能确定在其系统中PostgreSQL contrib模块安装的位置，那可以使用文件系统工具进行搜索。在许多类UNIX系统中，locate和find命令一样能够很好地达到目的。在Windows系统中，在开始菜单中可以找到文件搜索工具。例如，用户要搜索在下一章要谈到的内存分配的文件pg_ buffercache.sql，以下是在部分平台下，该文件所在的位置的说明。● RHEL和CentOS等Linux系统中，该文件的路径为：/usr/share/
pgsql/contrib/pg_ buffer cache.sql。● Debian或者Ubuntu等Linux系统中，该文件的路径为：/usr/share/
postgresql/ version/contrib/pg_buffercache.sql。● Solaris系统中该文件路径为：/usr/share/pgsql/contrib/
pg_buffercache.sql。● 在Windows系统中，采用默认选项将会安装contrib模块，其路径
为：C:\Program Files\ PostgreSQL/version/share/contrib/
pg_buffercache.sql。2．从源码安装contrib模块
在一些平台下，当用户的服务器环境符合相应的先决条件，则可以使用源码安装PostgreSQL作为一种简单的练习。相关详细信息请参考：http://www.postgresql.org/docs/current/static/install-procedure.html
。
在构建主要服务器的代码后，用户还需要自行编译诸如pg_buffercache之类的contrib模块。以下是一个相关的实例，在该例当中假设用户的PostgreSQL目标路径为/usr/local/postgresql，并且目录source是用户放置源代码的目录（本实例不作为典型或者推荐用户使用的目录结构），如下所示。
在contrib目录中运行make/make install命令可以构建并安装所有的contrib模块。请注意其中的一些更广泛的源代码构建的需求。uuid-ossp模块就是一个更具挑战性的自行编译的模块实例。3．使用contrib模块
虽然一些诸如pgbench的contrib程序可以直接执行，但那些安装在数据库中的工具大多数都是为了向其添加额外的功能。
例如，要将模块pg_buffercache安装到一个名为abc的数据库中，则要在命令行下使用如下命令。
用户可以使用图形化用户界面管理工具pgAdmin III替代命令行来完成工作。它是捆绑在Windows平台下的PostgreSQL工具，以替代命令行方法。具体使用方法如下。● 指明用户要安装模块的数据库。● 单击工具栏上的SQL图标，启动命令行编辑器。● 选择 File/Open，指向 C:\ProgramFiles\PostgreSQL/version/
share/contrib/pg_ buffercache.sql并打开文件。● 使用绿色箭头或者Query/Execute开始执行。
使用以下的查询可以快速检测任意类型的系统中所安装的模块。
如果返回任意值，则表明该模块已安装。注意pg_buffercache只能由数据库超级用户安装和使用。1.3.2 pgFoundry
与PostgreSQL相关的项目的官方站点是pgFoundry：http://pgfoundry.org/
。
pgFoundry只是存放PostgreSQL软件的主机，除了文件分发之外还提供诸如邮件列表和错误追踪的功能。许多最流行的PostgreSQL附加程序都可以在那里找到。● Windows程序可以通过.Net和OLE访问PostgreSQL。● 诸如pgpool和pgBouncer之类的连接缓冲池。● 诸如pgFouine、SkyTools以及pgtune之类的数据库管理工具。
尽管有时会由从事PostgreSQL核心的同一批人维护pgFoundry，但其代码质量时常会有显著变化。保持项目良好进行的一个方法是注意定期和最近的发布版本。1.3.3 其他一些与PostgreSQL相关的软件
除了PostgreSQL核心自带的程序之外，诸如contrib模块以及pgFoundry提供的软件等，还有很多的程序能够让PostgreSQL更加易用和强大。在网络上都能找到这些资源。为需求本身选择正确的包实际上有很多选择。
本书中，很多很有用的程序都会被重点提出，用户可以尽早了解所提供的简短列表。这是构建大型开源项目的标准方法，用户可以得到一个基本的系统运行环境并随后在需要的时候去添加额外的的组件。
对那些安装任何软件都要经过审批和QA周期的企业文化来说，这样做是比较困难的。为了提高在这种环境下用户成功安装PostgreSQL的几率，在早期就引进这一概念是很重要的。在后期需要往较小的数据库核心中附加程序来添加组件，很明显在刚开始的时候不需要全部组件。1.4 PostgreSQL应用程序扩展生命周期
虽然每一个应用程序都有其独特的发展方向，但是我们也会发现有必要作为使用PostgreSQL数据库的应用程序的一些共同技术变得更为频繁。本书中的章节分别关注这一过程的常见方面。运行数据库服务器的步骤一般如下。（1）决定服务器运行的硬件条件。理想情况下，用户将测试能够满足预期条件的硬件。（2）建立数据库磁盘的布局：RAID级别、文件系统以及硬盘上可能的表/索引的布局。（3）优化服务器配置。（4）监控服务器性能和查询执行的情况。（5）提高查询执行的效率，或创建索引以帮助加速。（6）由于很难仅通过调整服务器来达到承受更多工作负荷，取而代之的是通过引入连接池以及高速缓存来减少对这方面的担忧。（7）将数据复制到多个服务器，同时分布读取这些数据。（8）将较大的表分区为片段。最终，实际上一个比较大的表可能需要被分割，以便能够同时写入到多个服务器当中。
此过程不是按部就班的。用户反复多次对服务器参数进行优化。这可能会出现在决定购买较新的硬件的情况下，而不是开始那些需要重新设计应用程序复制或分区操作工作。部分设计可能会在从最开始的阶段整合缓存到设计当中。其中重要的是需要意识到有很多的选项可选，并且去采集足够的有关系统能够达到的性能极限，以决定哪些变化是有帮助的数据。1.5 作为实践的性能优化
提高数据库性能与其他领域一样，有其专门的术语。下面是本书中要用到一些术语或短语。● 瓶颈或限制因素：这两个术语常用于指明限制性能更进一步提升
的当前的制约因素。● 基准评测：运行一个测试以确定特定操作运行的速度。通常用来
指明程序或者系统的瓶颈。● 概要分析：监控在运行类似基准评测等复杂操作时，哪一部分程
序使用了最多的资源。最典型的是指明瓶颈的位置，以及瓶颈被
移除后是否有预期的效果。对一个数据库应用程序的概要分析通
常是以vmstat和iostat等监控工具作为开始的。在代码级比较流
行的概要分析工具有gprof、oprofile和dtrace。
在通常情况下，性能调优工作中比较令人关注的一个原则就是，用户无法指明应用程序在移除当前瓶颈之前会陷入哪一个瓶颈。假设某个系统运行的情况不能像用户预期的那样快，用户通常会去猜测当前的瓶颈在哪，或者下一个瓶颈又会是什么情况。这是很浪费时间的。用户最好能够进行性能测定，分析系统运行较慢的部分，用来确定原因以及指导相关的修改。
例如，用户已经知道应该提高的shared_buffers值，这个值用来调整缓冲数据库读和写时所使用的内存大小。这通常有些积极作用，但用户也有可能会遇到潜在的负面效果。需要指出哪一个应用程序会受到影响，这种变化是否会提高或降低性能，在服务器上运行的小设置能不能够进行预测。这是混沌理论的一种：在开始条件下即使是微小的变化，也将会引起非常不同的结果。例如，一个小小的度的变化，也会影响服务器数以百万计的决策。同样的，如果shared_buffers设置的值过小，会有部分参数不能像预期的那样良好运行，例如，在它们控制数据库检查点的情况下。
鉴于用户在绝大多数情况下无法预测将会发生的事，所以更倾向于用户进行深度的监控和变更控制。从应用程序到数据库服务器再到硬件，尽可能多地进行监控。这里引入一个有针对性的变化。尝试去量化具体的差异并且意识到某些用户所拒绝采用的修改不一定总是一直处于不积极状态之下。将瓶颈移到别的地方，用户就会发现在突然陷入下一个限制因素前，某些参数其实是无关紧要的。
在专注于PostgreSQL性能的邮件列表中，当用户没有做任何分析就推断其根本原因来证明他们的理论时，通常对此会有种通俗的表达：那就是“少说多做gprof”。虽然gprof可能不是每个性能问题要选择的工具，但是鉴于与其他一般的监控工具相比，它更多的是一种代码分析工具，用户在推断根本原因之前尽可能多的进行分析的做法是合理的。用户也需要进行推断来证实所期望的变化。
另一种在本书中反复和出现的原则就是：用户必须要把性能问题研究系统化。不能因为服务器是从名牌厂家购买的，就假设会运行得很快，基准评测是独立的组件。不要将数据库性能测试与应用程序级别的测试一同启动。首先运行那些可以与其他测试内容进行对比的综合的数据库性能测试。这样，当用户运行的应用程序不可避免地慢时，此时用户知道自身的硬件已经运行在预期的性能之内，并且数据库本身也良好运行。一旦用户的系统上线运行，需要做一些基本的不可能将系统拖垮的操作以查找出性能上的问题，例如，硬件速度的测试。
若用户部署的每台服务器都按照一些通用的方法进行测试的话，那么它会有更好的结构。接下来的章节将讲述测试相关内容。因为用户不是“唯器材是用”，这并不意味着用户可以跳过类似磁盘性能测试的这部分内容。用户在构建新的系统时应当经常进行此类工作——这是去获得最基本情况的惟一方法，而不管是否操作的这些行为在标准范围内抑或有些错误的操作。1.6 小结
PostgreSQL在近5年中取得了长足的发展。在建立了坚实的数据库基础后，众多开发人员向其添加了很多附加功能，在最近发布的版本中，所添加的功能和性能改进得到了很大提高。最新的PostgreSQL 9.0版本所添加的功能，使得复制和读取扩展比之前的版本变得更容易，人们期望能进一步加速这种适用于数据库的应用程序类型。● PostgreSQL 8.1版本上的大量性能改进，尤其是在8.3版本中打
破了一些关于与其竞争对手数据库服务器相对较慢的早期概念。● 还有一些情况，PostgreSQL的功能集在处理查询时，要比其他
的商业数据库要慢，这最终有可能会被取代。● 如果用户要使用PostgreSQL开始一个新的项目的话，要尽可能
使用最新的版本（强烈建议使用8.3或后续版本）。● PostgreSQL在很多常见的数据库应用程序上可以良好运行，但
不一定是最好的选择。● 基本安装不包含用户需要管理和优化PostgreSQL服务器的所有
工具。时刻准备去包含一些附加的工具，这些工具中增添了核心
数据库想要提供的范围外的功能。● 性能调优作为可以一种系统化的、仔细测量实践当中最好的方法
来使用。① 译者注：关于TCP-H基准评测一些相关信息的简介请参见http://www.db2cert.com/bencandy.php?fid=44&id=22/。第2章数据库硬件
本章旨在帮助用户在做计划购买并运行PostgreSQL服务器的时候能够更好地对开支做些优先级方面的考虑。如果用户已经有了正在运行的数据库服务器，可以跳过本章直接参考第3章以及第8章当中的部分内容。最后，用户可能会反复多次采用本章所讲述的一些技术。例如，用户要对服务器进行基准评测，其磁盘运行缓慢，那么本章的内容会给用户提出一些意见，如更换什么硬件能够提高它的性能表现。更换硬件后，重新进行测试。重复进行直到性能表现能与预期相同为止。2.1 平衡硬件支出
在生产环境中使用诸如PostgreSQL等开源数据库的一个原因是，用户本要花在软件授权上的每一分钱，都可以用在更好的硬件上。在用户的预算当中需要权衡的有三个主要部件：CPU、内存和包含相关磁盘控制器及重要部件的磁盘。2.1.1 CPU
目前，在售的每个CPU内部都集成有至少两个、甚至多达八个核心，核心的数量能反映出大多数的数据库应用程序的一些优势。在决定使用哪一种CPU解决方案能够满足用户的数据库应用需求时，需要考虑两个基本的问题。
1．选哪一种处理器系列？
目前，Intel和AMD都推出了各种类型的64位产品线可供选择，当然也有一些其他市场占有率不太高的产品可供选择（Itanium、SPARC等）。
2．需要更多的核心还是更快的核心？
这些选择在某些时候会比用户所想象得要复杂。目前，Intel在处理器与系统的RAM之间的传输速度更快，因此在单个处理器核心的速度上处于领先地位，但处理器和相关的部件也更加昂贵。AMD作为其竞争对手，提供更廉价的处理器核心，它们的服务器处理器设计能够使每个核心最大程度地利用内存。如果用户要选择更廉价的核心，那么AMD在这方面更适合。当用户要将两个以上的物理CPU安装在同一台服务器中时，AMD在多插槽配置当中也有可用的最快的处理器的辉煌历史。
要指出用户的数据库应用类型更适合于哪种CPU方案（多核还是更快的核心），最好方法是使用类似top的工具监控目前现有服务器。如果每一个CPU所运行的进程数量不多，那么对于这种类型的工作负荷则使用速度更快的核心会更好。这种情况经常在以批处理的方式运行大量查询的情况下发生，例如，在大批量的数据需要进行排序形成报表时。但是相反地，如果所有的CPU都与并发进程处于活动状态，那么用户需要的可能是更多核心的CPU。这些情况在具有大量用户的应用程序中，例如，数据库支持的Web应用程序等很常见。
如果用户没有从对运行中的系统监控中得到好处，那么可以尝试通过记录数据库的局限性来推断用户处于的状况。PostgreSQL不允许将一个查询分配到多个核心，而在其他数据库中，称其为并行查询并予以支持。也就是说，用户要求在执行任意一个查询或较少数量的查询尽可能得快，那唯一的办法就是将其按照次序分配给最快的核心。
另外一种情况是，在用户需要优先装载或导出数据的时候，使用更快的核心是更好的方法。COPY是PostgreSQL最好的数据导入方法，该方法很容易（但不经常）受到CPU性能的限制，这可能会成为操作的瓶颈。虽然它可以将输入文件分割成若干个小片段，并使用并行的方法去装载这些文件，但是必须自行去创建或者获得，而不是那些服务器所了解的能够为用户自动创建的内容。使用pg_dump工具导出一个数据库的副本在某些系统上是另外一个可以受限于CPU的例子。2.1.2 内存
给应用优先配置多少内存，实际上由工作中需要处理的最常见操作的数据集大小决定。一般的，加大内存能够显著提高性能。在以下情况下，可以不用这个方法来提供更好的服务。● 如果用户的数据集大小恰好能容纳于这种较小数量的RAM的时
候，那么增加更多的内存并不能提升性能。用户可能需要使用更
快的处理器。● 当在一些数据仓库的环境下，所运行的程序扫描的表大小大于用
户可以给其分配的内存大小时，用户需要更快的硬盘而不是增加
更多的内存。
常见的情况下更多内存有助于经常访问那些能够容纳较大数量的数据，而不是较小的那些。这种情况的发生比用户所预想的更为频繁，这是因为需要存储数据库B-树索引，即在内存当中无法适应整个表或甚至仅仅是索引的话，那么尽可能存储更多的一部分索引就意味着基于索引的数据查找会很显著地加速。将位于树结果顶端的那些最常使用的数据块进行缓存也会有助于在不能将所有叶子节点放入内存的情况下的处理。
一旦用户有程序在运行，PostgreSQL缓冲区高速缓存当中用户通常可以有更多有关内存是如何使用的信息（在操作系统中也可以查看），并且可以看到哪些数据能保存。本书中关于使用pg_buffercache的章节将会讲述如何监控这种数据。2.1.3 磁盘
虽然在数据库服务器中用户经常遇见的是CPU成为该系统瓶颈的情况，但是绝对可能会碰到磁盘成为系统瓶颈的时候，特别是在系统中只有一块或两块硬盘的情况下比较明显。几年前，在硬盘上有两个基本的选择，一个是较为便宜的通常在桌面环境使用的ATA（也就是IDE）驱动器，另一个是在服务器上使用的SCSI驱动器。
这两个技术目前已经得到发展，在配置数据库服务器时，目前选择倾向于使用串行ATA（SATA）或者串行连接SCSI（SAS）。在两种接口之下，可能会发现其所使用的几乎是相同的驱动器，甚至磁盘控制器可以附加任意一种磁盘。结合这两个之间的微小性能差距，在它们之间做选择比之前更难。
每种技术当中参数都被进行了简单的比较，当下的一些详细信息如下所示。● SAS磁盘：● 更高的每分钟最大转速RPM：10000或15000。● 73GB到1TB是较为常见的容量。● 更高的每MB成本。● SATA磁盘：● 较低的磁盘每分钟最大转速：标准为7200转，在Western Digital VelociRaptor磁盘产品设计为每分钟10000转。● 更高的容量：最大2TB。● 较低的每MB成本。
一般情况下，用户会发现在相似规格的情况下，单个SAS硬盘的速度会比SATA硬盘要快。特别是由于SAS磁盘更快的机械性能，其随机I/O上的寻道性能会更好，有时磁盘的传输速率也更快。此外，由于SAS驱动器已支持类似更长的命令队列等高级特性，因此更有可能的是操作系统将有匹配支持去充分利用这些特性。1．RAID
廉价冗余磁盘阵列（RAID，Redundant Array of Inexpensive Disk）方法是解决单个磁盘驱动器在处理性能和可靠性上的局限性问题上的标准方法。一个RAID阵列会将多块磁盘纳入一组磁盘集当中将其视作一个单独的磁盘，这些磁盘通常具有相同的配置。其所产生的效果要么性能提高，要么可靠性提高，或者两者都有提高。在某些情况下，写入阵列的奇偶校验（parity）信息计算能够带来额外的可靠性。奇偶校验是数据校验的一种方式，它能够在信息丢失的情况下进行重组。从空间的角度来看，使用奇偶校验的RAID级别在驱动器故障存在的前提下写入数据方面是有效的，但是奇偶校验计算开销将会显著影响数据库应用程序。
较为常见的RAID阵列的基本形式包括如下的几种类型。● RAID 0：也称为条带化（Striping），即同时使用多块硬盘，并
行地将数据分散到每个硬盘中进行读写。其性能几乎能够得到线
性的提升（两块硬盘读取的速度是单块硬盘的两倍），但磁盘组
中任意一块硬盘出现故障则会丢失所有数据。● RAID 1：也称为镜像（Mirroring）。相同的数据具有多个副本存
储在多块硬盘当中。这样有时候可以提高性能——横跨两块硬
盘的良好RAID 1镜像，在处理两个读取操作时可能会通过向每
个磁盘发送一个读取操作来完成。并行读取两块硬盘时，每秒的
效率可以增加一倍，但通常情况下，使用RAID 1的原因通常是
为了进行冗余：即如果其中一块硬盘失效，那么系统会使用其他
的磁盘来继续相应操作。● RAID 10或RAID 1+0：首先使用成对的磁盘，然后使用RAID 1进
行镜像。随后使用RAID 0对结果集进行分组。这样既能提供较
高的性能，并且还可以允许其中的任意一块硬盘失效，不像
RAID5/6那样需要用很多方法来保证在最糟糕以及平常情况下的
速度。RAID 10特别适合在那些写操作比较繁重的环境下，此时
RAID5/6的奇偶校验计算会降低磁盘性能。因此，在高性能数据
库系统中，这是会优先采用的RAID级别。● RAID5：也称为带奇偶校验的条带化（Striped with Parity）。这
是介于RAID 0和RAID 1之间的一种折衷方法。数据类似RAID 0
分片存储在磁盘中，可以提高读取性能。但冗余数据存储在校验
盘中。如果阵列的其中一块磁盘失效，丢失的数据可以使用其他
磁盘的校验信息计算得出。能够用较小的空间浪费来解决硬盘失
效的问题，在RAID 5当中的写入操作的性能还是可以承受的。● RAID 6：RAID 6与RAID 5类似，除了更多的校验信息外，允许
两块硬盘失效。这是它的优点，同时也是缺点所在。RAID 6是
目前处理在RAID 5阵列中，一块硬盘失效后可以提供更长的时
间进行数据修复的普遍方法，具有较大容量。在此期间，阵列没
有额外的容错机制，同时当花费几个小时的激烈磁盘活动进行重
建时也无暇顾及在重建数据完成之前第二个驱动器的故障。同一
批次制造的磁盘很可能会发生令人惊讶的整组失效。
为了公平公正地去比较磁盘的性能，需要考虑大多数系统都将会有个来自多个磁盘（如RAID阵列）的裸性能（net performance）。由于SATA磁盘相对便宜一些，因此同样预算情况下所采购到的SATA磁盘会比SAS多一些。如果确信应用程序在负载分散于更多磁盘之上会得到更快的响应速度，那么单位成本内购买的更多东西必将会导致系统整体速度的加快。需要注意的是，这里的上限通常是服务器的物理硬件所决定的。因此在环境当中只有这么多的存储机架或者控制器端
试读结束[说明：试读内容隐藏了图片]