偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

正確使用PostgreSQL的數(shù)組類型

開發(fā) 前端 PostgreSQL
在Heap中,我們依靠PostgreSQL支撐大多數(shù)后端繁重的任務,我們存儲每個事件為一個hstore blob,我們?yōu)槊總€跟蹤的用戶維護一個已完成事件的PostgreSQL數(shù)組,并將這些事件按時間排序。
在Heap中,我們依靠PostgreSQL支撐大多數(shù)后端繁重的任務,我們存儲每個事件為一個hstore blob,我們?yōu)槊總€跟蹤的用戶維護一個已完成事件的PostgreSQL數(shù)組,并將這些事件按時間排序。 Hstore能夠讓我們以靈活的方式附加屬性到事件中,而且事件數(shù)組賦予了我們強大的性能,特別是對于漏斗查詢,在這些查詢中我們計算不同轉化渠道步驟間的輸出。

在這篇文章中,我們看看那些意外接受大量輸入的PostgreSQL函數(shù),然后以高效,慣用的方式重寫它。 

你的***反應可能是將PostgreSQL中的數(shù)組看做像C語言中對等的類似物。你之前可能用過變換陣列位置或切片來操縱數(shù)據(jù)。不過要小心,在PostgreSQL中不要有這樣的想法,特別是數(shù)組類型是變長的時,比如JSON、文本或是hstore。如果你通過位置來訪問PostgreSQL數(shù)組,你會進入一個意想不到的性能暴跌的境地。

這種情況幾星期前在Heap出現(xiàn)了。我們在Heap為每個跟蹤用戶維護一個事件數(shù)組,在這個數(shù)組中我們用一個hstore datum代表每個事件。我們 有一個導入管道來追加新事件到對應的數(shù)組。為了使這一導入管道是冪等的,我們給每個事件設定一個event_id,我們通過一個功能函數(shù)重復運行我們的事 件數(shù)組。如果我們要更新附加到事件的屬性的話,我們只需使用相同的event_id轉儲一個新的事件到管道中。 

所以,我們需要一個功能函數(shù)來處理hstores數(shù)組,并且,如果兩個事件具有相同的event_id時應該使用數(shù)組中最近出現(xiàn)的那個。剛開始嘗試這個函數(shù)是這樣寫的:

  1. -- This is slow, and you don't want to use it! 
  2. -- 
  3. -- Filter an array of events such that there is only one event with each event_id. 
  4. -- When more than one event with the same event_id is present, take the latest one. 
  5. CREATE OR REPLACE FUNCTION dedupe_events_1(events HSTORE[]) RETURNS HSTORE[] AS $$ 
  6.   SELECT array_agg(event) 
  7.   FROM ( 
  8.     -- Filter for rank = 1, i.e. select the latest event for any collisions on event_id. 
  9.     SELECT event 
  10.     FROM ( 
  11.       -- Rank elements with the same event_id by position in the array, descending. 
  12.       SELECT events[sub] AS event, sub, rank() 
  13.       OVER (PARTITION BY (events[sub] -> 'event_id')::BIGINT ORDER BY sub DESC
  14.       FROM generate_subscripts(events, 1) AS sub 
  15.     ) deduped_events 
  16.     WHERE rank = 1 
  17.     ORDER BY sub ASC 
  18.   ) to_agg; 
  19. $$ LANGUAGE SQL IMMUTABLE; 

這樣奏效,但大輸入是性能下降了。這是二次的,在輸入數(shù)組有100K各元素時它需要大約40秒!

Execution Times For dedupe_events_1

這個查詢在擁有2.4GHz的i7CPU及16GB Ram的macbook pro上測得,運行腳本為:https://gist.github.com/drob/9180760。

在這邊究竟發(fā)生了什么呢? 關鍵在于PostgreSQL存貯了一個系列的hstores作為數(shù)組的值, 而不是指向值的指針. 一個包含了三個hstores的數(shù)組看起來像
{“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 解析從左側讀取的事件直到讀取到第二次讀取的數(shù)據(jù). 然后就是 forevents[3], 她再一次的從***個索引處開始掃描,直到讀到第三次的數(shù)據(jù)! 所以, evaluatingevents[sub]是 O(sub), 并且 evaluatingevents[sub]對于在數(shù)組中的每一個索引都是 O(N2), N是數(shù)組的長度.

PostgreSQL能得到更加恰當?shù)慕馕鼋Y果,  它可以在這樣的情況下分析該數(shù)組一次. 真正的答案是可變長度的元素與指針來實現(xiàn),以數(shù)組的值, 以至于,我們總能夠處理 evaluateevents[i]在不變的時間內(nèi).

即便如此,我們也不應該讓PostgreSQL來處理,因為這不是一個地道的查詢。除了generate_subscripts我們可以用unnest,它解析數(shù)組并返回一組條目。這樣一來,我們就不需要在數(shù)組中顯式加入索引了。

  1. -- Filter an array of events such that there is only one event with each event_id. 
  2. -- When more than one event with the same event_id, is present, take the latest one. 
  3. CREATE OR REPLACE FUNCTION dedupe_events_2(events HSTORE[]) RETURNS HSTORE[] AS $$ 
  4.   SELECT array_agg(event) 
  5.   FROM ( 
  6.     -- Filter for rank = 1, i.e. select the latest event for any collisions on event_id. 
  7.     SELECT event 
  8.     FROM ( 
  9.       -- Rank elements with the same event_id by position in the array, descending. 
  10.       SELECT event, row_number AS index, rank() 
  11.       OVER (PARTITION BY (event -> 'event_id')::BIGINT ORDER BY row_number DESC
  12.       FROM ( 
  13.         -- Use unnest instead of generate_subscripts to turn an array into a set. 
  14.         SELECT event, row_number() 
  15.         OVER (ORDER BY event -> 'time'
  16.         FROM unnest(events) AS event 
  17.       ) unnested_data 
  18.     ) deduped_events 
  19.     WHERE rank = 1 
  20.     ORDER BY index ASC 
  21.   ) to_agg; 
  22. $$ LANGUAGE SQL IMMUTABLE; 

結果是有效的,它花費的時間跟輸入數(shù)組的大小呈線性關系。對于100K個元素的輸入它需要大約半秒,而之前的實現(xiàn)需要40秒。

這實現(xiàn)了我們的需求:

  • 一次解析數(shù)組,不需要unnest。
  • 按event_id劃分。
  • 對每個event_id采用***出現(xiàn)的。
  • 按輸入索引排序。

教訓:如果你需要訪問PostgreSQL數(shù)組的特定位置,考慮使用unnest代替。 

我們希望能夠避免失誤。有任何意見或其他PostgreSQL的秘訣請@heap。 

[1]特別說明一下,我們使用一個名為Citus Data的貼心工具。更多內(nèi)容在另一篇博客中! 
[2]參考:https://heapanalytics.com/features/funnels。特別說明一下,計算轉換程序需要對用戶已完成事件的數(shù)組進行一次掃描,但不需要任何join。

原文鏈接:http://blog.heapanalytics.com/dont-iterate-over-a-postgres-array-with-a-loop/

譯文鏈接:http://www.oschina.net/translate/dont-iterate-over-a-postgres-array-with-a-loop

責任編輯:陳四芳 來源: 開源中國編譯
相關推薦

2012-08-23 09:33:25

數(shù)據(jù)庫數(shù)組PostgreSQL

2010-01-18 17:23:55

函數(shù)

2010-01-18 17:23:55

函數(shù)

2010-03-02 14:12:30

WCF枚舉類型

2013-08-29 13:31:07

PostgreSQL數(shù)據(jù)庫數(shù)據(jù)庫日期

2014-01-05 17:08:09

PostgreSQL數(shù)據(jù)類型

2024-07-08 10:48:51

2009-02-20 11:03:25

Vista特點

2017-02-23 15:37:44

OptionObject容器

2010-01-11 13:33:07

VB.NET使用數(shù)組

2010-01-18 13:12:43

VB.NET控件數(shù)組

2010-02-03 15:40:37

Python函數(shù)

2019-11-14 16:23:07

MySQL索引數(shù)據(jù)庫

2017-07-10 13:09:45

前端Flexbox

2018-04-12 08:37:27

2010-02-24 15:27:26

Python數(shù)組

2024-10-30 13:48:23

2010-04-23 13:45:14

Oracle存儲過程

2010-08-02 14:03:49

DB2驅動類型

2010-05-21 17:14:18

MySQL 數(shù)字類型
點贊
收藏

51CTO技術棧公眾號