Embed Size (px)
Citation preview
CENTRO UNIVERSITÁRIO DE ARARAQUARA - UNIARA
MBA EM GESTÃO DE BANCO DE DADOS ORACLE
JULIANO PARRO
ORACLE VS POSTGRESQL
ARARAQUARA/SP
2015
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
AGRADECIMENTOS
A minha família por me apoiar em todos os momentos. A Deus por permitir este momento.
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)
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.
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.
LISTA DE FIGURAS
Figura 1 - Sistema Gerenciador de Banco de Dados ..................................... 14
Figura 2 - Componentes de um SGBD .......................................................... 16
Figura 3 - Processo de levantamento e análise de requisitos. ....................... 19
Figura 4 – Teorema CAP. .............................................................................. 22
Figura 5 – Sistemas OLTP e OLAP em DW. ................................................. 25
Figura 6 - Oracle Exadata Database Machine X5-2 ....................................... 30
Figura 7 - Oracle Database Appliance X5-2 ................................................... 30
Figura 8 - HA Database Ready SX2 – Frente ................................................ 42
Figura 9 - HA Database Ready SX2 – Verso ................................................. 42
Figura 10 - OTN License Agreement for Oracle ............................................. 54
LISTA DE TABELAS
Tabela 1 – Modelos de dados ........................................................................ 22
Tabela 2 - Ambientes de teste ........................................................................ 55
Tabela 3 - Simples comandos para testes ..................................................... 56
Tabela 4 - Resultado dos testes ..................................................................... 57
LISTA DE ABREVIATURAS E SIGLAS
ACID Atomicidade, Consistência, Isolamento e Durabilidade
ANSI American National Standards Institute
ASM Automatic Storage Management
BASE Basically Available, Soft state, Eventually consistent.
BI Business Intelligence
CAP Consistency, Available, Partition tolerance
CPU Central Processing Unit
CRM Customer Relationship Management
DBA Database Administrator
DBMS Database Management System
DCL Data Control Language
DDL Data Definition Language
DM Data Mining
DML Data Manipulation Language
DW Data Warehouse
ERP Enterprise Resource Planning
ETL Extraction Transform Load
HA High Availability
NOSQL Not Only SQL
ODA Oracle Database Appliance
ODBC Open Database Connectivity
OLAP Online Analytical Processing
OLTP Online Transaction Processing
PIT Point in Time Recovery
RAC Real Application Clusters
RAM Random Access Memory
RDBMS Relational Database Management System
SGBD Sistema de Gerenciamento de Banco de Dados
SGBDR Sistema de Gerenciamento de Banco de Dados Relacional
SLA Service Level Agreement
SO Sistema Operacional
SQL Structured Query Language
TCL Transaction Control Language
SUMÁRIO
1 INTRODUÇÃO ............................................................................................. 11
1.1 OBJETIVO ............................................................................................ 12
1.2 JUSTIFICATIVA .................................................................................... 12
2 SISTEMA DE GERENCIAMENTO DE BANCO DE DADOS ....................... 14
3 LEVANTAMENTO DE REQUISITOS ........................................................... 18
4 TIPOS DE AMBIENTE ................................................................................. 21
4.1 TEOREMA CAP .................................................................................... 21
4.2 ACID/BASE ........................................................................................... 23
4.3 OLAP/OLTP .......................................................................................... 24
4.4 NOSQL .................................................................................................. 26
5 ORACLE ...................................................................................................... 28
6 POSTGRESQL ............................................................................................ 40
7 TESTE ......................................................................................................... 53
8 CONCLUSÃO .............................................................................................. 58
REFERÊNCIAS BIBLIOGRÁFICAS ............................................................... 60
GLOSSÁRIO ................................................................................................... 63
11
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.
12
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
13
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.
14
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).
15
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:
16
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
17
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.
18
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;
19
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:
20
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.
21
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:
22
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:
Tabela 1 – Modelos de dados
NOME Modelo de dados
Cassandra Família de Colunas
CouchDB Documentos
DynamoDB Chave/Valor
HBase Família de Colunas
MongoDB Documentos
23
Oracle Relacional
PostgreSQL Relacional
Redis Chave/Valor
Riak 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
24
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
25
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).
26
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.
27
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.
28
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.
29
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.
30
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.
31
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.
32
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
33
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
34
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
35
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. É
36
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.
37
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
38
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.
39
“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 2.600 colaboradores diretos e 5.200 indiretos, atendendo 237 cidades com
29 mil pontos de vendas e indiretamente 16 cidades com 1.600 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.
40
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 1986.
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.
41
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.
42
Figura 8 - HA Database Ready SX2 – Frente
FONTE: (FUJITSU, 2014)
Figura 9 - HA Database Ready SX2 – Verso
FONTE: (FUJITSU, 2014)
43
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 e-mail. As inscrições nas listas de e-mail 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.
44
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.
45
É 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.
46
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
47
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.
48
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.
49
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
50
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.
51
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 27.000 ATMs, picos de 6.000.000 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 18.000.000 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.
52
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.
53
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: http://www.tpc.org. 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
54
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
55
criadas duas máquinas virtuais com configurações idênticas em hardware e
software, exceto pelos bancos de dados (Tabela 2).
Tabela 2 - Ambientes de teste
Hostname debian1 debian2
Sistema Operacional Debian 7.8 (wheezy) Debian 7.8 (wheezy)
Arquitetura SO X86_64 X86_64
Kernel 3.2.0-4-amd64 3.2.0-4-amd64
Interface Gráfica Gnome 3.4.2 Gnome 3.4.2
Processador Intel i5 m460 2.53 Ghz (1 core) Intel i5 m460 2.53 Ghz (1 core)
Memória RAM 1024MB 1024MB
Memória SWAP 2845MB 2845MB
Disco Rígido 50GB 50GB
Banco de Dados Oracle 11g Express 11.2.0.2.0, 64 bit PostgreSQL 9.4.1, 64-bit
FONTE – Elaborada pelo autor
Alguns bancos de dados podem levar vantagem em relação ao outro se
considerar o ambiente no qual é instalado, plataforma utilizada, SO, hardware,
kernel, parâmetros e principalmente as configurações efetuadas no início da
implantação e os ajustes realizados no decorrer do seu uso. As configurações dos
bancos de dados foram mantidas da forma mais próxima do padrão de fábrica. Os
limites físicos de hardware suportado pelos SGBDs não foram ultrapassados,
evitando assim que uma configuração superior de hardware favoreça algum dos
sistemas.
Outro fator importante é que todos os comandos foram realizados da forma
mais semelhante possível em ambos os SGBDs, buscando não beneficiar nenhum
SGBD na realização dos testes e obter resultados imparciais. No momento em que
um SGBD é testado, o outro não é habilitado para não interferir no desempenho do
primeiro, antes de realizar o teste em um determinado banco de dados, o laptop é
reiniciado e apenas sua respectiva máquina virtual é ligada.
56
Apesar do Sistema Operacional ser iniciado em modo gráfico, os simples
comandos a seguir (Tabela 3) são executados através de um terminal em modo
texto utilizando a ferramenta psql com o tempo monitorado pelo comando “\timing”
do PostgreSQL, no Oracle é utilizado o sqlplus e o tempo é monitorado pelo
comando “set timing on”.
Tabela 3 - Simples comandos para testes
ORACLE POSTGRESQL DESCRIÇÃO
CREATE TABLE teste ( numeros INT NOT NULL );
CREATE TABLE teste ( numeros INTEGER NOT NULL );
Cria uma tabela chamada “teste” com uma coluna do tipo inteiro chamada “números" e não permite valores nulos.
DECLARE v_numeros INT; BEGIN FOR x IN 100000..999999 LOOP INSERT INTO teste (SELECT DBMS_RANDOM.VALUE(100000,999999) FROM DUAL); END LOOP; COMMIT; END;
INSERT INTO teste ( SELECT generate_series(100000, 999999) );
Insere novecentos mil registros numéricos com seis dígitos cada na coluna “números” na tabela “teste”.
SELECT COUNT(numeros) FROM teste;
SELECT COUNT(numeros) FROM teste;
Realiza a contagem dos registros inseridos.
SELECT numeros FROM teste; SELECT numeros FROM teste; Exibe os registros inseridos.
SELECT COUNT(*) SEGMENTS, ROUND(SUM(BYTES)/1024/1024,2) MB FROM USER_SEGMENTS;
SELECT PG_SIZE_PRETTY(PG_TOTAL_RELATION_SIZE('teste'));
Mede o tamanho da tabela “teste” em megabytes.
DROP TABLE teste; DROP TABLE teste; Apaga a tabela “teste” e todo o seu conteúdo.
FONTE – Elaborada pelo autor
É importante ressaltar que os resultados dos testes realizados refletem o
ambiente de pesquisa no qual os bancos de dados foram implantados com o
objetivo apenas de testes. Sendo assim, seus resultados não podem ser levados em
consideração como padrão para outro tipo de ambiente ou aplicação.
57
Deve ser levado em consideração que é possível ganhar desempenho em
cada banco de dados pois eles disponibilizam recursos que se aplicados de forma
diferente do padrão de fábrica podem ser mais eficientes.
A Tabela 4 exibe os resultados dos testes apresentados em segundos,
obtidos através dos comandos ilustrados na Tabela 3 mostrada anteriormente.
Tabela 4 - Resultado dos testes
DESCRIÇÃO ORACLE POSTGRESQL
Tempo de criação da tabela “teste”. *00.34 seg 0,18 seg
Tempo para inserir 900 mil registros numéricos de 6 dígitos cada.
*149.116 seg 2,98 seg
Tempo para contar os registros da tabela “teste”. *00.70 seg 0,2 seg
Tempo de consulta para disponibilizar os registros. *25.12 seg 0,41 seg
Tamanho em megabytes da tabela “teste” populada. *11 MB 31 MB
Tempo de exclusão da tabela “teste” e seus registros. *03.06 seg 0,07 seg
FONTE – Elaborada pelo autor
* Resultados suprimidos em respeito ao contrato de licença Oracle.
É notável que neste simples ambiente de testes com pouco volume de dados
e transações o Oracle consome muitos recursos tornando a máquina mais lenta, sua
utilização também é mais complexa, porém a compressão de armazenamento se
mostra bem superior ao PostgreSQL. Os resultados são surpreendentes e mostram
que para conhecer realmente um banco de dados não basta apenas considerar o
que é dito ou escrito por outras pessoas, mas é necessário testá-lo e obter
conclusões próprias.
58
8 CONCLUSÃO
Ambos são ótimos bancos de dados e cada um possui suas vantagens e
desvantagens. Do ponto de vista técnico, sistemas de gerenciamento de bancos de
dados podem diferir amplamente, e a organização das informações internamente
pode afetar a rapidez e a flexibilidade da extração das informações.
Os bancos de dados Open Source (PostgreSQL) e comerciais (Oracle)
podem ser escalonáveis e utilizados em aplicações de alta escalabilidade e
desempenho. O que geralmente diferencia uma solução comercial é a quantidade de
recursos oferecidos, que são maiores em um banco Oracle, por exemplo, do que no
banco PostgreSQL. Além disso, a Oracle oferece uma pilha de soluções integradas,
enquanto no PostgreSQL é necessário configurar e integrar tudo "manualmente", o
que pode gerar custos às vezes elevados com poucos benefícios.
Para as empresas a questão de custo-benefício é muito importante, por
exemplo, possuir um suporte técnico que transmita a "segurança" de que o produto
vai funcionar é um diferencial valioso. Quando um sistema gratuito não funciona, ele
é considerado mais caro do que um sistema pago que funciona. Portanto, adquirir
uma licença do Oracle é também adquirir a “garantia” de que bugs serão
prontamente corrigidos e as dúvidas serão sanadas rapidamente, de acordo com
SLA estabelecido em contrato.
Essa cultura proprietária é comum em muitas empresas, porém grandes
corporações de TI como o Google por exemplo, entre outras, geralmente criam e
apoiam novas tecnologias Open Source, pois possuem a mão-de-obra e os recursos
necessários para criar uma infraestrutura própria que suporte suas necessidades, e
inclusive utilizam bancos NoSQL ou mesmo SQL em clusters para prover muitos de
seus dados. Essas gigantes de TI possuem a vantagem de contar com um
engenheiro especializado para lidar com os problemas das ferramentas dentro da
própria empresa, entretanto, essa não é uma opção viável para a maioria das
empresas.
Empresas com cultura Open Source dificilmente adotam sistemas
proprietários, e o inverso também ocorre. Esse comodismo, aliado a falta de
59
conhecimento avançado em tecnologias concorrentes mais o medo de novos
desafios, fazem com que muitas empresas permaneçam estagnadas em um único
tipo de sistema sem evolução e acreditando que uma migração não possa atender
as suas necessidades. Outro fator que costuma desencorajar a migração de uma
tecnologia é o fato de haver um grande legado de antigas informações em tecnologias
conhecidas e utilizadas há muitos anos, o que dificulta e torna arriscado a manipulação
de todos os dados.
Para simplificar na escolha do SGBD um pensamento análogo a uma escolha
automobilística pode ser utilizado. Imagine por exemplo ter que escolher entre dois
veículos conhecidos, uma Ferrari e um Fusca. A Ferrari pode ser considerada
superior ao Fusca em muitos os aspectos como tecnologia, conforto, velocidade,
entre outros, mas seu valor financeiro é muito alto. Porém em um cenário onde seja
necessário trafegar em uma via com pavimentação precária, como em muitos
lugares do Brasil, ou mesmo para ir a fazenda através de uma via não pavimentada
e cheia de imperfeiçoes, a Ferrari não seria recomendada, pois ela não foi projetada
para esse tipo de situação e sua suspensão provavelmente seria danificada
rapidamente.
De forma semelhante os bancos de dados podem ser analisados, por
exemplo, possuir um farto orçamento disponível para investir em uma nova
tecnologia permite a escolha de uma solução com maior custo financeiro, mas deve
ser considerado se é a escolha ideal para o tipo de ambiente onde será implantado.
É importante lembrar que mesmo o melhor banco pode apresentar problemas em
uma “via” precária, por exemplo, caso o ambiente possua falhas de energia,
profissionais não qualificados, intermitências na rede ou internet, etc.
60
REFERÊNCIAS BIBLIOGRÁFICAS
4Linux. Caixa Econômica Federal - Suportando milhões de transações por dia com o banco de dados PostgreSQL. Disponível em: <http://www.4linux.com.br/case/caixa-economica-federal-suportando-milhoes-de-transacoes-por-dia-com-o-banco-de-dados> Acesso em: 07 mai. 2015.
CÔRTES; COSTA, S.; LUCENA, C. J. P. Um Framework de Regras Ativas para Sistemas de Gerência de Banco de Dados Distribuído. 2001. Disponível em: <ftp://ftp.inf.puc-rio.br/pub/docs/techreports/01_16_cortes.pdf> Acesso em: 01 de abr. 2015.
DATAWAREHOUSE4U. OLTP vs. OLAP. 2010. Disponível em: < http://datawarehouse4u.info/OLTP-vs-OLAP.html> Acesso em 04 de abr. 2015.
DATE, C. J. Introdução aos Sistemas de Banco de Dados. 8ª edição. Editora Campus, 2004.
ELMASRI, R.; NAVATHE, S.B. Fundamentals of Database Systems, 3rd Edition. Addison-Wesley, 2000.
FUJITSU. Fujitsu Enhances Lineup of Vertically Integrated Database Systems. 2014. Disponível em: <http://www.fujitsu.com/global/about/resources/news/press-releases/2014/0228-02.html> Acesso em: 28 mar. 2015.
GRAY, J. Database and Transaction Processing Performance Handbook. Chapter 1. Morgan Kaufmann Publishers. 1993.
MACFADDEN, G. 21 NoSQL Innovators to Look for in 2020. 2013. Disponível em: <http://wikibon.org/wiki/v/21_NoSQL_Innovators_to_Look_for_in_2020> Acesso em: 06 mar. 2015.
ORACLE. Coca-Cola Refrescos Bandeirantes atualiza infraestrutura com Oracle Database Appliance. 2014. <http://www.oracle.com/br/corporate/press/pr-br-08-aug-2014-2267549-ptb.html> Acesso em: 27 mar. 2015.
61
ORACLE. CPFL acelera processamento de informações financeiras e fiscais com tecnologia Oracle. 2015. Disponível em: <http://www.oracle.com/br/corporate/press/pr-br-28th-jan-2015-2420510-ptb.html> Acesso em: 22 abr. 2015.
ORACLE. Oracle Database Appliance X5-2. Disponível em: <https://www.oracle.com/engineered-systems/database-appliance/index.html> Acesso em: 10 mar. 2015.
ORACLE. Oracle Exadata Database Machine X5-2. Disponível em: < https://www.oracle.com/engineered-systems/exadata/database-machine-x5-2/index.html> Acesso em: 10 mar. 2015.
ORACLE. Oracle Technology Network Developer License Terms for Oracle Database Express Edition. 2011. Disponível em: <http://www.oracle.com/technetwork/licenses/database-11g-express-license-459621.html> Acesso em: 10 mai. 2015.
POSTGRESQL. FAQ/pt. 2009. Disponível em: <https://wiki.postgresql.org/wiki/FAQ/pt-br> Acesso em: 18 abr. 2015.
RODRIGUES, F. T.; Oracle X PostgreSQL – Parte I: Semelhanças. 2015. Disponível em: <http://savepoint.blog.br/oracle-x-postgresql-parte-i-semelhancas/> Acesso em: 22 mar. 2015.
SADALAGE, P. J.; FOWLER, M. NoSQL Essencial Um Guia Conciso para o Mundo Emergente da Persistência Poliglota. Editora Novatec, 2013.
SILBERSCHATZ, A. Sistema de banco de dados. Rio de janeiro: Elsevier, 2006. Traduzido por Daniel Vieira.
SOFTWARELIVRE; INSIDE, T.I.; Metrô-SP economiza US$ 900 mil com uso de software livre. Disponível em: <http://www.softwarelivre.gov.br/noticias/News_Item.2007-03-28.3442> Acesso em: 07 mai. 2015.
62
SOMERVILLE, I. Engenharia de software. 6° ed. Tradução Maurício de Andrade. São Paulo: Ed Addison-Wesley, 2003.
W3RESOURCE. NoSQL. 2015. Disponível em: <http://www.w3resource.com/mongodb/nosql.php> Acesso em: 06 mar. 2015.
YAMADERA, O. M.; Software Livre no Metrô-SP: Casos de Sucesso. 2004. Disponível em: <ftp://ftp.saude.sp.gov.br/Apresentacoes/Metro%20SP%2017%20de%20fevereiro%20de%202004.pdf> Acesso em: 07 mai. 2015.
63
GLOSSÁRIO
ALTER TABLE: Comando SQL responsável por altera uma tabela ou esquema.
APPLIANCE: Dispositivo de hardware com software integrado (firmware),
especificamente projetado para fornecer um recurso de computação específico,
geralmente são "fechados e selados".
BENCHMARK: Avaliação de performance de um hardware ou software por meio de
testes padronizados.
BRAINSTORMING: Tempestade cerebral ou tempestade de ideias. Técnica de
dinâmica de grupo desenvolvida para explorar a potencialidade criativa de um
indivíduo ou de um grupo (criatividade em equipe) colocando-a a serviço de
objetivos pré-determinados.
BUSINESS INTELLIGENCE: Inteligência empresarial. Processo de coleta,
organização, análise, compartilhamento e monitoramento de informações que
oferecem suporte a gestão de negócios. Conjunto de técnicas e ferramentas para
auxiliar na transformação de dados brutos em informações significativas e úteis a fim
de analisar o negócio.
CHECK: Restrição que verifica ou checa uma condição booleana.
CLUSTER: Conjunto de computadores interligados trabalhando como se fossem
uma única máquina.
COMMIT: Ato ou comando responsável pela efetivação de uma transação.
CONSTRAINT: Mecanismo de restrições que assegura que condições sejam
satisfeitas para efetivar uma alteração em um banco de dados.
DEFAULT: No âmbito de bancos de dados, é o comportamento padrão de um
campo que não tenha um valor explícito definido.
FOREIGN KEY: Um ou mais campos que identificam uma referência de uma tabela
com outra.
HARDWARE: Dispositivos físicos e equipamentos em tecnologia.
64
HIGH AVAILABILITY: Alta Disponibilidade
NULL: Valor nulo ou inexistente.
OPEN SOURCE: Código aberto, diferente de software livre.
ORACLE: Empresa de tecnologia e sistema de gerenciamento de bancos de dados.
PARENT: No contexto de bancos de dados, refere-se a tabela pai.
PRIMARY KEY: Um ou mais campos que identificam um registro dentro de uma
tabela.
ROLL BACK: Ato ou comando de reverter os efeitos de uma transação.
SAVE POINT: Ponto inicial ou predefinido de uma transação para restauração em
caso de erro.
SOFTWARE: Programa de computador.
SQL: Linguagem de armazenamento, gerenciamento e recuperação de dados.
STAKEHOLDERS: Parte interessada, compreende todos os envolvidos em um
processo, que pode ser de caráter temporário (como um projeto) ou duradouro
(como o negócio de uma empresa ou a missão de uma organização).
WHERE: Cláusula SQL responsável por filtrar registros afetados ou buscados e uma
determinada instrução.
WORKSHOP: Reunião de grupos de pessoas interessados em determinado projeto
ou atividade para discussão sobre o que lhes interessar e quiserem.
