- 论坛徽章:
- 1
|
转自
http://postgresql-chinese.blogspot.com/
这里有大量的PostgreSQL的相关信息。
原文（日文）出处：
http://itpro.nikkeibp.co.jp/arti ... =lin-server&P=1
现在正在开发中的PostgreSQL 8.3，很快就要「feature freeze」(功能确定)。5月期间进入β测试阶段，最早预计在7月正式发表。
8.3版本在性能方面有大幅度的改善，尤其被关注的是HOT(Heap Only Tuples)。
关于HOT
HOT用一句话描述的话就是：改善PostgreSQL更新性能的部件。在说明HOT之前，首先解释为何PostgreSQL的更新性能成为一个问题。
PostgreSQL更新处理的弱点
PostgreSQL采用追加型的架构，更新的时候，在数据库内部删除行之后再追加新行。删除掉的行由VACUUM命令作为可以再利用区域回收，然后被再利用。如果频繁进行更新处理也必须让VACUUM频繁运行，不然废弃区域会不断增加导致数据表肥大化而致使性能恶化。
VACUUM需要扫描数据表的全部数据，所以数据表越大处理时间越长。因此，如果数据表很大而且更新又很频繁，那么无论怎么频繁运行VACUUM也来不及回收更新处理产生的废弃区域。
然而问题不仅如此。
更新处理不仅仅是针对数据表本身，索引也必须同时更新。PostgreSQL的某个列被更新的话，关联索引也需要全部更新。因此，拥有大量索引的数据表的更新处理量将会特别大，索引也会越来越肥大化。索引的废弃区域也因此难于被VACUUM回收再利用，比数据表的问题更加严重。
利用HOT消除废弃区域
HOT为了解决这个问题设计了新的更新处理算法，利用HOT，不仅仅是数据表的肥大化，索引的无用肥大化也可以防止。
下边，简单地解释HOT的工作原理。
另外，正如文章开头描述的那样，PostgreSQL 8.3还在开发中，今后还会有些变化，也有不同实现的可能性。说不定，最坏比如8.3根本不会发布的情况也会出现（当然这种可能性非常低）。
抑制索引废弃领域的增加
假设有如下一个管理网页访问次数的简单数据表，当某个URL被访问时cnt增加计数，这是一个频繁更新的典型案例。
CREATE TABLE t1(
url TEXT PRIMARY KEY,-- 主键，自动附加索引
cnt INTEGER
);
cnt更新时，url字段的关联索引也会被更新。考虑一下cnt发生变更而url没有变化的情况，这时url的索引更新是没有必要的。而在HOT下，这样的索引更新不会发生，因而能够抑制索引肥大化。
这个没有关联索引更新的行为被称呼为「HEAP ONLY TUPLE」（HOT就是这样命名的）。
不使用VACUUM抑制数据表的废弃领域
更新cnt时，这行数据被删除（正确地说是在这个时刻变得不可见），然后追加新的数据行。被删除的行中放置一个被删除标志，以及一个指向新行的指针。再次更新这行数据时，从旧行的指针很容易找到新行，然后用上边提到的同样方式在这里放置指向新行的指针。这样反复更新的话就会形成一个指针链，叫做更新链（UPDATE chain）。
更新链越长检索和更新花费的时间就越长，直到运行VACUUM才会消除这种影响，这是现在PostgreSQL的问题点。
HOT也会形成更新链，这一点没有变化，但是如果没有其他的事务参照，对于HEAP ONLY TUPLE而言，会不调用VACUUM而仅仅回收删除行。能这样做的原因就是不需要从索引参照HEAP ONLY TUPLE。回收是用SELECT处理进行的，沿着HEAP ONLY TUPLE的更新链一边前进一边判断这一行是否需要废弃，如果可以废弃的话则作为可再利用对象处理。因此，它能够把更新链的长度控制在最短。
在SELECT时做这样的处理会有overhead的担心，通常PostgreSQL对数据表的访问是以块为单位进行，而上边对更新链的寻址是在已经读入块的缓存之上处理的，不会产生额外的I/O，因此几乎不会影响效率。
当然更新后的数据如果不写入数据块是不能进行这样的处理的，这个时候运行VACUUM就变得必要，实际业务中许多案例更新后的长度并没有增长很多，我认为也不会有什么大的影响。
HOT的效果
使用HOT以后更新性能到底会有多大程度的改善呢？我们看看开发者自己的benchmark测试结果。
benchmark是利用PostgreSQL附属的pgbench工具进行的。这个测试在900万行的数据表（accounts）上进行更新，同时将日志插入到另一个表中，这一连串操作都在同一个事务中。而这样的事务同时由90个每个运行5万次的session并发执行，并且没有在更新的列上定义索引。
运行这个测试的PC机fill factor设定为90%，2G内存，128M共享缓存，测试中autovacuum设定为每分钟启动一次。
benchmark在开发中的8.3之上，HOT有效和无效的情况下运行比较。
测试结果图示如下（HOTあり：HOT有效； HOTなし：HOT无效）：
纵轴是TPS，即每秒钟被执行的事务数，正如我们看到的，HOT有效的情况下性能大约提高一倍，也就是说HOT的效果是很大的。
另外，也证明了HOT能有效抑制废弃区域的增长。
看一下开始前和结束后数据表以及索引尺寸的比较图，在HOT有效的情况下，数据表和索引尺寸几乎都没有增长。（オリジナルサイズ：原始尺寸； HOTあり：HOT有效； HOTなし：HOT无效）
8.3中HOT之外的改善项目
除了HOT，还有许多预定在8.3中追加的新特性，下边我们来看一下引人关注的项目，不过这其中还有一些正在评估(preview)中，最终不在8.3中引入也是有可能的。
全文搜索引擎(Full-Text Search, FTS)
即将到来的8.3已不再像之前的版本附加功能(Tsearch v1, Tsearch v2)的方式导入，而是整合到DBMS成为系统的一部分，也伴随着增加了一些sql命令。
并发CREATE INDEX(CREATE INDEX CONCURRENTLY: CIC)
一直以来运行CREATE INDEX时，会将相应数据表锁住而禁止行的插入、更新和删除操作。这次追加的「CONCURRENTLY」选项，将不锁表进行CREATE INDEX，这对向正在使用中的大数据表增加新的索引特别有用。
BITMAP索引
BITMAP索引时已经在许多商业数据库中实现的索引类型，对性别这种种类比较少的值特别有效。
负荷分散的CHECKPOINT
CHECKPOINT是定期运行的对数据库缓存和数据库磁盘内容的同期化处理，这个时候会发生大量的磁盘写入操作而导致性能低下，负荷分散的CHECKPOINT能够分散磁盘写入操作，尽量使数据库负荷均等化。
DSM(Dead Space Map)
DSM是在共享内存中记录数据表和索引废弃区域的数据结构，VACUUM命令参照DSM而不是将整个数据表读入，因此能够实现高速化。DSM是由bgwriter进程生成的。
其他改善项目
追加对JIS X 0213（日语文字编码）字符集的支持。 |
|
免费注册
发表于 2007-04-17 23:09
