Extreme Go Horse DBA

Todos já conhecem o DBA Chuck Norris, aquele mega phoda que tudo pode no CPD. Aquele que está acima de Deus. Mas os tempos mudaram, estamos na era DevOps e migrando tudo para as nuvens. Então a moda agora é DBA XGH. Veja aqui uma compilação das melhores técnicas XGH para PostgrSQL:

  • Se você é um ninja do Linux, SEMPRE compile o PostgreSQL e explore todas as opções possíveis de compilação. Se possível utilize também o –whithout-readline e –without-zlib, assim você consegue tirar até a última gota de desempenho do seu banco de dados;
  • Para não ter problemas na hora de compilar, instale todos os pacotes da sua distribuição Linux, você garante uma instalação limpa, sem problemas com dependências e pronta para rodar qualquer parada;
  • Compre o maior disco possí
  • Na hora de particionar os discos, adote a filosofia KISS (Keep It Simple, Stupid): Deixe o particionador automático ocupar o disco inteiro com apenas uma partição. Você elimina assim as complexidades desnecessárias, aumenta o desempenho e não desperdiça espaço em disco;
  • Se você tiver bases grandes com alguns TB, aí é melhor você comprar um único disco grande como 8TB e dividir o disco em várias partições menores de 100GB colocando um tablespace em cada um, distribuindo assim o I/O no disco;
  • Se você tem vários discos e quer obter a melhor performance, utilize sempre um único RAID 0 e continue dividindo tudo em partições de 100GB;
  • Ao criar seu banco de dados sempre utilize como codificação de caractere padrão o SQL_ASCII. Você elimina a necessidade de conversões, ganha espaço em disco e desempenho, além de trabalhar com um padrão que qualquer linguagem de programação entende;
  • Use e abuse da flexibilidade do VARCHAR. Com ele você tem uma compatibilidade direta com a web que entende apenas texto. Com o VARCHAR você consegue armazenar texto, RG, CPF, CEP, telefones, Json, XML, o que você quiser.
  • Se precisar de campos flexíveis, você também pode utilizar o VARCHAR marcando as posições para distribuir vários campos de tamanho fixo dentro de uma cadeia de caracteres. Essa é uma técnica campeã utilizada já no tempo do Cobol e funciona até hoje;
  • Evite erros na sua aplicação removendo qualquer tipo de restrição do tipo PRIMARY KEY, FOREIGN KEY, UNIQUE e NOT NULL. Suas consultas vão rodar mais rápido e não vão mais dar erro na execução;
  • DevOps exige agilidade, utilize o esquema padrão e o usuário padrão para tudo. Assim você não tem que armazenar varias senhas ou se preocupar com vários esquemas.
  • Você ainda pode criar um acesso universal colocando a seguinte linha no seu pg_hba.conf: “host    all    all    0.0.0.0/0    trust”;
  • Uma ideia para facilitar o suporte remoto é colocar um IP público no servidor de banco de dados. Você vai conseguir acessar seu servidor sem rodeios, de forma muito mais ágil;
  • Não mexa no postgresql.conf, deixe os valores padrão que são otimizados para funcionar no seu hardware e na sua aplicação já na instalação;
  • Em nenhuma hipótese ative a gravação dos logs do banco de dados, isso vai ocupar mais espaço em disco e gerar mais I/O deixando seu banco de dados mais lento;
  • A melhor ferramenta de backup é sempre o PGAdmin. Em poucos clicks você resolve tudo, ponto final;
  • O jeito mais prático de matar uma sessão no banco de dados é com o comando kill -9, não falha nunca;
  • O melhor jeito de não ter dor de cabeça com os desenvolvedores é criar um super usuário próprio para eles na produção. Esta metodologia ágil é conhecida como OLD: On Line Development;
  • Se você tem uma tabela crítica para o seu sistema, crie um índice para cada campo da sua tabela e garanta que seu sistema sempre fará consultas indexadas;
  • Se você tem muitas tabelas, você deve criar uma view juntando a maioria das tabelas mais utilizadas e a partir dela criar todas as outras consultas do seu sistema;
  • A melhor forma de evitar problemas com o autovacuum é desligar ele para todas as tabelas. Assim você garante que não vai ter processos pesados de vacuum rodando no seu horário de pico;
  • Se você tem uma aplicação que é “database centric” e trabalha com um único banco monolítico, migre para a nuvem o quanto antes. Quanto maior o seu banco de dados, maior será a economia que você terá migrando diretamente para a nuvem. Sucesso garantido;
  • A melhor versão do PostgreSQL que já fizeram é a 8.2. Tudo que veio depois é besteira. Está funcionando, não é mesmo? Não mexa!
  • Repita comigo: SQL simples roda rápido, SQL com subconsultas é lento. Se você tem que atualizar 10 milhões de registros, a melhor forma é fazer 10 milhões de UPDATEs simples no banco de dados, claro;
  • Se você tem uma consulta complexa para fazer, crie uma função e divida a operação em diversas etapas e loops, simplificando a lógica e a execução da mesma;
  • A documentação do PostgreSQL é longa, prolixa e complexa. Já ouviu falar no Google?

 

Você utiliza XGH na sua empresa também? Ajude os demais colegas e conte nos comentários as técnicas de alto rendimento que você desenvolveu e recomenda para todos!

 

 

 

 

 

OBS: Eu sei…. o Go Horse Process não chega a ser algo novo. Mas sabe como é DBA: tá sempre atrasado no hype.

Compartilhe

Você pode gostar

Sobre minha saída da Timbira

Há 14 anos, durante o PGConf.Brasil 2009, lá na UNICAMP em Campinas/SP, 4 pessoas se reuniram e idealizaram a criação da primeira empresa dedicada exclusivamente

Split brain

Já tem algum tempo que eu pensava em fazer isso e chegou a hora. Este blog vai se dividir em 2 partes a partir de

plugins premium WordPress