A melhor palestra de hoje foi apresentada por Jair Silva e Flávio Gurgel, e foi sobre o CASE de uso do PostgreSQL na CEF, o que comprova que o PostgreSQL é sim uma solução viável de SGDB em ambientes críticos e de necessidade de alta-performance.
Eles estão usando uma solução com o PostgreSQL em caixas de auto-atendimento, em mais de 20mil terminais, com uma estimativa de 85 milhões de transações financeiras por mês, com uma movimentação de mais de 1 bilhão de reais mensais.
É uma aplicação multicanal em J2EE, que implementa uma certa independência de sistema operacional, banco de dados, etc.
Segundo Jair, essa palestra foi apresentada no ano passado, como sendo uma solução que seria implementada na CEF, mas que agora já é um CASE real, sendo que já está em pleno funcionamento.
Antes de implementar essa solução usando Debian + JBOSS em máquinas x86 (O SGDB roda em 2 HP Proliant Xeon dual-core com 32GB de RAM), eles fizeram benchmark com 3 possibilidades, sendo que 1 solução com máquinas SPARC e Solaris não passou nos requisitos de quantidade mínima de transações financeiras por segundo (750 TPS), ficando para decidir entre essa solução adotada, e outra com Mainframe da IBM usando DB como servidor de banco de dados. Devido ao custo de implementação usando Linux + PostgreSQL ser menos de 1% da solução com o Mainframe, ela foi adotada.
Algo interessante que Flávio Gurgel mencionou é que a Caixa Federal obrigou, em edital, as empresas concorrentes terem desenvolvedores ativos no projeto do PostgreSQL, com contribuição na árvore de desenvolvimento. Acabou vencendo a 4Linux, que foi parceira nessa solução.
Outro fato relevante para mim na palestra, foi em relação ao uso de um sistema de custerização/replicação de dados no PostgreSQL, já que estou para implementar algo similar em um projeto que estou trabalhando.
Eles fizeram teste com 2 soluções:
- PgPool II, obtendo 170TPS;
- Sequoia, atingindo 50TPS (vale lembrar, que a solução standalone conseguiu 750TPS).
Devido a esse baixo rendimento, eles acabaram optando por uma solução virtual de disco. Algo como 2 datacenters (1 em servidor em cada datacenter, a distância aproximada de 7 quadras de Brasília um do outro) interligados com fibra-ótica, com replicação de dados a nível de filesystem (Hitachi Storage em Raid5, virtualizada, síncrona e multipath). Como requisito para essa implementação, a Hitachi exigiu que eles usassem LVM com stripes para melhorar o gerenciamento e performance do disco. Como tipo de filesystem, eles optaram pelo XFS devido a se enquadrar melhor nas necessidades do PostgreSQL.
Como recomendação de tunning para o PostgreSQL, eles citaram o uso agressivo de memória e evitar o uso excessivo de I/O de disco, sendo que os maiores problemas que eles encontraram foi com quebra de performance com o autovaccum. Contudo, recomendaram dedicar algum tempo em ajustar valores do SGDB para encontrar um bom balanceamento, do que deixar desligado o autovaccum e fazê-lo manualmente (que compromete muito mais a performance).
A título de curiosidade, esses 750TPS representam algo em torno de: 4,8 milhões de inserts, 3,2 milhões de updates e 2 milhões de selects, alcançados durante o ano passado, em um “pico” de uso. Vale lembrar que ninguém quer esperar para “receber” seu dinheiro na frente da ATM, por isso é importante ter um tempo de resposta muito rápida. A base de dados deles, chegou a atingir cerca de 500GB.
Eles já estão com planos de expandir a quantidade de terminais e para isso vão criar outro centro com a mesma infraestrutura para atender os novos terminais, provavelmente em outra cidade.
Durante esse tempo todo de uso, eles ressaltaram que o PostgreSQL nunca “falhou” com eles. Todos os problemas que eles tiveram em ambiente de produção, foram causados por falha humana ou de hardware, sendo que nunca teve perda de dados.
Afirmaram que estão contribuíndo muito com a comunidade, sendo que os próximos objetivos é melhorar o PgAdmin, produzir uma ferramenta web similar (pois acham o phpPgAdmin muito inferior) e estão contribuíndo para tunning do banco de dados “a quente” via SQL (sem precisar reiniciar o SGDB).
Tags: Banco de Dados, CASES, fisl10, PostgreSQL
