Escalando um banco de dados PostgreSQL com 1.2 bilhão de registros por mês (2019)

O artigo que estou trazendo é uma experiência que o Gajus Kuizinas passou, em um projeto sem serviços de mensageria, serviço de cache ou réplicas para armazenamento de dados, e também sem um caminhão de dinheiro para aumentar a infraestrutura sempre que surgisse um gargalo.

Hoje o site da empresa está fora do ar, mas ela se chamava Applaudience (eu achei este site com algumas imagens e detalhes sobre o projeto).

A Applaudience agregava dados de cinema, incluindo os horários de exibição de filmes, preços de ingressos e entradas de mais de 3.200 cinemas em 22 territórios da Europa e dos Estados Unidos, algo próximo de 47.000 exibições por dia. Cada vez que uma pessoa reservasse ou comprasse um ingresso em qualquer um desses cinemas, um snapshot era capturado descrevendo os atributos de cada assento no auditório.

Esses dados eram combinados com outros tipos de dados de apoio, incluindo dados que obtinham do YouTube, Twitter e previsões meteorológicas. O resultado final era um conjunto de dados de série temporal abrangente que descrevia toda a janela de lançamento do filme nos cinemas. O objetivo era prever o desempenho que o filme teria.

Isso tudo resultava em 1.2 bilhão de registros por mês.

O artigo traz em detalhes três fatores que precisaram lidar ao escalar o banco de dados, e algumas dicas de forma mais resumida. Os principais pontos são a hospedagem (um serviço de terceiro ou hospedagem própria), views materializadas (materialized views) e o uso do banco de dados como uma fila de tarefas (job queue).

Decidindo onde hospedar o banco de dados

Eles experimentaram quatro hospedagens diferentes:

1. Google Cloud.
2. Amazon RDS.
3. Aiven.io.
4. Hospedagem própria (self-hosting).

Google Cloud SQL for PostgreSQL

O Google Cloud foi a primeira opção experimentada. O fator principal para essa decisão foram os US$ 100 mil de crédito que o Google oferecia para startups (hoje pode chegar a US$ 200 mil, ou US$ 350 mil se for relacionado à IA — Google for Startups).

O motivo principal da empresa ter ficado no Google Cloud por apenas 6 meses foi um bug que corrompia dados, que já havia sido corrigido em versões mais recentes do PostgreSQL, mas o Google não atualizava a versão utilizada.

Amazon RDS for PostgreSQL

A empresa também conseguiu créditos na Amazon, e a versão do PostgreSQL estava atualizada. Apesar disso, a Amazon RDS não dava suporte à extensão TimescaleDB que eles haviam planejado usar para particionar o banco de dados.

Aiven.io

O Aiven.io parecia bom: ele gerenciava o banco de dados PostgreSQL para você no provedor de serviços de nuvem de sua preferência, tinha todas as extensões que eles precisavam (incluindo o TimescaleDB), não prendia a um provedor de servidor específico e o suporte era útil.

Um problema é que a Applaudience precisava de acesso ao superusuário, o que não era possível e resultou em alguns problemas, como procedimentos de manutenção que usavam pararam de funcionar e não puderam usar o software de monitoramento devido a problemas de permissão, não conseguiram usar auto_explain, replicação lógica requeria extensões personalizadas e longas interrupções que poderiam ter sido evitadas.

Além disso, o Aiven.io não avisava quando o armazenamento do banco de dados estava próximo do limite, e eles também começaram a enfrentar interrupções contínuas devido a um bug na extensão do TimescaleDB usada pelo Aiven.io.

Hospedagem própria

O autor disse que estavam tentando evitar a hospedagem própria esse tempo todo para não precisarem gerenciar eles mesmos o banco de dados. Mas, após o Aiven.io, eles alugaram o próprio hardware e gerenciaram o banco de dados. Isso resultou em:

• Um hardware muito melhor do que qualquer um dos provedores de serviço em nuvem poderiam oferecer.
• Recuperação pontual (graças ao Barman).
• Sem dependência de fornecedor.
• É (teoricamente) 30% mais barato do que uma hospedagem usando Google Cloud ou AWS.

Esses 30% poderiam ser usados para contratar um DBA freelancer para fazer check-in nos servidores uma vez por dia.

Esse artigo foi escrito em 2019, e esse tipo de movimento começou a se popularizar apenas pós-pandemia, como por exemplo a Prerender.io que conseguiu diminuir os custos anuais de US$ 1 milhão para US$ 200 mil em 2022 migrando da AWS para uma infraestrutura própria (leia aqui).

Aprendizados

Um dos aprendizados que o autor menciona é que o Google e a Amazon priorizam suas soluções proprietárias (Google BigQuery e AWS Redshift) — minha impressão é que isso vale para qualquer provedor (vendor lock-in). Então, você deve planejar quais recursos serão necessários no futuro. O autor do artigo diz que, para um banco de dados simples que não crescerá em bilhões de registros e não exigirá extensões personalizadas, escolheria qualquer um deles sem pensar duas vezes por causa de alguns benefícios que economizam muito tempo:

• A capacidade quase instantânea de escalar a instância.
• Migrar servidores para territórios diferentes.
• Recuperação pontual.
• Ferramentas de monitoramento integradas.
• Replicação gerenciada.

O autor também sugere que, se o seu negócio gira em torno de dados e você sabe que precisará de configuração de hardware personalizada e outros detalhes, então é melhor escolher a hospedagem própria e gerenciar o banco de dados você mesmo.

Apesar disso, ele diz que a migração lógica é bastante simples, então se você puder começar com qualquer provedor gerenciado e aproveitar os créditos iniciais, é uma ótima maneira de inciar um projeto.

Se eu tivesse que começar de novo e tivesse gasto tempo para estimar quão rápido e quão grande iríamos crescer, eu teria usado uma configuração bare-metal e contratado um DBA freelancer desde o primeiro dia.

Outras melhorias

Como eu mencionei no início desta publicação, o autor também trata sobre o uso de views materializadas e filas no banco de dados. Além disso, trouxe mais algumas dicas, por exemplo:

• Com muitas consultas, a latência entre o banco de dados e os clientes do banco de dados era muito importante. Então, ele observou que a latência entre o banco de dados, quando hospedado na AWS RDS, e o cluster Kubernetes hospedado no GKE (Google Kubernetes Engine) era de 12ms. Ao mover o banco de dados para o mesmo datacenter e reduzir a latência, conseguiu aumentar o processamento da fila de tarefas em 4x.

• A ordem das colunas da tabela importa. Eles tinham tabelas com mais de 60 colunas e conseguiram economizar mais de 20% de armazenamento reorganizando elas para evitar o padding (leitura recomendada).
• Monitore constantemente o pg_stat_statements e ordene por total_time. As consultas no topo são as consultas em que melhorias trarão mais impacto para o projeto ("low hanging fruits").
• Monitore constantemente o pg_stat_user_tables. Identifique índices pouco usados e monitore o acúmulo de tuplas mortas.
• Monitore constantemente o pg_stat_activity. Identifique gargalos causados por locks e refatore as transações que causam isso.

Para ler os outros pontos de melhoria que o autor compartilhou, visite o link da fonte.