建站
咨詢
售后
建站咨詢
新聞中心
在Heap中，我們依靠PostgreSQL支撐大多數(shù)后端繁重的任務(wù)，我們存儲(chǔ)每個(gè)事件為一個(gè)hstore blob，我們?yōu)槊總€(gè)跟蹤的用戶維護(hù)一個(gè)已完成事件的PostgreSQL數(shù)組，并將這些事件按時(shí)間排序。 Hstore能夠讓我們以靈活的方式附加屬性到事件中，而且事件數(shù)組賦予了我們強(qiáng)大的性能，特別是對(duì)于漏斗查詢，在這些查詢中我們計(jì)算不同轉(zhuǎn)化渠道步驟間的輸出。
公司主營業(yè)務(wù)：網(wǎng)站設(shè)計(jì)、網(wǎng)站建設(shè)、移動(dòng)網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。成都創(chuàng)新互聯(lián)公司是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對(duì)我們的高要求，感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn)，讓我們激情的團(tuán)隊(duì)有機(jī)會(huì)用頭腦與智慧不斷的給客戶帶來驚喜。成都創(chuàng)新互聯(lián)公司推出單縣免費(fèi)做網(wǎng)站回饋大家。
在這篇文章中，我們看看那些意外接受大量輸入的PostgreSQL函數(shù)，然后以高效，慣用的方式重寫它。
你的***反應(yīng)可能是將PostgreSQL中的數(shù)組看做像C語言中對(duì)等的類似物。你之前可能用過變換陣列位置或切片來操縱數(shù)據(jù)。不過要小心，在PostgreSQL中不要有這樣的想法，特別是數(shù)組類型是變長的時(shí)，比如JSON、文本或是hstore。如果你通過位置來訪問PostgreSQL數(shù)組，你會(huì)進(jìn)入一個(gè)意想不到的性能暴跌的境地。
這種情況幾星期前在Heap出現(xiàn)了。我們?cè)贖eap為每個(gè)跟蹤用戶維護(hù)一個(gè)事件數(shù)組，在這個(gè)數(shù)組中我們用一個(gè)hstore datum代表每個(gè)事件。我們 有一個(gè)導(dǎo)入管道來追加新事件到對(duì)應(yīng)的數(shù)組。為了使這一導(dǎo)入管道是冪等的，我們給每個(gè)事件設(shè)定一個(gè)event_id，我們通過一個(gè)功能函數(shù)重復(fù)運(yùn)行我們的事 件數(shù)組。如果我們要更新附加到事件的屬性的話，我們只需使用相同的event_id轉(zhuǎn)儲(chǔ)一個(gè)新的事件到管道中。
所以，我們需要一個(gè)功能函數(shù)來處理hstores數(shù)組，并且，如果兩個(gè)事件具有相同的event_id時(shí)應(yīng)該使用數(shù)組中最近出現(xiàn)的那個(gè)。剛開始嘗試這個(gè)函數(shù)是這樣寫的：
- -- 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.
- 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;
這樣奏效，但大輸入是性能下降了。這是二次的，在輸入數(shù)組有100K各元素時(shí)它需要大約40秒！
這個(gè)查詢?cè)趽碛?.4GHz的i7CPU及16GB Ram的macbook pro上測得，運(yùn)行腳本為：https://gist.github.com/drob/9180760。
在這邊究竟發(fā)生了什么呢? 關(guān)鍵在于PostgreSQL存貯了一個(gè)系列的hstores作為數(shù)組的值, 而不是指向值的指針. 一個(gè)包含了三個(gè)hstores的數(shù)組看起來像
{“event_id=>1,data=>foo”, “event_id=>2,data=>bar”, “event_id=>3,data=>baz”}
相反的是
{[pointer], [pointer], [pointer]}
對(duì)于那些長度不一的變量, 舉個(gè)例子. hstores, json blobs, varchars,或者是 text fields, PostgreSQL 必須去找到每一個(gè)變量的長度. 對(duì)于evaluateevents[2], PostgreSQL 解析從左側(cè)讀取的事件直到讀取到第二次讀取的數(shù)據(jù). 然后就是 forevents[3], 她再一次的從***個(gè)索引處開始掃描,直到讀到第三次的數(shù)據(jù)! 所以, evaluatingevents[sub]是 O(sub), 并且 evaluatingevents[sub]對(duì)于在數(shù)組中的每一個(gè)索引都是 O(N2), N是數(shù)組的長度.
PostgreSQL能得到更加恰當(dāng)?shù)慕馕鼋Y(jié)果, 它可以在這樣的情況下分析該數(shù)組一次. 真正的答案是可變長度的元素與指針來實(shí)現(xiàn)，以數(shù)組的值, 以至于,我們總能夠處理 evaluateevents[i]在不變的時(shí)間內(nèi).
即便如此，我們也不應(yīng)該讓PostgreSQL來處理，因?yàn)檫@不是一個(gè)地道的查詢。除了generate_subscripts我們可以用unnest，它解析數(shù)組并返回一組條目。這樣一來，我們就不需要在數(shù)組中顯式加入索引了。
- -- 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;
結(jié)果是有效的，它花費(fèi)的時(shí)間跟輸入數(shù)組的大小呈線性關(guān)系。對(duì)于100K個(gè)元素的輸入它需要大約半秒，而之前的實(shí)現(xiàn)需要40秒。
這實(shí)現(xiàn)了我們的需求：
- 一次解析數(shù)組，不需要unnest。
- 按event_id劃分。
- 對(duì)每個(gè)event_id采用***出現(xiàn)的。
- 按輸入索引排序。
教訓(xùn)：如果你需要訪問PostgreSQL數(shù)組的特定位置，考慮使用unnest代替。
我們希望能夠避免失誤。有任何意見或其他PostgreSQL的秘訣請(qǐng)@heap。
[1]特別說明一下，我們使用一個(gè)名為Citus Data的貼心工具。更多內(nèi)容在另一篇博客中！
[2]參考：https://heapanalytics.com/features/funnels。特別說明一下，計(jì)算轉(zhuǎn)換程序需要對(duì)用戶已完成事件的數(shù)組進(jìn)行一次掃描，但不需要任何join。
名稱欄目：正確使用PostgreSQL的數(shù)組類型
網(wǎng)站鏈接：http://fisionsoft.com.cn/article/coecdpo.html
