2011-11-30 74 views
5

我在PostgreSQL 9.0上有DELETE/INSERT序列的吞吐量問題。我正在尋找想法來改善這種狀況。PostgreSQL DELETE/INSERT吞吐量問題

在我們可以使用的硬件上,我可以以3000/s的持續速率(均勻地跨越10個表)將新行插入到數據庫中,遠遠超出我通常測試的每個表中的1m行。但是,如果我切換到刪除行並重新插入不同數據的模式,則性能下降超過250個行/秒(同樣,均勻地跨10個表)。

任何表都沒有限制。每個表中有2個索引列,總索引大小(每個表1m行)爲1GB,舒適地位於shared_buffers(2GB)內。總數據大小(每行1m行)爲12GB,遠小於系統總內存。這是一個影子數據庫,我們可以在緊急情況下重建,因此我們使用fsync關閉。

看起來,當我們處於填充模式時,由於數據被追加,我們從非常低的磁盤尋道時間中獲益。但是,當我們切換到更新模式時,有很多正在尋找(據推測可能會刪除舊的行)。隨機磁盤尋找成本約8毫秒(=〜每秒125)。有沒有辦法(沒有硬件的改變)我們可以顯着提高UPDATE/re-INSERT操作的性能?編輯1:我在兩個不同的硬件平臺上進行性能測試。我之前引用的數字來自更高規格的平臺。我剛剛在較低規格的平臺上完成了測試。在此測試中,我儘可能快地插入新行,每隔10秒記錄一次插入速率,直到插入100萬行。此時我的測試腳本切換到更新隨機行。

Perf results graph

該圖顯示所測得的更新速率爲〜150個更新所有10個表/秒期間人口和更新率爲< 10更新到所有10個表/秒。

@wildplasser - 機器是一臺真機,而不是虛擬機。這10個表格都有以下模式。

CREATE TABLE objecti_servicea_item1 
(
    iss_scs_id text, 
    iss_generation bigint, 
    boolattr1 boolean, 
    boolattr2 boolean, 
    boolattr3 boolean, 
    boolattr4 boolean, 
    boolattr5 boolean, 
    boolattr6 boolean, 
    boolattr7 boolean, 
    boolattr8 boolean, 
    boolattr9 boolean, 
    boolattr10 boolean, 
    boolattr11 boolean, 
    boolattr12 boolean, 
    boolattr13 boolean, 
    boolattr14 boolean, 
    boolattr15 boolean, 
    boolattr16 boolean, 
    boolattr17 boolean, 
    intattr1 bigint, 
    intattr2 bigint, 
    intattr3 bigint, 
    intattr4 bigint, 
    intattr5 bigint, 
    intattr6 bigint, 
    intattr7 bigint, 
    intattr8 bigint, 
    intattr9 bigint, 
    intattr10 bigint, 
    intattr11 bigint, 
    intattr12 bigint, 
    intattr13 bigint, 
    intattr14 bigint, 
    intattr15 bigint, 
    intattr16 bigint, 
    intattr17 bigint, 
    strattr1 text[], 
    strattr2 text[], 
    strattr3 text[], 
    strattr4 text[], 
    strattr5 text[], 
    strattr6 text[], 
    strattr7 text[], 
    strattr8 text[], 
    strattr9 text[], 
    strattr10 text[], 
    strattr11 text[], 
    strattr12 text[], 
    strattr13 text[], 
    strattr14 text[], 
    strattr15 text[], 
    strattr16 text[], 
    strattr17 text[] 
) 
WITH (
    OIDS=FALSE 
); 
CREATE INDEX objecti_servicea_item1_idx_iss_generation 
    ON objecti_servicea_item1 
    USING btree 
    (iss_generation); 
CREATE INDEX objecti_servicea_item1_idx_iss_scs_id 
    ON objecti_servicea_item1 
    USING btree 
    (iss_scs_id); 

正在執行的「更新」涉及10個表中的每一個的以下SQL。

DELETE FROM ObjectI_ServiceA_Item1 WHERE iss_scs_id = 'ObjUID39' 
INSERT INTO ObjectI_ServiceA_Item1 
VALUES ('ObjUID39', '2', '0', NULL, '0' 
, NULL, NULL, NULL, '1', '1', NULL, '0' 
, NULL, NULL, NULL, NULL, '0', '1', '1' 
, '-70131725335162304', NULL, NULL, '-5241412302283462832' 
, NULL, '310555201689715409', '575266664603129486' 
, NULL, NULL, NULL, NULL, NULL, NULL 
, '-8898556182251816700', NULL, '3325820251460628173' 
, '-3434461681822953613' 
, NULL 
, E'{pvmo2mt7dma37roqpuqjeu4p8b,"uo1kjt1b3eu9g5vlf0d02l6iaq\\\\\\",",45kfns1j80gc7fri0dm29hnrjo}' 
, NULL, NULL 
, E'{omjv460do8cb7abn8t3eg5b6ki,"a7hrlninbk1rmu6h3rd4787l7f\\\\\\",",24n3ipfua5spma2vrj2aji98g3}' 
, NULL 
, E'{1821v2n2ermm4jujrucu5tekmm,"ukgst224964uhthkhjj9v189ft\\\\\\",",6dfsaniq9mftvbdr8g1sr8e6as}' 
, E'{c2a9gvf0fnd38m8vprlhkp2n74,"ts86vbat12lfr0d7l4tc29k9uk\\\\\\",",32b5j9r5evmrie4h21hi10dpot}' 
, E'{18pve4cmcbrjiom9bpvoo1l4n0,"hrqcsane6r0n7u2oj79bj605rh\\\\\\",",32q5n18q3qbkuit605fv47270o}' 
, E'{l3bf96shrpnnqgt35m7574t5n4,"cpol4k8296hbdqc9kac79oj0ua\\\\\\",",eqioulmb7vav10lbnc5jg752df}' 
, E'{5fai108h163hpjcv0ofgfi7c28,"ci958009ddak3li7bp37slcs8i\\\\\\",",2itstj01tkprlul8f530uhs6s2}' 
, E'{ueqfkdold8vc84jllr4b2cakt5,"t5vbea4r7tva091pa8j6886t60\\\\\\",",ul82aovhil1lpd290s14vd0p3i}' 
, NULL, NULL, NULL, NULL, NULL) 

請注意,在我的性能測試的第一階段,DELETE命令將始終不起作用。

@Frank Heikens - 在我正在運行的性能測試中,更新從10個線程完成。但是,這些更新以確保對同一行的多個更新始終由同一個線程處理的方式分配給線程。

+0

這是虛擬機還是真機?還請添加表格定義&&查詢(的一個片段),並將結果查詢計劃添加到問題中。 – wildplasser

+0

你檢查過鎖嗎?多個進程可能會嘗試刪除相同的記錄。 –

+0

我編輯了我的帖子以回覆您的評論。 – mchr

回答

3

這個數據模型不是美麗的DELETE INSERT。 UPDATE有什麼問題?如果iss_generation和iss_scs_id在UPDATE中未更改,則數據庫可以執行HOT update(堆溢出元組)以提高性能。更新也將受益於較低的填充因子。

當您執行刪除記錄時,該記錄可能與INSERT將執行的位置不同。使用較低的填充因子並使用UPDATE可能會爲數據庫提供DELETE和INSERT更新記錄到磁盤上相同塊的選項。這將導致更少的隨機I/O。當可以使用HOT時,情況變得更好,因爲不需要更新索引。

1

不知道,但也許改變fillfactor會有幫助嗎?

+0

感謝您的建議 - 我會研究這一點。 – mchr

0

我們已成功從內存中的csv中刪除/複製。