Alguns eventos são ótimas oportunidades para empresas consolidarem sua marca e aumentarem seu ticket médio. A Black Friday e o Dia Sem Imposto são datas que movimentam o comércio, e, por isso, aumentam a quantidade de acessos a aplicações e a bases de dados. Seu ambiente Postgres está preparado?
Em um levantamento feito com os clientes da Timbira, foi constatado que, para a maioria das empresas, o evento mais importante do ano é a Black Friday, que ocorre ao final do mês de novembro. Algumas empresas aproveitam para fazer a promoção no mês inteiro, a chamada “Black November”. Em seguida na lista de eventos importantes também temos Natal, Ano Novo e Cyber Monday.
Esses eventos aumentam as demandas de acessos no banco de dados e, por consequência, o volume de transações. Isso pode gerar grandes dores de cabeça para as equipes que não se preparam previamente.
Separamos algumas situações comuns que podem acontecer durante estes períodos e sugerimos algumas ações que podem ajudar a diminuir riscos.
1) Backup: O backup da base de dados é essencial porque ajuda a prevenir a perda de dados no caso de uma falha no sistema, erro humano ou ataque cibernético. Um exemplo foi a situação que aconteceu em 11 de setembro de 2001, onde muitas empresas que atuavam nas Torres Gêmeas tinham site backup, entretanto estavam localizados na outra torre ou em áreas afetadas pela destruição nas proximidades. Essas organizações perderam os dois sites e toda sua informação. Do ponto de vista da informação, isso afetou não só a vida de inúmeros clientes que dependiam desses dados, como também a continuidade do negócio de muitas empresas. A partir desse evento, toda a política de segurança cibernética foi repensada e ganhou força o uso das clouds.
Um backup bem-sucedido permite a recuperação e restauração rápida dos dados, minimizando assim o tempo de inatividade e a interrupção das atividades de negócios. Investir em sistemas de backup e manter cópias atualizadas dos dados é fundamental para proteger a integridade da empresa e garantir sua continuidade. Afinal, a perda de dados pode ter consequências graves, podendo impactar sua assistência, receita e até mesmo a sua existência. Já imaginou se amanhã seu banco de dados some? O que acontece com a sua empresa?
2) Resiliência: Um risco muito comum é o serviço de banco de dados não suportar um número excessivo de acessos simultâneos. E as causas que podem gerar indisponibilidade em situações como esta são inúmeras: podem ser ajustes finos que não foram feitos no PostgreSQL, uma query mal estruturada, um sistema operacional desatualizado (assim como o próprio PG) e até mesmo problemas de cluster. Para garantir que a sua base de dados tenha resiliência, vários aspectos devem ser analisados e alinhados, como o sistema de backup (pode ser cloud, híbrido, on-premise), questões de acesso à Internet (se o sistema for on-premise é indicado duas empresas de telefonia acessíveis, assim como um sistema de blackout e, se possível, uma cópia em nuvem), questões de infraestrutura de redes, entre outros.
Uma dica bacana para quem não sabe por onde começar é fazer um trabalho de análise e monitoramento do ambiente PostgreSQL. Assim será possível aplicar melhorias como ajustes de configurações de banco, melhoria em consultas lentas, identificar necessidade de índices que ajudam no desempenho, entre outras situações que podem deixar seu banco rodando muito melhor.
3) Segurança: O fator segurança sempre deve ser levado em consideração, tanto em relação a acessos internos quanto externos. Os níveis de segurança devem ser tratados em camadas, conforme o modelo de negócio de cada cliente. Muitos centralizam o controle de quem acessa a base de dados através de um “superusuário administrador”. Não é incomum, no entanto, vazar informações e ocorrer a exposição de dados sensíveis. É importante avaliar quem deve ter acesso no seu time, o responsável em monitorar esses acessos e a possibilidade de rastrear os acessos para minimizar o risco de erros.
Independentemente da estratégia adotada, a Lei Geral de Proteção de Dados (LGPD), promulgada em 2018, defende vários aspectos da segurança e o trato com as informações coletadas de terceiros. O vazamento de dados confidenciais de clientes podem gerar multas milionárias, processos e desgaste da imagem e credibilidade da empresa. A maioria das empresas já exigem adequações à LGPD em seus contratos. Portanto, é fundamental se pensar na segurança da informação em vários níveis.
4) Consultas Lentas: Um dos problemas mais comuns quando falamos em banco de dados é lentidão. Não é novidade que isso pode ser causado por uma série de fatores, desde mal configuração do PostgreSQL, um mal planejamento das ferramentas de extensão para uso de tabelas, falta de índices, consultas mal escritas, um cluster que não suporta o número de acessos, entre outros. Em muitos casos, torna-se desafiador encontrar e solucionar problemas de lentidão.
Existem algumas ferramentas e métodos de investigação que ajudam na análise e melhorias de consultas existentes ou mesmo no desenvolvimento de novas consultas. O primeiro passo nesse desafio é encontrar ferramentas que ajudem a apontar as piores consultas, aquelas que são as principais ofensoras do desempenho.
Uma boa ferramenta é a extensão pg_stat_statements, que faz parte do conjunto de módulos adicionais que vem com o Postgres. Com uma simples instalação do pacote contrib do PostgreSQL e um CREATE EXTENSION, esta extensão já começa a apresentar seu valor. Você pode conferir uma lista das consultas que mais executam, o tempo de execução dessas consultas, quantas vezes cada uma executou e, em versões mais recentes, até mesmo o quanto cada uma consumiu de recursos de escrita e leitura. Acompanhar essas informações e avaliar de forma frequente as consultas listadas por essa ferramenta é uma boa abordagem para identificar e atuar na melhoria destas consultas.
5) Inchaço de tabelas: O inchaço de tabelas é outro problema que impacta diretamente na performance do banco de dados. Uma tabela inchada desperdiça espaço em disco, eleva o tempo de restore de um backup físico, consome mais memória e torna as consultas mais lentas.
Para controlar o inchaço e garantir melhor desempenho do seu banco de dados, o postgreSQL possui um processo chamado autovacuum. Ele é responsável por varrer todas as tabelas e, com base em parametrizações, identificar quais precisam ser limpas. Durante a limpeza, ele marca o registro “morto” como reutilizável e atualiza as estatísticas do objeto, tornando o planejador mais eficiente na hora de montar um plano para executar consultas. A configuração padrão atende de forma satisfatória a pequenos ambientes.
No entanto, em ambientes críticos e de alto volume transacional, é necessário otimizar essa configuração para que ele seja mais eficaz, garantindo um melhor desempenho para o seu ambiente. Em alguns casos, mesmo com o autovacuum otimizado, pode ocorrer inchaço das tabelas e índices. Para garantir que o ambiente esteja saudável, é necessário monitorar e identificar objetos que precisam de manutenção e, por fim, fazer uso do pg_repack para eliminar o inchaço dos objetos. O pg_repack é muito útil, pois possui o mínimo de bloqueio possível e garante a limpeza das tabelas e índices sem gerar indisponibilidade do banco de dados.
O melhor conselho que podemos dar é que você invista em um planejamento prévio para o seu ambiente PostgreSQL, não só para datas importantes, mas com a visão de futuro de crescimento e de sustentabilidade do seu ambiente. Assim seu negócio, suas vendas e sua marca não sofrem com sobrecarga, instabilidades e gastos não previstos com atendimentos emergenciais. E, se precisar de ajuda, podemos ser seus parceiros para analisar seu ambiente e promover melhorias com nossa metodologia única de Health Check.
