在PostgreSQL中使用数组时值得注意的一些地方
在Heap中，我们依靠PostgreSQL支撑大多数后端繁重的任务，我们存储每个事件为一个hstore blob，我们为每个跟踪的用户维护一个已完成事件的PostgreSQL数组，并将这些事件按时间排序。 Hstore能够让我们以灵活的方式附加属性到事件中，而且事件数组赋予了我们强大的性能，特别是对于漏斗查询，在这些查询中我们计算不同转化渠道步骤间的输出。
在这篇文章中，我们看看那些意外接受大量输入的PostgreSQL函数，然后以高效，惯用的方式重写它。
你的第一反应可能是将PostgreSQL中的数组看做像C语言中对等的类似物。你之前可能用过变换阵列位置或切片来操纵数据。不过要小心，在PostgreSQL中不要有这样的想法，特别是数组类型是变长的时，比如JSON、文本或是hstore。如果你通过位置来访问PostgreSQL数组，你会进入一个意想不到的性能暴跌的境地。
这种情况几星期前在Heap出现了。我们在Heap为每个跟踪用户维护一个事件数组，在这个数组中我们用一个hstore datum代表每个事件。我们有一个导入管道来追加新事件到对应的数组。为了使这一导入管道是幂等的，我们给每个事件设定一个event_id，我们通过一个功能函数重复运行我们的事件数组。如果我们要更新附加到事件的属性的话，我们只需使用相同的event_id转储一个新的事件到管道中。
所以，我们需要一个功能函数来处理hstores数组，并且，如果两个事件具有相同的event_id时应该使用数组中最近出现的那个。刚开始尝试这个函数是这样写的：
-- This is slow, and you don't want to use it! -- -- Filter an array of events such that there is only one event with each event_id. -- When more than one event with the same event_id is present, take the latest one. CREATE OR REPLACE FUNCTION dedupe_events_1(events HSTORE[]) RETURNS HSTORE[] AS $$ SELECT array_agg(event) FROM ( -- Filter for rank = 1, i.e. select the latest event for any collisions on event_id. SELECT event FROM ( -- Rank elements with the same event_id by position in the array, descending.
这个查询在拥有2.4GHz的i7CPU及16GB Ram的macbook pro上测得，运行脚本为：https://gist.github.com/drob/9180760。
在这边究竟发生了什么呢? 关键在于PostgreSQL存贮了一个系列的hstores作为数组的值, 而不是指向值的指针. 一个包含了三个hstores的数组看起来像
{“event_id=>1,data=>foo”, “event_id=>2,data=>bar”, “event_id=>3,data=>baz”}
相反的是
{[pointer], [pointer], [pointer]}
对于那些长度不一的变量, 举个例子. hstores, json blobs, varchars,或者是 text fields, PostgreSQL 必须去找到每一个变量的长度. 对于evaluateevents[2], PostgreSQL 解析从左侧读取的事件直到读取到第二次读取的数据. 然后就是 forevents[3], 她再一次的从第一个索引处开始扫描,直到读到第三次的数据! 所以, evaluatingevents[sub]是 O(sub), 并且 evaluatingevents[sub]对于在数组中的每一个索引都是 O(N2), N是数组的长度.
PostgreSQL能得到更加恰当的解析结果, 它可以在这样的情况下分析该数组一次. 真正的答案是可变长度的元素与指针来实现，以数组的值, 以至于,我们总能够处理 evaluateevents[i]在不变的时间内.
即便如此，我们也不应该让PostgreSQL来处理，因为这不是一个地道的查询。除了generate_subscripts我们可以用unnest，它解析数组并返回一组条目。这样一来，我们就不需要在数组中显式加入索引了。
-- Filter an array of events such that there is only one event with each event_id.
-- When more than one event with the same event_id, is present, take the latest one.
CREATE OR REPLACE FUNCTION dedupe_events_2(events HSTORE[]) RETURNS HSTORE[] AS $$
SELECT array_agg(event)
FROM (
-- Filter for rank = 1, i.e. select the latest event for any collisions on event_id.
SELECT event
FROM (
-- Rank elements with the same event_id by position in the array, descending.
SELECT event, row_number AS index, rank()
OVER (PARTITION BY (event -> 'event_id')::BIGINT ORDER BY row_number DESC)
FROM (
-- Use unnest instead of generate_subscripts to turn an array into a set.
SELECT event, row_number()
OVER (ORDER BY event -> 'time')
FROM unnest(events) AS event
) unnested_data
) deduped_events
WHERE rank = 1
ORDER BY index ASC
) to_agg;
$$ LANGUAGE SQL IMMUTABLE;
结果是有效的，它花费的时间跟输入数组的大小呈线性关系。对于100K个元素的输入它需要大约半秒，而之前的实现需要40秒。
这实现了我们的需求：
- 一次解析数组，不需要unnest。
- 按event_id划分。
- 对每个event_id采用最新出现的。
- 按输入索引排序。
教训：如果你需要访问PostgreSQL数组的特定位置，考虑使用unnest代替。
SELECT events[sub] AS event, sub, rank() OVER (PARTITION BY (events[sub] -> 'event_id')::BIGINT ORDER BY sub DESC) FROM generate_subscripts(events, 1) AS sub ) deduped_events WHERE rank = 1 ORDER BY sub ASC ) to_agg; $$ LANGUAGE SQL IMMUTABLE;
这样奏效，但大输入是性能下降了。这是二次的，在输入数组有100K各元素时它需要大约40秒！
这个查询在拥有2.4GHz的i7CPU及16GB Ram的macbook pro上测得，运行脚本为：https://gist.github.com/drob/9180760。
在这边究竟发生了什么呢? 关键在于PostgreSQL存贮了一个系列的hstores作为数组的值, 而不是指向值的指针. 一个包含了三个hstores的数组看起来像
{“event_id=>1,data=>foo”, “event_id=>2,data=>bar”, “event_id=>3,data=>baz”}
相反的是
{[pointer], [pointer], [pointer]}
对于那些长度不一的变量, 举个例子. hstores, json blobs, varchars,或者是 text fields, PostgreSQL 必须去找到每一个变量的长度. 对于evaluateevents[2], PostgreSQL 解析从左侧读取的事件直到读取到第二次读取的数据. 然后就是 forevents[3], 她再一次的从第一个索引处开始扫描,直到读到第三次的数据! 所以, evaluatingevents[sub]是 O(sub), 并且 evaluatingevents[sub]对于在数组中的每一个索引都是 O(N2), N是数组的长度.
PostgreSQL能得到更加恰当的解析结果, 它可以在这样的情况下分析该数组一次. 真正的答案是可变长度的元素与指针来实现，以数组的值, 以至于,我们总能够处理 evaluateevents[i]在不变的时间内.
即便如此，我们也不应该让PostgreSQL来处理，因为这不是一个地道的查询。除了generate_subscripts我们可以用unnest，它解析数组并返回一组条目。这样一来，我们就不需要在数组中显式加入索引了。
-- Filter an array of events such that there is only one event with each event_id.
-- When more than one event with the same event_id, is present, take the latest one.
CREATE OR REPLACE FUNCTION dedupe_events_2(events HSTORE[]) RETURNS HSTORE[] AS $$
SELECT array_agg(event)
FROM (
-- Filter for rank = 1, i.e. select the latest event for any collisions on event_id.
SELECT event
FROM (
-- Rank elements with the same event_id by position in the array, descending.
SELECT event, row_number AS index, rank()
OVER (PARTITION BY (event -> 'event_id')::BIGINT ORDER BY row_number DESC)
FROM (
-- Use unnest instead of generate_subscripts to turn an array into a set.
SELECT event, row_number()
OVER (ORDER BY event -> 'time')
FROM unnest(events) AS event
) unnested_data
) deduped_events
WHERE rank = 1
ORDER BY index ASC
) to_agg;
$$ LANGUAGE SQL IMMUTABLE;
结果是有效的，它花费的时间跟输入数组的大小呈线性关系。对于100K个元素的输入它需要大约半秒，而之前的实现需要40秒。
这实现了我们的需求：
- 一次解析数组，不需要unnest。
- 按event_id划分。
- 对每个event_id采用最新出现的。
- 按输入索引排序。
教训：如果你需要访问PostgreSQL数组的特定位置，考虑使用unnest代替。
相关文章
这篇文章主要介绍了Multisim访问主数据库时发生错误原因分析及解决办法的相关资料,这个错误绝大多数情况源于权限不足未以管理员身份安装或运行程序,导致其无法读写系统目录中的主数据库文件,需要的朋友可以参考下2026-04-04
这篇文章主要介绍了梧桐数据库和Gbase数据库的日期函数使用方法,包括日期加减、时间戳加减和其他日期函数,虽然两个数据库的函数名不同,但功能相似,为开发提供了便利,需要的朋友可以参考下2025-02-02
MySQL有很多可以导入数据的方法，然而这些只是数据传输中的一半，另外的一般是从MySQL数据库中导出数据。有许多的原因我们需要导出数据。一个重要的原因是用于备份数据库。数据的造价常常是昂贵的，需要谨慎处理它们。2006-12-12
这篇文章主要给大家介绍了关于SQL语句优化的相关资料，文中通过示例代码介绍的非常详细，对大家学习或者使用SQL具有一定的参考学习价值，需要的朋友们下面来一起学习学习吧2019-05-05
Navicat 是香港卓软数字科技有限公司生产的一系列 MySQL、MariaDB、MongoDB、Oracle、SQLite、PostgreSQL 及 Microsoft SQL Server 的图形化数据库管理及发展软件。这篇文章主要介绍了Linux系统下Navicat 激活教程详解,需要的朋友可以参考下2021-08-08
DBeaver是一个通用的数据库客户端,可以通过配置不同驱动连接各种不同的数据库,这篇文章主要介绍了通过DBeaver连接GaussDB数据库的相关资料,包括前置条件、连接步骤、常见问题及解决方案、高级操作,需要的朋友可以参考下2025-11-11
这篇文章主要给大家介绍了关于neo4j创建数据库以及导入csv文件内容的相关资料,Neo4j是一个基于图形结构的NoSQL数据库,它提供了一种高效的方式来管理和查询大型复杂数据,需要的朋友可以参考下2023-11-11
SQL中case when then else end用法实例
CASE WHEN THEN ELSE END是一个固定搭配,这样排列是想把通过格式把逻辑展示出来,CASE告诉计算机接下来是条件句式了,下面这篇文章主要给大家介绍了关于SQL中case when then else end用法的相关资料,需要的朋友可以参考下2023-02-02
powerdesigner for mysql脚本要求字段、表名有注释操作
在PowerDesigner中,可以通过修改DBMS设置为MySQL数据库添加字段和表名的注释,具体步骤包括编辑当前的DBMS设置,并在相应的Script选项下调整Column和Table的配置,本文给大家介绍powerdesigner for mysql脚本要求字段、表名有注释操作,感兴趣的朋友跟随小编一起看看吧2023-07-07
ClickHouse数据库的监控与运维：监控指标、监控工具、运维策略、故障处理
本文详细介绍了ClickHouse数据库的监控与运维策略,包括监控指标（服务器指标、ClickHouse指标、ZooKeeper指标）、监控工具（Prometheus+Grafana、ClickHouse系统表、日志监控）、运维策略（日常维护、配置管理、安全管理）以及故障处理流程和案例2026-03-03
最新评论