tcc anderson v04 (reparado)
TRANSCRIPT
CENTRO UNIVERSITÁRIO DE JOÃO PESSOA – UNIPÊ
PRÓ-REITORIA DE ENSINO DE GRADUAÇÃO
CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO
ANDERSON GUIMARÃES MARQUES
Cassandra x Oracle:
uma análise prático-comparativa aplicada ao sistema de gerenciamento otimizado da
distribuição elétrica
João Pessoa – PB
2012
ANDERSON GUIMARÃES MARQUES
Cassandra x Oracle:
uma análise prático-comparativa aplicada ao sistema de gerenciamento otimizado da
distribuição elétrica
Monografia apresentada ao Curso de Bacharelado
em Ciência da Computação do Centro Universitário
de João Pessoa – Unipê, como pré-requisito para a
obtenção do grau de Bacharel em Ciência da
Computação, sob a orientação da Profa. Ms.
Ludmila de Almeida Pedrosa.
João Pessoa – PB
2012
ANDERSON GUIMARÃES MARQUES
Cassandra x Oracle:
uma análise prático-comparativa aplicada ao sistema de gerenciamento otimizado da
distribuição elétrica
Monografia apresentada ao curso de Bacharelado em Ciência da Computação do Centro
Universitário de João Pessoa – UNIPÊ, como pré-requisito para a obtenção do grau de
Bacharel em Ciência da Computação, apreciada pela banca examinadora composta pelos
seguintes membros:
Aprovada em: __/__/__
BANCA EXAMINADORA
___________________________________________________________
Profa Ms. Ludmila de Almeida Pedrosa
Orientadora - UNIPÊ
___________________________________________________________
Profa Ms. Fabiana Nascimento
Examinador - UNIPÊ
___________________________________________________________
Profa Ms. Francisco Porfírio
Examinador - UNIPÊ
Dedico este trabalho aos meus pais, Orlando
e Penha Marques, e minha querida esposa,
Wínea Vasconcelos, pelo imenso suporte,
dedicação e disponibilidade.
AGRADECIMENTOS
O primeiro requisito para o sucesso é a
habilidade de aplicar incessantemente
suas energias físicas e mentais a
qualquer problema, sem se cansar.
Thomas Edison
RESUMO
A modelagem dos bancos de dados tem passado, durante os últimos anos, por relevantes
transformações, principalmente quando tratamos de aplicações cujo volume de dados
ultrapassa perspectivas nunca vistas antes. Os bancos de dados relacionais tiveram papel
fundamental durante esse processo de mudança, por serem amplamente utilizados em
praticamente todos os tipos de sistemas nas últimas décadas. Entretanto, esse papel vem
dando lugar a mais um protagonista, os sistemas de gerenciamento de dados capazes de atuar
em cenários de alta escalabilidade e disponibilidade das informações. Essa nova classe de
banco de dados, conhecida por NoSQL, vai de encontro às muitas ideias do modelo relacional
e vem sendo citado na literatura científica (livros, artigos e eventos) e técnica (blogs, sites e
revistas de divulgação tecnológica), além de estar sendo adotado, de maneira concreta, por
gigantes da TI. Neste trabalho estudaremos as motivações que levaram as criações desses
novos conceitos e o estado da arte dessa nova tecnologia. Também será realizada uma análise
comparativa entre um SGBD relacional e um NoSQL aplicados ao Sistema de Gerenciamento
Otimizado da Distribuição – SIGOD, sistema utilizado atualmente no Grupo Energisa. Nessa
comparação serão utilizados bancos de dados Oracle e Cassandra.
Palavras-chave: NoSQL. Escalabilidade. Banco de Dados.
ABSTRACT
The modeling of databases has experienced over the past years, significant changes,
especially when dealing with applications whose data volume exceeds perspectives never seen
before. The relational databases had an important role during this process of change, because
they are widely used in virtually all types of systems in recent decades. However, this role has
given rise to another protagonist, the data management systems capable of acting in scenarios
of high scalability and availability of information. This new class of database, known as
NoSQL, meets the many ideas of the relational model and has been cited in the scientific
literature (books, articles, and events) and technical (blogs, websites and magazines of
technology diffusion), and being adopted, practically, by IT giants. In this paper we study the
motivations that led the creations of these new concepts and state of the art of this new
technology. Also there will be a comparative analysis between a relational DBMS and a
NoSQL applied to the Management System Optimized Distribution - SIGOD, system
currently used in Energisa Group. In this comparison will be used Oracle databases and
Cassandra.
Keywords: NoSQL. Scalability. Database.
LISTA DE FIGURAS
Figura 1: Arquitetura Tradicional ........................................................................................... 20
Figura 2: Escalabilidade Horizontal ........................................................................................ 20
Figura 3: Esquema de Sharding .............................................................................................. 21
Figura 4: Sistemas distribuídos ACID .................................................................................... 23
Figura 5: BD Distribuído......................................................................................................... 24
Figura 6: Teorema de Brewer - CAP ....................................................................................... 25
Figura 7: Modelo Chave/Valor ............................................................................................... 28
Figura 8: Demonstrando o relacionamento de informações em grafos ................................... 30
Figura 9: Família de colunas dos usuários do Twitter ............................................................. 31
Figura 10: Tabela de dados ..................................................................................................... 31
Figura 11: Lista de Valores ..................................................................................................... 33
Figura 12: Mapa nome/valor ................................................................................................... 34
Figura 13: A estrutura de uma coluna ..................................................................................... 34
Figura 14: Column Familly ..................................................................................................... 34
Figura 15: Exemplo de column families .................................................................................. 35
Figura 16: Super Column Family ............................................................................................ 35
Figura 17: Keyspace ................................................................................................................ 36
Figura 18: Rede Peer-To-Peer ................................................................................................ 37
Figura 19: Evolução do desempenho no Cassandra ................................................................ 38
Figura 20: Diretório Datastax Community Edition ................................................................. 40
Figura 21: Comandos CQL ..................................................................................................... 40
Figura 22: Create Keyspace .................................................................................................... 40
Figura 23: Create Keyspace utilizando DCE .......................................................................... 41
Figura 24: CREATE TABLE .................................................................................................... 41
Figura 25: CREATE TABLE utilizando DCE .......................................................................... 41
Figura 26: Datastax Opscenter Edition - Modelagem ............................................................ 42
Figura 27: Insert e Select utilizando CQL ............................................................................... 43
Figura 28: Data Explorer ........................................................................................................ 43
Figura 29: Processo de envio e acompanhamento de OS's ..................................................... 45
Figura 30: Arquitetura do SIGOD ........................................................................................... 45
Figura 31: Interface do embarcado.......................................................................................... 46
Figura 32: Módulo de despacho .............................................................................................. 46
Figura 33: Interface de mapas ................................................................................................. 47
Figura 34: Diagrama de caso de uso ....................................................................................... 48
LISTA DE TABELAS
Tabela 1: Tabela Relacional .................................................................................................... 29
Tabela 2: Orientado a Documento ........................................................................................... 29
Tabela 3: Análise comparativa NoSQL ................................................................................... 32
Tabela 4: Diretórios do Cassandra .......................................................................................... 39
Tabela 5: Tipos de dados ......................................................................................................... 42
LISTA DE ABREVIATURAS E SIGLAS
ACID – Atomicidade, Consistência, Isolamento e Durabilidade.
API – Application Programming Interface.
BD – Banco de Dados
CAP – Consistency, Availability e Partition Tolerance
CQL – Cassandra Query Language
DCE – Datastax Comunity Edition
DDL – Data Definition Language
DML – Data Manipulation Language
ER – Entidade Relacionamento
GT – Gerenciador de Transações
GD – Gerenciador de Dados
GR – Gerenciador de Recuperação
HDFS – Hadoop Distributed File System
HQL – Hipertable Query Language
JSON – JavaScript Objetct Notation
NoSQL – Not Only SQL
ODBC – Open Database Connectivity
OLAP – Online Analytical Processing
OLTP – Online Transactional Processing
RDBMS – Relational Database Management System
SGBD – Sistema Gerenciador de Banco de Dados
SIGOD – Sistema de Gerenciamento Otimizado da Distribuição
SQL – Struct Query Language
TI – Tecnologia da Informação
XML – eXtensible Markup Language
YAML – Yet Another Markup Language
SUMÁRIO
1 I NTRODUÇÃO ................................................................................................................. 14
1.1 OBJETIVOS ...................................................................................................................... 15
1.1.1 Objetivo geral ................................................................................................................ 15
1.1.2 Objetivos específicos ..................................................................................................... 16 1.2 ORGANIZAÇÃO DO TRABALHO ................................................................................. 16
2 NOSQL: O QUE É E POR QUE UTILIZÁ-LO ............................................................. 17 2.1 CONTEXTO HISTÓRICO ............................................................................................... 17
2.2 OS DESAFIOS DOS BANCOS DE DADOS RELACIONAIS ........................................ 18
2.2.1 Escalabilidade e a Web 2.0 ............................................................................................ 19 2.3 GERENCIANDO TRANSAÇÕES E A INTEGRIDADE DOS DADOS ......................... 22
2.3.1 Sistemas distribuídos ACID ......................................................................................... 23 2.4 USANDO NOSQL NA NUVEM ...................................................................................... 26
2.5 PRINCIPAIS MODELOS DE ARMAZENAMENTO DE DADOS NOSQL................... 27
2.5.1 Key/value stores (chave/valor)....................................................................................... 27
2.5.2 Document databases (orientado a documentos) .......................................................... 28
2.5.3 Graph databases (orientado a grafo) ............................................................................ 29
2.5.4 Column oriented store (orientado a colunas) ............................................................... 30
2.6 CONSIDERAÇÕES DO CAPÍTULO ............................................................................... 31
3 CASSANDRA ..................................................................................................................... 33 3.1 O MODELO DOS DADOS NO CASSANDRA ............................................................... 33
3.2 ARQUITETURA ............................................................................................................... 36
3.3 DEFINIÇÃO E MANIPULAÇAO DOS DADOS ............................................................. 38
3.3.1 Diretórios do Cassandra ............................................................................................... 39
3.3.2 Comandos básicos de definição (DDL) ........................................................................ 40
3.3.3 Comandos básicos de manipulação (DML) ................................................................. 43
4 ESTUDO DE CASO .......................................................................................................... 44 4.1 DESCRIÇÃO DO SISTEMA DE GERENCIAMENTO OTIMIZADO DA
DISTRIBUIÇÃO – SIGOD ...................................................................................................... 44
4.1.1 Interface do sistema ...................................................................................................... 46
4.2 MODELAGEM E CENÁRIO ATUAL DO BANCO DE DADOS ................................... 47
4.3 DIFICULDADES DA APLICAÇÃO ................................................................................ 49
4.4 MAPEAMENTO DO BANCO RELACIONAL PARA O MODELO NOSQL ................ 49
4.5 ANÁLISE COMPARATIVA ............................................................................................ 49
5 CONSIDERAÇÕES FINAIS ............................................................................................ 49
REFERÊNCIAS...................................................................................................................... 50
14
1 I NTRODUÇÃO
O rápido crescimento dos sistemas Web e a necessidade de ter um conteúdo
orientado ao usuário tem provocado um significativo aumento no volume e no tipo de dado
gerado, manipulado, analisado e arquivado pelas aplicações. Esse conteúdo se caracteriza pela
facilidade e disponibilidade dos dados, e informações que sejam relevantes para o usuário.
Tais volumes de conjuntos de dados tem imposto novos desafios e oportunidades em torno do
armazenamento e da análise dos mesmos.
Paralelo a esse crescimento, os dados também têm se tornado, cada vez mais,
semiestruturados e esparsos, ou seja, apresentam uma representação estrutural heterogênea,
não sendo completamente não estruturados, nem estritamente tipados. Isso difere das
características mantidas por um BD relacional que apresenta esquemas pré-definidos e
estruturas homogenias em nível de atributos e tipos (string, date, etc.) [MELLO et al., 2000].
Dados Web se enquadram nessa definição de semiestruturados: alguns casos com
descrição uniforme (um catálogo de produtos), em outros algum padrão estrutural pode ser
identificado (documentos no formato de artigo), ou então não existem informações descritivas
associadas (um arquivo de imagem). Pode-se dizer que os dados semiestruturados são
representados no próprio dado, ou seja, auto-descritivos [MELLO et al., 2000]. De uma forma
geral, podemos citar como exemplo as páginas de sites de livrarias eletrônicas, referências
bibliográficas, catálogos eletrônicos, sites de previsão do tempo e outros. Dados desse tipo
são denominados semiestruturados.
As soluções para resolver tais diferenças entre as estruturas relacionais e
semiestruturadas, do ponto de vista do volume e da distribuição desses dados, remete a novos
tipos de banco de dados, os quais consistem no armazenamento orientado a coluna,
chave/valor, orientado a documentos, entre outras categorias. Coletivamente, eles têm sido
identificados como NoSQL (Not Only SQL), ou seja, não podemos definir essa expressão
como sendo de um único produto ou tipo. Ela representa uma classe de produtos e uma
coleção de conceitos de armazenamento e manipulação de dados. Entretanto, é preciso
mencionar que essa expressão passou por grandes discussões quanto ao seu significado. Nos
primeiros conceitos foram utilizadas expressões como “Não é SQL”, “Não RDBMS”, “Não
Relacional”, e definido como “NoRel”, por Carlo Strozzi em 1998 [STROZZI, 1998]. Mas,
em 2009 o termo NoSQL, expandido para “Not Only SQL”, introduzido por Eric Evans
15
durante evento de discussão de bancos de dados open source distribuídos, se estabeleceu nas
pesquisas referente a essa tecnologia.
De maneira geral, o termo NoSQL define os bancos de dados que apresentam, em
sua maioria, características não relacionais, distribuídos, de código aberto, escaláveis
horizontalmente, ausência de esquema ou esquema flexível, suporte a replicação e acesso via
API’s simples [DIANA; GEROSA, 2010].
Os atuais sistemas que se enquadram como NoSQL são bastante variados, cada
um deles com características diferentes. Diante disso, frequentemente, encontramos
dificuldades em decidir qual sistema utilizar para certa situação ou certo caso, ao qual
propomos uma solução com bancos de dados não relacionais. Serão abordadas neste trabalho
as principais categorias dos bancos de dados NoSQL, afim de se obter os critérios necessários
para tal decisão. Dentre elas foi selecionado uma para ser utilizada no estudo de caso que
analisará de forma prático-comparativa o Oracle (BD relacional) e o Cassandra (NoSQL).
Ambos servirão no armazenamento de dados do Sistema de Gerenciamento Otimizado da
Distribuição – SIGOD, utilizado, atualmente, pela empresa Energisa.
A escolha do SIGOD para o estudo de caso deste trabalho se deve ao fato dele
dispor de um ambiente perfeito para a análise de um banco de dados NoSQL, em especial, o
Cassandra, o qual será abordado mais adiante, e por utilizar dados de várias fontes e possuir
um grande volume de dados. Tal característica o enquadra na classe de sistemas corporativos
de grande porte, cujo volume de dados é geralmente medido em gigabytes, ou até mesmo
terabytes. A finalidade de um SGBD, nesse contexto, é simplificar e facilitar o acesso aos
dados, além de alcançar um dos principais fatores na satisfação do usuário com o sistema de
banco de dados que é o desempenho. Se o tempo de resposta de um sistema é muito longo,
consequentemente seu valor será diminuído. Com a análise será possível observar o
comportamento do Cassandra submetido ao mesmo ambiente que está submetido o BD
Oracle, bem como sua aplicabilidade em sistemas corporativos.
1.1 OBJETIVOS
1.1.1 Objetivo geral
Analisar comparativamente o banco de dados relacional Oracle e o não-relacional
Cassandra aplicados em um sistema de gerenciamento otimizado da distribuição elétrica, a
partir do estudo dos bancos de dados NoSQL.
16
1.1.2 Objetivos específicos
Fornecer os conceitos essenciais que atuam nas construções dos produtos NoSQL;
Realizar um estudo comparativo do desempenho dos bancos de dados Oracle e
Cassandra, que serão avaliados pelas ferramentas DataStax Community Edition,
JMeter, Benchmark Factory e YCSB. Poderão ser verificados fatores como uso do
processador, memória, disco, além de aspectos como performance, escalabilidade,
consistência e disponibilidade.
Desenvolver estudo de caso prático-comparativo entre bancos de dados NoSQL e
bancos de dados relacionais.
1.2 ORGANIZAÇÃO DO TRABALHO
Os capítulos apresentados neste trabalho dividem-se em tópicos e subtópicos,
conforme descrito a seguir.
O Capítulo 2 apresenta a aplicabilidade e a necessidade dos métodos NoSQL no
armazenamento de dados, bem como a compreensão dos seus conceitos e características.
Também serão abordados os principais modelos NoSQL de armazenamento de dados, assim
como uma breve comparação entre eles afim de justificar a sua escolha do Cassandra para o
estudo proposto.
O Capítulo 3 trás definições de modelagem, arquitetura e manipulação dos dados
utilizados pelo Cassandra.
No Capítulo 4 é descrito o estado atual do sistema de gerenciamento otimizado da
distribuição – SIGOD e realizado o estudo de caso a partir da utilização de um banco de dados
NoSQL, o Cassandra, comparando-o com o banco de dados relacional Oracle, atual banco de
dados do sistema.
O Capítulo 5 apresenta a conclusão e os trabalhos futuros pertinentes ao tema.
17
2 NOSQL: O QUE É E POR QUE UTILIZÁ-LO
Existem diferentes abordagens para os bancos de dados NoSQL, entretanto o que
eles tem em comum é o fato de não serem relacionais, ou seja, ao contrário dos BD
relacionais eles lidam com dados não estruturados tais como arquivos de texto, email,
multimídia, meios de comunicação social e grandes volumes de dados distribuídos. A
composição da Web é, basicamente, distribuída num grande conjunto de dados
semiestruturados, como páginas e websites, descritos em documentos HTML, o que expressa
pouco sobre seus conteúdos. Além de conteúdos multimídias, como imagens, sons e vídeos.
Alguns autores propõem que os dados extraídos da Web devam passar por
estruturação da sua natureza particular para em seguida armazená-los e manipulá-los em
bancos de dados relacionais [MELLO et al, 2000][MAGALHÃES et al, 2001]. Contudo, os
BD NoSQL surgem como soluções otimizadas, e favorecidas pelas características da Web, no
tratamento e gerenciamento dos dados de forma diferente das tradicionais [DIANA et al,
2010].
Antes de entrarmos em detalhes sobre os tipos e conceitos envolvidos, é
importante definirmos o contexto em que os bancos de dados NoSQL surgiram.
2.1 CONTEXTO HISTÓRICO
Os bancos de dados não relacionais não são uma novidade dentre as tecnologias
de armazenamento de dados, na verdade, o surgimento deles nos remete ao tempo em que as
máquinas computacionais foram inventadas. Eles têm existido desde os mainframes, em
locais especializados, e especificamente em locais de domínio – diretórios hierárquicos de
armazenamento, autenticação e credenciais de autorização. No entanto, o mundo NoSQL
ganha uma nova roupagem, e nasce em um momento importante da Web, com as aplicações
escaláveis, distribuídas e paralelas, e a computação nas nuvens.
Com o aumento, tanto na velocidade como na conectividade à Internet, os
usuários passam a ter exigências mais criteriosas quanto à disponibilidade dos dados e de
computação. Tais necessidades e mudanças que vem ocorrendo na Web proporcionam aos BD
relacionais seu próprio conjunto de problemas quando aplicados a grandes quantidades de
dados. Problemas estes relacionados à eficiência de processamento, paralelização eficaz,
escalabilidade e custos. [TIWARI, 2011], e que serão abordados na seção 2.2 com mais
detalhes.
18
Ao longo dos últimos anos a empresa Google tem se destacado na construção de
infraestruturas altamente escaláveis para seu motor de busca e outras aplicações, incluindo
Google Maps, Google Earth, Gmail, Google Finance e Google Apps [TIWARI, 2011]. Uma
das primeiras implementações de um sistema não relacional surgiu em 2004, quando a Google
lançou o BigTable, um banco de dados proprietário de alta performance que tinha como
objetivo promover maior escalabilidade e disponibilidade. A ideia central era justamente
flexibilizar a forte estruturação utilizada pelo modelo relacional [BRITO, 2010], ou seja,
construir uma infraestrutura escalável para processamento paralelo de grandes quantidades de
dados. E para isso se fez necessário a implementação de um sistema de arquivos distribuído,
um armazenamento de dados orientado a coluna de família (column-family-oriented), e um
sistema distribuído de coordenadas [CHANG et al, 2006]. Estas e outras estruturas serão
mais abordadas na seção 2.5, onde também serão apontados os principais produtos NoSQL
para cada método.
Sem entrar tanto na linha exata do tempo, ou na história de quem cunhou o termo
NoSQL, é necessário destacar o surgimento de uma alternativa open source, liderada pelo
Google, que lançou as bases para o rápido crescimento do NoSQL, que foi o Hadoop, seus
subprojetos, e seus projetos relacionados. Tal sucesso do Google ajudou a impulsionar os
conceitos de computação distribuída [TIWARI, 2011]. Algum tempo depois da Google
mostrar seus interesses no processamento paralelo escalável e no armazenamento de dados
não relacionais distribuídos, a empresa Amazon decidiu compartilhar um pouco da sua história
de sucesso, apresentando ideias de um conjunto de dados distribuídos altamente disponíveis e,
eventualmente consistentes, nomeando o projeto de Amazon Dynamo [TIWARI, 2011].
Com o aval do NoSQL de dois gigantes da Web vários novos produtos surgiram
neste espaço e muitos desenvolvedores começaram a usar seus métodos em suas aplicações,
empresas e corporações. Em menos de cinco anos os conceitos NoSQL e afins para
gerenciamento de dados tornaram-se grandes casos de uso em empresas bem conhecidas
como Facebook, Yahoo, eBay, IBM e muito mais, onde elas também tem contribuído com
código aberto e novos produtos para a comunidade [TIWARI, 2011].
2.2 OS DESAFIOS DOS BANCOS DE DADOS RELACIONAIS
Os desafios dos bancos de dados relacionais não estão direcionados apenas a um
produto ou sistema de gerenciamento, mas estende-se a toda sua classe, ou seja, está nas
características e nos métodos que o armazenamento de grandes volumes de dados na Web
19
vem formando. Conforme abordado no início deste capítulo, a Web é formada, na sua maioria,
por dados semiestruturados, enquanto que os RDBMS assumem uma estrutura bem definida
dos dados e baseia-se em pré-requisitos como inter-relações bem estabelecidas e
sistematicamente referenciadas. Esses bancos também pressupõem que os índices podem ser
consistentemente definidos em conjuntos de dados e que esses índices podem ser
uniformemente alavancados para uma pesquisa mais rápida e com um significativo ganho de
performance [TIWARI, 2011].
Os SGBDs relacionais proporcionam aos usuários processos de validação,
verificação e garantia da integridade dos dados, do controle de concorrências, da recuperação
de falhas, da segurança, do controle de transações, da otimização de consultas, etc.. Outra
característica importante do modelo relacional é o processo de normalização, que tem como
objetivo aplicar regras sobre as tabelas do banco de dados, a fim de garantir a estruturação do
projeto.
Todos esses recursos ajudaram a manter os SGBDs relacionais em posição de
destaque até então. Entretanto, não conseguiram impedir o surgimento de certos problemas,
principalmente devido ao crescimento acelerado dos volumes de dados presentes nos bancos
de certas organizações.
De maneira geral esses problemas estão concentrados na dificuldade em conciliar
tal modelo com a demanda por escalabilidade. Seus conceitos principais serão apresentados
com mais detalhes na seção a seguir.
2.2.1 Escalabilidade e a Web 2.0
Não é correto afirmar que os SGBDs relacionais não são escaláveis, mas o fato
que essa não é uma tarefa trivial. Vejamos, no esquema abaixo, uma demonstração de uma
aplicação Web evoluindo no volume de dados:
Na Figura 1 vemos uma arquitetura simples de uma aplicação Web. Com o
crescente aumento da massa de dados e à medida que o sistema passa a receber um número
maior de usuários, começam a surgir os primeiros problemas de escalabilidade. Nesse
momento, sem alterar a estrutura da referida figura, realizamos um upgrade no servidor,
aumentando memória, processador e armazenamento; tal técnica é conhecida como
Escalabilidade Vertical (scale up). Com essa técnica se mantêm os dados confiáveis e
concentrados num único nó, e utilizam-se as mesmas configurações no sistema. Contudo,
20
existe um limite de capacidade do equipamento e, por que não, do próprio orçamento durante
as mudanças.
Figura 1: Arquitetura Tradicional
Fonte: Próprio Autor
A segunda opção seria utilizar a técnica de Escalabilidade Horizontal (scale out),
aumentando o número de servidores Web, conforme demonstrado na Figura 2. Nesse formato
é possível alcançar níveis bem maiores de processamento dos dados, entretanto é um processo
bem mais trabalhoso e complexo. A escalabilidade vertical é tradicionalmente mais indicada
para as camadas de banco de dados, enquanto que a escalabilidade horizontal tem sua
utilização direcionada às camadas das aplicações, em especial para as aplicações Web
[BRITO, 2010].
Figura 2: Escalabilidade Horizontal
Fonte: Próprio Autor
A abordagem de esquema compartilhado nos remete a projetar sistemas levando
em consideração que eles necessitarão ser escalados quando não puderem mais atender às
métricas de desempenho de linha de base, como ocorre nas situações mencionadas no início
desta seção, quando há aumento de usuários acessando o banco de dados simultaneamente ou
quando o tamanho do banco de dados faz com que as consultas e atualizações levem muito
tempo para serem executadas.
21
Uma das formas mais utilizadas para lidar com essas situações de escalabilidade
em bancos de dados é o sharding, que consiste de escalonar o próprio banco de dados, como
pode ser visto na Figura 3.
Figura 3: Esquema de Sharding
Fonte: Próprio Autor
Essa técnica permite distribuir o banco de dados no formato horizontal,
utilizando-se do particionamento dos dados. Ou seja, mesmo com a falha de um nó o sistema
continua funcionando para todas as operações que não dependam dos dados contidos naquele
nó, além da sensível minimização do volume de dados por máquina devido o processo de
distribuição. Contudo, essa abordagem vai de encontro com as características dos SGBDs
relacionais, dado a sua dificuldade de adaptação à estrutura lógica do modelo relacional. Os
SGBDs relacionais utilizam a estratégia da escalabilidade vertical, reforçando o servidor,
diferentemente do sharding que trabalha com a escalabilidade horizontal, controlando seus
dados de forma paralela em vários servidores. Outro ponto importante é quanto a obediência
aos critérios de normalização, já que o processo de sharding tem característica inversa, ou
seja, a desnormalização dos dados [BRITO, 2010]. Entretanto é preciso destacar que o
processo de sharding em BDs relacionais é uma tarefa possível de ser implementada, mas que
retira deles a capacidade lidar com restrições de dados, a realização de junções de forma
transparente, e de oferecer algumas de suas principais funcionalidades aos desenvolvedores de
aplicações [DIANA; GEROSA, 2010].
Em 2008 a rede social Twitter cogitou a utilização dos conceitos de sharding na
sua base de dados em MySQL. Entretanto as opções apresentadas por produtos NoSQL, em
especial o Cassandra, se destacaram por serem mais escaláveis e mais fáceis de gerenciar do
que as demais alternativas. Segundo Ryan King, engenheiro do Twitter, esses fatores
influenciaram significativamente na decisão da empresa em mudar sua base de dados do
MySQL para o Cassandra. O cluster de servidores MySQL, com um sistema de cache em
memória, se tornou proibitivo, ou seja, além do aceitável com relação aos custos. Com isso a
22
empresa necessitou de um sistema capaz de crescer de forma mais automática e com alta
disponibilidade. O Cassandra proveu essa solução e recebeu a migração da maior, e talvez a
mais dolorosa de manter, tabela. A tabela de status, que contém todos os tweets e retweets.
Depois disso os novos projetos e a migração de outras tabelas passaram a ser implantadas no
Cassandra. Somente depois de mais testes o Twitter deixará o Cassandra em produção e
desativará o MySQL [COMPUTER WORLD, 2010].
2.3 GERENCIANDO TRANSAÇÕES E A INTEGRIDADE DOS DADOS
Para entendermos transações e integridade dos dados no mundo NoSQL,
precisamos, antes, compreender a similaridade desses conceitos no ambiente relacional. Uma
vez abordado essas noções ficará mais fácil de conceber como os conceitos transacionais são
desafiados em grande escala nos ambientes distribuídos, lugar onde se destaca os BDs
NoSQL.
ACID, que significa Atomicidade, Consistência, Isolamento e Durabilidade,
tornou-se o padrão para se definir o mais alto nível de integridade transacional em sistemas de
banco de dados, bem como os requisitos necessários que devem ser atendidos por uma
transação [TIWARI, 2011].
Atomicidade: Conhecida como a propriedade do “tudo ou nada”, durante a operação de
transação, nada do que é inconsistente entre dois estados deve ser aceitável. Por exemplo,
uma transferência bancária entre a conta A e B. Essa operação envolve duas etapas, débito
e crédito. A atomicidade implica que se, por alguma razão, o débito obtiver sucesso e em
seguida operação de crédito falhar, toda operação é revertida ao estado anterior, ou seja, o
estado inconsistente é evitado. Quando ocorrer o sucesso a transação pode ser persistida
em banco.
Consistência: Implica na obediência a todas as regras e restrições definidas no banco de
dados, como validações no tipo, relacionamentos por chaves estrangeiras, etc. Ou seja,
uma transação deve conduzir um BD de um estado consistente para outro estado também
consistente.
Isolamento: As transações devem funcionar completamente a parte, ou seja, é relevante
que os dados sejam acessados simultaneamente sem sofrer interferência de operações
concorrentes. Pois com dois processos ou segmentos independentes manipulando o mesmo
conjunto de dados, é possível que um interfira na transação do outro e ocorram falhas.
23
Durabilidade: Implica em tornar permanente o resultado de uma transação, ou seja, a
operação transacional é confirmada e assegurada. Deve-se garantir que as modificações
realizadas por uma transação que concluiu com sucesso persistam no BD.
A garantia ACID é bem conhecida e até mesmo esperada em sistemas de banco de
dados relacionais. Isto funciona bem nos casos em que toda pilha, isto é, toda a base de dados
e da aplicação, reside num único servidor ou nó. Contudo, a partir do momento que os
componentes dessa pilha são distribuídos a múltiplos nós, passamos a encontrar dificuldades
em implantar tais conceitos [TIWARI, 2011].
Passados os conceitos de ACID estamos prontos para explorar como esses
fundamentos são aplicados em sistemas altamente distribuídos.
2.3.1 Sistemas distribuídos ACID
Sistemas distribuídos são conhecidos por suas diferentes formas, tamanhos,
características típicas, e são expostos a complicações semelhantes. Consequentemente, quanto
maior e mais distribuído for o sistema, maiores são os desafios, e as dificuldades se
multiplicam. A Figura 4 demonstra, de forma simples, como esses sistemas estão
estruturados. Temos duas aplicações ligadas à base de dados diferentes e todas às quatro peças
de execução em máquinas separadas.
Figura 4: Sistemas distribuídos ACID
Fonte: TIWARI (2011, p. 173)
O desafio de oferecer o ACID não é uma tarefa trivial, em sistemas distribuídos
esses princípios são aplicados utilizando conceitos previstos pelo XA (padrão para
processamento de transação distribuída especificada pelo consórcio X/Open), ou seja,
utilizando um gerenciador de transações distribuídas ou gerenciador global de transações.
Contudo, mesmo com um coordenador central de isolamento, a implementação em várias
bases de dados é extremamente difícil. Isto ocorre por causa da necessidade em garantir o
24
isolamento distribuído. Algumas técnicas como two-phase-locking e two-phase-commit
ajudam na diminuição dessas dificuldades [TIWARI, 2011]. No entanto, estas técnicas levam
ao bloqueio de operações e a disponibilidade de partes do sistema durante os estados do
processo de transação.
Como pode ser visto na Figura 5, que exemplifica bem o cenário utilizado por
bancos de dados distribuídos, as transações no SGBD passam por um gerenciador de
transações (GT), que as encaminha para um escalonador, responsável por decidir qual o
processo que será executado, de forma a proporcionar a ilusão de execução simultânea, e
direcionar ao gerenciador de dados (GD). Este por sua vez, contém dois importantes
componentes, o gerenciador de recuperação (GR) e o gerenciador de memória (GM),
responsáveis por acessar diretamente os dados e manter as combinações, o controle de
atualizações imediatas e postergadas, e os pontos de confirmação do registro de log
[FERREIRA; TAKAI, 2006].
Figura 5: BD Distribuído
Fonte: FERREIRA, TAKAI (2006)
Em transações de longa duração, as transações baseadas em XA não funcionam
devidamente, como por exemplo, mantendo os recursos bloqueados por um longo tempo. Por
outro lado, existem estratégias alternativas, como operações de compensação, que ajudam a
implementar a fidelidade transacional em transações distribuídas de longa duração.
Os desafios de indisponibilidade de recursos em transações de longa duração
aparecem diversos cenários. Os problemas maiores ocorrem, especialmente, em ambientes
onde é mínima a tolerância à indisponibilidade de recursos e a queda do sistema.
Uma maneira de avaliar os problemas envolvidos pela garantia ACID em sistemas
distribuídos é entendendo três fatores importantes: Consistência, disponibilidade e tolerância a
particionamento. Estes fatores são os três pilares do teorema de Brewer ou Brewe’s Theorem
(CAP – Consistency, Availability e Partition Tolerance), onde consistência significa que uma
25
vez escrito um registro, este deve ficar disponível para ser utilizado imediatamente.
Availability ou disponibilidade refere-se à concepção de assegurar que um sistema permaneça
ativo e por último a tolerância a particionamento ou falha, onde caracteriza um sistema por
continuar a operar na presença de uma falha na rede [TIWARI, 2011]. Os princípios desse
conceito estão em torno da integridade transacional escalável e em sistemas distribuídos. Ele
afirma que em sistemas distribuídos é impossível alcançar todos os três fatores, ou seja,
somente dois desses podem ser garantidos ao mesmo tempo.
A Figura 6 demonstra essa relação entre os pilares do teorema de Brewer, de
forma que é necessário sacrificar pelo menos um em favor dos outros dois. Isso é diferente
nos bancos de dados tradicionais, que não possuem essas características no design do sistema
ou delegam isso para o sistema de arquivos (filesystem). Poder particionar os dados em
diferente nós de um cluster é um dos recursos que aparecem com frequência nos bancos
NoSQL [BREWER, 2000].
Figura 6: Teorema de Brewer - CAP
Fonte: BREWER (2000)
Sistemas NoSQL CP: Para sistemas que precisam da consistência forte e tolerância a
particionamento, abrindo mão de parte da disponibilidade. Pode acontecer, caso haja
particionamento e o sistema não entre em consenso, que uma escrita seja rejeitada. Os
sistemas em sua maioria tentam evitar isso ao máximo, tanto que não é normal a existência
de transações distribuídas e sim protocolos de consenso (algoritmos de gerenciamento e
resolução de consenso). A necessidade desses protocolos advém de sistemas distribuídos,
nos quais os processos precisam cooperar na realização de tarefas a fim de garantir a
progressão do sistema e os resultados corretos. De forma que os processos se comuniquem
Disponibilidade (Availability)
Tolerância a Particionamento
(Partition
Tolerance)
Consistência (Consistancy)
CA AP
CP
N/A
26
e mantenham o sistema em um estado consistente, ou seja, o consenso ocorre em duas
fases, a primeira para o envio dos valores e a segunda para a confirmação [BREWER,
2000] [GODOI, 2007]. Exemplos desses sistemas são BigTable1, HBase2 e MongoDB3.
Sistemas NoSQL AP: Representam os sistemas que jamais podem ficar offline, portanto
não desejam sacrificar a disponibilidade. E para ter alta disponibilidade, mesmo com a
tolerância a particionamento, é preciso prejudicar a consistência. Não podemos dizer que
seria uma total inconsistência, mas a ideia é que os sistemas aceitem escritas sempre e
tentam sincronizar os dados em algum momento depois, podendo, então, ter uma janela de
inconsistência [BREWER, 2000]. Exemplos são o Cassandra4, o Dynamo5 e o Riak6.
Sistemas NoSQL CA: São os sistemas com consistência forte e alta disponibilidade. Eles
não sabem lidar com uma possível falha de uma partição. Caso ocorra, o sistema inteiro
pode ficar indisponível até o membro do cluster voltar. Exemplos disso são algumas
configurações clássicas de bancos de dados relacionais [BREWER, 2000].
O processamento paralelo e fora de escala são métodos comprovados e estão
sendo adotados como modelos para escalabilidade e alto desempenho ao invés de ir
aumentando gradualmente e construindo enormes “super” computadores. Os últimos anos tem
mostrado que estruturar esses enormes computadores é caro e pouco prático na maioria dos
casos [TIWARI, 2011]. Adicionar um número de unidades de hardware em cluster e fazê-los
trabalhar em conjunto é uma eficiente relação entre custo, recursos eficazes e soluções
eficientes. O surgimento da computação nas nuvens é um testemunho desse fato.
2.4 USANDO NOSQL NA NUVEM
Atualmente, a geração de aplicativos populares, como os da Google e Amazon,
alcançaram alta disponibilidade e capacidade para milhões de usuários em serviços
simultâneos. Com expansão horizontal entre várias máquinas, espalhadas por vários centros
de dados. Essas histórias de sucesso em aplicações Web de grande escala, provam que, em
ambientes escalados horizontalmente, soluções NoSQL tendem a se destacar sobre os
RDBMS. Tais ambientes foram batizados de “nuvem” e se escalabilidade e disponibilidade
são sua prioridade, NoSQL é, possivelmente, a configuração ideal para eles. Contudo, seria
1 http://research.google.com/archive/bigtable.html 2 http://hbase.apache.org/ 3 http://www.mongodb.org/ 4 http://cassandra.apache.org/ 5 http://aws.amazon.com/pt/dynamodb/ 6 http://wiki.basho.com/
27
impreciso dizer que apenas o NoSQL funcionaria em ambiente horizontal. Em algumas
situações, tanto o relacional como o não-relacional, são utilizados em combinação. Depende
muito da escala necessária, da estrutura dos dados e das expectativas de integridade
transacional da aplicação.
Algumas opções de NoSQL na nuvem são o Bigtable, SimpleDB7, CouchOne8,
MongoHQ9 e Riak. Entre os bancos de dados relacionais, destacam-se a plataforma Windons
Azure10 da Microsoft e Amazon Relational Database Service (RDS)11.
Como a computação em nuvem tem passado por um crescimento contínuo, e é
cada vez mais propensa a adoção dos serviços dos bancos de dados na nuvem, os produtos
NoSQL tendem a alavancar ainda mais, ou seja, proporcionando a muitos desenvolvedores a
oportunidade de começar a pensar num banco de dados como um serviço de persistência
[TIWARI, 2011].
2.5 PRINCIPAIS MODELOS DE ARMAZENAMENTO DE DADOS NOSQL
Nesta seção abordaremos os tipos mais comuns de bancos de dados NoSQL,
apresentando suas diferenças básicas com os bancos de dados relacionais, as principais
implementações e seu contexto na Web.
2.5.1 Key/value stores (chave/valor)
Nesse modelo os dados são estruturados em tabelas Hash ou arrays associativos,
ou seja, um banco de dados composto por um conjunto de chaves associadas a um único
valor, como string ou binário. Tais estruturas são extremamente populares porque fornecem
eficiência quanto a disponibilidade de acesso aos dados, ou seja, tempo constante de
execução. Alguns mantêm os dados na memória e alguns possuem a capacidade de manter os
dados em disco. Armazenam objetos indexados por chaves, e possibilitam a busca por esses
objetos a partir de suas chaves (Ver
Figura 7). Suas operações de manipulação são bem simples, como get() e set(),
que permitem retornar e capturar valores [LÓSCIO; OLIVEIRA; PONTES, 2011].
7 http://aws.amazon.com/pt/simpledb/ 8 http://www.couchbase.com/ 9 https://www.mongohq.com/home 10 http://www.windowsazure.com/pt-br/ 11 http://aws.amazon.com/pt/rds/
28
Figura 7: Modelo Chave/Valor
Fonte: Próprio Autor
Dentre os bancos de dados NoSQL, são os que suportam mais carga de dados e
que possuem maior escalabilidade, entretanto não permitem a recuperação de objetos por
meio de consultas mais complexas. Alguns exemplos são BerkeleyDB12, SimpleDB e
Voldemort13.
2.5.2 Document databases (orientado a documentos)
O modelo orientado a documentos são coleções de atributos e valores, onde o
atributo pode ser multi-valorado. Baseados em documentos XML (eXtensible Markup
Language) ou JSON (JavaScript Object Notation), podem ser localizados pelo seu id único ou
por qualquer registro que tenha no documento. Permitem a indexação de documentos não só
pelo identificador, mas também por suas propriedades, e a elaboração de um conjunto
diversificado de documentos [TIWARI, 2011]. No modelo chave/valor apenas uma única
tabela hash é criada no banco de dados, enquanto que o modelo orientado a documentos
possui um conjunto de documentos e para cada um existe um conjunto de campos (chaves)
com seus respectivos valores [LÓSCIO; OLIVEIRA; PONTES, 2011]. Dentre os bancos de
dados orientados a documentos temos o MongoDB e o CoucheDB.
Os bancos de dados orientados a documentos estão tomando cada vez mais força
no âmbito comercial. Entre suas principais características, está a escalabilidade vertical de
fácil manutenção e instalação, não grava campos em branco, rápido e flexível. Todavia eles
apresentam replicação desnecessária, pouca documentação, possíveis frustrações na
modelagem do projeto e os desenvolvedores podem se confundir facilmente [MATTEUSSI,
12 http://www.oracle.com/technetwork/products/berkeleydb/overview/index.html 13 http://project-voldemort.com/voldemort/
29
2010]. Para startups e sites de grandes volumes de manipulação de dados, a utilização desses
sistemas pode ser a solução mais adequada.
Exemplificando o agrupamento das informações promovido pelos bancos de
dados orientados a documentos, temos na Tabela 1 uma tabela relacional simples e na Tabela
2 o formato que esses dados ganham quando alterados para a orientação a documento.
Tabela 1: Tabela Relacional
Id Nome Sobrenome Idade
1 João Gomes 28
2 Lisa Dias 25
3 Pedro Santos 29
4 Carla Azevedo 31
Fonte: Próprio Autor
Tabela 2: Orientado a Documento
Id: 1
Nome: João
Sobrenome: Gomes
Idade: 28
Id: 2
Nome: Lisa
Sobrenome: Dias
Idade: 25
Id: 3
Nome: Pedro
Sobrenome: Santos
Idade: 28
Id: 4
Nome: Carla
Sobrenome: Azevedo
Idade: 31
Fonte: Próprio Autor
2.5.3 Graph databases (orientado a grafo)
A adoção de um banco de dados orientados a grafos, assim como qualquer
solução NoSQL, passa fatores bastante comuns, como necessidade de alta escalabilidade e
disponibilidade, flexibilidade de esquema e ganho de desempenho. Eles permitem a criação
de modelos de dados extremamente complexos e, ainda, manter uma considerável facilidade
em pesquisar dados. Aliado a isso estão as características que tornaram os bancos de dados
relacionais ferramentas tão reconhecidas no mercado, como transações ACID e linguagens
simples de pesquisa. Este modelo possui três componentes básicos: os nós (são as vértices dos
grafos), os relacionamentos (são as arestas) e as propriedades (atributos) dos nós, conforme é
possível observar na Figura 8 [LÓSCIO; OLIVEIRA; PONTES, 2011]. Nela está indicado
que uma pessoa possui interesse em determinados produtos. Que por sua vez possuem relação
30
com uma categoria. O cliente se relaciona com a compra e também pode possuir
relacionamentos com outros clientes. Cada nó possui propriedades e são interligados pelas
setas de relacionamento. Estes também podem possuir propriedades, como por exemplo, o
nível de interesse do cliente, nesse caso podendo ser de 1 a 5.
Com uma complexidade maior, esses bancos de dados guardam objetos, e não
registros como os outros tipos de sistemas NoSQL. As buscas nesse formato de banco de
dados são realizadas através da navegação desses objetos. Alguns exemplos que utilizam
esses conceitos são: Neo4J, BigData e InfoGrid.
Figura 8: Demonstrando o relacionamento de informações em grafos
Fonte: ALMEIDA (2012)
2.5.4 Column oriented store (orientado a colunas)
O armazenamento orientado a coluna permite que os dados sejam armazenados de
forma eficaz, evitando o consumo do espaço por valores nulos. Simplesmente por não
armazenar uma coluna quando um valor não existe para ela. Cada unidade de dados pode ser
pensada como um conjunto de chave/valor, onde a unidade é identificada com a ajuda de um
identificador primário, muitas vezes referida como chave primária [TIWARI, 2011].
Bigtable e seus clones são exemplos de uso dessa metodologia. Eles tendem a
chamar essa chave primária de linha de chave (row-key). Além disso, as unidades de dados
são ordenadas com base nessa linha de chave. A ideia é não salvar os dados em linhas, como
estamos acostumados pelos bancos relacionais. Os dados serão salvos através de colunas e
não oferecem junções e chave composta. Com orientação a colunas também podemos aplicar,
de forma mais fácil, projeções sobre os dados. A segunda vantagem é importante,
principalmente, para sistemas OLAP (online analytic process) que utilizam pesquisas de
forma intensificada.
Cassandra é frequentemente referida como um banco de dados orientado a
colunas, e diferentemente do modelo relacional, cada linha pode ter uma ou mais colunas, mas
31
cada linha não precisar ter todas as colunas da outra linha. Cada linha tem uma chave única, o
que torna os seus dados acessíveis. Assim, embora não seja errado dizer que o Cassandra seja
orientado a coluna, é mais útil pensarmos nisso como uma indexação, como pode ser visto na
Figura 9. Abordaremos os conceitos do Cassandra, com mais detalhes, no próximo capítulo.
Figura 9: Família de colunas dos usuários do Twitter
Fonte: http://demoiselle.sourceforge.net/docs/guide-cassandra/1.0-v1/html_single/
O BD relacional possui como característica a “orientação a linhas”, ou seja, os
dados são armazenados em uma linha e após o último elemento dessa linha vem o primeiro
elemento da linha seguinte. Enquanto que o BD orientado a coluna armazena a mesma coluna
em sequência, com o final de uma coluna seguida do primeiro elemento da coluna seguinte
[TIWARI, 2011]. É possível observar uma tabela simples na Figura 10: Tabela. Em um BD
relacional estes dados seriam armazenados da seguinte maneira: 1, 321. Antônio Marcos,
87651, Maria Antonieta; 2, 123, João Nunes, 321, Doutor Carneiro; 3, ... Se estes dados
estivessem armazenados em um BD orientado a coluna seguiriam o seguinte formato: 1, 2, 3;
321, 123, 456; Antônio Marcos, João Nunes; Anderson Guimarães; 87651...
Figura 10: Tabela de dados
Fonte: Próprio Autor
2.6 CONSIDERAÇÕES DO CAPÍTULO
Os conceitos apresentados neste capítulo denotam a importância de conhecer bem
as ferramentas de armazenamento do NoSQL já que, pela variedade, torna-se difícil compará-
las e decidir por qual solução aplicar. Dessa forma é importante considerar quais são as
necessidades computacionais do cenário em que serão aplicados tais sistemas, e o
alinhamento dos mesmos com que é disponibilizado no mercado, combinando com o que é
certo para a empresa. Conforme se pode observar na Tabela 3, é necessária uma análise
32
comparativa entre os principais modelos NoSQL disponíveis afim de decidir corretamente
qual aplicar.
Tabela 3: Análise comparativa NoSQL
Modelo Aplicações Típicas Pontos Fortes Pontos Fracos
Armazenamento
Chave/Valor
(Key/value stores).
Cache de conteúdo
(Foco em escalar para
imensas quantidades
de dado, criado para
lidar com
carregamento
massiço), logging etc.
Pesquisas rápidas. Dados armazenados
não tem esquema.
Armazenamento
orientado a
documentos
(Document
databases)
Aplicações Web
(Similar ao
armazenamento chave
valor, mas o banco de
dados sabe qual é o
valor).
Tolerante a dados
incompletos
Query performance,
sem sintaxe de
consulta padrão.
Armazenamento
orientado a grafos
(Graph databases)
Redes sociais,
recomendações (foco
em modelar as
estruturas dos dados,
interconectividade).
Algoritmos
gráficos, como
caminho mais
curto,
conectividade,
relacionamentos,
etc.
Tem que atravessar
todo o gráfico para
obter uma resposta
definitiva. Não é
fácil de agrupar.
Armazenamento
orientado a colunas
(Column oriented
store)
Sistemas de arquivos
distribuídos
Pesquisas rápidas,
boa distribuição de
armazenamento de
dados.
API de baixo nível.
Fonte: VARDANYAN (2011)
Para o estudo de caso deste trabalho o modelo NoSQL adotado foi o
armazenamento orientado a colunas por atender melhor as necessidades da aplicação, como
pesquisas mais rápidas, distribuição e projeções sobre os dados, e apresentar características
semelhantes aos modelos relacionais, o que facilita sua implementação em sistemas
corporativos. O banco de dados adotado para o estudo deste trabalho é o Cassandra, por
conter ser capaz de lidar com carregamento pesados, suportar muitas operações de escrita no
armazenamento e processar grandes quantidades de dados distribuídos em muitas máquinas.
Seus conceitos e características serão mais bem abordados no capítulo 3.
33
3 CASSANDRA
O Apache Cassandra é um sistema de armazenamento de dados distribuídos,
orientado a coluna, open source, que se difere dos SGBDs relacionais. Criado no Facebook e
tem sido utilizado em produção por várias empresas da Web, incluindo o próprio Facebook, o
Twitter, a Cisco, a Digg, entre outras. Sua popularidade se destaca por características como
fácil escalabilidade, consistência, rápida execução, alta disponibilidade, poder de
armazenamento e ofere um esquema livre de modelo de dados.
É preciso destacar que, embora não seja incorreto referir o Cassandra como
orientado a coluna, ele não é relacional. Ou seja, para qualquer determinada linha é possível
ter uma ou mais colunas, não precisando ter as mesmas colunas das outras linhas, como um
modelo relacional. É mais fácil pensar nisso como uma indexação, onde cada linha tem uma
chave única que torna seus dados acessíveis. Isto significa que não é necessário decidir
previamente como os dados devem ser estruturados, ou quais os campos de cada registro. De
forma que isso pode ser muito útil quando lidamos com cenários onde existem mudanças no
negócio, adição ou alteração nas características com frequência, utilização de metodologia
ágil onde não é possível levar meses para uma análise, e principalmente adicionar ou remover
campos sem interromper o serviço [HEWITT, 2011].
3.1 O MODELO DOS DADOS NO CASSANDRA
De maneira simples um banco de dados relacional possui a própria base de dados,
que contém tabelas, nomeadas, e nelas existem uma ou mais colunas, que também tem nomes.
Ao inserir dados em uma tabela, ou seja, valores para cada coluna, esta nova entrada adiciona
uma nova linha, inclusive escrevendo nulo nas colunas que não tenham valor. Mais tarde
esses dados podem ser consultados ou atualizados utilizando expressões SQL que atendam
aos critérios da linha como identificadores, chaves primárias, etc. [HEWITT, 2011].
No Cassandra o modelo dos dados segue estrutura semelhante ao modelo
relacional que facilita seu entendimento. Um simples armazenamento de dados pode ser visto
na Figura 11, entretanto para consultá-lo haveria dificuldade em entender o que cada um
representa.
Figura 11: Lista de Valores
Fonte: Próprio Autor
Valor 1 Valor 2 Valor 3
34
Por não informar muito sobre seu significado é necessário acrescentar
identificadores, ou seja, nomes as valores de forma a combinar com cada um coforme
representado na Figura 12. Com isso é possível saber os nomes de cada valor, sendo uma
estrutura um pouco mais rica de se trabalhar.
Figura 12: Mapa nome/valor
Fonte: Próprio Autor
Contudo, mesmo sendo uma melhoria, essa estrutura só funciona com instâncias
de determinadas entidades, como por exemplo, pessoa, usuário e etc., não permitindo
armazenar várias entidades com a mesma estrutura. O conjunto nome/valor representa a
estrutura básica contida no Cassandra, a Column ou coluna, acrescida de um timestamp que
fornece quando foi a última atualização (Ver Figura 13).
Figura 13: A estrutura de uma coluna
Fonte: HEWITT (2011)
Nesse momento é necessário algo que agrupe as colunas de forma endereçável, ou
seja, uma linha que possua um identificador (Row Key). O Cassandra define algo chamado de
Column Family ou família de colunas, que representa um agrupamento lógico de dados
semelhantes, algo análogo as tabelas no modelo relacional. De forma resumida as estruturas
básicas do Cassandra são: Column (Coluna) e a Column Family (família de Coluna) que
armazena linhas de semelhantes, mas não iguais, e conjuntos de colunas como é possível
observar na Figura 14 e no exemplo da Figura 15 [HEWITT, 2011].
Figura 14: Column Familly
Fonte: HEWITT (2011)
35
Figura 15: Exemplo de column families
Fonte: Próprio Autor
O Cassandra permite a criação de outra dimensão em cima dessa estrutura, um
grupo de colunas relacionadas formando subcolunas de formato “super”, denominadas Super
Column e Super Column Family. Assim, uma Column Family possui uma coleção de pares
nome/valor, ou seja, Row Key endereçando uma coluna que aponta para o valor, enquanto a
Super Column Family contém a Row Key apontando para uma coluna, que aponta para
subcolunas. Estas endereçam o valor, ou seja, uma linha na Super Column Family que contém
colunas, cada uma contendo subcolunas como descrito na Figura 16 [HEWITT, 2011].
Figura 16: Super Column Family
Fonte: HEWITT (2011)
A seção 3.2 abordará detalhes sobre as configurações do Cassandra, mas a
princípio é importante definir que o Cassandra provavelmente não é a melhor escolha quando
tratamos de armazenamento de dados em um único nó, por ter sido especificado para ser
distribuído sobre várias máquinas operando como uma única instância ao usuário final, ou
seja, sua estrutura mais externa é o cluster, chamado de anel, por atribuir os dados à nós do
cluster, organizando-os em um anel. Cada nó mantém uma réplica para diferentes faixas de
dados, de maneira que se um estiver indisponível existe outro para responder as solicitações
[HEWITT, 2011].
ColumnFamily 1
RowKey 1
ColumnName: Valor
ColumnName: Valor
RowKey 2
ColumnName: Valor
ColumnFamily 2
RowKey 1
ColumnName: Valortelefone: 8855-9977
Jorge:
Músicos:
Banda:
Jorge:
Cláudio:
email: [email protected]
instrumento: baixo
instrumento: guitarra
36
Nesse contexto, o cluster é um armazenador de Keyspaces¸ que são as
responsáveis pelo armazenamento dos dados no Cassandra. Algo correspondente a um banco
de dados relacional, com nome e um conjunto de atributos que definem seu comportamento.
A Figura 17 demonstra essa semelhança entre o modelo de dados do Cassandra e do BD
relacional.
Figura 17: Keyspace
Fonte: Próprio Autor
3.2 ARQUITETURA
No Microsoft SQL Server duas bases de dados são mantidas, a “master” usada
para manter informações sobre espaço em disco, utilização, configurações do sistema, e as
notas gerais de instalação do servidor. E “tempdb” onde são armazenados resultados
intermediários e executadas tarefas gerais. Da mesma forma o banco de dados Oracle utiliza
uma tabela chamada SYSTEM. Semelhante a estes bancos de dados, o Cassandra possui uma
keyspace interna chamada “system” usada nas operações e no armazenamento de metadados,
que são um conjunto de dados que descrevem outros dados, algo semelhante a um dicionário
de dados. Estes metadados possuem informações como o nome do nó e do cluster, definições
de keyspace e esquema para suportar o carregamento dinâmico, onde as definições de
esquema são armazenadas em duas column families, CF schema (usuários, migrações, etc.) e
CF records (registros das alterações feitas). Esta keyspace interna não permite modificações
[HEWITT, 2011].
A maioria dos bancos de dados, sejam eles tradicionais ou até mesmo os modelos
mais recentes como o Bigtable da Google, utilizam uma estrutura onde alguns nós são
denominados “mestres” e outros “escravos”, onde cada um possui papel diferente no cluster
global. O mestre atua como fonte de autoridade sobre os dados, gerenciando qualquer escrita
ou alteração existente repassando aos nós escravos. Estes, por sua vez, são submetidos a
atualizar seus dados com o mestre [HEWITT; TIWARI, 2011].
Base de dados no relacional
Tabela no relacional
37
Por outro lado, o Cassandra tem um modelo de distribuição peer-to-peer, de
forma que qualquer nó possui a mesma estrutura do outro, ou seja, não há um mestre que atua
de forma diferente aos demais nós, como observado na Figura 18. Isso o torna extremamente
escalável e tolerante a falhas deixando o nó ainda disponível para leituras e escritas. Contudo,
extrema escalabilidade possui um custo, que neste caso é a fraca consistência proporcionada
pelo modelo peer-to-peer, mas que não caracteriza uma total inconsistência [TIWARI, 2011].
Figura 18: Rede Peer-To-Peer
Fonte: Próprio Autor
A facilidade em escalar permite que novos nós sejam adicionados de forma mais
simples, ou seja, por possuírem comportamentos idênticos, para adicionar um novo servidor,
basta inseri-lo ao cluster. O novo nó não aceitará imediatamente os pedidos, pois necessita
aprender a topologia da rede e também aceitar a responsabilidade pelos dados. Isso ocorre, em
boa parte, de maneira automática. Por isso o modelo P2P consegue ampliar e redimensionar
uma tarefa mais facilmente do que um modelo no formato mestre/escravo [HEWITT, 2011].
Um modelo altamente escalável, mas que possui uma eventual consistência
necessita de um protocolo de comunicação para detectar possíveis falhas entre os nós. O
Cassandra se baseia na utilização do Gossip, que como a própria tradução do termo sugere, é
algo semelhante a uma “fofoca humana”, cujo objetivo é detectar possíveis falhas utilizando
mensagens que são propagadas pela rede. Isto ocorre de maneira sistemática e desencadeada
por uma classe chamada Gossiper a partir de um temporizador. Ela envia uma mensagem
(GossipDigestSyncMessage) para o nó, que se ativo, retorna uma mensagem de confirmação
ao Gossiper. Se durante este processo a comunicação falhar isso indica que possivelmente o
38
nó esta indisponível, ou seja, o Gossiper possui uma lista dos nós que estão ativos e inativos
[TIWARI, 2011].
O protocolo Gossip é comumente empregado em grandes sistemas que possuem
redes descentralizadas e muitas vezes usado como um mecanismo automático de replicação
em bases de dados distribuídas [HEWITT, 2011].
3.3 DEFINIÇÃO E MANIPULAÇAO DOS DADOS
Até a versão 0.6 do Cassandra suas configurações e definições de keyspaces,
clusters, colomn families, eram através do arquivo “conf.xml”, e que posteriormente foi
convertido para YAML. A partir da versão 0.7 essas configurações e definições passaram a
ser realizadas através da API Thrift ou interface de linha de comando (cassandra-cli) como
cliente padrão, dando suporte a operações de DDL – Data Definition Language, de forma
semelhante ao SQL. Contudo, um importante conceito foi inserido a partir da versão 0.8, uma
linguagem extremamente parecida com o SQL, chamada CQL, que foi definida em duas
especificações: CQL 2.0 e CQL 3.0. Ambas com suporte a colunas dinâmicas, contudo apenas
a especificação CQL 3.0 dá suporte a chave primária compostas. [HEWITT, 2011]. É
necessário destacar que, a cada nova versão, o Cassandra tem evoluído consideravelmente em
aspectos como compressão de dados, gerenciamento de memória e disco, nível de
compactação, e principalmente desempenho (escrita e leitura), quando comparado a versão
0.6 e versão 1.0 (2010), conforme demonstrado na Figura 19 [ELLIS, 2011].
Figura 19: Evolução do desempenho no Cassandra
Fonte: ELLIS (2011)
39
3.3.1 Diretórios do Cassandra
O Cassandra é obtido através do código fonte (podendo ser compilado na própria
máquina) e através dos arquivos binários, que depois de descompactado resulta no diretório
principal (apache-cassandra-x.x.x) da versão, dividindo-se em 7 subdiretórios conforme
definidos na Tabela 4:
Tabela 4: Diretórios do Cassandra
Diretório Descrição
bin Contêm os executáveis que inicializam o Cassandra Server, Client e os
utilitários para inspeção e configuração de clusters.
conf
Onde se encontram todos os arquivos de configuração do Cassandra,
como diretórios de armazenamento, nomes de keyspaces e column
families, logs.
interface Contêm o arquivo cassandra.thrift, que é a API cliente.
javadoc Encontra-se a documentação gerada pelas classes do Java.
lib Contêm todas as bibliotecas externas que o Cassandra utiliza no seu
funcionamento como Json, Collections Google, e Apache Commons.
pylib
Por possuir sua própria linguagem de consulta chamada CQL, as versões
mais recentes possuem esse diretório que contêm alguns drives do CQL
para python.
tools
Contêm ferramentas que o Cassandra disponibiliza como, por exemplo, o
cassandra-stress, que é uma ferramenta feita em Java para a realização de
testes de stress em um cluster.
Fonte: Próprio Autor
Contudo, existe uma importante solução gratuita disponibilizada pela empresa
Datastax. A DataStax Community Edition14 - (DCE) é uma ferramenta Web que consiste de
componentes como a versão atual do Apache Cassandra, “Ops Center Community Edition”,
como a primeira solução em gerenciamento e monitoramento visual do banco de dados
Cassandra, exemplos, instaladores inteligentes para Windows, Linux e Mac, bem como
suporte a linguagem CQL.
Os comandos CQL de definição e manipulação dos dados são bens semelhantes
aos utilizados em SQL e serão vistos nas seções 3.3.2 e 3.3.3 utilizando o Cassandra CQL
14 http://www.datastax.com/products/community
40
Shell e DataStax Community Edition, instalados no sistema operacional Windows 7 (Figura
20).
Figura 20: Diretório Datastax Community Edition
Fonte: Próprio Autor
3.3.2 Comandos básicos de definição (DDL)
Os comandos básicos da linguagem podem ser observados executando o comando
“help” conforme Figura 21.
Figura 21: Comandos CQL
Fonte: Próprio Autor
CREATE KEYSPACE: Utilizado na criação da base de dados (Figura 22). A
mesma operação utilizando a DataStax Community Edition pode ser visto na Figura 23.
Figura 22: Create Keyspace
Fonte: Próprio Autor
41
Figura 23: Create Keyspace utilizando DCE
Fonte: Próprio Autor
CREATE TABLE: Utilizado na criação das column families (Figura 22). O
mesmo comando, utilizando a DataStax Community Edition, pode ser visto na Figura 23,
onde column_type representa se a CF pode ser padrão (standard) ou super (super),
compare_with e default_validation_class, que são classificações que a CF pode possuir para
efeitos de comparação e ordem de classificação (AsciiType, BytesType, LexicalUUIDType,
IntegerType, LongType, TimeUUIDType, ou UTF8Type).
Figura 24: CREATE TABLE
Fonte: Próprio Autor
Figura 25: CREATE TABLE utilizando DCE
Fonte: Próprio Autor
42
Da mesma forma comandos como DROP e ALTER, utilizados em SQL, podem
ser executados em CQL e no DataStax Community Edition, que permite que tais definições
sejam realizadas de maneira mais ágil. A Figura 26 demonstra a utilização desta ferramenta e
a possibilidade de ter uma visão mais ampla das estruturas existentes e da modelagem da base
de dados.
Figura 26: Datastax Opscenter Edition - Modelagem
Fonte: Próprio Autor
Na criação das column families os tipos de dados podem ser definidos conforme a
Tabela 5.
Tabela 5: Tipos de dados
Tipo CQL Descrição
ascii US-ASCII caracteres string bigint 64 bits blob Bytes arbitrários (sem validação), expressos em hexadecimal
boolean Verdadeiro ou falso counter Distribuído valor do contador (64 bits de comprimento) decimal Variável de precisão decimal double 64 bits ponto flutuante IEEE-754
float 32 bits de ponto flutuante IEEE-754 int Inteiro de 32 bits text UTF-8 string codificada
timestamp Data/hora, codificados como 8 bytes uuid Tipo 1 ou 4 UUID
varchar UTF-8 string codificada varint De precisão arbitrária inteira
Fonte: Documentação do Apache Cassandra 1.0
43
3.3.3 Comandos básicos de manipulação (DML)
O SQL contém comandos básicos de manipulação dos dados, como por exemplo:
SELECT, INSERT, UPDATE e DELETE. Utilizando CQL, tais comandos possuem as mesmas
finalidades. Na temos um exemplo que demonstra uma inserção de dados e uma consulta logo
em seguida.
Figura 27: Insert e Select utilizando CQL
Fonte: Próprio Autor
Os dados existentes nas column families também podem ser consultados
utilizando a funcionalidade DATA EXPLORER da Datastax OpsCenter Comunity, conforme a
Figura 28
Figura 28: Data Explorer
Fonte: Próprio Autor
44
4 ESTUDO DE CASO
O sistema de gerenciamento otimizado da distribuição – SIGOD é utilizado
atualmente pelo Grupo Energisa. Empresa que atua nas áreas de distribuição, transmissão e
comercialização de energia elétrica, concentrada principalmente nos estados de Sergipe,
Paraíba, Minas Gerais e Rio de Janeiro. Segundo a mesma, cobrindo uma área de
aproximadamente 91.180 Km² e 5.205 GWh de energia distribuída, atendendo a cerca de 2,5
milhões de clientes15.
Tal característica de crescimento dos consumidores acarreta na necessidade de
oferecer serviços cada vez melhores e ágeis, utilizando tecnologias eficientes. Uma destas
melhorias se refere ao atendimento de ordens de serviço (OS), sejam elas de caráter
emergencial ou comercial. Os atendimentos destas OS’s são fiscalizados pelo regulador
ANEEL – Agência Nacional de Energia Elétrica, cuja missão é proporcionar condições
favoráveis ao mercado de energia elétrica e equilíbrio entre os agentes e a sociedade. Este
acompanhamento da ANEEL abrange o acompanhamento de indicadores como DIC (Duração
de interrupção por unidade consumidora), FIC (Frequência de interrupção por unidade
consumidora), DMIC (Duração máxima por unidade consumidora), de forma a aferir a
qualidade do serviço prestado.
4.1 DESCRIÇÃO DO SISTEMA DE GERENCIAMENTO OTIMIZADO DA
DISTRIBUIÇÃO – SIGOD
O SIGOD é um sistema de gerenciamento e automação da força de campo,
desenvolvido internamente pelas empresas da Energisa e com o objetivo de possibilitar o
envio de ordens de serviços – OS do centro de operação para os eletricistas em campo. De
forma que estas são atualizadas e acompanhadas “On Line” diretamente nos sistemas
corporativos, conforme o processo demonstrado na Figura 29.
Suas funcionalidades permitem melhorar, tanto no ambiente corporativo (SIGOD)
quanto no embarcado (Windows Mobile/Smartphone), através de GPS e geoprocessamento, os
processos de despacho/envio e acompanhamento, bem como a orientação das equipes de
campo, através de recursos gráficos das equipes e OS’s sobre o mapa (topografia, hidrografia
e arruamento) integrado com a rede elétrica.
15 http://www.mzweb.com.br/energisa/web/arquivos/FACT_SHEET_2TRI2012.pdf
45
Figura 29: Processo de envio e acompanhamento de OS's
Fonte: Próprio Autor
O sistema também conta com um ambiente embarcado (Windows
Mobile/Smartphone) que proporciona as equipes de campo à realização de sincronismos com
a base de dados permitindo a realização dos atendimentos das OS’s. A Figura 30 demonstra a
arquitetura do sistema e como as bases de dados estão distribuídas para o sincronismo.
Figura 30: Arquitetura do SIGOD
Fonte: Próprio Autor
46
4.1.1 Interface do sistema
O sistema constituído de três módulos de produção, compostos por:
Ambiente Embarcado: Citado anteriormente, desenvolvido para ambiente
operacional Windows Mobile, composto por várias telas e utilizado pelas equipes de campo
durante atendimento (Figura 31).
Figura 31: Interface do embarcado
Fonte: Próprio Autor
Ambiente Corporativo: Este ambiente é composto pelo módulo de despacho
(Figura 32) e a interface de mapas (Figura 33), onde os operadores gerenciam as equipes.
Figura 32: Módulo de despacho
Fonte: SIGOD, 2012
47
Figura 33: Interface de mapas
Fonte: SIGOD, 2012
Este ambiente possibilita a parametrização de regiões e equipes com base na
responsabilidade de cada área, enviando e recebendo OS’s. É possível, ainda, acompanhar o
desempenho em tempo real na execução das tarefas, agendar tarefas programadas, formar
equipes, reprogramar a OS do smartphone em campo e enviar para outra equipe.
4.2 MODELAGEM E CENÁRIO ATUAL DO BANCO DE DADOS
Todas as informações de referência à base de mapas são gravadas em banco de
dados apontando para coordenadas geográficas, composta por postes, cabos, equipamentos e
consumidores, de forma que toda a rede elétrica é representada graficamente dentro dos
padrões vigentes.
A Figura 34 demonstra alguns dos requisitos existentes, exemplificando as
necessidades do sistema com relação ao gerenciamento das equipes, a visualização de mapas,
o monitoramento do atendimento, a consulta de viaturas, o recebimento dos dados, entre
outras funcionalidades.
48
Figura 34: Diagrama de caso de uso
Fonte: Documento de Requisitos - SIGOD, 2010
A fonte dos dados está contida nos sistemas transacionais, cuja base dos dados
contempla informações comerciais, de faturamento, de atendimento e etc. Além das
informações técnicas oriundas do SGD – Sistema de Gerenciamento da Distribuição. Essas
bases de dados seguem o modelo relacional, com armazenamento em banco de dados Oracle,
e são constantemente acessadas pelo SIGOD formando a base de dados utilizada pelo sistema.
Tal acesso se utiliza de recursos de sincronização a fim de manter seus dados sempre
atualizados com os demais sistemas.
49
4.3 DIFICULDADES DA APLICAÇÃO
4.4 MAPEAMENTO DO BANCO RELACIONAL PARA O MODELO NOSQL
4.5 ANÁLISE COMPARATIVA
5 CONSIDERAÇÕES FINAIS
50
REFERÊNCIAS
ALMEIDA, Adriano. Neo4J na Prática, MUNDOJ. Curitiba, n. 51, jan. e fev. 2012, p. 19.
BREWER, Eric . Towards robust distributed systems. Simpósio ACM – Princípios de
computação distribuída (PODC), 2000.
Disponível em http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf
Acesso em 12/05/2012.
BRITO, Ricardo W. Bancos de Dados NoSQL x SGBD Relacionais: Análise Comparativa.
In: III CONGRESSO TECNOLÓGICO INFO, 2010, Fortaleza.
CHANG, F. et al. Bigtable: a distributed storage system for structured Data. 7th Conference
on Usenix Symposium on Operating Systems Design and Implementation, Volume 7, 2006.
COMPUTER WORLD, Crescimento faz Twitter trocar o MySQL pelo Cassandra.
Disponível em http://computerworld.uol.com.br/tecnologia/2010/02/23/crescimento-faz-twitter-
trocar-o-mysql-pelo-cassandra/ Acesso em 12/05/2012.
DIANA, Maurício de; GEROSA, Marco Aurélio. NoSQL na Web 2.0: um estudo comparativo
de bancos não-relacionais para armazenamento de dados na Web 2.0. IX Workshop de Teses
e Dissertações em Banco de Dados, Belo Horizonte, 2010.
Disponível em: http://www.lbd.dcc.ufmg.br/colecoes/wtdbd/2010/sbbd_wtd_12.pdf
Acesso em: 07/04/2012.
ELLIS, Jonathan. What’s new in Cassandra 1.0: Perfarmance. Outubro, 2011. Disponível
em: http://www.datastax.com/dev/blog/whats-new-in-cassandra-1-0-performance Acesso em:
08/09/2012.
FERREIRA, João Eduardo; TAKAI, Osvaldo Kotaro. Controle de Concorrência e
Recuperação de Transação. Disponível em http://www.ime.usp.br/~jef/bd10.pdf Acesso em
12/08/2012.
GODOI, Ana Flávia Barreto de. Uma ferramenta para comunicação confiável em sistemas
P2P baseada em grupos de peers. Dissertação (Mestrado em Informática)-UFPR, Curitiba,
2007.
HEWITT, Eben. Cassandra: The definitive guide. Sabastopol, Editora O’Reilly, Ed. 1, 2011.
LÓSCIO, Bernadette F.; OLIVEIRA, Hélio Rodrigues de; PONTES, Jonas C. de Sousa.
NoSQL na Web 2.0: Um estudo comparativo de bancos não-relacionais para armazenamento
de dados na Web 2.0. VIII Simpósio Brasileiro de Sistemas Colaborativos, 2011, Rio de
Janeiro. Disponível em: http://www.addlabs.uff.br/sbsc_site/SBSC2011_NoSQL.pdf
Acesso em: 12/04/2012.
51
MAGALHÃES, Karine V.; LAENDER, Alberto H. F.; SILVA, Altigran S. da. Uma
abordagem para armazenamento de dados semi-estruturados em bancos de bados relacionais.
XVI Simpósio Brasileiro de Banco de Dados (SBBD), Belo Horizonte, 2001. Disponível
em: http://www.lbd.dcc.ufmg.br:8080/colecoes/sbbd/2001/017.pdf Acesso em: 07/04/2012.
MATTEUSSI, Kassiano José. Protótipo de interface web com PHP para gerenciamento de
banco de dados CouchDB. Trabalho de Conclusão de Curso (Graduação em Ciência da
Computação). Universidade Comunitária da Região de Chapecó, Santa Catarina, 2010.
MELLO, Ronaldo dos S.; DORNELES, Carina F.; KADE, Adrovane; BRAGANHOLO,
Vanessa de P.; HEUSER, Carlos Alberto. Dados semi-estruturados. Simpósio Brasileiro de
Banco de Dados (SBBD) - Tutorial, João Pessoa, 2000.
Disponível em http://www.dcc.ufrj.br/~braganholo/artigos/tutorial.pdf
Acesso em 03/04/2012.
STROZZI, Carlos. NoSQL: A relational database managament system, 1998.
Disponível em: http://www.strozzi.it/cgi-bin/CSA/tw7/I/en_US/NoSQL/Home%20Page
Acesso em: 28/08/2012.
TIWARI, Shashanki. Professional NoSQL. Indianópolis, Editora Wiley, Ed. 1, 2011.
VARDANYAN, Mikayel. Picking the right NoSQL database tool, 2011.
Disponível em http://blog.monitis.com/index.php/2011/05/22/picking-the-right-nosql-database-tool/
Acesso em 01/09/2012