BR-Linux.org

“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 (http://fisl.softwarelivre.org/9.0/papers/pub/programacao/369), 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 (http://fisl.softwarelivre.org/9.0/papers/pub/programacao/138). 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” (http://fisl.softwarelivre.org/9.0/papers/pub/programacao/102) 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. (aliás, a palestra poderia ser chamada de Perl no PostgreSQL, hehehe).
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 (http://fisl.softwarelivre.org/9.0/papers/pub/programacao/161). 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: http://www.postgresql.org.br/Palestras_do_PGCon_Brasil_2007?action=AttachFile&do=get&target=07_Fazendo_um_elefante_passar_debaixo_da_porta_-_F%C3%A1bio_Telles.pdf (foi alterado um pouco para o FISL, pelo que eu pude ver, mas a 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.”

Enviado por Luciano Giordani Bassani (lgbassaniΘgmail·com) .