Estratégias para redução do tamanho do banco de dados no PostgreSQL: uma abordagem baseada no uso

Os modelos de precificação de bancos de dados são difíceis. Como um desenvolvedor que procura um banco de dados gerenciado, um dos aspectos mais irritantes (e ainda cruciais) do processo de pesquisa envolve avaliar não apenas o preço inicial da solução para o tamanho do seu banco de dados, mas também como o preço funciona e quão bem ele será dimensionado. .

Além das nuances ao avaliar o preço do banco de dados (por exemplo, “Quanto a conta aumenta à medida que meus dados crescem?”, “Estou sendo cobrado por gravações ou leituras?” e “Tenho que pagar mais por backups?” ), os desenvolvedores tendem a ignorar um aspecto: a forma como o modelo de preços de um banco de dados é estruturado influenciará como você gerencia seus dados e avalia o tamanho do banco de dados Postgres.

Diferentes modelos de preços exigem abordagens diferentes para executar o PostgreSQL. Por exemplo, se você estiver preso a um disco grande, talvez não priorize a redução do tamanho do banco de dados. Se você for cobrado por leitura de dados, poderá pensar duas vezes antes de executar determinadas consultas e, se for cobrado por entrada de dados, poderá ser cauteloso quanto à frequência e ao volume de dados recém-ingeridos.

Cada elemento de precificação influencia sutilmente as estratégias e comportamentos que você acabará adotando, levando você a uma maneira específica de gerenciar e interagir com seu banco de dados para garantir economia e desempenho ideal.

Na Timescale, fizemos a transição para um modelo de armazenamento baseado em uso há alguns meses , com ótimo feedback dos clientes. Nesta postagem do blog, exploraremos as vantagens operacionais que observamos em nossos clientes desde a transição para esse modelo, juntamente com táticas sobre como gerenciar de maneira ideal seu armazenamento PostgreSQL em um modelo baseado em uso.

Os modelos de armazenamento baseados no uso estão se tornando cada vez mais populares no mundo dos bancos de dados. Quem quer pagar pelo espaço em disco que não está usando? Ainda assim, um modelo baseado no uso tem consequências, e você precisa considerar algumas práticas recomendadas para navegar nele de maneira eficaz.

Recapitulação rápida dos modelos de armazenamento PostgreSQL

Para estabelecer um ponto comum para nossa discussão sobre como gerenciar o tamanho do seu banco de dados em um modelo baseado em uso, vamos começar abordando rapidamente como funciona a precificação em nossa plataforma PostgreSQL ( Escala de tempo ) e como ele se compara a outros produtos PostgreSQL gerenciados, como Amazon RDS for PostgreSQL e Amazon Aurora.

A partir de ontem (💥), oferecemos dois tipos de serviços de banco de dados na plataforma Timescale:

• Serviços PostgreSQL dinâmicos , onde os desenvolvedores podem criar bancos de dados PostgreSQL com computação dinâmica para economizar dinheiro sem sacrificar o desempenho.

  
  

• Serviços de série temporal, onde os desenvolvedores podem criar bancos de dados PostgreSQL aprimorados com desempenho e escalabilidade extras por meio de hipertabelas, compactação colunar, agregados contínuos e armazenamento em camadas.

  
  

Vamos nos concentrar em como precificamos o armazenamento em nossa plataforma. Ambos os serviços vêm com um modelo de armazenamento baseado em uso, o que significa o seguinte:

• Os desenvolvedores são cobrados pelo volume que usam, sem letras pequenas – sem tamanho mínimo de banco de dados, sem etapas mínimas de escalabilidade. Se, até o final do mês, você tiver usado 128 GB, será cobrado por isso. Você pode começar com 1 GB e crescer até TB.

• Não há cobranças com base na gravação de dados, transferências de dados ou execução de consultas.

• Não há necessidade de alocar armazenamento ao criar um banco de dados ou dimensionar.

• Não há necessidade de reduzir manualmente o tamanho dos discos.

  
  

Para esclarecer isso, vamos expor as diferenças entre este modelo, Amazon RDS PostgreSQL e Amazon Aurora:

Em resumo, aqui estão as três principais conclusões de nossa comparação:

• Tanto o Timescale quanto o Aurora cobram pelo tamanho real do seu banco de dados. Por outro lado, o RDS PostgreSQL cobra pelo armazenamento provisionado. Você não pode reduzir volumes no RDS.

  
  

• A escala de tempo não cobra por gravação de dados, transferências de dados ou operações de consulta. Tanto o RDS quanto o Aurora cobram por transferência de dados, armazenamento de backup extra e você pode incorrer em algumas cobranças extras de E/S, dependendo do tipo de armazenamento escolhido.

  
  

• A escala de tempo não tem etapas mínimas de escalabilidade, enquanto o Aurora escala em incrementos de 10 GB após começar com 10 GB.

  
  

Como você pode ver, o modelo da Timescale está mais próximo de Aurora I/O otimizado , com a diferença de que o Timescale não possui etapas de escalonamento e cobranças extras para coisas como transferência de dados. Em contraste, o RDS é uma boa representação do modelo baseado em alocação, mesmo que O RDS não possui os “níveis de armazenamento” tradicionalmente encontrado em fornecedores de banco de dados que operam neste modelo.

Como o preço baseado no uso melhora o gerenciamento de armazenamento do PostgreSQL

Conforme introduzimos anteriormente, diferentes modelos de precificação implicam diferentes experiências de banco de dados. Quando fizemos a transição de um modelo baseado em alocação para um modelo baseado em uso, nossos clientes nos disseram que viram melhorias imediatas em três áreas operacionais:

• Eles não precisavam provisionar o armazenamento antecipadamente ao iniciar um banco de dados, o que gerava menos erros de provisionamento excessivo e, portanto, menores contas de armazenamento.
• Eles não precisaram pensar em armazenamento durante a expansão.
• Eles poderiam reduzir a escala — por exemplo, se excluíssem dados, parariam de pagar por eles.

Modelos baseados em uso eliminam o problema de superprovisionamento de armazenamento

Em modelos tradicionais baseados em alocação, os desenvolvedores muitas vezes se veem prevendo suas necessidades de armazenamento, o que, muitas vezes, leva ao provisionamento excessivo de armazenamento. Observamos isso em nossa frota quando a Timescale operava em um modelo baseado no uso: a maioria dos nossos clientes não estava usando toda a capacidade do disco, o que significa que estavam basicamente pagando pelo espaço de armazenamento que ainda não estavam usando. Os modelos baseados no uso eliminam esse jogo de adivinhação (e as consequências de suposições erradas).

Você não precisa pensar em armazenamento durante a expansão

“O armazenamento baseado no uso do Timescale significa que não preciso mais pensar no tamanho do disco. Nosso custo de armazenamento caiu 30% e não precisei fazer nada!"

Adam McCrea, Judôescala (Cliente de escala de tempo)

Em modelos baseados em uso, o armazenamento é dimensionado perfeitamente à medida que seu banco de dados cresce. A principal fonte de estresse nos modelos tradicionais baseados em alocação é o perigo de ficar sem espaço em disco, o que pode levar a vários problemas, desde tempo de inatividade de aplicativos e perda de transações até corrupção de dados nos piores cenários.

Com modelos baseados no uso, os desenvolvedores não precisam mais monitorar vigilantemente seu armazenamento para evitar atingir um limite de armazenamento. Ao mesmo tempo, eles não precisam se preocupar com etapas pesadas de escalonamento automático ou saltos de níveis.

Você pode reduzir a escala (parar de pagar pelos dados excluídos)

Por último, mas não menos importante, os modelos baseados no uso permitem “reduzir a escala”. Se você excluir dados (ou conseguir reduzir consideravelmente o tamanho do seu banco de dados), começará a pagar menos por armazenamento, o que parece justo. Como veremos na próxima seção, o Timescale possui alguns recursos para ajudar os clientes a reduzir o tamanho do banco de dados PostgreSQL. A adoção de um modelo baseado no uso permitiu que nossos clientes obtivessem economias imediatas ao reduzir o uso do disco, o que os incentivou a manter seu banco de dados enxuto.

Como navegar com eficácia em um modelo baseado em uso: dicas para reduzir o tamanho do banco de dados Postgres

Os benefícios que acabamos de mencionar melhoram significativamente a experiência do desenvolvedor ao trabalhar com armazenamento, e é por isso que os modelos baseados em uso estão se tornando muito populares. Mas o preço baseado no uso traz uma consequência óbvia (mas profunda): força os desenvolvedores a adotarem boas práticas de dados para reduzir ao máximo o tamanho do banco de dados PostgreSQL.

Quando você sabe que seus custos de armazenamento estão diretamente ligados ao tamanho do disco que você realmente está usando, há um novo incentivo para ser mais criterioso com o armazenamento de dados. Se você estiver operando em um modelo de armazenamento baseado no uso, será sua responsabilidade garantir o armazenamento eficiente dos dados.

De certa forma, isso pode ser considerado uma “desvantagem” dos modelos baseados no uso e requer algum trabalho – mas na verdade é uma bênção disfarçada. Nos modelos tradicionais baseados em alocação, a higiene dos dados pode ser um tanto negligenciada porque os custos são fixos: se você estiver preso a um disco de 500 GB no RDS e seu banco de dados tiver 200 GB, você não parece ter um grande incentivo para tornar o uso do armazenamento eficiente.

Mas o problema é o seguinte: boas práticas de dados não envolvem apenas economizar dinheiro. Para dimensionar um banco de dados PostgreSQL, é essencial mantê-lo otimizado. Ao adotar boas práticas de gerenciamento de dados PostgreSQL, você não apenas verá um melhor desempenho, mas também sua vida como administrador de banco de dados ficará muito mais fácil.

Com isso em mente, vamos examinar algumas práticas que ajudarão você a navegar em um modelo de armazenamento baseado no uso da maneira mais eficaz possível, reduzindo o tamanho do banco de dados PostgreSQL de maneira sistemática. No caso específico do Timescale, temos alguns recursos particularmente úteis, que também abordaremos.

Reduza o inchaço em seu banco de dados PostgreSQL

A primeira coisa a fazer em um modelo baseado em uso é prestar atenção às especificidades de como funciona o armazenamento PostgreSQL, ou seja, você deve reduzir o inchaço regularmente. Isso o ajudará não apenas com o tamanho do banco de dados, mas também com os requisitos de E/S. Indicaremos alguns princípios básicos nesta seção, mas este tópico da HN tem ótimos conselhos , e também escrevemos uma postagem de blog sobre inchaço de tabelas no PostgreSQL .

• Monitore tuplas mortas. Uma abordagem proativa para otimizar o armazenamento do PostgreSQL começa com a observação cuidadosa das tuplas mortas. Tuplas mortas, se não forem verificadas, podem se acumular e levar a sobrecargas de armazenamento desnecessárias. A extensão pgstattuple() pode ser uma grande aliada para entender como as tabelas gerenciam essas tuplas.

  
  

• Aspire com frequência. Para combater efetivamente o inchaço da mesa, você pode querer configurar o autovacuum para ser executado com mais frequência. Em vez de ajustar globalmente as configurações de autovacuum no postgresql.conf, é mais preciso ajustar essas configurações por tabela. Isso se deve ao fato de que tabelas diferentes podem ter tendências variadas para acumular tuplas mortas. Também é crucial monitorar transações de longa duração que possam prejudicar as operações de autovacuum.

  
  

• Recupere páginas não utilizadas. Embora o vácuo automático e o vácuo tratem de tuplas mortas, a recuperação de páginas não utilizadas exige uma abordagem diferente. Embora VACUUM FULL possa ser utilizado para essa finalidade, ele tem a limitação inerente de bloquear a tabela inteira. Pg_repack pode ajudá-lo com isso.

Faça alguns ajustes no PostgreSQL

A redução sistemática do tamanho do banco de dados PostgreSQL está intimamente relacionada à capacidade de dimensionar seu banco de dados PostgreSQL de maneira eficaz, ou seja, manter as coisas rápidas e ágeis enquanto você adiciona mais e mais dados. Ficar de olho (e talvez ajustar) alguns parâmetros-chave do PostgreSQL pode ajudar. Este artigo analisa os parâmetros de desempenho mais importantes . Aqui estão alguns aspectos que você precisa considerar:

• shared_buffers : controla a memória usada para o cache de páginas do PostgreSQL e normalmente é definido como 25% da RAM total do sistema.

  
  

• work_mem : define a memória alocada por operação dentro de uma consulta. Na escala de tempo, a configuração recomendada é (25 % of RAM) / max_connections .

  
  

• max_connections : define o número máximo de conexões simultâneas permitidas ao banco de dados. Os poolers de conexões podem ajudar a gerenciar muitas conexões de curta duração.

  
  

• max_worker_processes : determina o número máximo de processos de trabalho que o PostgreSQL pode iniciar. Se estiver usando Timescale, a fórmula para definir esse parâmetro é: max_worker_processes = 3 + timescaledb.max_background_workers + max_parallel_workers .

  
  

• max_parallel_workers : especifica o número máximo de trabalhadores que suportam consultas paralelas. O padrão é definir isso igual ao número de CPUs disponíveis.

  
  

• autovacuum_max_workers : determina o número máximo de processos de autovacuum simultâneos. Na escala de tempo, é definido como 10 por padrão.

Pratique a higiene da indexação

A otimização regular dos índices ajudará a manter o PostgreSQL eficiente, especialmente à medida que o banco de dados é dimensionado. Embora os índices possam ajudá-lo a melhorar o desempenho da consulta quando usados com sabedoria, índices excessivos podem criar problemas em grandes implantações do PostgreSQL.

A consequência mais óbvia da indexação excessiva é o aumento do consumo de armazenamento, pois cada índice necessita de armazenamento separado, que cresce proporcionalmente com o tamanho das tabelas. Essa sobrecarga pode se tornar mais significativa quando as tabelas são particionadas, como nas hipertabelas do Timescale.

Índices desnecessários também podem ser contraproducentes para melhorar suas operações de gravação, pois cada nova entrada ou modificação de dados implica atualizações simultâneas de índice, levando a mais operações de E/S e possível inchaço da tabela. Monitorar seus índices irá ajudá-lo a identificar quais deles não estão mais sendo usados, mantendo as coisas enxutas.

Uma maneira de fazer isso é usando pg_stat_user_indexes :

 -- Retrieve indexes that might not be used or are infrequently used SELECT schemaname, relname AS table_name, indexrelname AS index_name, idx_scan AS times_used FROM pg_stat_user_indexes WHERE idx_scan = 0 OR idx_scan < some_low_threshold -- replace 'some_low_threshold' with a value that makes sense for your context ORDER BY idx_scan ASC, schemaname, relname;

Se um índice tiver valor 0 na coluna idx_scan, significa que ele não foi usado desde a última vez que as estatísticas foram redefinidas, o que significa que pode ser um candidato para otimização. Ao definir um limite baixo para idx_scan , você também pode identificar índices usados com pouca frequência.

Reduza suas tabelas grandes por meio da compactação de escala de tempo

Um dos recursos de destaque do Timescale é o suporte nativo à compactação colunar, que pode reduzir drasticamente o espaço em disco usado por tabelas grandes sem comprometer o desempenho da consulta. A compactação melhora o desempenho de muitas consultas.

A compactação da escala de tempo funciona convertendo dados regulares baseados em linhas em um formato colunar mais compacto. Este processo é particularmente eficaz para dados de séries temporais, onde muitas colunas podem conter valores repetitivos; podemos alcançar taxas de compressão impressionantes (+90%) aplicando diferentes algoritmos de compressão dependendo de cada tipo de dados. Isso significa que suas mesas grandes podem ser reduzidas em até 10x.

Na escala de tempo, a compactação é habilitada tabela por tabela por meio de uma política de compactação baseada em tempo. Por exemplo, este código permite a compactação em uma hipertabela específica e compacta automaticamente os dados com mais de duas semanas:

 -- Enable compression on the hypertable ALTER TABLE your_hypertable SET ( timescaledb.compress, timescaledb.compress_segmentby = 'some_column' ); -- Set a compression policy to compress data older than two weeks SELECT add_compression_policy('your_hypertable', INTERVAL '2 weeks');

Para saber mais sobre compactação, confira nossa documentação .

Configure uma estratégia de gerenciamento de dados: mova os dados mais antigos para um armazenamento mais barato, exclua os dados que não são mais necessários

As táticas anteriores são muito úteis para reduzir o tamanho do seu banco de dados, mas há outro caminho que você pode aproveitar no Timescale para dimensionar seu armazenamento de maneira eficaz: armazenamento em camadas.

Ao criar uma política de camadas simples, você pode mover dados mais antigos e menos acessados para uma camada de armazenamento de objetos sem fundo:

 -- This policy moves all data older than one month to object storage SELECT add_tiering_policy('example', INTERVAL '1 month);

Este armazenamento de objetos possui as seguintes características:

• Ele vem com um preço mais baixo do que nosso armazenamento de alto desempenho, permitindo armazenar muitos TB de dados por muito menos.
• É infinito, o que significa que você pode armazenar quantos dados desejar.
  

Essa arquitetura de armazenamento em camadas está enraizada no back-end do Timescale. O armazenamento de objetos não é um “balde” separado do seu banco de dados; em vez disso, é parte integrante dele. As consultas acessarão ambas as camadas de armazenamento de forma transparente, sem qualquer ação necessária de sua parte – você pode simplesmente continuar usando o SQL padrão no mesmo esquema. Depois que sua política de níveis estiver definida, não há mais nada a considerar!

Recomendamos mover os dados para a camada de armazenamento de baixo custo, uma vez que eles não são acessados com frequência pelo seu aplicativo, pois há um custo de desempenho (o armazenamento de objetos não é tão rápido quanto nosso armazenamento normal). Mas você pode continuar executando consultas ad-hoc sobre esses dados confortavelmente (por exemplo, consultas que não são críticas para a experiência do usuário de seus clientes e para as quais o desempenho superior não é essencial).

Além de oferecer essa camada de armazenamento de baixo custo, o Timescale facilita a configuração de políticas de retenção de dados para excluir dados desnecessários:

 -- Set a data retention policy to drop data older than 10 months SELECT add_retention_policy('your_hypertable', INTERVAL '10 months');

Você pode combinar políticas de retenção de dados como a acima com agregados contínuos para reduzir efetivamente a resolução do seu conjunto de dados — por exemplo, reduzindo a granularidade de um segundo para um minuto, excluindo os valores de um segundo, mas mantendo os agregados de um minuto. Leia esta postagem do blog para ver um exemplo de como fazer isso e gerenciar proativamente os dados de longo prazo .

Modelos Baseados em Uso e o Paradigma de Gerenciamento de Dados

Embora os modelos baseados no uso possam parecer apenas uma mudança de preço superficialmente, eles provocam uma mudança de paradigma na forma como os desenvolvedores pensam sobre o tamanho do banco de dados e como eles percebem e lidam com os dados.

Os modelos baseados no uso promovem uma cultura de melhoria contínua, onde o foco muda do mero gerenciamento de armazenamento para a integridade e eficiência do banco de dados. Isso requer alguma disciplina no início, mas quando sua mentalidade mudar e você aprender algumas técnicas, você estará no melhor lugar para dimensionar seu banco de dados PostgreSQL de maneira eficiente e eficaz.

O Timescale possui ferramentas valiosas para ajudá-lo a reduzir sistematicamente o tamanho do banco de dados PostgreSQL, como compactação, armazenamento em camadas e políticas de retenção de dados. Isso permite dimensionar efetivamente seus bancos de dados PostgreSQL em um modelo baseado em uso. Para experimentar você mesmo, inscreva-se no Timescale – você pode usá-lo gratuitamente durante os primeiros 30 dias .

- Escrito por Carlota Sota .