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

 介绍

在Nilenso,哥在搞一个 (开源的哦!)用来设计和发起调查的应用。

下面这个是一个调查的例子:

在内部,它是这样表示滴:

一个调查包括了许多问题(question)。一系列问题可以归到(可选)一个分类(category)中。我们实际的数据结构会复杂一点(特别是子问题sub-question部分),但先当它就只有question跟category吧。

我们是这样保存question跟category的。

每个question和category都有一个order_number字段。是个整型,用来指定它自己与其它兄弟的相对关系。

举个例子,比如对于上面这个调查:

Bar的order_number比Baz的小。

这样一个分类下的问题就能按正确的顺序出现:

# In category.rb

def sub_questions_in_order
 questions.order('order_number')
end

实际上一开始我们就是这样fetch整个调查的。每个category会按顺序获取到全部其下的子问题,依此类推遍历整个实体树。

这就给出了整棵树的深度优先的顺序:

对于有5层以上的内嵌、多于100个问题的调查,这样搞跑起来奇慢无比。

递归查询

哥也用过那些awesome_nested_set之类的gem,但据我所知,它们没一个是支持跨多model来fetch的。

后来哥无意中发现了一个文档说PostgreSQL有对递归查询的支持!唔,这个可以有。

那就试下用递归查询搞搞这个问题吧(此时哥对它的了解还很水,有不到位,勿喷)。

要在Postgres做递归查询,得先定义一个初始化查询,就是非递归部分。

本例里,就是最上层的question跟category。最上层的元素不会有父分类,所以它们的category_id是空的。

(
 SELECT id, content, order_number, type, category_id FROM questions
 WHERE questions.survey_id = 2 AND questions.category_id IS NULL
)
UNION
(
 SELECT id, content, order_number, type, category_id FROM categories
 WHERE categories.survey_id = 2 AND categories.category_id IS NULL
)

(这个查询和接下来的查询假定要获取的是id为2的调查)

这就获取到了最上层的元素。

下面要写递归的部分了。根据下面这个Postgres文档:

递归部分就是要获取到前面初始化部分拿到的元素的全部子项。

WITH RECURSIVE first_level_elements AS (
 -- Non-recursive term
 (
  (
   SELECT id, content, order_number, category_id FROM questions
   WHERE questions.survey_id = 2 AND questions.category_id IS NULL
  UNION
   SELECT id, content, order_number, category_id FROM categories
   WHERE categories.survey_id = 2 AND categories.category_id IS NULL
  )
 )
 UNION
 -- Recursive Term
 SELECT q.id, q.content, q.order_number, q.category_id
 FROM first_level_elements fle, questions q
 WHERE q.survey_id = 2 AND q.category_id = fle.id
)
SELECT * from first_level_elements;

等等,递归部分只能获取question。如果一个子项的第一个子分类是个分类呢?Postgres不给引用非递归项超过一次。所以在question跟category结果集上做UNION是不行的。这里得搞个改造一下:

WITH RECURSIVE first_level_elements AS (
 (
  (
   SELECT id, content, order_number, category_id FROM questions
   WHERE questions.survey_id = 2 AND questions.category_id IS NULL
  UNION
   SELECT id, content, order_number, category_id FROM categories
   WHERE categories.survey_id = 2 AND categories.category_id IS NULL
  )
 )
 UNION
 (
   SELECT e.id, e.content, e.order_number, e.category_id
   FROM
   (
    -- Fetch questions AND categories
    SELECT id, content, order_number, category_id FROM questions WHERE survey_id = 2
    UNION
    SELECT id, content, order_number, category_id FROM categories WHERE survey_id = 2
   ) e, first_level_elements fle
   WHERE e.category_id = fle.id
 )
)
SELECT * from first_level_elements;

在与非递归部分join之前就将category和question结果集UNION了。

这就产生了所有的调查元素:

不幸的是,顺序好像不对。
 
在递归查询内排序

这问题出在虽然有效的为一级元素获取到了全部二级元素,但这做的是广度优先的查找,实际上需要的是深度优先。

这可怎么搞呢?

Postgres有能在查询时建array的功能。

那就就建一个存放fetch到的元素的序号的array吧。将这array叫做path好了。一个元素的path就是:

父分类的path(如果有的话)+自己的order_number

如果用path对结果集排序,就可以将查询变成深度优先的啦!

WITH RECURSIVE first_level_elements AS (
 (
  (
   SELECT id, content, category_id, array[id] AS path FROM questions
   WHERE questions.survey_id = 2 AND questions.category_id IS NULL
  UNION
   SELECT id, content, category_id, array[id] AS path FROM categories
   WHERE categories.survey_id = 2 AND categories.category_id IS NULL
  )
 )
 UNION
 (
   SELECT e.id, e.content, e.category_id, (fle.path || e.id)
   FROM
   (
    SELECT id, content, category_id, order_number FROM questions WHERE survey_id = 2
    UNION
    SELECT id, content, category_id, order_number FROM categories WHERE survey_id = 2
   ) e, first_level_elements fle
   WHERE e.category_id = fle.id
 )
)
SELECT * from first_level_elements ORDER BY path;

这很接近成功了。但有两个 What's your favourite song?

这是由比较ID来查找子项引起的:

WHERE e.category_id = fle.id

fle同时包含question和category。但需要的是只匹配category(因为question不会有子项)。

那就给每个这样的查询硬编码一个类型(type)吧,这样就不用试着检查question有没有子项了:

WITH RECURSIVE first_level_elements AS (
 (
  (
   SELECT id, content, category_id, 'questions' as type, array[id] AS path FROM questions
   WHERE questions.survey_id = 2 AND questions.category_id IS NULL
  UNION
   SELECT id, content, category_id, 'categories' as type, array[id] AS path FROM categories
   WHERE categories.survey_id = 2 AND categories.category_id IS NULL
  )
 )
 UNION
 (
   SELECT e.id, e.content, e.category_id, e.type, (fle.path || e.id)
   FROM
   (
    SELECT id, content, category_id, 'questions' as type, order_number FROM questions WHERE survey_id = 2
    UNION
    SELECT id, content, category_id, 'categories' as type, order_number FROM categories WHERE survey_id = 2
   ) e, first_level_elements fle
   -- Look for children only if the type is 'categories'
   WHERE e.category_id = fle.id AND fle.type = 'categories'
 )
)
SELECT * from first_level_elements ORDER BY path;

这看起来就ok了。搞定!

下面就看看这样搞的性能如何。

用下面这个脚本(在界面上创建了一个调查之后),哥生成了10个子问题序列,每个都有6层那么深。

survey = Survey.find(9)
10.times do
 category = FactoryGirl.create(:category, :survey => survey)
 6.times do
  category = FactoryGirl.create(:category, :category => category, :survey => survey)
 end
 FactoryGirl.create(:single_line_question, :category_id => category.id, :survey_id => survey.id)
end

每个问题序列看起来是这样滴:

那就来看看递归查询有没有比一开始的那个快一点吧。

pry(main)> Benchmark.ms { 5.times { Survey.find(9).sub_questions_using_recursive_queries }}
=> 36.839999999999996

pry(main)> Benchmark.ms { 5.times { Survey.find(9).sub_questions_in_order } }
=> 1145.1309999999999

快了31倍以上?不错不错。

(0)

相关推荐

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

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

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

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

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

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

  • 一个提升PostgreSQL性能的小技巧

    在一个(差)的PostgreSQL 查询中只要一个小小到改动(ANY(ARRAY[...])to ANY(VALUES(...)))就能把查询时间从20s缩减到0.2s.从最简单的学习使用 EXPLAIN ANALYZE开始,到学习使用 Postgres community大量学习时间的投入将有百倍时间到回报. 使用Postgres监测慢的Postgres查询 在这周早些时候,一个用于我们的图形编辑器上的小表(10GB,1500万行)的主键查询,在我们的一个(多个)数据库上发生来大的查询性能问题

  • 在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

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

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

  • 介绍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

  • 使用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 \&

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

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

  • 深入解读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"

随机推荐