一个提升PostgreSQL性能的小技巧

在一个(差)的PostgreSQL 查询中只要一个小小到改动(ANY(ARRAY[...])to ANY(VALUES(...)))就能把查询时间从20s缩减到0.2s。从最简单的学习使用 EXPLAIN ANALYZE开始,到学习使用 Postgres community大量学习时间的投入将有百倍时间到回报。

使用Postgres监测慢的Postgres查询

在这周早些时候,一个用于我们的图形编辑器上的小表(10GB,1500万行)的主键查询,在我们的一个(多个)数据库上发生来大的查询性能问题。

99.9%到查询都是非常迅速流畅的,但是在一些使用大量的枚举值的地方,这些查询会需要20秒。花费如此多到时间在数据库上,意味着使用者必须在浏览器面前等待图形编辑器的响应。很明显只因为这0.01%就会造成很不好到影响。

查询和查询计划

下面是这个出问题的查询

SELECT c.key,
    c.x_key,
    c.tags,
    x.name
 FROM context c
 JOIN x
  ON c.x_key = x.key
WHERE c.key = ANY (ARRAY[15368196, -- 11,000 other keys --)])
 AND c.x_key = 1
 AND c.tags @> ARRAY[E'blah'];

表X有几千行数据,表C有1500万条数据。两张表的主键值“key”都有适当的索引。这是一个非常简单清晰的主键查询。但有趣的是,当增加主键内容的数量,如在主键有11,000个值的时候,通过在查询语句上加上 EXPLAIN (ANALYZE, BUFFERS)我们得到如下的查询计划。

Nested Loop (cost=6923.33..11770.59 rows=1 width=362) (actual time=17128.188..22109.283 rows=10858 loops=1)
 Buffers: shared hit=83494
 -> Bitmap Heap Scan on context c (cost=6923.33..11762.31 rows=1 width=329) (actual time=17128.121..22031.783 rows=10858 loops=1)
    Recheck Cond: ((tags @> '{blah}'::text[]) AND (x_key = 1))
    Filter: (key = ANY ('{15368196,(a lot more keys here)}'::integer[]))
    Buffers: shared hit=50919
    -> BitmapAnd (cost=6923.33..6923.33 rows=269 width=0) (actual time=132.910..132.910 rows=0 loops=1)
       Buffers: shared hit=1342
       -> Bitmap Index Scan on context_tags_idx (cost=0.00..1149.61 rows=15891 width=0) (actual time=64.614..64.614 rows=264777 loops=1)
          Index Cond: (tags @> '{blah}'::text[])
          Buffers: shared hit=401
       -> Bitmap Index Scan on context_x_id_source_type_id_idx (cost=0.00..5773.47 rows=268667 width=0) (actual time=54.648..54.648 rows=267659 loops=1)
          Index Cond: (x_id = 1)
          Buffers: shared hit=941
 -> Index Scan using x_pkey on x (cost=0.00..8.27 rows=1 width=37) (actual time=0.003..0.004 rows=1 loops=10858)
    Index Cond: (x.key = 1)
    Buffers: shared hit=32575
Total runtime: 22117.417 ms

在结果的最底部你可以看到,这个查询总共花费22秒。我们可以非常直观的通过下面的CPU使用率图观察到这22秒的花费。大部分的时间花费在 Postgres和 OS 上, 只有很少部分用于I/O .

在最低的层面,这些查询看起来就像是这些CPU利用率的峰值。CPU图很少有用,但是在这种条件下它证实了关键的一点:数据库并没有等待磁盘去读取数据。它在做一些排序,哈希以及行比较之类的事情。

第二个有趣的度量,就是距离这些峰值很近的轨迹,它们是由Postgres“取得”的行数(本例中没有返回,就看看再忽略掉吧)。

显然有些动作在规则的有条不紊的浏览过许多行:我们的查询。
 
Postgres 的问题所在:位图扫描

下面是行匹配的查询计划

Buffers: shared hit=83494
 -> Bitmap Heap Scan on context c (cost=6923.33..11762.31 rows=1 width=329) (actual time=17128.121..22031.783 rows=10858 loops=1)
    Recheck Cond: ((tags @> '{blah}'::text[]) AND (x_key = 1))
    Filter: (key = ANY ('{15368196,(a lot more keys here)}'::integer[]))
    Buffers: shared hit=50919

Postgres 使用位图扫描表C. 当主键的数据量小的时候,它能有效的使用索引在内存里建立位图。如果位图太大,最优查询计划就改变查询方式了。在我们这个查询中,因为主键包含的数据量很大,所以查询就使用最优(系统自己判断的)的方式去检索查询候选行,并且立即查询所有和主键匹配的数据。就是这些¨放入内存¨和¨立即查询¨花费太多的时间(查询计划中的Recheck Cond)。

幸好只有30%的数据被导入到内存中,所以还不至于像从硬盘里读取那么坏。但它仍然对性能有非常明显的影响。记住,查询是非常简单的。这是一个主键查询所以没有很多明了的方式来确定它有没有戏剧性的重新架构数据库或应用程序。PGSQL-Performance mailing list给予了我们很大的帮助.
 
解决方案

这是我们喜欢开源和喜欢帮助用户的另外一个原因。Tom Lane是开源代码作者中最盛产的程序员之一,他建议我们做如下尝试:

SELECT c.key,
    c.x_key,
    c.tags,
    x.name
 FROM context c
 JOIN x
  ON c.x_key = x.key
WHERE c.key = ANY (VALUES (15368196), -- 11,000 other keys --)
 AND c.x_key = 1
 AND c.tags @> ARRAY[E'blah'];

把ARRAY改成VALUES,你能指出他们的不同点吗?

我们使用ARRAY[...]列举出所有的关键字以用来查询,但是这却欺骗了查询优化器。然而Values(...)却能够让优化器充分使用关键字索引。仅仅是一行代码的改变,并且没有产生任何语义的改变。

下面是新查询语句的写法,差别就在于第三和第十四行。

Nested Loop (cost=168.22..2116.29 rows=148 width=362) (actual time=22.134..256.531 rows=10858 loops=1)
 Buffers: shared hit=44967
 -> Index Scan using x_pkey on x (cost=0.00..8.27 rows=1 width=37) (actual time=0.071..0.073 rows=1 loops=1)
    Index Cond: (id = 1)
    Buffers: shared hit=4
 -> Nested Loop (cost=168.22..2106.54 rows=148 width=329) (actual time=22.060..242.406 rows=10858 loops=1)
    Buffers: shared hit=44963
    -> HashAggregate (cost=168.22..170.22 rows=200 width=4) (actual time=21.529..32.820 rows=11215 loops=1)
       -> Values Scan on "*VALUES*" (cost=0.00..140.19 rows=11215 width=4) (actual time=0.005..9.527 rows=11215 loops=1)
    -> Index Scan using context_pkey on context c (cost=0.00..9.67 rows=1 width=329) (actual time=0.015..0.016 rows=1 loops=11215)
       Index Cond: (c.key = "*VALUES*".column1)
       Filter: ((c.tags @> '{blah}'::text[]) AND (c.x_id = 1))
       Buffers: shared hit=44963
Total runtime: 263.639 ms

查询时间从22000ms下降到200ms,仅仅一行代码的改变效率就提高了100倍。

在生产中使用的新查询

即将发布的一段代码:
它使数据库看起来更美观轻松. 

 第三方工具

postgres慢查询不存在了。但是有谁乐意被0.1%不幸的少数折磨。要立即验证修改查询的影响,就需要Datadog来帮助我们判断修改是否是正确的。

如果你想要找出对Postgres查询改变的影响,可能需要几分钟来注册一个免费的Datadog账号。

(0)

相关推荐

  • 介绍PostgreSQL中的范围类型特性

    PostgreSQL 9.2 的一项新特性就是范围类型 range types,通过这个名字你可以轻松猜出该类型的用途,它可让你为某列数据定义数值范围. 这个简单的特性可以让我们不需要定义两个字段来描述数值的开始值和结束值,一个最直观的例子就是: postgres# CREATE TABLE salary_grid (id int, position_name text, start_salary int, end_salary int); CREATE TABLE postgres# INSE

  • 使用Bucardo5实现PostgreSQL的主数据库复制

    下一代异步多个主数据库复制系统Bucardo 5发布了.这个版本删除了老版本中两个数据库源的限制,允许有更多的源数据库(即主数据库)以及更多的目标数据库(即备份数据库).Bucardo还可以复制到其他类型的目标数据库,其中包括MySQL.MariaDB.Oracle.SQLite.MongoDB和Redis.Bucardo已经被完全重写了,这个版本比前一版本Bucardo 4功能更强大,效率更高.你可以访问Bucardo wiki查找最新版本的Bucardo. 这篇文章快速的介绍了一下Bucar

  • 深入解读PostgreSQL中的序列及其相关函数的用法

    一.简介 序列对象(也叫序列生成器)就是用CREATE SEQUENCE 创建的特殊的单行表.一个序列对象通常用于为行或者表生成唯一的标识符. 二.创建序列 方法一:直接在表中指定字段类型为serial 类型 david=# create table tbl_xulie ( david(# id serial, david(# name text); NOTICE: CREATE TABLE will create implicit sequence "tbl_xulie_id_seq"

  • 在PostgreSQL上安装并使用扩展模块的教程

    安装模块 注意: 我的运行环境是 Ubuntu 10.04 和 PostgreSQL 8.4 首先安装 postgresql-contrib 包并重启数据库服务器,然后检查 contrib 目录看是否包含一些可用模块: sudo apt-get install postgresql-contrib sudo /etc/init.d/postgresql-8.4 restart cd /usr/share/postgresql/8.4/contrib/ ls 然后我们创建一个名为 module_t

  • 详细讲解PostgreSQL中的全文搜索的用法

    开发Web应用时,你经常要加上搜索功能.甚至还不知能要搜什么,就在草图上画了一个放大镜. 搜索是项非常重要的功能,所以像elasticsearch和SOLR这样的基于lucene的工具变得很流行.它们都很棒.但使用这些大规模"杀伤性"的搜索武器前,你可能需要来点轻量级的,但又足够好的搜索工具. 所谓"足够好",我是指一个搜索引擎拥有下列的功能: 词根(Stemming) 排名/提升(Ranking / Boost) 支持多种语言 对拼写错误模糊搜索 方言的支持 幸运

  • 在PostgreSQL中使用数组时值得注意的一些地方

    在Heap中,我们依靠PostgreSQL支撑大多数后端繁重的任务,我们存储每个事件为一个hstore blob,我们为每个跟踪的用户维护一个已完成事件的PostgreSQL数组,并将这些事件按时间排序. Hstore能够让我们以灵活的方式附加属性到事件中,而且事件数组赋予了我们强大的性能,特别是对于漏斗查询,在这些查询中我们计算不同转化渠道步骤间的输出. 在这篇文章中,我们看看那些意外接受大量输入的PostgreSQL函数,然后以高效,惯用的方式重写它. 你的第一反应可能是将PostgreSQ

  • 在PostgreSQL的基础上创建一个MongoDB的副本的教程

    我有一个偷懒的想法.这个好点子该如何开始呢?好吧,这是一个恰如其分的小疯狂:为什么不直接在Postgres的基础上建立我们自己的MongoDB版本呢?这听起来有点牵强附会,但却简单而实在. 当NoSQL运动风生水起的时候,Postgres社区没有干坐着摆弄他们的大拇指.他们持续开发,贯穿整个Postgres的生态系统,几个突出的功能吸引了我的眼球:整合JSON支持和PLV8.PLV8把V8 Javascript引擎引入到Postgres,他让Javascript成为一个第一类别的语言(first

  • 在PostgreSQL中使用日期类型时一些需要注意的地方

    当我们这些使用Rails的人看到例如5.weeks.from_nowor3.days.ago + 2.hours时并不会感到惊讶.同样,PostgreSQL也可以做到,你可以通过简单调用PostgreSQL内置函数来实现相同的功能. 当前时间/日期/时间戳 获取当前时间的方式有很多种,在这之前我们需要知道以下两种类型的区别: 总是返回当前的值 (clock_timestamp()) 总是返回当前值,但在事务中它返回的是事务开始的时间(now()) 让我们看下面这个例子 postgres=# BE

  • 在PostgreSQL中实现递归查询的教程

     介绍 在Nilenso,哥在搞一个 (开源的哦!)用来设计和发起调查的应用. 下面这个是一个调查的例子: 在内部,它是这样表示滴: 一个调查包括了许多问题(question).一系列问题可以归到(可选)一个分类(category)中.我们实际的数据结构会复杂一点(特别是子问题sub-question部分),但先当它就只有question跟category吧. 我们是这样保存question跟category的. 每个question和category都有一个order_number字段.是个整

  • 使用Ruby on Rails和PostgreSQL自动生成UUID的教程

    Rails 4 能原生态的支持Postgres 中的UUID(Universally Unique Identifier,可通用的唯一标识符)类型.在此,我将向你描述如何在不用手工修改任何Rails代码的情况下,用它来生成UUID. 首先,你需要激活Postgres的扩展插件'uuid-ossp': class CreateUuidPsqlExtension < ActiveRecord::Migration def self.up execute "CREATE EXTENSION \&

随机推荐