O que aprendemos ao escalar o PostgreSQL por 5 anos

 (onesignal.com)
18 pontos por xguru 2021-04-20 | 1 comentários | Compartilhar no WhatsApp

O serviço de notificações push OneSignal compartilha o que aprendeu operando 75 TB de dados em 40 servidores de banco de dados

  • Visão geral dos dados: as tabelas subscribers e notifications são as maiores

  • Bloat: fenômeno em que passa a ocupar mais espaço, fica mais lento e exige mais poder computacional

→ Table bloat: VACUUM

→ Index bloat: otimização Heap Only Tuple (HOT)

→ ativar autovacuum

→ automatizar o particionamento de tabelas com a extensão pg_partman

→ pg_repack e pgcompacttable

  • Atualizações do banco de dados

→ pg_upgrade exige que o banco de dados fique offline, então não foi uma opção

→ configurar separadamente um servidor PostgreSQL na nova versão e usar replicação lógica com a extensão pglogical

  • XID Wraparound

→ o recurso MVCC (Multi Version Concurrency Control) do PostgreSQL usa IDs de transação de 32 bits, então com muitas transações isso pode estourar rapidamente

→ monitorar os XIDs restantes é importante

→ autovacuum_freeze_max_age

  • Promoção de réplica

→ para promover uma réplica rapidamente, ela foi colocada atrás do haproxy

  • Particionamento

→ as versões recentes do PostgreSQL já incluem funcionalidade de particionamento de tabelas

→ quando precisar de particionamento, recomenda-se, se possível, dividir em um grande número de partições

→ A OneSignal pretende passar de 16 para 256 e depois para 4096 partições

  • Sharding

→ não há suporte nativo

→ originalmente, o sharding era feito com Tenant IDs separados por faixa com base em UUID v4

→ atualmente estão criando um proxy de dados que reconhece partições e shards

Leituras relacionadas

1 comentários

 
xguru 2021-04-20