Como o PostgreSQL deu e dá sustentabilidade ao projeto e-cidade
Apresentação Fabrízio de Royes Mello Membro PGBR Experiência Profissional 5 anos Gerente de CPD Prefeitura DBSeller desde 2005 Desenvolvimento de Software desde 1993 Experiência em PostgreSQL desde 1999 Experiência em PHP desde 2002 Desenvolvedor do Software Público e-cidade
Parte 1 HISTÓRIA
História Porque PostgreSQL? Experiência anterior em PostgreSQL (desde 2000) Confiável Plataforma de Desenvolvimento Software Livre Na época existia MySQL e PostgreSQL que integravam facilmente com PHP... logo... obviamente...
História 2002 Fundação DBSeller 2002 PG7.2 e PG7.3 (Usávamos 7.2) 2003 PG7.3 2005 PG8.0 e PG8.1 2006 Migramos do PG7.2 para PG8.1 2006 PG8.2 2008 - PG8.3
História 2009 PG 8.4, Migramos para PG8.2 e Lançamos o e-cidade como GPL 2010 PG 9.0 2011 PG 9.1 2011/2012 Processo Migração PG8.2 > 9.1 2012 - Extensões
História Hoje o e-cidade está presente em diversas Ufs do país (RS, MG, RS, AL, RO, AC, BA...) Informatização completa de Municípios Prefeitura Câmara de Vereadores Autarquias / Fundações / RPPS Postos de Saúde Escolas
História Alguns números do banco do e-cidade 59 esquemas ~2900 tabelas ~2020 sequencias ~5021 índices ~490 funções ~140 gatilhos (esse número irá aumentar)
Parte 2 ARQUITETURA
Problemas e Soluções de Arquitetura
Variáveis de Sessão Reutilização de Conexões (pool) Regras de Negócio no Banco de Dados Auditoria de Tabelas Problemas e Soluções de Arquitetura
Variáveis de Sessão Problema Informações da sessão do PHP ($_SESSION) não visíveis nas PLs Algumas informações podem ser ajustadas durante a sessão do usuário: Instituição Departamento Módulo / Item de Menu Data/Hora de Processamento
Variáveis de Sessão Solução adotada Tabelas temporárias para armazenar um par chave/valor PLs para recuperar e atualizar essas variáveis Na aplicação é transferido conteúdo de $_SESSION para o banco Em 2009 algumas discussões: http://bit.ly/vpavv8 DEMO!
Reutilização de conexões (pool) Problema Alto overhead no app server devido conexões/desconexões com PG PG 8.2 não tem DISCARD ALL para retornar sessão ao seu estado inicial
Reutilização de conexões (pool) Solução adotada Escolhido pgbouncer pela simplicidade, velocidade e facilidade de configuração/instalação Para o PG 8.2 implementamos uma função para emular o comportamento do DISCARD ALL pool_mode = session server_reset_query = SELECT fc_discard_all();
Regras de negócio no banco Problema Muitas funções monolíticas Redundância de funcionalidades Falta de modularização Caso Cálculo IPTU : Função ùnica Não mantinha histórico de cálculos de anos anteriores Manutenção dificultada
Regras de negócio no banco Solução adotada Modularização Criação de Estrutura (micro-framework) para cálculo de impostos e taxas Reutilização de Código Velocidade Desenvolvimento Padronização
Auditoria de tabelas Problema 2 (duas) tabelas com informações redundantes Somente atualizações oriundas das classes da aplicação sofriam auditoria Muitos INSERTs devido estrutura redundante Crescimento muito alto das tabelas
Auditoria de tabelas Solução adotada (NOVO) Uma tabela com alterações (INS/UPD/DEL) Triggers nas tabelas a serem auditadas Particionamento da tabela de auditoria Interface de acesso as mudanças (função)
Parte 3 SUSTENTABILIDADE
Sustentabilidade é uma característica ou condição de um processo ou um sistema que permite sua permanência, em certo nível, por um determinado prazo (Fonte: wikipedia)
Como obtemos sustentabilidade Estabilidade, Escalabilidade, etc...etc... Plataforma de Desenvolvimento Comunidade Ativa Documentação abrangente Novos recursos importantes a cada versão Produto de Altíssima Qualidade
FUTURO
Futuro Novas versões do PostgreSQL Extensões (pgxn.org) Replicação / Distribuição de Carga
Obrigado fabriziomello@gmail.com @fabriziomello