FISL11: Fim do segundo dia

Depois de perder várias palestras, algumas por super-lotação, outras porque o palestrante não veio, acabei assistindo 2 palestras que não era a intenção inicial de acompanhar:

– Sessão III: Engenharia de Software

– Eventos Comunitários: Debian Brasil

O evento comunitário do Debian Brasil eu participei mais por curiosidade mesmo. Uso muito o Debian em servidores e é minha opção predileta. Já usei muito ele em desktop, mas atualmente meu notebook roda openSUSE. Estava curioso para ver como funcionava um evento desses. De interessante ficou que o pessoal do Debian está planejando organizar uma nova conferência mundial no Brasil, em 2012, sendo que existe uma péssima notícia para o FISL em 2014… Como é o ano da Copa no Brasil, a ASL está analisando não realizar o FISL em 2014.

Já da palestra de Engenharia de Software, foram discutidos assuntos diversos, com palestrantes diferentes, mas a que mais me atraiu a atenção foi da ferramenta NODIPO, que ainda não está completa, mas é um software criado para efetuar o levantamento de requisitos… Como ela, segundo o autor, existiria apenas o softwiki. Incialmente ela foi construida para ser incorporado a um repositório de softwares, mas acabou virando uma ferramenta standalone e o autor agora pretende completar essa mudança, basicamente implementado um sistema de usuários e direitos.

Está sendo desenvolvida em PHP, PostgreSQL e XML e eu encontrei esse exemplo de execução na web:  http://nodipo.viadigital.org.br/

Gostei muito da idéia do autor.

Assisti, também, uma palestra sobre Websockets, mas julguei ser uma implementação muito  imatura ainda, por isso nem vou escrever nada sobre ela.

FISL10: Documentação automática no PostgreSQL

Essa palestra foi apresentada por Leandro Dutra, que trabalha a mais de 10 anos com PostgreSQL, e foi muito interessante, pois lançou algumas idéias muito inovadoras ao atual modelo de modelagem de dados. Eu consideraria até que são idéias um pouco revolucionárias, pois estariam em desacordo com o que a gente aprende como “correto” em cursos de nível superior, etc.

Inicialmente, o Leandro listou as ferramentas tradicionais de modelagem de dados, que usamos:

– Cérebro, ou seja, inicialmente pensamos e imaginamos como será nossa implementação;

–  Livros-textos e documentação;

– Caneta e papel, ou seja, o ideal é que você faça um esboço inicial em papel, sem o comprometimento de ter que gravar isso;

– Programas de diagramação: nesse caso, ele não gosta de usar a palavra programas de modelagem de dados, porque ele acredita que estas ferramentas são muito improdutivas e não conseguem criar um bom modelo referencial para ser usado no banco de dados, sem mencionar que produzem um monte de código desnecessário na hora de importar para o banco de dados;

– Por fim, DDL (data definition language), que seria a linguagem de definição de dados.

Para o desenvolvimento da base de dados, o palestrante sugere aplicar a programação literária, ao invés de processo tradicional de desenvolvimento (esse processo tradicional, seria compostos por passos rígidos, como levantamento de requisitos, criação de um modelo, criação de diagramas, etc).

Na programação literária, ao invés de se elaborar um diagrama da base de dados, partiria direto para a modelagem dos dados em código fonte e após a implementação seria gerado os gráficos do diagrama, bem como toda a documentação da base de dados. Essa modelagem combinaria documentação com código fonte, com alguns identificadores, para que o computador pudesse separar os dados pertinentes a ele, quando necessário.

Para essa modelagem em código fonte, o palestrante sugeriu:

– O próprio PostgreSQL;

– ISO SQL;

– D4: no caso, o D4 seria um padrão muito interessante, na opinião do Leandro, pois ele não teria as limitações do SQL, conseguindo normalizar todas as regras do negócio, mas é algo que não está 100% pronto, tão pouco tem boa documentação.

Para a fase de geração dos diagramas e documentação, ele sugeriu:

– Autodoc, específico do PostgreSQL, com suporte a gerar gráficos, docbook e html;

– SQL::Fairy, um módulo do Perl, capaz de gerar gráficos e código em latex, com a grande vantagem de se comunicar com praticamente qualquer tipo de banco de dados, bem como converter para qualquer saída que se deseje;

–SchemaSpy, uma solução em Java, que gera HTML, com a vantagem de ter uma inteface gráfica para ajudar na hora de gerar a documentação da base de dados.

Algo que o palestrante deixou bem claro é que para isso funcionar é necessário usar muito definição de domínios.

Para finalizar, algumas curiosidades:

O Brasil está em terceiro lugar em importância de uso de PostgreSQL (boa parte por causa do CASE da CEF), sendo que em primeiro está o Japão e em segundou lugar os USA.

Sobre a CEF, ainda, ele disse que a solução deles de 750TPS (transações por segundo), corresponde, aproximadamente, a 1500 transações no banco de dados por segundo.

Uma dica que ele deu sobre a modelagem de dados é tentar usar muito chave natural, ao invés de joins tradicionais, pois além de melhorar a visualização das consultas, isso pode ajudar a melhorar o desempenho também.

FISL10: PostgreSQL 8.4

Fernando Ike apresentou um aparado geral do que vem por ai nessa nova versão desse SGDB. Algumas coisas interessantes:

– Melhorias no cancelamento de consultas:

Na versão 8 já era possível cancelar uma consulta com select pg_cancel_backend(pid)

Agora, será possível terminar uma consulta com select terminate_backend(pid)

– Suporte a ACL por coluna

– Suporte a autenticação do usuário com certificado SSL

– Melhoria em montagem de consultas com o uso de with

– Possibilidade de usar limit em subselect

– Disponibilização da ferramenta pg_migrator que facilita a migração entre versões do PostgreSQL, opcionalmente não ocupando muito espaço em disco com uma brutal melhora de performance na tarefa de restaurar uma base de dados;

Algumas coisas esperadas para a versão 8.4 foram adiadas para a versão 8.5, devido alguns bugs. Entre elas:

– Replicação síncrona suportada diretamente na árvore de desenvolvimento principal

– Suporte a SE-Linux

– Hot stand-by

FISL10: Expresso 2.0

Depois da palestra que assisti no dia 25/06 da DATAPREV, fiquei muito curioso para conhecer melhor a ferramenta de e-mail Expresso, por isso não perdi a oportunidade.

Dessa vez, a palestra começou com atraso e com muita gente impaciente na porta de entrada da sala, devido a palestra anterior ter ultrapassado o limite de tempo. Auditório lotado, Walter Zapalowski apresentou a ferramenta ao público.

Na apresentação deu para perceber que o Expresso 2.0 é muito mais que um webmail, sendo uma ferramenta muito robusta para comunicação e está expandindo para outras áreas como colaboração. A ferramenta chega a conseguir se interligar com o Asterisk para fazer ligações VOIP com apenas um click.

Algo legal que o Zapalowski demonstrou é que os desenvolvedores (que não é apenas a SERPRO e a DATAPREV) estão muito preocupados em deixar a ferramenta extremamente configurável, para facilitar a adoção por outras empresas, seguindo o verdadeiro espírito de Software Livre.

Aparentemente existe uma colaboração muito grande com troca de código com a comunidade, o que é muito louvável.

Existe uma gama enorme de recursos, como possibilidade de usar Cerficação Digital de nível A1 (com a chave gravada em disco) e até A3 (com tokens), algo que não se tem notícia que outra ferramenta de webmail livre disponha.

Outros recursos que chamaram a atenção é a possibilidade de poder se trabalhar off-line no módulo de e-mail, sendo que está sendo implementando esse recurso para o módulo de agenda.

Além de poder trabalhar off-line, é possível sincronizar o Expresso com versões mais leves que rodam em celulares e outros dispositivos similares.

O Expresso nasceu na CELEPAR (Paraná) e desde 2005 é a ferramenta de comunicação eletrônica do governo de lá, sendo desenvolvido em PHP e AJAX, mas com uma gama muito grande de tecnologias livres agregadas como o GoogleGears, entre outras.

Durante a palestra eu fiquei com a impressão que o desenvolvimento do Expresso foi uma espécie de “resposta” ao fechamento do código do DIRETO da PROCERGS. Aliás, Marcos Mazoni, antigo diretor da PROCERGS (me lembro dele no primeiro FISL) abriu a apresentação da palestra (em tempo: agora ele é diretor da SERPRO)…

FISL10: PgScript

A palestra “Um Elefante de barriga cheia: alimentando bases de dados PostgreSQL com pgScript”  foi bastante técnica, mas muito simples de se entender e é muito fácil de ser utilizada.

O pgScript é um “filho” do Google Summer 2008 e faz parte do PgAdmin III do Postgresql 8.4, mas a príncipio pode ser usada em versões mais antigas do SGDB, como por exemplo 8.3, desde que o PgAdmin seja o mais recente. Foi escrito em C++ e também pode ser executado em shell (e não apenas no ambiente do PgAdmin III).

Além do PgScript existem outras soluções para gerar dados de testes para o PostgreSQL, entre elas (que pretendo estudar mais no futuro próximo):

– DBGEN, que foi escrito em ansy C e utiliza TPC-H benchmark para “popular” a base de dados;

– Generatedata.com: um aplicação web para realizar a função de gerador de dados, com possibilidade de baixar. Em uma análise rápida me pareceu bastante robusto e simples de instalar;

– Módulo Data::Faker do Perl: me pareceu bastante extensível e permite gerar dados mais realistas (e não totalmente aleatórios, como no caso do PgScript tradicional). Facilmente extensível;

– Datagen e Faker no Ruby;

– DBMonster e dgMaster para quem gosta de  Java.

Até pouco tempo atrás eu nunca tinha me preocupado muito com testes de desempenho em base de dados, pois geralmente as configurações padrões atendiam bem as nossas necessidades, mas um novo projeto está exigindo muito mais desempenho do SGDB do que o convencional. Chegamos ao ponto de um servidor Xeon Quadcore com 4GB de RAM não aguentar a carga de processamento com pouco menos de 100 máquinas com acessos simultâneo. Mas eu creio que estes testes na base de dados vão exigir mais do que estas ferramentas podem oferecer e vou ter que estudar melhor como fazer uma simulação baseada na aplicação, para conseguir um ajuste fino mais preciso nas variáveis do PostgreSQL. Contudo, algo é certo: essas ferramentas de geração de dados aleatórios são um bom ponto de partida.

FISL10: PostgreSQL na CEF

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).

Replicação em PostgreSQL: Fim do sonho

Assisti hoje, no segundo dia do FISL, a outra palestra sobre replicação de dados no PostgreSQL, com o Bucardo. Já cheguei meio “traumatizado” com a palestra sobre replicação do dia anterior (porque não é tão simples replicar dados no PostgreSQL como é no MySQL???).

Até que a palestra começou bem, e eu comecei a ficar feliz quando o palestrante falou que ela era uma solução multi-master e escrita em Perl, Pl/Perl e Pl/pgsql, mas começou a desandar quando falou que usa triggers (não me agrada usar triggers na minha base de dados para implementar replicação, pois não quero “sujar” minha BD). Piorou quando disse que era uma solução que não aceitava chave primária composta, apesar que os autores do projeto estão pensando em melhorar esta funcionalidade. Na verdade, creio que até eu poderia adaptar o Bucardo para as minhas necessidades, mas o fato de usar triggers realmente não me agrada. Eu quero ter controle total sobre a minha base de dados. Sou muito possessivo com as minhas coisas! 🙂

Tem mais alguns pré-requisitos, como PostgreSQL 8.1 ou superior, além de ter que ter o Perl e mais alguns módulos do Perl instalados no servidor “principal” de replicação, mas o fato de não aceitar chave primária composta é muito limitante.

Achei interessante que ele tem alguns controles para resolver conflito de chave, como por exemplo, você pode escolher qual servidor tem prioridade, em caso de conflito, ou até uma opção engraçada, que é a “random” (isso mesmo, faz um “sorteio”, huahuhauhua). Mas bem que podia ter uma opção do tipo “migrate“, onde os registros duplicados de um dado servidor tivessem sua chave primária modificada, sem perda de dado, mas tudo bem. No fim, o que vale mesmo é adotar o velho range de auto-numeração.

Creio que vou pesquisar um pouco mais a replicação por log e ver se existe maneira de deixar o servidor “escravo” aberto para seleção, assim como eu faço atualmente com o MySQL (solução perfeita para as aplicações que eu tenho atualmente). Na pior das hipóteses, foi implementar a replicação manualmente usando triggers MINHAS, hehehe

FISL 9: Dia do PostgreSQL!!!

Depois do primeiro dia de FISL, daria para “apelidar” hoje como o dia do PostgreSQL. Amanhã, ainda, terá pelo menos mais uma palestra sobre replicação de dados, mas somente hoje eu participei de 4 palestras sobre este SGDB.

---

Logo cedo, assisti a palestra sobre replicação de dados, onde foram abordados conceitos como replicação síncrona e assíncrona e que às vezes uma solução mais simples pode ser a mais indicada. O palestrante usou uma analogia com vários tipos de carros de velocidade, passando por carros que desenvolviam mais de 400Km/h mas que só andavam em linha reta, sem muito controle, passando por fusca, que chega a 120Km/h por hora com algum esforço, mas anda para todos os lados e pode ser usado na cidade, até chegar no carrinho de rolimã, que não tem motor, mas em compensação tem custo quase zero de manutenção.
Mostrou várias ferramentas para replicação, sendo que eu destacaria o skytools da Skype, uma solução de replicação síncrona com centenas de servidores rodando em ambiente de produção, soluções mais clichês, como o Slony (que usa triggers para replicações assíncronas, mais indicado para replicação de tabelas), Warm-Standby (baseado em log), que aparentemente seria algo similar ao sistema de replicação do MySQL, mas que precisa que o slave fique em modo de espera, sem poder ser usado.
Fiquei surpreso com a afirmação de que pg_cluster é extremamente instável com base de dados grande (ele citou ser impossível em usar em uma base de dados de mais de 10GB, porque simplesmente o SGBD pára de funcionar com ele). Pensava em adotar esta solução em um projeto.

Depois, teve uma palestra muito interessante sobre segurança de dados no PostgreSQL. O palestrante, usou a frase “Safe Data Is Happy Data” (Dado seguro é dados feliz) como referência em toda a apresentação.

Basicamente, ele falou que a maioria das soluções de sistemas de banco de dados não se preocupavam com a segurança do lado de dentro do firewall, apenas definindo políticas de segurança no roteador, servidor web, etc. Esta despreocupação com a segurança interna é uma das principais causas de “dado infeliz”. Ele citou, que cerca de 2/3 das invasões são internas, com roubo de dados por funcionários, etc.

Para ter uma base de dados realmente segura, é necessário várias ações, entre elas, definir corretamente uma política de acesso de senhas no arquivo pg_hda.conf (por exemplo, usando ident apenas para usuários tipo administradores logados em rede local e segura e md5 para usuários web com conexão ssl, etc.).

Outra atitude a ser adotada é definir corretamente os direitos de acesso as tabelas. Por exemplo, definir usuários web com acesso apenas de select e os usuários da sua rede interna com acesso total, bem como definir acesso apenas as tabelas necessárias para cada grupo.

Infelizmente não lembro mais de todas as práticas de segurança que foram sugeridas, mas tem uma que achei muito interessante, que nem sempre é utilizada, que se trata da auditoria do sistema. Eventualmente, pessoas mal intencionadas com acesso ao sistema ou a base de dados podem roubar informações ou alterar dados por má fé ou até mesmo erro. A auditoria ajuda a detectar estes problemas e até mesmo corrigir, voltando ao estado anterior. Para isso, é essencial usar triggers e definir corretamente o acesso as tabelas de auditoria, para que um invasor não consiga comprometer esta auditoria, também.

Em seguida, teve uma palestra sobre “Postgres Application Server” (aliás, a palestra poderia ser chamada de Perl no PostgreSQL, hehehe), que seria basicamente mover parte da aplicação para o SGDB, como por exemplo, validação de dados, uso de store procedures para processamentos em lote, etc.

Podem ser usadas várias linguagens para a implementação, sendo que o palestrante citou o pl/sql que seria uma linguagem segura e que não precisa de nada, pois é como se fosse um “default” do PostgreSQL e linguagens ditas “inseguras”, as quais poderiam fazer um bom estrago na base de dados ou no sistema (se forem mal utilizadas), pois implementam acesso a disco, etc. Entre estas linguagens, o palestrante deu destaque para a Lua e o Perl, mas também poderia ser usado PHP, C, etc.

Destaque para a implementação de um domain email (tipo de dado), validado via Perl, com poucas linhas (graças ao uso do CPAN).

A última palestra de PostgreSQL do dia foi sobre boas práticas em desenvolvimento em banco de dados. Foi a palestra mais genérica sobre PostgreSQL, mas certamente foi a mais interessante. Para quem tiver interesse, dá para conferir o pdf dos slides da palestra, aqui (foi alterado um pouco para o FISL, pelo que eu pude ver, mas a idéia original da mensagem continua a mesma).
As partes que eu acredito que valem a pena destacar, são:

1. Uma pessoa sem bom senso não se preocupa com melhores práticas;
2. Uma pessoa com bom senso e pouca experiência procura aprender e utilizar as melhores práticas;
3. Uma pessoa com bom senso e muita experiência sabe quando não utilizar as melhores práticas.

A maioria dos desenvolvedores devem procurar se enquadrar no segundo item e apenas quando tiverem muita “estrada” e muitas “melecas” (como o palestrante gostava de dizer) feitas é que pode pensar em ir para o terceiro grupo de pessoas.

Além disso, vale a pena citar uma frase de Eric Raimond: “Estrutura de dados inteligente e código burro trabalham muito melhor do que o contrário”, ou seja, se a estrutura de dados for mal definida, nada salva o projeto, nem programadores fenomenais. Tudo parte de uma boa definição da modelagem dos dados. Nos slides tem várias dicas boas para se conseguir isso. Vale a pena conferir.