Otimizando o desempenho da atualização em massa no PostgreSQL

Usando o PG 9.1 no Ubuntu 12.04.

Atualmente, leva até 24 horas para executarmos um grande conjunto de instruções UPDATE em um banco de dados, que estão no formato:

UPDATE table
SET field1 = constant1, field2 = constant2, ...
WHERE id = constid

(Estamos apenas substituindo os campos dos objetos identificados pelo ID.) Os valores vêm de uma fonte de dados externa (ainda não no banco de dados de uma tabela).

As tabelas possuem vários índices e nenhuma restrição de chave estrangeira. Nenhum COMMIT é feito até o fim.

Leva 2h para importar um pg_dumpbanco de dados inteiro. Parece uma linha de base que devemos razoavelmente atingir.

Com exceção da produção de um programa personalizado que, de alguma forma, reconstrói um conjunto de dados para a importação do PostgreSQL, existe alguma coisa que podemos fazer para trazer o desempenho UPDATE em massa mais próximo do da importação? (Essa é uma área que acreditamos que as árvores de mesclagem estruturadas em log lidam bem, mas estamos pensando se há algo que possamos fazer no PostgreSQL.)

Algumas ideias:

• descartando todos os índices que não são de ID e reconstruindo depois?
• aumentar os pontos de verificação, mas isso realmente ajuda a taxa de transferência sustentada a longo prazo?
• usando as técnicas mencionadas aqui ? (Carregue novos dados como tabela e "mescle" dados antigos em que o ID não foi encontrado nos novos dados)

Basicamente, existem várias coisas para tentar e não temos certeza do que são mais eficazes ou se estamos ignorando outras coisas. Passaremos os próximos dias experimentando, mas pensamos em perguntar aqui também.

Eu tenho carga simultânea na tabela, mas é somente leitura.

Suposições

Como faltam informações no Q, assumirei:

• Seus dados vêm de um arquivo no servidor de banco de dados.
• Os dados são formatados como COPYsaída, com um único id por linha para corresponder à tabela de destino.
  Caso contrário, formate-o corretamente primeiro ou use as COPYopções para lidar com o formato.
• Você está atualizando todas as linhas da tabela de destino ou a maioria delas.
• Você pode deixar de lado e recriar a tabela de destino.
  Isso significa que não há acesso simultâneo. Caso contrário, considere esta resposta relacionada:
  • Melhor maneira de preencher uma nova coluna em uma tabela grande?
• Não há objetos dependentes, exceto os índices.

Solução

Sugiro que você siga uma abordagem semelhante, conforme descrito no link da sua terceira bala . Com grandes otimizações.

Para criar a tabela temporária, existe uma maneira mais simples e rápida:

CREATE TEMP TABLE tmp_tbl AS SELECT * FROM tbl LIMIT 0;

Um único grande UPDATEde uma tabela temporária dentro do banco de dados será mais rápido que as atualizações individuais de fora do banco de dados por várias ordens de magnitude.

No modelo MVCC do PostgreSQL , um UPDATEmeio para criar uma nova versão de linha e marcar a antiga como excluída. Isso é tão caro quanto um INSERTe um DELETEcombinado. Além disso, deixa você com muitas tuplas mortas. Como você está atualizando a tabela inteira de qualquer maneira, seria mais rápido, em geral, criar uma nova tabela e excluir a antiga.

Se você tiver RAM suficiente disponível, defina temp_buffers(apenas para esta sessão!) Alto o suficiente para manter a tabela temporária na RAM - antes de fazer qualquer outra coisa.

Para obter uma estimativa da quantidade de RAM necessária, execute um teste com uma pequena amostra e use as funções de tamanho de objeto db :

SELECT pg_size_pretty(pg_relation_size('tmp_tbl'));  -- complete size of table
SELECT pg_column_size(t) FROM tmp_tbl t LIMIT 10;  -- size of sample rows

Script completo

SET temp_buffers = '1GB';        -- example value

CREATE TEMP TABLE tmp_tbl AS SELECT * FROM tbl LIMIT 0;

COPY tmp_tbl FROM '/absolute/path/to/file';

CREATE TABLE tbl_new AS
SELECT t.col1, t.col2, u.field1, u.field2
FROM   tbl     t
JOIN   tmp_tbl u USING (id);

-- Create indexes like in original table
ALTER TABLE tbl_new ADD PRIMARY KEY ...;
CREATE INDEX ... ON tbl_new (...);
CREATE INDEX ... ON tbl_new (...);

-- exclusive lock on tbl for a very brief time window!
DROP TABLE tbl;
ALTER TABLE tbl_new RENAME TO tbl;

DROP TABLE tmp_tbl; -- will also be dropped at end of session automatically

Carga simultânea

As operações simultâneas na tabela (que eu descartei nas suposições no início) aguardarão, quando a tabela estiver bloqueada no final e falharão assim que a transação for confirmada, porque o nome da tabela é resolvido imediatamente para seu OID, mas a nova tabela possui um OID diferente. A tabela permanece consistente, mas operações simultâneas podem receber uma exceção e precisam ser repetidas. Detalhes nesta resposta relacionada:

• Melhor maneira de preencher uma nova coluna em uma tabela grande?

Rota UPDATE

Se você (tiver que) seguir o UPDATEcaminho, descarte qualquer índice que não seja necessário durante a atualização e recrie-o posteriormente. É muito mais barato criar um índice em uma peça do que atualizá-lo para cada linha individual. Isso também pode permitir atualizações QUENTES .

I descrito um procedimento semelhante utilizando UPDATEa esta resposta estreitamente relacionada no SO .

Se os dados puderem ser disponibilizados em um arquivo estruturado, você poderá lê-los com um invólucro de dados externo e executar uma mesclagem na tabela de destino.