ORACLE VS POSTGRESQL

Transcrição

1 CENTRO UNIVERSITÁRIO DE ARARAQUARA - UNIARA MBA EM GESTÃO DE BANCO DE DADOS ORACLE JULIANO PARRO ORACLE VS POSTGRESQL ARARAQUARA/SP 2015

2 JULIANO PARRO ORACLE VS POSTGRESQL Trabalho de Conclusão de Curso apresentado ao Departamento de Ciências da Administração e Tecnologia, do Centro Universitário de Araraquara - UNIARA, como exigência para obtenção do título de Especialista em Gestão de Banco de Dados Oracle. Orientador: Prof. Esp. Carlos Alberto Silva ARARAQUARA/SP 2015

3 AGRADECIMENTOS A minha família por me apoiar em todos os momentos. A Deus por permitir este momento.

4 Quando você perceber que, para produzir, precisa obter a autorização de quem não produz nada; quando comprovar que o dinheiro flui para quem negocia não com bens, mas com favores; quando perceber que muitos ficam ricos pelo suborno e por influência, mais que pelo trabalho, e que as leis não nos protegem deles, mas, pelo contrário, são eles que estão protegidos de você; quando perceber que a corrupção é recompensada, e a honestidade se converte em auto sacrifício; então poderá afirmar, sem temor de errar, que sua sociedade está condenada. (Ayn Rand)

5 RESUMO Este trabalho traz uma abordagem sobre os principais aspectos a serem considerados na escolha de um Sistema de Gerenciamento de Banco de Dados (SGBD). São apresentadas semelhanças e diferenças entre o Oracle e o PostgreSQL partindo da necessidade do ambiente de negócios até os resultados dos testes realizados. Essas informações tem o objetivo de auxiliar na escolha de um SGBD de acordo com as especificações do projeto e minimizar o conflito entre os envolvidos neste processo como os membros técnicos, os responsáveis pela implantação, migração, manutenção e administração da nova tecnologia definida. Ao final deste trabalho é apresentada uma conclusão imparcial de acordo com os impactos e análises realizadas, revelando que uma tecnologia não é superior ou inferior a outra mas que cada tecnologia é recomendada a um determinado tipo de ambiente ou negócio, que por mais semelhante que possa parecer pode ser completamente diferente, dependendo da necessidade única que cada projeto demanda. Palavras-chave: ORACLE. POSTGRESQL. SQL. SGBD. RDBMS.

6 ABSTRACT This paper presents an approach on the main aspects to consider when choosing a Database Management System (DBMS). Carried out similarities and differences between Oracle and PostgreSQL starting from the need of the business environment until the test results are displayed. This information is intended to assist in choosing a DBMS according to the specifications of the project and minimize conflict among those involved in this process as the technical members, those responsible for implementation, migration, maintenance and administration of the new set technology. At the end of this work is given a fair conclusion according impacts and analyzes, revealing that a technology is not higher or lower other but each technology is recommended for a particular type or business environment, which more similar it may seem can be quite different depending on the unique needs that each project demands. Keywords: ORACLE. POSTGRESQL. SQL. SGBD. RDBMS.

7 LISTA DE FIGURAS Figura 1 - Sistema Gerenciador de Banco de Dados Figura 2 - Componentes de um SGBD Figura 3 - Processo de levantamento e análise de requisitos Figura 4 Teorema CAP Figura 5 Sistemas OLTP e OLAP em DW Figura 6 - Oracle Exadata Database Machine X Figura 7 - Oracle Database Appliance X Figura 8 - HA Database Ready SX2 Frente Figura 9 - HA Database Ready SX2 Verso Figura 10 - OTN License Agreement for Oracle... 54

8 LISTA DE TABELAS Tabela 1 Modelos de dados Tabela 2 - Ambientes de teste Tabela 3 - Simples comandos para testes Tabela 4 - Resultado dos testes... 57

9 LISTA DE ABREVIATURAS E SIGLAS ACID ANSI ASM BASE BI CAP CPU CRM DBA DBMS DCL DDL DM DML DW ERP ETL HA NOSQL ODA ODBC OLAP Atomicidade, Consistência, Isolamento e Durabilidade American National Standards Institute Automatic Storage Management Basically Available, Soft state, Eventually consistent. Business Intelligence Consistency, Available, Partition tolerance Central Processing Unit Customer Relationship Management Database Administrator Database Management System Data Control Language Data Definition Language Data Mining Data Manipulation Language Data Warehouse Enterprise Resource Planning Extraction Transform Load High Availability Not Only SQL Oracle Database Appliance Open Database Connectivity Online Analytical Processing

10 OLTP PIT RAC RAM RDBMS SGBD SGBDR SLA SO SQL TCL Online Transaction Processing Point in Time Recovery Real Application Clusters Random Access Memory Relational Database Management System Sistema de Gerenciamento de Banco de Dados Sistema de Gerenciamento de Banco de Dados Relacional Service Level Agreement Sistema Operacional Structured Query Language Transaction Control Language

11 SUMÁRIO 1 INTRODUÇÃO OBJETIVO JUSTIFICATIVA SISTEMA DE GERENCIAMENTO DE BANCO DE DADOS LEVANTAMENTO DE REQUISITOS TIPOS DE AMBIENTE TEOREMA CAP ACID/BASE OLAP/OLTP NOSQL ORACLE POSTGRESQL TESTE CONCLUSÃO REFERÊNCIAS BIBLIOGRÁFICAS GLOSSÁRIO... 63

12 1 INTRODUÇÃO Atualmente a expansão da tecnologia é cada vez mais constante, fazendo com que bancos de dados sejam implantados ou migrados com grande frequência em um cenário onde surge cada vez mais dados a serem tratados, principalmente devido à grande quantidade de máquinas diferentes que conseguem conectar à Internet hoje em dia. O banco de dados pode ser definido como: conjuntos de dados com uma estrutura regular que organizam informação, ou seja, é um conjunto de registros dispostos em estrutura regular que possibilita a reorganização dos mesmos e produção de informação. (DATE, 2004, p.10). Seja em um novo projeto ou em uma migração é comum ocorrer a seguinte dúvida: - Qual banco de dados utilizar? Na maioria das empresas e projetos as opiniões se divergem entre os defensores e entusiastas de uma determinada tecnologia para outra. Uma tomada de decisão ideal deve atender as regras de negócio da empresa de acordo com o seu ambiente e suas necessidades únicas. Deste modo, um Sistema de Gerenciamento de Banco de Dados (SGBD) deve ser definido como o que melhor conseguir cumprir esses requisitos. Essa decisão deve levar em conta alguns aspectos importantes como: confiabilidade, escalabilidade, suporte, manutenção, garantia, etc. Também é importante a realização de testes onde os resultados buscam comprovar o que é prometido pelo sistema. No mercado atual um fator importante é realizar uma análise sobre a quantidade de profissionais disponíveis bem como suas qualificações para trabalhar com a tecnologia em questão. 11

13 1.1 OBJETIVO Este trabalho tem como objetivo apresentar os principais aspectos a serem considerados na escolha de um SGBD apontando algumas semelhanças e diferenças entre o Oracle e o PostgreSQL desde a necessidade do ambiente de negócios até os resultados dos testes realizados. Essas informações tem o objetivo de auxiliar na escolha de um SGBD de acordo com as especificações do projeto além de minimizar o conflito entre os envolvidos neste processo como os membros técnicos, os responsáveis pela implantação, migração, manutenção e administração da nova tecnologia definida. A conclusão desenvolvida no final deste trabalho visa uma abordagem imparcial de acordo com as análises realizadas, revelando que uma tecnologia não é superior ou inferior a outra mas que cada tecnologia é recomendada para um tipo de ambiente ou negócio e que por mais semelhantes que pareçam podem ser completamente diferentes dependendo da necessidade exclusiva que cada projeto demanda. 1.2 JUSTIFICATIVA Implantações de banco de dados seja em Oracle ou em PostgreSQL ocorrem com frequência, assim como migrações tanto de Oracle para PostgreSQL quanto o inverso. Este trabalho é especialmente focado nesses dois bancos de dados, devido a sua forte presença nos mais diversos nichos de mercado principalmente no mercado corporativo e governamental, independentemente de serem ambientes OLAP (Online Analytical Processing) ou OLTP (Online Transaction Processing).E esse aquecido mercado de banco de dados exige uma demanda de profissionais cada vez mais qualificados. Este trabalho também pode ser considerado um estudo importante e grande fator motivador que contribui para a aquisição de um maior conhecimento durante o 12

14 seu desenvolvimento e leitura, tanto sobre a tecnologia Oracle quanto PostgreSQL assim como o processo de análise e definição. Apesar da dúvida sobre qual SGBD escolher ser comum, definir qual deles atende melhor as necessidades de um projeto é uma tarefa metódica e polêmica. Nesta decisão existem fatores de peso a serem considerados e também pessoas envolvidas com os mais variados interesses, que podem ou não contribuir para o avanço e sucesso do projeto, e esses desafios constantes são considerados como inspiração para a criação deste trabalho. 13

15 2 SISTEMA DE GERENCIAMENTO DE BANCO DE DADOS ELMASRI; NAVATHE (2000) dizem que um Sistema de Gerenciamento de Banco de Dados (SGBD) pode ser definido como uma coleção de programas que possibilita a definição, construção e manipulação de bancos de dados. Normalmente um SGBD adota um modelo de dados, de forma pura, reduzida ou estendida. Muitas vezes o termo banco de dados é usado, de forma errônea, como sinônimo de SGBD. (SILBERSCHATZ, 2006, p.90). Segundo Date (2004) um Sistema de Gerenciador de Banco de Dados é composto pelos quatro componentes principais que são: dados, hardware, software e usuários, conforme a Figura 1 ilustra na sequência: Figura 1 - Sistema Gerenciador de Banco de Dados FONTE: (DATE, 2004) Segundo Côrtes (2001) o SGBD é composto por componentes de softwares, onde cada um possui uma função específica. Também são classificadas três categorias de usuários: programador de aplicação, usuário final e administrador de banco de dados (DBA). 14

16 Existem ainda funcionalidades dos SGBD apoiadas por funções dos sistemas operacionais, como por exemplo a exclusividade de acesso a arquivos, prioridades de execução dos processos, etc. Devido a estes serviços, o SGBD costuma ser construído em camadas acima dos sistemas operacionais. Ainda são apresentados os seguintes itens como os principais componentes de SGBD: a) Processador de Consulta; b) Gerente de Banco de Dados; c) Gerente de Arquivos; d) Processador de DML; e) Compilador de DDL; f) Gerente de Dicionário; g) Controle de Autorização; h) Processador de Comando; i) Verificador de Integridade; j) Otimizador de Consulta; k) Gerente de Transação; l) Scheduler (Escalonador); m) Gerente de Recuperação; n) Gerente de Buffer. A Figura 2 em sequência ilustra os principais componentes de um SGBD com as categorias de usuário: 15

17 Figura 2 - Componentes de um SGBD FONTE: (CÔRTES, 2001) Os seguintes itens podem ser inclusos como funções desempenhadas por um SGBD: Processamento e Otimização de Consultas: Consultas expressas em linguagem de alto nível como SQL devem ser examinadas, analisadas, validadas e otimizadas primeiro, para só então serem executadas; Processamento de Transações: Em um ambiente OLTP, a manipulação do banco de dados se dá por meio de transações. Uma transação é uma unidade lógica de processamento, formada por uma ou mais operações de acesso a dados. O SGBD deve garantir que as transações tenham um conjunto de propriedades conhecido como ACID (Atomicidade, Consistência, Independência e Durabilidade). Sendo assim, ele deve escalonar as transações, provendo controle de concorrência; Recuperação de Falhas: É responsabilidade do SGBD manter a consistência do banco de dados mesmo após a ocorrência de falhas. Para isto, o SGBD 16

18 deve manter informações sobre as alterações executadas por transações em um arquivo de log. A partir do log é possível refazer ou desfazer os efeitos das transações. 17

19 3 LEVANTAMENTO DE REQUISITOS Apesar do levantamento de requisitos ser uma atividade mais utilizada na área de engenharia de software, também pode ser considerado um aliado valioso que contribui nos projetos de bancos de dados. Analisar e pesquisar sobre o ambiente e os negócios são consideradas requisitos indispensáveis antes de iniciar um projeto de banco de dados, seu objetivo é explorar e conhecer todos os processos que serão afetados com o desenvolvimento do novo projeto. As regras de negócios de uma empresa é algo que deve ser claramente compreendido logo no início do projeto ainda na fase de levantamento de requisitos, pois estas informações são primordiais para identificar e definir qual solução é a mais adequada de acordo com a situação identificada. Sommerville (2003) diz que um processo genérico de levantamento e análise contém: Compreensão do domínio: Os responsáveis devem desenvolver sua compreensão do domínio da aplicação, neste caso também do banco de dados; Coleta de requisitos: É o processo de interagir com os stakeholders do sistema para descobrir seus requisitos. A compreensão do domínio se desenvolve mais durante essa atividade; Classificação: Essa atividade considera o conjunto não estruturado dos requisitos e os organiza em grupos coerentes; Resolução de conflitos: Quando múltiplos stakeholders estão envolvidos, é comum que os requisitos apresentem conflitos. Essa atividade tem por objetivo solucionar esses conflitos; 18

20 Definição das prioridades: Em um conjunto de requisitos, alguns são mais importantes do que outros. Esse estágio envolve uma interação com os stakeholders para definir quais são os requisitos mais importantes; Verificação de requisitos: Os requisitos são verificados para descobrir se estão completos, consistentes e em concordância com que os stakeholders desejam do sistema. A Figura 3 busca demonstrar que o levantamento e a análise de requisitos são processos iterativos, com uma contínua validação de uma atividade para outra: Figura 3 - Processo de levantamento e análise de requisitos. FONTE: (SOMMERVILLE, 2003) Conhecer detalhadamente os negócios de uma empresa é uma tarefa que leva tempo, portanto entrevistar colaboradores que estão ativos há um longo tempo na empresa e que estão envolvidos com outros setores e processos é uma tarefa importante que ajuda a elucidar muitas dúvidas nebulosas que surgem no decorrer do tempo. Logo abaixo segue algumas das diversas técnicas utilizadas: 19

21 a) Entrevistas: A entrevista é uma das técnicas tradicionais mais simples de utilizar e que produz bons resultados na fase inicial de obtenção de dados. Convém que o entrevistador dê espaço ao entrevistado para esclarecer as suas necessidades. Trata-se de uma discussão do projeto desejado com diferentes grupos de pessoas. b) WorkShop: É uma técnica de licitação em grupo usada em uma reunião estruturada. Devem fazer parte do grupo uma equipe de analistas e uma seleção dos stakeholders que melhor representam a organização e o contexto em que o sistema será usado, obtendo assim um conjunto de requisitos bem definidos. c) BrainStorming: É utilizado normalmente em workshops. Após os workshops serão produzidas documentações que refletem os requisitos e decisões tomadas sobre o sistema a ser desenvolvido. Seu objetivo é apresentar os problemas/necessidades a um grupo específico, requerendo assim soluções. d) Questionário: Diferente da entrevista, essa técnica é interessante quando temos uma quantidade grande de pessoas para extrair as mesmas informações. As questões são dirigidas por escrito aos participantes com o objetivo de obter conhecimento sobre opiniões das mesmas questões. São autoaplicáveis pois o próprio informante responde. e) Grupo Focal (Focus Group): É um grupo de discussão informal e de tamanho reduzido (até 12 pessoas), com o propósito de obter informação qualitativa em profundidade. As pessoas são convidadas a participar da discussão sobre determinado assunto. As informações obtidas também devem servir para evitar que o projeto se torne um elefante branco e apontar o caminho ideal a ser seguido de acordo com as dificuldades enfrentadas. Não existe uma técnica padrão para o processo de levantamento de requisitos. Para alcançar um levantamento de requisitos mais preciso é importante o conhecimento de diversas técnicas para saber qual aplicar em cada situação. 20

22 4 TIPOS DE AMBIENTE Com o conhecimento obtido sobre as regras de negócio através da utilização das atividades de levantamento de requisitos já é possível identificar o tipo de ambiente a ser trabalhado. O teorema CAP, explicado a seguir, pode ser utilizado como um guia para auxiliar na escolha ideal de acordo com o tipo de banco de dados e as necessidades do projeto. 4.1 TEOREMA CAP De acordo com MACFADDEN, (2013) no ano de 2000 em Berkeley, CA, o pesquisador Eric Brewer publicou o Teorema CAP (consistência, disponibilidade e tolerância a partição) que afirma que é impossível para um sistema de computador distribuído fornecer simultaneamente todas as três garantias CAP. Em maio de 2012, Brewer esclareceu algumas das suas posições sobre os conceitos mais frequentemente usados. Consistência: Todos os nós possuem os mesmos dados ao mesmo tempo. Disponibilidade: A garantia de que cada solicitação recebe uma resposta independente se foi bem sucedido ou não. Tolerância ao Particionamento: O sistema continua a funcionar apesar das mensagens arbitrárias de perda ou falhas em parte do sistema. A Figura 4, logo abaixo, ilustra melhor o Teorema CAP: 21

23 Figura 4 Teorema CAP. FONTE: (W3RESOURCE, 2015) A Tabela 1, logo abaixo, classifica alguns bancos de dados de acordo com suas respectivas categorias de modelos de dados: NOME Tabela 1 Modelos de dados Modelo de dados Cassandra CouchDB DynamoDB HBase MongoDB Família de Colunas Documentos Chave/Valor Família de Colunas Documentos 22

24 Oracle PostgreSQL Redis Riak Relacional Relacional Chave/Valor Chave/Valor FONTE: Elaborada pelo autor No entanto, em alguns casos o Riak é retratado como um modelo de documento de dados. Redis é muitas vezes referido como família de colunas, e Cassandra é muitas vezes considerado como Coleção. Aparentemente nada impede que alguma evolução nos bancos de dados faça com que seja alterada suas categorias classificadas. 4.2 ACID/BASE O acrônimo ACID possui o seguinte significado: Atomicity (Atomicidade): A operação de uma transação será executada totalmente, ou não será executada; Consistency (Consistência): Garante a preservação de um estado consistente quando a transação iniciar e terminar; Isolation (Isolamento): Garante que a transação não sofrerá interferência por nenhuma outra transação concorrente tratando sua execução de forma isolada; Durable (Durabilidade): Os efeitos de uma transação bem-sucedida são mantidos permanentemente a salvo e sem perdas. Alguns bancos de dados ACID oferecem certa tolerância ao particionamento através de uma técnica chamada two-phase commit que nada mais é que um protocolo para fazer commit distribuído, geralmente é utilizado quando há mais de um banco de dados participando de uma transação. Assim, é oferecido 23

25 consistência e tolerância ao particionamento, mas que costuma comprometer a disponibilidade. O padrão BASE é uma alternativa a ser considerada, pois ele trata os dados de uma forma oposta a delineada pelo ACID. Enquanto o ACID força a consistência dos dados em cada operação, BASE aceita que os dados vão ficar consistentes em determinado momento. Sua disponibilidade é alcançada através do tratamento de falhas locais, impedindo de serem ampliadas para todo o sistema. O acrônimo BASE possui o seguinte significado: Basically Available (Basicamente Disponível) Soft state (Estado Leve) Eventually consistent (Eventualmente Consistente) O padrão BASE geralmente não pertence ao modelo de dados relacional, em seu ambiente uma aplicação funciona praticamente o tempo todo sem ter que ser sempre consistente, fazendo com que o sistema se torne consistente somente no momento necessário. Conforme apresentado no Teorema CAP não podemos ter consistência, disponibilidade e tolerância ao particionamento de forma simultânea. Deste modo, o ideal é considerar os conceitos principais de acordo com cada tipo de sistema e ambiente envolvido. 4.3 OLAP/OLTP Os ambientes OLAP e OLTP possuem conceitos divergentes e são aplicados em contextos diferentes. Ambos costumam ser bancos de dados relacionais e estas siglas são bastante utilizadas na área de Business Intelligence (BI). OLTP (Online Transaction Processing): São sistemas de processamento de transações, isto é, sistemas voltados a operações repetitivas e com uma estrutura voltada para esse tipo de objetivo, por exemplo, em um negócio cujo a principal 24

26 atividade são as vendas no caixa de um supermercado é comum que este ambiente seja do tipo OLTP. Este tipo ambiente costuma ser crítico e com uma alta demanda de confiabilidade nas transações, neste caso o conceito ACID é essencial, estando presente tanto no Oracle quanto no POSTGRESQL. OLAP (Online Analytical Processing): São sistemas responsáveis pela forma analítica da informação e possibilitam sua múltipla análise por diferentes ângulos e formas, por exemplo, quando o sistema é mais voltado a análise de grandes volumes de informações nas mais diversas perspectivas dentro de um Data Warehouse (DW). Em geral, podemos supor que sistemas OLTP fornecem dados de origem para o DW, enquanto que sistemas OLAP ajudam a analisar esses dados. (Figura 5). Figura 5 Sistemas OLTP e OLAP em DW. FONTE: (DATAWAREHOUSE4U, 2010) Pode-se dizer que a diferença está basicamente no fato de que um sistema está direcionado ao funcionamento dentro do ambiente operacional (OLTP) e o outro possui um foco mais gerencial (OLAP). 25

27 Tanto os bancos de dados relacionais ORACLE quanto o PostgreSQL podem ser utilizados em conceitos OLAP e OLTP. Considerando as diferenças aqui mostradas, podemos dizer que não se trata de um conceito ser melhor que o outro, mas sim que são conceitos complementares de objetivos distintos em uma organização. Sendo assim, a empresa deve buscar utilizar ambos da melhor forma possível buscando conciliar desempenho operacional e resultado estratégico. 4.4 NOSQL Bancos de dados NoSQL é uma denominação para banco de dados não relacionais, e isso não quer dizer que não possuem relacionamentos, mas sim que não são orientados a tabelas. Not Only SQL (Não Apenas SQL) não utiliza a linguagem SQL, suas linguagens de consulta são semelhantes ao SQL e costumam ser mais facilmente aprendidas. Em uma abordagem breve sobre bancos de dados não relacionais SADALAGE; FOWLER (2013) diz que não há uma definição genericamente aceita nem uma autoridade para fornecer tal definição para bancos de dados que tendem a ser chamadas de NoSQL, é provável que nunca haja uma definição coerente de NoSQL. Esses bancos de dados geralmente, são projetos com código aberto e a maioria é orientado pela necessidade de execução em clusters. Bancos de dados relacionais utilizam transações ACID para lidar com consistência, o que é conflitante com um ambiente de clusters, de modo que os bancos de dados NoSQL oferecem uma vasta gama de opções para consistência e distribuição. Os bancos de dados NoSQL atuam sem um esquema, permitindo que sejam adicionados campos aos registros do banco de dados, sem ter de definir primeiro quaisquer mudanças na estrutura. Por outro lado, essa ausência de esquema não garante a integridade dos dados. 26

28 O NoSQL é voltado a grandes volumes de dados sendo processados em clusters, simplificando o acesso ao banco de dados, mesmo que não tenham a necessidade de escalar para além de uma única máquina. Existe ainda a vantagem de lidar com acesso a dados cujo tamanho e desempenho demandam um cluster e melhoram a produtividade de desenvolvimento de aplicativos utilizando um estilo de interação de dados mais conveniente. Essas características fazem do NoSQL um forte candidato para ambientes onde sistemas de banco de dados relacionais não são suficientes ou adequados às necessidades específicas como: baixa latência, grandes volumes de dados, escalabilidade, alta disponibilidade HA (High Availability) com importantes estruturas de conexões entre os dados e uma consistência diferente dos ambientes relacionais e do conceito ACID. 27

29 5 ORACLE Fundada no final da década de 70 por Larry Ellison e os co-fundadores, Bob Miner e Ed Oates a Oracle foi a pioneira em comercializar o modelo de banco de dados relacional. A tecnologia Oracle pode ser encontrada em quase todos os setores do mundo e em incontáveis escritórios de empresas. A Oracle é o principal fornecedor de software para gerenciamento de informações e a segunda maior empresa de software independente do mundo. A Oracle foi uma das primeiras a tornar seus aplicativos empresariais disponíveis através da Internet e ainda o faz atualmente. Neste capítulo são abordados alguns aspectos sobre a perspectiva do banco de dados Oracle com análises consideradas importantes na escolha de um SGBD: SISTEMA OPERACIONAL O banco de dados Oracle é considerado multiplataforma por ser compatível com diversos sistemas operacionais: Unix, Linux, Windows, etc. O sistema operacional sobre qual o banco de dados funciona é algo que deve ser analisado com atenção pois ele influencia diretamente em fatores como desempenho e segurança do banco de dados, por exemplo, no Linux o Oracle costuma ter uma melhor performance e mais recursos em termos de alta disponibilidade, porém é suscetível a ataques do tipo rootkit. Já no Windows o Oracle é mais fácil de ser implantado e integrado as ferramentas ODBC e.net porém é mais vulnerável a vírus e ainda existe o custo de licença do sistema operacional mais das atualizações. A Oracle fornece um sistema operacional próprio Linux, que disponibiliza os principais recursos previamente ajustados, o que facilita a instalação do banco de dados e permite um melhor aproveitamento do sistema. 28

30 Uma configuração refinada no sistema operacional é imprescindível para obter bons resultados e inclui ajustes de parâmetros, configuração do sistema de arquivos, compilação do kernel, etc. Deste modo, o SO é determinante para que o banco de dados utilize todo o seu potencial disponível. A escolha de uma versão de sistema operacional homologada também é decisiva para permitir a aquisição do suporte da Oracle. HARDWARE O Oracle 11g pode ser utilizado em máquinas modestas com apenas 256MB de memória RAM, e o mínimo recomendado pelo fabricante são 512MB de memória RAM e 1,5GB de espaço em disco. O Oracle Express não possui custos mas é limitada a utilizar no máximo 1GB de memória RAM, 11GB de disco rígido e apenas um processador. Existem outras versões desenvolvidas a serem comercializadas de acordo com o hardware utilizado, como por exemplo, Oracle Enterprise Edition, Oracle Standard Edition, etc. Há ainda soluções mais robustas e milionárias comercializadas pela Oracle em termos de hardware, podemos citar por exemplo produtos renomados como o Exadata (Figura 6) e o Oracle Database Appliance (ODA) (Figura 7) ambos otimizados e desenvolvidos para trabalhar com grandes quantidades de dados. 29

31 Figura 6 - Oracle Exadata Database Machine X5-2 FONTE: (ORACLE, 2015) Figura 7 - Oracle Database Appliance X5-2 FONTE: (ORACLE, 2015) Outro fator importante a ser considerado é o ambiente tecnológico disponível onde será realizada a implantação, este deve possuir um hardware adequado ao novo projeto, por exemplo, uma comunicação de rede, internet ou mesmo energia intermitente pode comprometer o sistema. 30

32 LICENÇA São diversos os tipos de licenças oferecidas pela Oracle, sendo capazes de atender aos mais variados casos até a situações mais específicas. Suas licenças são comercializada de acordo com a edição, por exemplo, Oracle Standard Edition, Oracle Enterprise Edition, etc. E os preços variam ainda conforme a quantidade de usuários, número de sockets e cores de processador. Por exemplo, a venda de uma licença da versão Oracle Enterprise pode ser avaliada por CPU e quantidade de core do processador. A versão Oracle Express não possui custos e pode inclusive ser utilizada para fins comerciais mas é muito limitada. Há ainda a necessidade de licença para o serviço de suporte e também para as funcionalidades específicas (chamadas Options), que podem tornar o produto mais caro. Além do ambiente de produção, demais ambientes que utilizarem Oracle também devem ser licenciados, como por exemplo, servidores de homologação, desenvolvimento, backup, relatórios, etc. SUPORTE O suporte oficial da Oracle é comercializado em várias modalidades, há planos básicos e planos com assistência técnica 24 horas por dia e 7 dias por semana. O suporte da Oracle disponibiliza todos os recursos necessários para as atualizações dos produtos. Os preços variam conforme a versão do Oracle adquirida e a modalidade do suporte escolhida. É importante que a modalidade do serviço contratado esteja de acordo com o nível de criticidade do negócio. 31

33 INSTALAÇÃO E CONFIGURAÇÃO A instalação do Oracle é facilitada através do assistente gráfico conhecido como Oracle Universal Installer (OUI). Outro assistente o DBCA (Database Configuration Assistent) ou Assistente de Configuração de Banco de Dados também auxilia e facilita nas tarefas de criação e ajuste de um novo banco de dados. O Oracle possui uma arquitetura flexível e muitos recursos para otimizar a performance, tornando possível diversas configurações e tuning, além da criação e gerenciamento de várias estruturas de memória no banco de dados. É possível, por exemplo, definir estruturas de armazenamento com tamanhos de blocos que podem variar de 2k à 32k, ideal para sistemas OLAP e índices em geral, melhor otimizados com tamanhos de blocos grandes (32k). O Oracle possui Packages, que são objetos que permitem entre diversos outros benefícios agrupar e encapsular código de stored procedures e funções. Configurar tantos recursos pode tornar o tempo de conclusão de uma implantação impreciso, devido há muitos parâmetros importantes a serem configurados de acordo com cada projeto. Sendo assim, o ideal é possuir uma janela com no mínimo o dobro do tempo previsto, e se tratando de banco de dados quanto maior essa janela melhor, pois existe o fator agravante de estar trabalhando com um grande volume de dados geralmente muito importantes para a empresa. MANUTENÇÃO E SEGURANÇA O Oracle possui mais recursos de segurança e performance que a maioria dos SGBDS disponíveis no mercado, e estes são cruciais para empresas que possuem aplicações críticas com muitos dados e usuários concorrentes em geral. É importante que a manutenção e a atualização de um SGBD seja realizada por um profissional qualificado para evitar a ocorrência de desastres que podem 32

34 atingir escalas catastróficas. Esse serviço é um diferencial importante oferecido através do suporte da Oracle, sendo possível adquirir de forma confiável todas as instruções necessárias referentes a estes procedimentos, além dos patches de atualização. É interessante observar que a Oracle desenvolve as correções prontamente assim que alguma eventual falha for descoberta e ainda possui mecanismos robustos para evitar ataques externos, injeção de SQL e outros perigos. Por padrão, o Oracle não commita transações, isso permite que você desfaça as alterações de uma instrução SQL, caso ela tenha sido submetido erroneamente. DESEMPENHO O Oracle é considerado um banco de dados com ótimo desempenho no mercado, mas como qualquer outro banco de dados ele deve ser bem configurado. Ele possui muitos recursos que monitoram e auxiliam no ajuste de desempenho além de uma vasta gama de opções a serem parametrizadas, o que permitem atingir um alto nível de desempenho. Seus resultados são bem conceituados nos testes de benchmark do TPC (Transaction Processing Performance Council), especialmente nos testes do tipo TPC-C, mas algumas pessoas o considera polêmico por não ser disponibilizado a comunidade e também pelo responsável pela construção do benchmark ser o próprio interessado na divulgação dos resultados, que nesse caso são grandes fornecedores de SGBDs comerciais e empresas da área de hardware. Outros fatores decisivos para o bom desempenho em qualquer banco de dados são instruções SQL bem formuladas e também possuir um bom conjunto de hardware. BACKUP 33

35 Um recurso que merece destaque é o conceito PIT (Point In Time Recovery) que permite ir até um ponto no tempo específico ou posterior ao backup, utilizando cópias dos logs de transação (conhecidos como archives) isso faz com que a perda de dados seja mínima. Outro recurso de destaque no Oracle é o RMAN (Recovery Manager), uma famosa ferramenta que permite realizar backups incrementais, ela é utilizada principalmente em sistemas ASM (Automatic Storage Management) muito comuns em ambientes RAC (Real Application Clusters). FERRAMENTAS O Oracle é bastante completo em termos de recursos extras e possui inúmeras ferramentas excelentes presentes para implantação, configuração, monitoramento, tunning, análise, relatórios, etc. Muitas de suas ferramentas incluem interface gráfica amigável como por exemplo o OEM (Oracle Enterprise Manager) com gráficos interessantes e que são melhorados a cada nova versão. Há muitas ferramentas desenvolvidas para o Oracle, mais do que diversos outros bancos de dados, mas infelizmente as melhores ferramentas são pagas. DOCUMENTAÇÃO A Oracle possui uma documentação online farta das mais diversas tecnologias e com fácil acesso aos manuais, termos de serviço, tutoriais, etc. O banco de dados Oracle possui uma documentação oficial bem desenvolvida além de existir muito conteúdo criado e disponibilizado por terceiros. CONFIABILIDADE 34

36 O banco de dados Oracle possui um ótimo suporte a transações e leva muito a sério os requisitos ACID, fazendo com que seja um banco de dados confiável e consistente. O Oracle permite efetuar a leitura consistente de dados utilizando o modelo de controle de acesso concorrente chamado MVRC (Multiversion Read Consistency), um dos melhores modelos do mercado para permitir um controle de acesso concorrente com menor contenção de linhas e consequentemente, melhor performance. Quando há acesso concorrente aos dados no Oracle o controle de bloqueios é realizado através da gravação de indicadores de bloqueio no nível das linhas. O fato de alterar um registro não impede que a versão não alterada seja lida em outras sessões até que a transação atual confirme a alteração em andamento (read commited). Esse recurso permite que um usuário "B" leia os dados de uma linha de uma tabela, no mesmo momento em que ela está sendo alterada por um usuário "A", sem que o usuário "B" visualize os dados que estão sendo alterados pelo "A". A tradição da marca Oracle também consegue transmitir a confiança e a segurança de que dificilmente a corporação ou sua tecnologia venha a ser encerrada de alguma forma inesperada, algo que ainda preocupa quando se trata de software livre. Um aspecto desagradável em relação a confiança do banco de dados Oracle é ter que considerar o desempenho que prometem sem poder realizar testes de benchmark e divulgar seus resultados sem autorização prévia da Oracle, o que resulta na escassez de testes comparativos no mercado. ESCALABILIDADE Diferentemente de sistemas NoSQL os bancos de dados relacionais costumam ser mais complexos quando seu crescimento demandam hardware. É 35

37 comum bancos relacionais crescerem apenas de forma vertical, onde apenas são adicionados mais recursos em um único nó do sistema (mais memória ou discos). A tecnologia exclusiva Oracle RAC (Real Application Clusters) permite utilizar o poder em cluster, podendo obter disponibilidade do dado além de ter um processamento em load balance (balanceamento de carga). Outra vantagem do RAC é possuir o Gerenciamento Automático de Armazenamento (ASM) utilizado em vários discos dentro de grupos de discos, assim pode-se obter o dado a qualquer momento, mesmo que um disco não esteja ativo no servidor, pode-se obter o dado de outro disco dentro do grupo de discos. MERCADO DE TRABALHO A maioria das pesquisas realizadas apontam o Oracle como o banco de dados mais utilizado no mundo, o que faz com que haja mais profissionais e vagas no mercado do que outros SGBDS. Há ainda a possibilidade de obter certificações, o que contribui para profissionais qualificados preencherem as vagas ofertadas e ainda contribui para um plano de carreira. ANÁLISE TÉCNICA a. Em um Data Warehouse ou em grandes consultas em tabelas gigantes existe a possibilidade de quebrar uma única consulta em vários processos com o Parallel Query que funciona muito bem há muito tempo. O Oracle RAC é uma tecnologia muito avançada mas ainda não é uma solução perfeita em performance ou alta disponibilidade. Quando há gargalo de I/O a performance não pode ser garantida, especificamente em escrita onde discos flash podem ajudar a resolver esse problema. Também não é assegurada a alta disponibilidade caso os discos sejam corrompidos, onde uma solução do tipo standby pode resolver esse problema. O PostgreSQL tem desenvolvido uma infraestrutura para fazer a mesma coisa a partir da versão 9.4 mas ainda deve demorar um pouco para madurecer. 36

38 b. Em um ambiente que possui várias bases num cluster, migrar apenas uma base para um outro servidor é uma tarefa um pouco complexa. A versão 12c do Oracle tem se esforçado para desenvolver uma arquitetura conhecida como Multitenant Architecture, que visa tornar este tipo de tarefa mais simples assim como a experiência em cloud computing. No PostgreSQL criar uma nova base é uma questão de segundos porém ele trabalha com várias bases sob o mesmo cluster, dividindo um catálogo global, processos, etc. c. Os assistentes de performance são realmente úteis e apontam problemas críticos facilmente. Porém há erros que apenas um DBA experiente consegue identificar, mas mesmo assim os assistentes podem ajudar muito em uma avaliação inicial. d. O particionamento de tabelas do Oracle merece destaque pois possui inúmeras funcionalidades avançadas e é bastante robusto. O particionamento no PostgreSQL foi melhorando nas últimas versões, mas ainda está longe do Oracle. e. O Flashback Query é similar ao Point In Time Recovery sendo útil para voltar a base toda no tempo, ele funciona bem e é bem simples de usar, mas deve ser utilizado logo após a ocorrência de um desastre pois com o passar do tempo os dados deixam de estar disponíveis no UNDO. f. Executar um commit ou rollback dentro de um PL pode não ser elegante mais é prático, e isso evita a construção de uma aplicação externa ou trabalhar com exceptions, esse tipo de transação é algo que PostgreSQL não permite. CUSTO/BENEFÍCIO 37

39 O valor a ser investido em uma solução de banco de dados costuma ser uma das principais características (ou até mesmo a característica principal) analisada pela diretoria em algumas empresas. Os valores do Oracle podem variar muito conforme o tipo de licença e hardware utilizado, o que torna inviável sua aquisição para algumas empresas. Há pessoas que realmente analisam os benefícios do produto sobre o investimento a ser realizado, mas há também pessoas que valorizam apenas custos menores e não consideram os benefícios a serem obtidos. Deste modo, é importante considerar que a aquisição do banco de dados Oracle disponibiliza recursos únicos não oferecidos por nenhum outro SGBD no mercado, mas cabe ao comprador decidir se o custo vale a pena. CASOS DE SUCESSO As empresas que utilizam o banco de dados Oracle são inúmeras e de diversos tamanhos e seguimentos no mundo inteiro. Logo abaixo é fornecida uma breve citação de dois casos de uso no Brasil: O primeiro caso é a Companhia Paulista de Força e Luz (CPFL) com receita anual bruta operacional de R$19 bilhões, sendo a maior empresa privada de distribuição elétrica do país e referência de mercado de utilities. Seus mais de 7,5 milhões de clientes geram um gigantesco volume de dados transacionais diariamente. Implantou dois equipamentos Oracle Exadata Database Machine, para armazenar e processar seus dados financeiros e fiscais dos sistemas financeiros Mastersaf e Modeler. O Oracle Exadata foi fundamental para apoiar o crescimento dos dados e atender aos prazos curtos", afirma Marcio Felix, Gerente de Tecnologia, Telecomunicações e Segurança, da CPFL. 38

40 Neste projeto comprova sua eficácia mesmo quando integrado a aplicativos da concorrência. A infraestrutura da CPFL tornou-se mais robusta e está pronta para apoiar o crescimento dos negócios e do volume de dados da companhia", diz Fabiano Matos, vice-presidente de Vendas de Sistemas da Oracle do Brasil. O segundo caso é a Coca-Cola Refrescos Bandeirantes (Rebic), empresa do segmento de bebidas do Grupo José Alves, distribui e vende de forma exclusiva para a região Centro-Oeste, os refrigerantes da Coca-Cola Brasil. Assim como as cervejas da Heineken Brasil, os sucos, chás, energéticos, achocolatados, isotônicos e hidrotônicos da Sabb e as águas minerais da Acqua Lia. A companhia emprega mais de colaboradores diretos e indiretos, atendendo 237 cidades com 29 mil pontos de vendas e indiretamente 16 cidades com pontos de vendas. As onze unidades de negócios da Rebic apresentam volume de transações com alta disponibilidade, 24x7. São emitidas cerca de 15 mil notas por dia. Por isso, a empresa precisava de um banco de dados mais moderno e robusto, optaram pela doção do Oracle Database Appliance X3-2 e o Oracle Real Application Clusters. Precisamos manter nossa operação sem interrupções e o Oracle Database Appliance garante isso oferecendo uma plataforma de negócios estruturada e alinhada aos padrões de mercado.", afirma Odiberto Pedrosa da Silva, gerente de produção da Coca-Cola Refrescos Bandeirantes (Rebic). "Ficamos satisfeitos em oferecer à Rebic todo o apoio nesse projeto, desde o minucioso planejamento até a avaliação positiva da implementação das soluções Oracle.", comenta Dejair Resende, Diretor de Operações da Red&White Solutions. 39

41 6 POSTGRESQL O PostgreSQL é derivado do projeto Ingres, posteriormente chamado de Postgres patrocinado pela DARPA (Agência de Projetos de Pesquisa Avançada para Defesa), ARO (Departamento de Pesquisa Militar), NSF (Fundação Científica Nacional) e ESL Inc., originalmente liderado pelo professor Michael Stonebraker, na Universidade da Califórnia em Berkeley e com a implementação iniciada em O PostgreSQL é atualmente o mais avançado banco de dados de código aberto disponível. É extremamente robusto, confiável, flexível e rico em recursos, também é considerado objeto-relacional por implementar as características de um SGBD relacional mais algumas características de orientação a objetos, como herança e tipos personalizados. Neste capítulo são abordados alguns aspectos sobre a perspectiva do PostgreSQL com análises consideradas importantes na escolha de um banco de dados: SISTEMA OPERACIONAL O PostgreSQL é considerado multiplataforma por ser compatível com diversos sistemas operacionais: Unix, Linux, Windows, etc. O sistema operacional sobre qual o banco de dados funciona é algo que deve ser analisado com atenção pois ele influencia diretamente em fatores como desempenho e segurança do banco de dados, por exemplo, no Linux o PostgreSQL costuma ter uma melhor performance, melhor gerenciamento de memória além de mais ferramentas e módulos, sendo também considerado mais seguro. Já no Windows o PostgreSQL é mais vulnerável a ataques por vírus ou outras pragas eletrônicas além de existir o custo de licença do sistema operacional e mais as atualizações. 40

42 O PostgreSQL executa nativamente nos sistemas operacionais Microsoft Windows baseados no NT, nas versões do Windows baseadas no MS-DOS a instalação pode ser executada com a utilização do CYGWIN, um conjunto de ferramentas portadas do Unix que funciona como um emulador para que se possa utilizar as APIs do Unix. Também é um software livre registrado sob a licença GNU. Uma configuração refinada no sistema operacional é imprescindível para obter bons resultados e inclui ajustes de parâmetros, configuração do sistema de arquivos, compilação do kernel, etc. Deste modo, o SO é determinante para que o banco de dados utilize todo o seu potencial disponível. HARDWARE O PostgreSQL pode ser utilizado em máquinas modestas com pouca memória RAM e espaço em disco. Ele é bastante flexível com seus requisitos de hardware, dependendo dos arquivos de instalação adquiridos, tipo da instalação realizada, sistema operacional a ser instalado, etc. Por exemplo, a instalação da versão 9.4 a partir de um pacote GNU exige 100MB de espaço em disco para compilação, 20MB para instalação, 35MB para um criação de um cluster vazio e pode ser executado com 64MB de memória RAM. Em termos de hardware, uma solução mais robusta é o appliance conhecido como HA Database Ready SX2 (Figura 8) e (Figura 9) comercializada pela Fujistu. Trata-se de uma solução otimizada e desenvolvida para trabalhar com grandes quantidades de dados, capaz de criptografar os dados de maneira transparente e automática, podendo ser considerado um concorrente do ODA da Oracle. 41

43 Figura 8 - HA Database Ready SX2 Frente FONTE: (FUJITSU, 2014) Figura 9 - HA Database Ready SX2 Verso FONTE: (FUJITSU, 2014) 42

44 Outro fator importante a ser considerado é o ambiente tecnológico disponível onde será realizada a implantação, este deve possuir um hardware adequado ao novo projeto, por exemplo, uma comunicação de rede, internet ou mesmo energia intermitente pode comprometer o sistema. LICENÇA O PostgreSQL é distribuído gratuitamente sob a licença BSD (Berkeley Software Distribution), o que torna o seu código fonte disponível e o seu uso livre para aplicações comerciais ou não. Sua licença também permite que usuários façam qualquer coisa com o código, incluindo revender os binários sem o código-fonte, mas há uma restrição para não responsabilizar legalmente o PostgreSQL por problemas com o programa. Há também a exigência de que a licença apareça em todas as cópias do programa. SUPORTE A comunidade do PostgreSQL fornece assistência gratuita a muitos de seus usuários via . As inscrições nas listas de general e bugs são um bom lugar para começar. Há também canais de IRC disponíveis em diversos idioma, inclusive o português do Brasil e com membros ativos da comunidade. No próprio site do PostgreSQL é possível encontrar uma lista de empresas que prestam suporte comercial com alta disponibilidade e qualidade. Essa grande concorrência composta por muitas opções de suporte contribui para que o cliente não se torne refém do monopólio de uma única empresa. 43

45 INSTALAÇÃO E CONFIGURAÇÃO Há uma grande quantidade de arquivos de instalação disponíveis do PostgreSQL que variam conforme o sistema operacional e seu tipo de instalação. Há arquivos compactados ou executáveis com assistente gráfico para Windows, pacotes específicos para diferentes distribuições Linux, inclusive via repositório, pacotes binários a ser compilados, imagens live cd, etc. O PostgreSQL é um sistema dotado de muitos tipos de índices (B-Tree, GiST, etc.) com muitas opções de configuração, algumas podendo ser realizadas e aplicadas com ele ainda em execução. Muitas configurações e parâmetros importantes são realizadas em um arquivo simples chamado postgresql.conf que pode ser configurado utilizando um simples editor de textos. As configurações de acessos estão localizadas em um arquivo chamado pg_hba.conf. Configurar tantos recursos pode tornar o tempo de conclusão de uma implantação impreciso, devido há muitos parâmetros importantes a serem configurados de acordo com cada projeto. Sendo assim, o ideal é possuir uma janela com no mínimo o dobro do tempo previsto, e se tratando de banco de dados quanto maior essa janela melhor, pois existe o fator agravante de estar trabalhando com um grande volume de dados geralmente muito importantes para a empresa. MANUTENÇÃO E SEGURANÇA É importante que a manutenção e a atualização de um SGBD seja realizada por um profissional qualificado para evitar a ocorrência de desastres que podem atingir escalas catastróficas. A manutenção e atualização do PostgreSQL é capaz de dispensar a necessidade de um profissional altamente especializado para realizá-la. Comandos básicos de atualização no Linux e alguns comandos simples executados via psql são suficientes para manter as tarefas mais básicas funcionais. 44

46 É interessante observar que o PostgreSQL desenvolve as correções prontamente assim que alguma eventual falha for descoberta e ainda possui mecanismos robustos para evitar ataques externos, injeção de SQL e outros perigos. DESEMPENHO O PostgreSQL possui uma performance comparável à de bancos de dados comerciais, sendo mais rápido em alguns aspectos e mais lento em outros com uma variação em torno de 10%. Ele possui muitos recursos a serem parametrizados, o que permitem atingir um alto nível de desempenho, mas como qualquer outro banco de dados também deve ser bem configurado. Uma vantagem do PostgreSQL em relação a alguns bancos de dados comerciais é que ele permite a realização e divulgação de testes de benchmark sem qualquer tipo de restrição, o que facilita ao pesquisar comparativos de desempenho. Outros fatores decisivos para o bom desempenho em qualquer banco de dados são instruções SQL bem formuladas e também possuir um bom conjunto de hardware. BACKUP Um recurso que merece destaque é o conceito PIT (Point In Time Recovery) que permite ir até um ponto no tempo específico ou posterior ao backup, utilizando cópias dos logs de transação (conhecidos como archives) isso faz com que a perda de dados seja mínima. Para realizar um backup incremental no PostgreSQL, existe uma espécie de clone do RMAN, chamado pg_rman. Há ainda outros recursos para backups mais simples que podem ser feitos utilizando o pg_basebackup ou até mesmo o popular rsync. 45

47 Porém a inexistência de uma integração nativa com ferramentas de backup em fita pode fazer falta em alguns casos. FERRAMENTAS O PostgreSQL não disponibiliza ferramentas gráficas nativas, mas existem muitos projetos livres disponíveis, como por exemplo o PGAdmin3 e o PGphpadmin, também existem muitos projetos pagos. Assim como acontece no Oracle, muitas das melhores ferramentas desenvolvidas costumam ser pagas. Qualquer pessoa pode enviar uma nova funcionalidade a equipe de desenvolvimento do PostgreSQL ou publicar no PGXN, a rede de extensões para o PostgreSQL. A funcionalidade pode ser incluída no código da nova versão do SGBD. Atualmente existem diversas funcionalidade encomendadas por empresas que já fazem parte do conjunto nativo do PostgreSQL. Em alguns casos, estas funcionalidades podem entrar como um módulo separado e opcional, distribuídos no diretório contrib, conhecidas como extensões. DOCUMENTAÇÃO O PostgreSQL possui uma vasta documentação online oficial e não oficial de fácil acesso, incluindo um extenso manual, FAQ, Wiki, artigos técnicos, manuais, tutoriais, etc. Sua documentação oficial é bem desenvolvida e traduzida para vários idiomas, inclusive para o Português do Brasil, além de existir muito conteúdo criado e disponibilizado por terceiros. CONFIABILIDADE 46

48 O banco de dados PostgreSQL possui um ótimo suporte a transações e leva muito a sério os requisitos ACID, fazendo com que seja um banco de dados confiável e consistente. O PostgreSQL permite efetuar a leitura consistente de dados utilizando o método MVCC (Multiversion Concurrency Control) onde o fato de alterar um registro não impede que a versão não alterada seja lida em outras sessões até que a transação atual confirme a alteração em andamento (read commited). Esse recurso permite que um usuário "B" leia os dados de uma linha de uma tabela, no mesmo momento em que ela está sendo alterada por um usuário "A", sem que o usuário "B" visualize os dados que estão sendo alterados pelo "A". Por trabalhar com padrões abertos possui uma comunicação transparente com maior facilidade de integrar a outros sistemas. A equipe de desenvolvimento do PostgreSQL busca sempre manter a compatibilidade com os padrões ISO/SQL. Existe ainda um cuidado especial em lançar versões bem testadas, de código estável e que tenha o mínimo de bugs. Cada versão tem no mínimo um mês de teste em versão beta, e o histórico de versões mostra que podem fornecer versões estáveis e sólidas, prontas para uso em produção. ESCALABILIDADE Diferentemente de sistemas NoSQL os bancos de dados relacionais costumam ser mais complexos quando seu crescimento demandam hardware. É comum bancos relacionais crescerem apenas de forma vertical, onde apenas são adicionados mais recursos em um único nó do sistema (mais memória ou discos). O PostgreSQL oferece diversas soluções com conceitos variados em termos de alta disponibilidade, balanceamento de carga e replicação. Há por exemplo algumas implementações mais comuns como o PGCluster, DRBD, Slony, pgpool-ii, Bucardo, etc. Apesar de possuir diversas soluções, nenhuma delas funciona da mesma forma que o Oracle RAC. 47

49 MERCADO DE TRABALHO O PostgreSQL está entre os bancos de dados gratuitos mais utilizados no mercado, porém se comparado aos bancos pagos ainda está muito distante do Oracle. Anúncios de vagas de trabalho não são muito comuns, mas mesmo assim podem existir, pois demoram a ser preenchidas devido à falta de profissionais qualificados. Não há certificação oficial endossada pelo PostgreSQL até o momento, o que existe são certificações não oficiais fornecidas por algumas empresas como a Enterprisedb e outras menos conhecidas. ANÁLISE TÉCNICA a) A flexibilidade e leveza do PostgreSQL permite sua execução até mesmo em videogames ou em outra plataforma. Ele pode ser instalado embarcado junto com a aplicação e executado de forma transparente ao cliente. De forma simples e intuitiva o PostgreSQL pode ser instalado em qualquer máquina em questões de segundos, sendo configurado em poucos minutos, dispensando inclusive a documentação. Comandos DDL (Data Definition Language) como por exemplo criar e renomear bases, são operações quase instantâneas. Há ainda o terminal de trabalho psql, semelhante ao SQL*Plus, porém muito mais simples de usar. b) O particionamento no PostgreSQL é complexo e possui alguns problemas, porém ainda possui muitas vantagens em relação ao Oracle. O PostgreSQL consegue particionar uma tabela com o sistema em execução, de forma segmentada e flexível, e também realizar o expurgo de uma partição utilizando o DROP sem exigir que as FKs (Foreign Keys) relacionadas sejam desabilitadas. 48

50 c) O PostgreSQL possui embutido a PL (Procedure Language) nativa da linguagem C possibilitando a manipulação dos dados armazenados através de camadas ODBC e JDBC, além do PL/pgSQL, baseado no PL/SQL do Oracle. Ainda é possível desenvolver aplicações complexas para a manipulação de dados armazenados utilizando as linguagens mais comuns como PL/Python, PL/PHP, PL/Java, PL/Perl, PL/sh e até as mais específicas como PL/R, PL/LOL, etc. d) O FDW (Foreign Data Wraper) é semelhante ao famoso e oneroso Gateway da Oracle, porém trata-se de uma opção mais simples, robusta e flexível. Sua infraestrutura permite que o PostgreSQL se comunique com diversas tecnologias distintas, e também permite que com um trabalho de poucas horas em C, seja criado um novo conector para diversas situações. e) Há muitos tipos de dados no PostgreSQL, como por exemplo enum, arrays, geométricos, tipos de intervalo, hstore, etc. Todos definidos de acordo com a maioria dos bancos de dados e os padrões ISO. No Oracle não há tipos de dados como Integer, Boolean ou Time, comuns na maioria dos bancos de dados. Seus formatos de data são bem confusos e o campo do tipo Date guarda data e hora, o tipo Interval se subdivide em dois subtipos Year To Month e Day To Second. Apesar do Oracle possuir uma variedade maior de dados dentro do PL/SQL e SQL puro, eles não existem para armazenar em tabelas e serem utilizados. f) No PostgreSQL os comandos DDL como por exemplo create, drop e alter são transacionais, o que permite realizar um rollback a qualquer momento. Já no Oracle os comandos DDL geram um commit implícito, o que dificulta o deploy de novos objetos e algumas rotinas mais complexas. CUSTO/BENEFÍCIO 49

51 O valor a ser investido em uma solução de banco de dados costuma ser uma das principais características (ou até mesmo a característica principal) analisada pela diretoria em algumas empresas. Apesar do PostgreSQL ser totalmente gratuito, é importante considerar que existe custos com treinamento e suporte em qualquer banco de dados. No PostgreSQL esse valor é muito menor que nos bancos de dados comerciais, incluindo todo o ecossistema de suporte, cursos, ferramentas terceiras e até mesmo o hardware. CASOS DE SUCESSO As empresas que utilizam o banco de dados PostgreSQL são inúmeras e de diversos tamanhos e seguimentos no mundo inteiro. Logo abaixo é fornecida uma breve citação de dois casos de uso no Brasil: O primeiro caso é a Caixa Econômica Federal (CEF), criada em 1861, sendo uma empresa 100% pública, atua no setor bancário e também é o agente responsável pelos programas sociais do Governo Federal como o Fundo de Garantia do Tempo de Serviço (FGTS), o Programa de Integração Social (PIS), o Seguro-Desemprego, o Bolsa Família e unidades lotéricas. Utilizando a tecnologia Java EE a Caixa precisava decidir qual infraestrutura apresentava melhor relação custo/benefício para executar esta aplicação. Através de um teste de benchmark foram consideradas três plataformas já existentes em seu ambiente de TI: Plataforma alta: zseriesibm - zos - DB2 Websphere; Plataforma intermediária: Sparc-Solaris-Oracle-SJSAS; Plataforma baixa: x86-linux- PostgreSQL-JBoss. A solução apresentada pela empresa 4Linux foi escolhida, ocorrendo a criação da infraestrutura do ambiente multicanal com sistema Operacional Linux, servidor de aplicação JBoss, monitoramento do ambiente com Zabbix e banco de dados PostgreSQL. 50

52 Ao modernizar seu sistema de autoatendimento a Caixa passou a suportar milhões de transações por dia com o banco de dados PostgreSQL, obtendo maior economia no ambiente (Mainframes IBM) e banco de dados, além de um maior domínio sobre os dados e negócios, já que as operações eram terceirizadas. O ambiente Multicanal atende mais de ATMs, picos de de transações bancárias e sociais por dia. Passam pelo multicanal mais de R$ 1 bilhão por mês. O banco de dados PostgreSQL - com mais de de transações de banco de dados por dia - passou a ser uma alternativa ao banco de dados Oracle e DB2 dentro da Caixa. "Aqui na Caixa Econômica Federal, usamos o PostgreSQL em ambientes financeiros de importância crítica porque ele tem a qualidade para suportar as nossas operações," disse Clarice Coppetti, Vice Presidente para a área IT, Caixa Econômica Federal. O segundo caso é a Companhia do Metropolitano de São Paulo (Metrô-SP), com quatro linhas em operação e uma rede de 58 km e 52 estações, possui sua economia mista vinculada à Secretaria de Estado dos Transportes Metropolitanos (STM). Seu parque tecnológico continha mais de 4800 empregados que acessavam o correio eletrônico web, 3000 empregados ainda acessavam o correio do mainframe, quase 5000 equipamentos de informática para apoio à gestão técnica, administrativa e gerencial, mais de 80 diferentes aplicações voltadas ao suporte à gestão rede corporativa Windows-NT em baixa plataforma com mais de 1700 pontos ativos, permitindo também acesso ao mainframe (parque de 1800 micros e 96 servidores). Para alcançarem as metas ações conjuntas entre a Dextra, empresa vencedora da licitação, e o Metrô foram necessárias. Houve treinamento de administradores de banco de dados (DBAs) para o gerenciamento do ambiente PostgreSQL e para o uso de recursos do projeto, além de palestras de aculturamento, criação de lista de respostas às perguntas mais frequentes (FAQ) sobre o PostgreSQL, facilidades de acesso aos dados replicados, apoio ao desenvolvimento e migração de aplicações, definição de uma interface amigável de acesso a dados e uso do software livre. 51

53 A partir de um projeto para implantação de um sistema gerenciador de banco de dados, em 2001, o Metrô-SP aderiu ao software livre onde o desafio inicial da implantação abrangia a validação efetiva dos recursos do sistema PostgreSQL e uma mudança cultural nos processos de desenvolvimento local. E cerca de seis anos depois, com os desafios iniciais já vencidos e com o sistema totalmente implantado e operando, a companhia avalia a decisão e os resultados do projeto como positivos. O sucesso do projeto PostgreSQL se reflete na aderência à diretriz do governo do Estado de São Paulo na adoção de softwares livres, diz a coordenadora de TI do Metrô-SP, Maria Cecília Serapião. Ela classifica a solução como abrangente e de baixo custo, e ressalta que tem possibilitado uma economia de US$ 990 mil em licenças de sistemas de banco de dados proprietários e garante que o PosgreSQL não é uma apenas uma segunda opção aos sistemas proprietários. 52

54 7 TESTE A principal referência quando se trata de testes de desempenho de sistemas comerciais é o Transaction Processing Performance Council (TPC), uma organização sem fins lucrativos que divulga dados objetivos de desempenho verificáveis para a indústria. Seu website pode ser acessado no seguinte endereço de internet: Há diversos tipos de testes desenvolvidos pelo TPC, como por exemplo o TPC-H indicado para ambientes OLAP, o TPC-C voltado para ambientes do tipo OLTP, o TPCC-C3SL semelhante ao TPC-C com alguns recursos diferenciais, entre outros. Alguns estudos comparativos de desempenho, exibem resultados contrários e tendenciosos, fazendo com que os mesmos sejam contestados. Existe o fato de que muitos dos testes realizados por alguma instituição fornecedora de soluções possa ser patrocinado pela própria marca testada. O ideal é que os testes comparativos de desempenho sejam produzidos através de uma série variada de benchmarks, o que algumas vezes não é possível devido a incompatibilidade ou limitação em relação a sua utilização para diversas configurações de arquiteturas. Em muitos casos os benchmarks são desenvolvidos especificamente para um determinado SGBD e adaptado as suas características. Uma ferramenta direcionada a um determinado SGBD pode apresentar problemas pois impossibilita sua utilização na avaliação de diferentes SGBDs, além de fazer com que a carga de trabalho possa ser irreal. Otimizações podem ser implementadas para atender certos requisitos do próprio SGBD, por exemplo, no caso de stored procedures o código seria compilado, otimizado e guardado na memória do SGBD e isso poderia distorcer os resultados da avaliação. Outra dificuldade em testar bancos de dados comerciais, como o Oracle por exemplo, é a existência de uma restrição conhecida como a cláusula DeWitt, disponível nos contratos e nos termos de download (Figura 10), ela torna o produto não passível de benchmark, proibindo a realização dos testes e sua publicação sem a prévia autorização do fabricante. Em razão disso, muitos benchmarks são 53

55 desencorajados o que tem resultado em uma escassez de testes comparativos de desempenho de sistemas proprietários. Figura 10 - OTN License Agreement for Oracle FONTE: (ORACLE, 2011) Desta forma, com intuído de respeitar os termos disponibilizados na documentação do Oracle, os resultados referentes aos seus testes são suprimidos neste trabalho. A realização de testes de bechmarks não são o foco deste trabalho, o que ainda demandaria hardware robusto, horas de execução, grandes volumes de dados, simulação multiusuário, além de ajustes finos e configurações bem definidas. O mais apropriado é que esse tipo de tarefa seja realizada em um trabalho específico sobre o tema. O presente trabalho tem como meta mostrar alguns conceitos sobre estes bancos, e apresentar algumas características de desempenho através de testes simples utilizando a linguagem SQL em um sistema computacional comum a todos, tanto no quesito hardware como no sistema operacional através de consulta, inserção e exclusão. O equipamento utilizado nos testes é um laptop Dell com processador Intel core i5 2.53Ghz (4 núcleos), 4GB de memória RAM e disco IDE de 500GB. Foram 54