A parte do PostgreSQL que mais odiamos (2023)

A parte de que mais odiamos no PostgreSQL

• O PostgreSQL se consolidou, nos últimos 5 anos, como o DBMS mais amado da internet. Isso acontece por causa de sua confiabilidade, funcionalidade, escalabilidade e adequação à maioria das cargas de trabalho em produção.
• No entanto, a forma como o PostgreSQL implementa o controle de concorrência multiversão (MVCC) é considerada a pior quando comparada à de outros DBMS relacionais.

O que é controle de concorrência multiversão?

• O objetivo do MVCC é permitir que várias consultas leiam e escrevam no banco de dados ao mesmo tempo sem interferirem entre si.
• O DBMS não sobrescreve linhas existentes; em vez disso, mantém várias versões para que as consultas escolham a versão apropriada para satisfazer a solicitação.
• Essa abordagem elimina a necessidade de bloqueios explícitos de registros e permite que as consultas observem um snapshot do banco de dados.

O controle de concorrência multiversão do PostgreSQL

• Ao atualizar uma linha existente, o PostgreSQL usa um método de armazenamento de versões append-only, criando uma nova versão para aplicar as alterações.
• Essa abordagem causa vários problemas complexos.

Armazenamento multiversão

• O PostgreSQL armazena todas as versões de linha no mesmo espaço de armazenamento.
• Em uma atualização, ele aloca um novo slot de versão, copia a versão existente e aplica as mudanças.
• O PostgreSQL usa uma cadeia de versões para registrar a relação entre as versões.

Vacuum de versões

• O PostgreSQL usa um procedimento de vacuum para remover versões antigas.
• O autovacuum é executado periodicamente para remover versões expiradas e reutilizar o espaço.

Por que o MVCC do PostgreSQL é o pior

• A implementação de MVCC do PostgreSQL é um projeto da década de 1980 e não combina com os padrões modernos de sistemas log-structured.
• O texto explica quatro grandes problemas que surgem no MVCC do PostgreSQL.

Problema 1: cópia de versões

• O PostgreSQL copia todas as colunas para a nova versão, aumentando a duplicação de dados e a necessidade de armazenamento.
• MySQL e Oracle evitam esse problema armazenando deltas.

Problema 2: inchaço de tabela

• As versões expiradas do PostgreSQL ocupam espaço e, se o autovacuum não conseguir removê-las, o banco de dados continuará crescendo.
• Isso degrada o desempenho das consultas.

Problema 3: manutenção de índices secundários

• O PostgreSQL precisa atualizar todos os índices a cada update.
• Isso degrada o desempenho das consultas.

Problema 4: gerenciamento de vacuum

• O desempenho do PostgreSQL depende fortemente da eficácia do autovacuum.
• Se o autovacuum não funcionar corretamente, surgirão problemas de desempenho.

Resumo do GN⁺

• O PostgreSQL continua sendo um DBMS muito querido, mas sua forma de implementar MVCC não é moderna.
• Resolver os problemas de MVCC do PostgreSQL exige muito tempo e esforço.
• É possível melhorar o desempenho otimizando as configurações de autovacuum do PostgreSQL.
• Como alternativas para resolver os problemas de MVCC do PostgreSQL, podem ser considerados MySQL e Oracle.

[GN⁺]

Comentários no Hacker News

• O OrioleDB tentou resolver o problema com um novo mecanismo de armazenamento

  • Se a carga for principalmente de INSERT, não há necessidade de espaço adicional
  • Há um limite para o número de instruções dentro de uma transação, mas isso pode ser evitado usando COPY FROM
  • Do ponto de vista do DBA, não é necessário gerenciar separadamente espaço de rollback/undo

• O design do PostgreSQL não é ruim em todos os aspectos

  • MySQL e Oracle armazenam deltas comprimidos entre a nova versão e a versão atual
  • O git não armazena diff e, de forma semelhante ao PostgreSQL, armazena o objeto completo

• As implementações de MVCC do Oracle e do MySQL não armazenam o endereço físico da nova versão

  • Em vez disso, armazenam um identificador lógico para que o SGBD encontre o endereço físico da versão atual
  • Isso pode tornar a leitura de índices secundários mais lenta, mas reduz overhead por outras vantagens

• Ao atualizar uma única linha no MySQL, SELECT id WHERE something; UPDATE what WHERE id=id é muito mais rápido

  • Em operações comuns, essa abordagem não é usada, e isso torna DML pontual mais lento

• Na década de 2010, o MongoDB era visto como "webscale" por causa de escritas não duráveis

  • Isso foi resultado de marketing

• Não concorda com a explicação sobre pg_repack

  • VACUUM FULL é pesado, mas repack é uma alternativa mais rápida e mais leve

• Os motivos pelos quais o PostgreSQL se tornou popular incluem:

  • segurança dos dados, ACID, semelhança com Oracle, MVCC, conformidade com o padrão SQL, a equipe do Postgres, a comunidade, tipos de dados, alto desempenho e a flexibilidade da licença BSD
  • O PostgreSQL continua evoluindo, e a comunidade tem um papel importante nisso

• Há uma pergunta sobre se o armazenamento completo de novas versões de row-tuples no PostgreSQL é uma propriedade do mecanismo de armazenamento padrão

• O artigo foi bem escrito, fácil de ler e de entender

  • Ajudou a entender problemas relacionados a vacuum, e os diagramas também eram bons