PostgreSQL DELETE / INSERT吞吐量问题

Question

PostgreSQL 9.0上的DELETE / INSERT序列存在吞吐量问题。我正在寻找改善这种情况的想法。

在我们可用的硬件上，我可以以3000 / s的持续速率（在10个表中均匀地）将新行插入数据库，远远超出我通常测试的每个表中的1m行。但是，如果我切换到我们删除行并使用不同数据重新插入它的模式，性能会下降超过一个数量级到250行/秒（再次，在10个表中均匀分布）。

任何表都没有约束。每个表中有2个索引列，总索引大小（每个表1m行）为1GB，在shared_buffers（2GB）内很容易。总数据大小（每个表1m行）为12GB，远远低于系统总RAM。这是一个影子数据库，我们可以在紧急情况下重建，所以我们关闭fsync。

当我们处于填充模式时，我们会从非常低的磁盘搜索时间中受益，因为数据正在被追加。但是，当我们切换到更新模式时，有很多寻求进行（大概删除旧行）。随机磁盘的成本约为8毫秒（=每秒125帧）。有没有办法（没有硬件更改）我们可以显着提高UPDATE / re-INSERT操作的性能？

EDIT1：我正在两个不同规格的硬件平台上进行性能测试。我之前引用的数字来自更高规格的平台。我刚刚在较低规格的平台上完成了测试。在此测试中，我尽可能快地插入新行，每10秒记录一次插入速率，直到我插入了100万行。此时，我的测试脚本切换到更新随机行。

此图显示测量的更新率在人口中对所有10个表/秒进行约150次更新，更新率为10次/ 10次/秒更新。

@wildplasser - 机器是真机，而不是VM。这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 - 在我正在运行的perf测试中，更新是从10个线程完成的。但是，更新将以确保对同一行的多个更新始终由同一线程处理的方式分配给线程。

Answer 1

不确定，但是改变fillfactor会有帮助吗？

Answer 2

我们在内存中从csv删除/复制成功。