Utilização do SGBD PostgreSQL Utilização do SGBD PostgreSQL
no Metrô São Paulo no Metrô São Paulo
Versão 2 Novembro /2006
Elaborado por:
Gerência de Informática e Tecnologia da Informação
Gustavo Celso de Queiroz Mazzariol - gqueiroz@metrosp.com.br Coordenadoria de Metodologias e Arquitetura de Dados Maria Cecília Serapião
– mcecilis@m etrosp.com.br
Este material foi desenvolvido pela Gerência de Tecnologia da Informação da Companhia do Metropolitano de São Paulo – Metrô e está registrada como propriedade no Creative Commons – www.creativecommons.co.br
1- Introdução
O PostgreSQL foi adotado no Metrô de São Paulo como o Sistema Gerenciador de Banco de Dados free no final de 2001.
O PostgreSQL é um banco de dados objeto-relacional. Assemelha-se aos SGBDRs comerciais com recursos como transações, funções, gatilhos, visões e integridade referencial. Apresenta também recursos de orientação a objetos como tipos definidos pelo usuário e herança.
A performance e segurança do PostgreSQL é comparável a outros bancos de dados comerciais e de código livre.
2 - O processo de seleção que elegeu o PostgreSQL
A seleção de um banco de dados free que culminou com a escolha do PostgreSQL para o Metrô-SP ocorreu em meados de 2001.
O processo de seleção considerou aspectos como estabilidade, presença no mercado e suporte disponível no Brasil como características imprescindíveis. Foram eleitos quatro softwares de larga utilização no mercado com as mais diversas aplicações e objetivos.
Avaliou-se o PostgreSQL, o Adabas, o Interbase e o MySQL.
No aspecto mais técnico avaliou-se funções específicas de armazenamento de dados, portabilidade, storage procedures, functions, transações concorrentes, integridade referencial, ODBC free, estabilidade, entre outras questões.
O processo de seleção na integra encontra-se disponível no endereço:
https://extranet.metrosp.com.br/downloads/index_postg.shtml 3 – Ferramenta de interface de acesso a dados do PostgreSQL
A partir da disponibilização do ambiente PostgreSQL foi necessário iniciar um novo processo em busca de uma interface, também free, que complementasse as funcionalidades do banco PostgreSQL.
Com foco na redução gradativa das licenças MsAccess e MsExcel buscamos ferramentas de interface de acesso a dados. Detectamos uma resistência inicial devido ao fato de que um SGDB não substitui um Access, mas é preciso sim, uma suite de produtos que ofereçam funcionalidades não só de armazenamento mas tambem recursos de desenvolvimento de aplicações.
Para se optar pelo uso de uma ferramenta de interface de acesso a dados, foram
avaliados varios software freware, sendo que os seguintes aspectos foram observados:
- a que tipo de usuário destina-se o produto, no caso, especialistas da área de negócio e/ou usuários desenvolvedores;.
- licença: free e opensource;
- usabilidade: interface amigável e baixa complexidade de uso;
- administração: instalação e administração pelo usuário;
- performance: desempenho do aplicativo;
- geração de relatórios: formato de saída de relatório padrão (ex. PDF, RTF...);
- fornecedor : suporte ao uso da ferramenta e política de evolução e correção de falhas.
Esse processo, em 2002, conclui que o StarOffice, frente a outros extratores de dados na filosofia freeware, era o que mais recursos oferecia.
O Metrô já adotava o StarOffice, como suite de escritório oficial em substituição ao Microsoft Office. Assim, devido a esse posicionamento técnico e a cultura já implantada , optou-se pela evolução no uso da suite StarOffice, até então limitada as funções de escritório, e passou-se a adota-la como ferramenta de interface de acesso a dados. O StarOffice logo após seria substituído, com vantagens, pelo OpenOffice.
O projeto PostgreSQL evoluiu e o OpenOffice mostrou-se limitado frente a demanda crescente.
Uma nova prospecção em ferramentas free, em 2005, identificou a ferramenta Scribes, fornecida pela IpNetwork Consultoria. Com mais recursos do que o OpenOffice e após algumas customizações para necessidades específicas do Metrô, passamos oficialmente a adotá-la no final de 2006.
4 - Arquitetura PostgreSQL
A arquitetura de dados corporativa do Metrô-SP contemplava o SGBD Oracle na baixa plataforma e DB2 no Mainframe. Essa ambiente garantia uma administração efetiva das informações, integridade dos dados, segurança e disponibilidade das aplicações em de produção. Tinhamos tambem um SGDB SQL Server corporativo, porem sua utilização é restrita a um software específico da area Contábil.
Entretanto, o ambiente departamental encontrava-se com soluções locais baseadas em Ms-Access, Dbase, FoxPro, sem a administração da área de TI. Esses dados residiam em micro computadores (desktop) compartilhados.
O PostgreSQL veio preencher essa lacuna na administração dos dados da empresa, departamentais, suprindo a necessidade de um ambiente de dados departamental
estruturado, íntegro, com segurança e disponibilidade. Implantou-se o ambiente PostgreSQL Departamental, em hardwares servidores, com os dados corporativos sendo replicados, sob demanda, para as várias unidades de negócio.
Implantamos inicialmente 3 ambientes departamentais com PostgreSQL, visando atender as áreas de Manutenção, Operação e Administrativa.
Face ao seu desempenho e confiabilidade dos ambientes departamentais adotamos o PostgreSQL também para o ambiente corporativo, com foco em aplicações não críticas.
A arquitetura de dados corporativa do Metrô-SP, a partir do final de 2004, além do DB/2 e Oracle passa a ter também o PostgreSQL.
Em 2005 o PostgreSQL passa também a suportar o ambiente de dados da Extranet e no projeto de Business Intelligence é adotado como repositorio de Data Warehouse..
Os servidores PostgreSQL rodam em hardware com tecnologia Intel sob o sistema operacional Linux Fedora 4.0 e o banco de dados PostgreSQL 8.1.5. O ambiente de rede é Windows 2000.
A arquitetura PostgreSQL trouxe como benefícios:
- o comprometimento do usuário com a gestão integrada da informação (corporativa &
departamental);
- diminuição significativa do acesso direto às bases corporativas, melhorando a performance das transações das aplicações;
- armazenamento de dados departamentais da empresa em ambientes de servidores com segurança e disponibilidade dos dados;
- substituição de aplicativos locais, reduzindo custos de licenças Access e melhorando a segurança;
- garantir a integridade da informação replicada, via um processo controlado e administrado pela área de TI;
-proporcionar independência de link no acesso aos dados pelos departamentos, visto que, o Metro encontra-se distribuído fisicamente na cidade de São Paulo;
- economia de custo em licenças de uso de SGDB´s.
5 - Processo de Implantação
A implantação do ambiente PostgreSQL exigiu muito além de recursos tecnológicos
adequados e suficientes as necessidades, mas também a introdução de uma nova cultura que até então se mostrava fiel ao ambiente Microsoft.
Foram realizadas diversas palestras de convencimento junto aos usuários, com a presença do CIO, o que deu maior credibilidade ao projeto.
Investiu-se na aquisição de hardware e na implantação de um software de ETL para suportar o ambiente. Iniciamos com o software EDA/CopyManager e atualmente utilizamos o Sunopsis.
Foi necessário, ainda, o investimento em capacitação de pessoal no uso do PostgreSQL, no uso da suite OpenOffice, com foco na conexão ao banco de dados e na extração de informações. Em 2006, iniciamos a capacitação no software de extração de reltorios, Scribes.
Contou-se tambem com o suporte de uma parceria externa no apoio a implantação do ambiente PostgreSQL.
Implantou-se uma Metodologia de Desenvolvimento Departamental que serve como guia aos desenvolvedores.
Realizou-se varias visitas aos departamentos com o intuito de se identificar as necessidades departamentais, sejam as já atendidas pelo Access ou as novas necessidades.
Implantou-se um FAQ para apoiar o uso do ambiente.
6 - A redução de licenças Oracle
A implantação do PostgreSQL determinou a redução de investimentos em licenças de banco de dados Oracle, embora ainda exista um ambiente de dados Oracle no Metrô destinado exclusivamente a aplicações de missão critica e a pacotes proprietarios Oracle.
A ausência do custo de licenças de SGDB´s foi a alternativa capaz de viabilizar o Projeto Postgres no Metrô, que em 2006 conta com 22 bancos de dados PostgreSQL, atendendo ambientes de teste e produção nos setores departamentais, coporativos, DW, Extranet, laboratório e Integração.
O custo dessa solução com licenças Oracle estaria em torno de U$ 500 mil.
7 – O Cenário de Arquitetura de Dados do Metrô em 2006e O grafico
O desenho abaixo mostra o cenário de dados em 2006, com todos os bancos de dados e a integração entre eles, realizada atraves do software Sunopsis.
Existem no ambiente PostgreSQL 126 aplicações, sendo:
– 38 aplicações corporativas,
– 76 aplicações departamentais,
– 12 aplicações/módulos de BI.
O ambiente PostgreSQL possui:
– 1600 usuarios,
– 10.000 tabelas,
– 500 milhões de registros,
– 300 GB de armazenamento
8 – Conclusão
O projeto PostgreSQL viabilizou um novo modelo de negócio na empresa.
A partir do conceito de Fábrica de Informações, passamos a compartilhar informações consolidadas e tornamos o processo de gestão integrada da informação não só perceptível ao usuário más de suma importância para a definição de ações mais eficazes.
Percebemos também uma mudança positiva no comportamento dos usuários que, hoje, são mais exigentes quanto a qualidade das informações corporativas, e "provocam" um interessante e rico processo de melhoria contínua.
Como benefícios tangíveis, podemos citar a economia de cerca de US$ 500mil em licenças de uso de SGDB, só no ultimo ano.
Também foi possível tratarmos adequadamente os dados que antes ficavam no MS- Access, em microcomputadores (desktop) compartilhados. O PostgreSQL é residente em hardwares servidores com todo o processo de back-up, segurança e disponibilidade que esta configuração propicia.
Para a área de TI do Metrô o sucesso do projeto Postgres tem um significado muito especial.
A implantação de soluções com software livre é árdua e são necessários muitos esforços para romper as resistências. Os resultados precisam ser explícitos e superar as expectativas para obter credibilidade. Assim sendo, o estagio atual de projeto demonstra o êxito desse empreendimento e serve de estímulo para novas empreitadas.
A equipe responsável pelo projeto se sente vencedora, recompensada e motivada.
