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!