TCC Anderson v04 (Reparado)

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


Cassandra x Oracle:



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


Cassandra x Oracle:



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


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


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/

http://research.google.com/archive/bigtable.html

http://hbase.apache.org/

http://www.mongodb.org/

http://cassandra.apache.org/

http://aws.amazon.com/pt/dynamodb/

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/

http://aws.amazon.com/pt/simpledb/

http://www.couchbase.com/

https://www.mongohq.com/home

http://www.windowsazure.com/pt-br/

http://aws.amazon.com/pt/rds/

28

Figura 7: Modelo Chave/Valor


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/

http://www.oracle.com/technetwork/products/berkeleydb/overview/index.html

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


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


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


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

http://demoiselle.sourceforge.net/docs/guide-cassandra/1.0-v1/html_single/

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


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


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


35

Figura 15: Exemplo de column families


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


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


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


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.


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

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


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


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


41

Figura 23: Create Keyspace utilizando DCE


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


Figura 25: CREATE TABLE utilizando DCE


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


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


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


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

http://www.mzweb.com.br/energisa/web/arquivos/FACT_SHEET_2TRI2012.pdf

45

Figura 29: Processo de envio e acompanhamento de OS's


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


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


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.

http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf

http://computerworld.uol.com.br/tecnologia/2010/02/23/crescimento-faz-twitter-trocar-o-mysql-pelo-cassandra/

http://computerworld.uol.com.br/tecnologia/2010/02/23/crescimento-faz-twitter-trocar-o-mysql-pelo-cassandra/

http://www.lbd.dcc.ufmg.br/colecoes/wtdbd/2010/sbbd_wtd_12.pdf

http://www.datastax.com/dev/blog/whats-new-in-cassandra-1-0-performance

http://www.ime.usp.br/~jef/bd10.pdf%20Acesso%20em%2012/08/2012

http://www.ime.usp.br/~jef/bd10.pdf%20Acesso%20em%2012/08/2012

http://www.addlabs.uff.br/sbsc_site/SBSC2011_NoSQL.pdf

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

http://www.lbd.dcc.ufmg.br:8080/colecoes/sbbd/2001/017.pdf

http://www.dcc.ufrj.br/~braganholo/artigos/tutorial.pdf

http://www.strozzi.it/cgi-bin/CSA/tw7/I/en_US/NoSQL/Home%20Page

http://blog.monitis.com/index.php/2011/05/22/picking-the-right-nosql-database-tool/

TCC Anderson v04 (Reparado)

Documents

Transcript of TCC Anderson v04 (Reparado)