Hoje recebi um e-mail de alguém me perguntando porque os testes dele com o pgbench variam tanto, mesmo usando os mesmos parâmetros todas as veses. Para quem não sabe o pgbench é um pequeno aplicativo que lhe ajuda a fazer medições de perfomance no banco de dados simulando um teste TPC-B. Ele é muito simples de se utilizar e permite realizar testes com diferentes volumes de dados, conexões simultâneas e transações por conexão. O pgbench NÃO SERVE para fazer tuning em servidores de produção, mas serve para ajudar medir a diferença entre diferentes hardwares, SOs, sistemas de arquivo, etc. No mínimo, com o pgbench você vai começar a aprender muito sobre performance no PostgreSQL, comparando seus resultados em diferentes cenários.

Mas, voltando ao nosso colega, vejamos os resultados que ele obteve:

TPS: 19
TPS: 23
TPS: 18
TPS: 25
TPS: 23
TPS: 29
TPS: 35
TPS: 17

Veja que de 17 para 35, a direrença é de mais de 100%. Realmente, não dá para desprezar uma diferença tão grande. Eu diria que de qualquer forma, apredi no laboratório de física que você tem que realizar a mesma experiência pelo menos umas 5 vezes. Além disso, se você encontra um resultado que está destoando demais dos outros, é melhor repetir o teste mais umas 5 vezes com cuidado redobrado e se apenas um valor destoar, você deve descarta-lo. Assim o seu resultado é uma média entre os testes considerados válidos (sem o resultado descartado). No caso de um instrumento de medida direta (como uma régua ou termômetro) é fácil saber qual é a precisão da sua medida (metade da menor divisão, repetia o professor todas em as aulas no laboratório). No nosso caso, temos que ficar com o dado estatístico das medições considerando a variação dos resultados obtidos.

Veja, se você faz um ajuste na configuração do PostgreSQL e tem um aumento de desempenho de 2%, mas as suas amostras tem uma margem de erro (em relação a média) de 10%, você pode se questionar se realmente pode afirmar alguma coisa. Bom, mas se você tem 100% de variação… alguma coisa está realmente errada.

O primeiro detalhe sobre o nosso colega é que ele usa o PostgreSQL em Windows. Veja… usar o PostgreSQL em Windows funciona… mas fazer tuning em Windows não é tão eficiente. Não sou um profundo conhecedor do Windows, mas que eu saiba você tem muitas opções de ajustes de desempenho neste SO. O PostgreSQL, assim como outros grandes SGDBs, foram construídos para funcionar originalmente em sistemas operacionais Unix. Outro problema é que como o SO é uma caixa preta, você nunca sabe o que está rodando em paralelo exatamente e dificilmente tem controle sobre isso. Isto não quer dizer que não é possível ver o PostgreSQL rodando satisfatóriamente em Windows, significa que o Windows não é a opção número um de quem procura um SO robusto, confiável, seguro e rápido. Mas se você não está querendo levar o seu banco de dados ao limite, não há nada de errado em usar o Windows e ajustar o PostgreSQL para que ele tenha um desempenho melhor nele.

Vejamos alguns outros ítens que você deve se perguntar antes de avaliar os resultados:

1. Qual tipo de disco você usa? Os discos SATA são muito instáveis para testes, pois não conseguem manter um fluxo de dados em alta velocidade por muito tempo. Este não é um problema do disco físico em si e sim do protocolo do SATA. Usar discos SCSI ou SAS lhe trarão resultados mais confiáveis.
2. Você deixou os discos isolados para o banco? Deixou discos isolados para o Wall?? A questão aqui é saber se alguma outra aplicação pode estar competindo com o acesso aos discos.
3. Você tem certeza absoluta que não tem nenhuma outra aplicação rodando em segundo plano. O ideal é deixar uma instalação do SO o mais crua possível. O principio básico da experimentação científica é ter um ambiente controlado para que qualquer pessoa possa reproduzir exatamente os mesmos testes. Isto significa que você tem de documentar exatamente como o SO foi instalado, incluindo parâmetros de configuração.
4. Você tem que realizar testes mais longos para que ocorram checkpoints no meio. Se você parar para estudar o mecanismo de funcionamento interno do PostgreSQL, descobrirá que o momento em que o checkpoint ocorre há uma degradação de performance significativa. Realize testes que garantam a ocorrencia de pelo menos uns 10 checkpoints. Imagine testes que durem no mínimo uma hora cada.
5. Você precisa decidir como vai configurar o vacuum. Se usar o autovacuum, tem que utilizar testes longos para que a ocorrencia do autovacuum nas tabelas seja computado e ocorram um número de vacuuns semelhantes em cada testes.
6. O cache de memória é um ponto crítico. Cada vez que você roda um teste, uma parte dos dados fica em memória, seja o IPC, cache em userspace, kernespace, o cache da controladora de discos ou o cache dos discos em si. Resultado: para ter certeza que a memória está num estado idêntico entre os testes… reinicie o servidor entre cada testes. Após reiniciar o servidor, tenha o cuidado de realizar exatamente as mesmas operações na mesma órdem para minimizar as diferenças de quais dados entram no cache. Podem haver outras formas de controlar o cache do disco, mas eu só conheço esta.
7. Use uma quantidade gererosa de dados, usar menos de 1GB de dados dificilmente reproduz cenários realistas. A não ser que o seu alvo sejam bases realmente pequenas, é melhor fazer testes com diferentes tamanhos de bases. 1GB, 10GB e 100GB são um bom começo.
8. Se você pretende realizar os testes simulando uma grande quantidade de conexões, faça-o a partir de 1 ou mais clientes remotos e não a partir do servidor. Testes com 100, 200, 500, 1000 conexões simultâneas podem exigir uma estrutura considerável para os clientes. Você vai querer medir o impácto da rede no desempenho e ao mesmo tempo não vai querer que os clientes sejam um peso no desempenho do servidor, a não ser que a sua aplicação e o seu banco de dados fiquem no mesmo servidor. Se for esse o seu caso, prepare-se para um ajuste de desempenho bem mais complexo.

Antes de você achar que o PostgreSQL é um banco “instável”, “lento” ou pouco confiável, Recomendo enfáticamente que você estude mais sobre o funcionamento do PostgreSQL, realize testes em um SO Unixlike como Linux, Solaris e FreeBSD, e use outras ferramentas de testes como o DBT-2 e os testes do TPC como o TPC-C, TPC-E e TPC-H.

Em tempo, escrevi um pequeno texto para quem está começando: “12 dicas para aprender a ajustar a performance em bancos de dados“.

Está no ar o site do PGCon Brasil 2008. Para quem não sabe, esta é a sigla da “Conferência Brasileira de PostgreSQL”. Na sua segunda versão, o evento ocorrerá dentro da Unicamp, em Campinas/SP. A data também já está fechada: 26 e 27 de Setembro, numa sexta e sábado. Então, já reserve a data para “o maior evento sobre bancos de dados livres do Brasil”. Após contar com mais de 200 participantes em 2007, a expectativa é de ter mais de 300 pessoas este ano.

Alguns detalhes interessantes:

• A chamada de trabalhos internacional. Espera-se a vinda de 2 desenvolvedores internacionais, além dos desenvolvedores nacionais.
• O número de desenvolvedores nacionais parece que está aumentando neste ano e o número de colaboradores na organização do evento também.
• O plano de captação do evento já está no ar também, se você conhece alguém que poderia patrocinar o evento, não deixe nos avisar.
• Se você quer ajudar a divulgar o evento, já temos banners para você colocar no seu blog, site, etc.
• As inscrições para o evento ainda não começaram, mas quem quiser ir fazendo reservas num hotel, você já pode fazer sua reserva. Conseguimos proços especiais para os participantes do evento.
• Para se ter uma idéia, para fazer o site do evento, foram dezenas de e-mails trocados na lista pgbr-dev o que tornou a lista mais movimentada que a lista pgbr-geral. Um recorde. Gostaria de agradecer a contribuição do Dickson S. Guedes, Euler Taveira, Leandro Dutra, Leonardo César, Rodrigo Gomes Santana, Rodrigo Marins, Sebastian SWC, Thiago Risso e outros que não lembro agora por terem contribuído para o site sair.

Em breve, estaremos melhorando o site do evento, colocando mais informações, abrindo a chamada de trabalhos nacional e abrindo as incrições também. Por enquanto é só pessoal.

Já faz um tempo que ando investigando a parte de segurança em Bancos de Dados. Passei um tempão estudando a parte de segurança no Oracle e andei investigando algumas questões sobre o assunto aqui e acolá neste blog e na palestra sobre melhores práticas que fiz no FISL 9.0 e no PGCon Brasil 2007. Calhou de ontem eu estar conversando com o Dickson Guedes no IRC e resolvemos escrever um pouco sobre segurança no PostgreSQL. A idéia é para variar um pouco um tanto ambiciosa: fazer uma lista de possíveis melhorias que seriam interessante implementar no PostgreSQL para melhorar a segurança. Uma segunda etapa seria colocar a mão na massa e tentar implementar algum patch no PostgreSQL. Particularmente eu tenho muito receio de abrir o código fonte e sair mexendo. Manjo pouco de C e não tenho tanto domínio assim do funcionamento interno de SGDBs para fazer isso. Mas por outro lado, se eu não fizer o fike nunca vai me deixar em paz… e ao fim e ao cabo, a gente só aprende a fazer fazendo!!! Por fim, existe uma segunda intenção, que é começar a escrever coisas mais detalhadas sobre este assunto, iniciando assim alguns capítulos do livro sobre PostgreSQL que começa a sair do papel entrar no ar. Particularmente, eu acho que só a parte de segurança já é suficiente escrever mais de 100 páginas. Bom, de toda forma, todos aqueles que lerem este texto e sentir que há algum equívoco ou que falta alguma coisa está convidadíssimo a colaborar, seja nos comentários, seja enviando um e-mail ou mesmo no IRC.

Caramba… mas segurança é um tema tão complexo assim? Bom, depende de como você define o que é segurança em SGDB para você. Vamos começar pensando em duas ou três formas de se enarar o problema:

• Segurança em SGDB não se refere apenas ao seu banco de dados, diz respeito a toda a cadeia tecnologia associada a sua aplicação, uma vez que um único elo fraco da sua solução de TI põe em risco o conjunto como um todo. Então não basta pensar no SGDB isoladamente. Temos que pensar no equipamento onde o SGDB se encontra, no SO, na instalação do SGDB, nos dados contidos no banco de dados, na aplicação acessando o banco de dados e finalmente no usuário que precisa destas informações;
• Todos estão carecas de saber, mas não custa repetir: os bancos de dados guardam um patrimônio valioso: informação. Quando você tem um problema de segurança num SGDB, são os seus dados que estão ameaçados. A pergunta que sempre se faz é “quanto vale a informação guardada nos bancos de dados”. Melhor pergunta seria: “quanto custa a perda destes dados?”.
• Segurança tem haver com coisas com o potencial de tirar o sono/emprego de toda uma equipe de TI. O desempenho é importante. Algumas vezes é muito importante. Mas em geral, a segurança vem em primeiro lugar. Esta importancia hoje tem nome, endereço, telefone, e-mail e tudo o mais. Depois da onda gerada pelo SOx nos Estados Unidos, a segurança passou a ser mais importante ainda. O COBIT e o ITIL e suas normas e regulamentações associadas são representam mais uma pressão na busca por mais segurança em torno das informações.

Muito bonito tudo isso… mas enfim, quando falamos em segurança qual é a pauta em questão? Ah sim… muitas coisas, vejamos algumas:

• Integridade: tem muito haver com ACID. Seus dados não podem se corromper, independente do que venha a acontecer. Mesmo que seus dados se tornem indisponíveis durante um certo período (devido a uma queda de energia, falha na rede ou num disco por exemplo) você tem que garantir que uma vez que o problema de indisponibilidade esteja resolvido, todos os dados tem que reaparecer intactos. Integridade também tem muito haver com o uso de restrições de integridade, para que um erro do usuário ou da aplicação não permita que os dados sejam corrompidos. O uso das restrições de integridade devem proteger seus dados contra alterações que não estão de acordo com as suas regras de negócio;
• Perda de dados: a preocupação número 1 de todo administrador de banco de dados é evitar ao máximo a perda de dados. Aí entra em cena a mais tediosa das tarefas: o backup. Ocorre que em bancos de dados, não existe uma única forma de se fazer um backup, existem várias estratégias. De toda forma, é preciso definir antes de mais nada: qual é o volume máximo de dados que admissível perder? Os dados relativos a última semana de operação? Talvez o último dia? A última hora? Nem um segundo sequer? Bom, é claro que ninguém quer perder nada, mas você sabe realmente qual é a o grau de proteção que a sua atual política de backup lhe oferece?
• Disponibilidade: capacidade de manter o acesso às informações de forma contínua. Falhas humanas, falhas de software e falhas de hardware podem gerar indisponibilidade a qualquer momento. A sua tolerância a indisponibilidade vai variar conforme a importância e rítimo de operação das suas aplicações. Algumas não podem parar nunca e trabalham em regime 24/7. Outras só precisam estar ativas em horário comercial, mas não admitem um minuto sequer de indisponibilidade neste período. Seja como for, é importantíssimo definir qual é o SLA agregado aos serviços prestados pelo banco de dados para que se possa traçar uma estratégia adequada para se atingir estes objetivos. Sua estratégia deve garantir que mesmo ocorrendo uma falhas, mesmo graves, os dados devem estar disponíveis no prazo determinado pelo seu contrato de SLA.
• Controle de Acesso: capacidade de que as informações disponíveis no banco de dados estejam disponíveis para as pessoas corretas, que terão permisão de acesso apenas as operações permitidas para o seu perfil. Geralmente o controle de acesso se dá a partir de objetos do banco de dados, mas pode se re referir ao acesso de apenas um parte dos dados de um objeto, como apenas algumas linhas de uma tabela. O controle de acesso pode limitar a quantidade de recursos que você pode utilizar no banco de dados. Os recursos podem ser o número de conexões ativas, memória, processador, volume de dados acessados em disco, etc.
• Auditoria: registro de operações realizadas no banco de dados. O registro pode conter informações sobre quem, realizou que tipo de operação, sobre qual objeto e em qual momento. O registro também pode conter quais foram as alterações realizadas, permitindo reconstruir os dados num estado anterior se necessário. A auditoria também pode significar monitorar outras condições do banco de dados, como picos de utilização, espaço em disco e outros detalhes que se deseje registrar.

Como se pode ver, ao falar em segurança, temos inúmeros desafios pela frente. Temas consagrados como “Alta Disponibilidade”, “Backup”, “Política de Mínimo Privilégio”, “Trilhas de auditoria” entre outros, fazem parte do dia-a-dia (ou seria noite-a-noite?) dos que se preocupam com segurança. Em grandes equipes de TI, há pessoas especializadas em segurança. Muitas vezes, encontramos Administradores de Bancos de Dados especializados em um ou dois aspectos da segurança, como o controle de acesso e auditoria. Administradores de Dados são especialistas em avaliar problemas de restrição de integridade enquanto os Administradores de Sistemas costumam se preocupar com backup e alta disponibilidade.

Com isso, em mente, vejamos alguns capítulos de deveremos abordar em seguida:

• Trabalhando de forma segura:
  • Escrevendo código robusto e flexível;
  • Usando o psql;
  • Documentando o trabalho realizado;
• Ambientes de Trabalho
  • Isolar para proteger
  • Ambiente de Produção
  • Ambiente de Homologação
  • Ambiente de Testes
  • Ambiente de Laboratório
• Integridade
  • Modelagem de Dados;
    • Domínios;
    • Sequências;
    • Chaves Primárias;
      • Chaves Primárias artificiais X naturais;
      • Quando é permitido criar uma tabela sem PK?
    • Chaves Estrangeiras;
    • Restrição UNIQUE;
    • Restrição NOT NULL;
    • Restrição CHECK;
    • Gatilhos;
    • Visões Materializadas;
  • ACID
    • Transações
    • MVCC
    • LOCKs
    • Write Ahead Log
      • Espelhamento dos logs;
      • Arquivamento e Stand By;
      • Recuperação de instância;

• Perda de Dados e Disponibilidade;
  • Backup
    • Backup lógico;
    • Backup físico off-line;
    • Backup físico on-line;
      • Dificuldades com grandes bases;
    • Backup via Snapshot;
  • Técnicas de fail over
    • Hardware Redundante;
      • RAID
    • LVM e RAID por software;
    • Stand By;
    • Heart beat;
    • Replicação X Clusterização;
  • Replicação
    • Replicação Síncrona X Assíncrona;
    • Replicação Multi Master X Master/Slave
    • Replicação via log de transação;
    • Replicação via commit em duas fases;
    • Replicação via gatilhos;
    • Replicação via Midleware;
    • Implementações para PostgreSQL;
  • Cluster
    • Shared Nothing
    • Shared All
    • Implementações para PostgreSQL;
• Controle de Acesso
  • Política do Privilégio Mínimo;
  • SQL Injection;
  • Segurança na autenticação
    • Visões;
    • Funções;
    • Serviços de Diretório;
  • Ferramentas de controle no PostgreSQL;
    • GRANT / REVOKE
    • Roles
    • Limite de acesso aos recursos do servidor;
    • pg_hba.conf
    • SELinux
  • Estratégias de Autenticação da Aplicação;
    • Autenticação Interna;
      • Uso de grupos de usuários;
      • Impedindo os usuários de obterem acesso por fora da aplicação;
      • Lidando com senhas;
    • Autenticação Externa;
    • Autenticação via Aplicação;
      • Pool de Conexões;
• Auditoria
  • Auditoria dos dados:
    • Utilizando campos adicionais em tabelas já existentes;
    • Utilizando tabelas de autitorias alimentadas por RULEs e TRIGGERs;
    • Utilizando o log do PostgreSQL;
    • O problema da identificação do usuário em aplicações com Autenticação via Aplicação;
      • Criando uma variável de sessão;
    • Protetendo as informações de auditoria;
  • Monitorando o seu servidor:
    • Monitorando a disponibilidade;Monitorando a performance;
    • Monitorando o espaço em disco;
      • Dividir para melhor enchergar;
    • Disparando alertas;

Como se pode ver, temos muito assunto pela frente. Não tenho nenhum ímpeto de escrever seguindo uma órdem específica, provavelmente eu deverei escrever numa ordem caótica e tentar juntar as peças aos poucos.