CENTRO UNIVERSITRIO DE JOO PESSOA UNIP PR-REITORIA DE ENSINO DE GRADUAO CURSO DE BACHARELADO EM CINCIA DA COMPUTAO

ANDERSON GUIMARES MARQUES

Cassandra x Oracle: uma anlise prtico-comparativa aplicada ao sistema de gerenciamento otimizado da distribuio eltrica

Joo Pessoa PB 2012

ANDERSON GUIMARES MARQUES

Cassandra x Oracle: uma anlise prtico-comparativa aplicada ao sistema de gerenciamento otimizado da distribuio eltrica

Monografia apresentada ao Curso de Bacharelado em Cincia da Computao do Centro Universitrio de Joo Pessoa Unip, como pr-requisito para a obteno do grau de Bacharel em Cincia da Computao, sob a orientao da Profa. Ms. Ludmila de Almeida Pedrosa.

Joo Pessoa PB 2012

ANDERSON GUIMARES MARQUES

Cassandra x Oracle: uma anlise prtico-comparativa aplicada ao sistema de gerenciamento otimizado da distribuio eltrica

Monografia apresentada ao curso de Bacharelado em Cincia da Computao do Centro Universitrio de Joo Pessoa UNIP, como pr-requisito para a obteno do grau de Bacharel em Cincia da Computao, 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 Porfrio Examinador - UNIP

Dedico este trabalho aos meus pais, Orlando e Penha Marques, e minha querida esposa, Wnea Vasconcelos, pelo imenso suporte, dedicao e disponibilidade.

AGRADECIMENTOS

O primeiro requisito para o sucesso a habilidade de aplicar incessantemente suas energias fsicas 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 transformaes, principalmente quando tratamos de aplicaes cujo volume de dados ultrapassa perspectivas nunca vistas antes. Os bancos de dados relacionais tiveram papel fundamental durante esse processo de mudana, por serem amplamente utilizados em praticamente todos os tipos de sistemas nas ltimas dcadas. Entretanto, esse papel vem dando lugar a mais um protagonista, os sistemas de gerenciamento de dados capazes de atuar em cenrios de alta escalabilidade e disponibilidade das informaes. 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 cientfica (livros, artigos e eventos) e tcnica (blogs, sites e revistas de divulgao tecnolgica), alm de estar sendo adotado, de maneira concreta, por gigantes da TI. Neste trabalho estudaremos as motivaes que levaram as criaes desses novos conceitos e o estado da arte dessa nova tecnologia. Tambm ser realizada uma anlise comparativa entre um SGBD relacional e um NoSQL aplicados ao Sistema de Gerenciamento Otimizado da Distribuio SIGOD, sistema utilizado atualmente no Grupo Energisa. Nessa comparao sero 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 distribudos ACID .................................................................................... 23 Figura 5: BD Distribudo......................................................................................................... 24 Figura 6: Teorema de Brewer - CAP ....................................................................................... 25 Figura 7: Modelo Chave/Valor ............................................................................................... 28 Figura 8: Demonstrando o relacionamento de informaes em grafos ................................... 30 Figura 9: Famlia de colunas dos usurios 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: Evoluo do desempenho no Cassandra ................................................................ 38 Figura 20: Diretrio 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: Mdulo 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: Anlise comparativa NoSQL ................................................................................... 32 Tabela 4: Diretrios do Cassandra .......................................................................................... 39 Tabela 5: Tipos de dados ......................................................................................................... 42

LISTA DE ABREVIATURAS E SIGLAS

ACID Atomicidade, Consistncia, 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 Transaes GD Gerenciador de Dados GR Gerenciador de Recuperao 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 Distribuio SQL Struct Query Language TI Tecnologia da Informao

XML eXtensible Markup Language YAML Yet Another Markup Language

SUMRIO

1 I NTRODUO................................................................................................................. 14 1.1 OBJETIVOS ...................................................................................................................... 15 1.1.1 Objetivo geral ................................................................................................................ 15 1.1.2 Objetivos especficos ..................................................................................................... 16 1.2 ORGANIZAO DO TRABALHO ................................................................................. 16 2 NOSQL: O QUE E POR QUE UTILIZ-LO ............................................................. 17 2.1 CONTEXTO HISTRICO ............................................................................................... 17 2.2 OS DESAFIOS DOS BANCOS DE DADOS RELACIONAIS ........................................ 18 2.2.1 Escalabilidade e a Web 2.0 ............................................................................................ 19 2.3 GERENCIANDO TRANSAES E A INTEGRIDADE DOS DADOS ......................... 22 2.3.1 Sistemas distribudos 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 CONSIDERAES DO CAPTULO ............................................................................... 31 3 CASSANDRA ..................................................................................................................... 33 3.1 O MODELO DOS DADOS NO CASSANDRA ............................................................... 33 3.2 ARQUITETURA ............................................................................................................... 36 3.3 DEFINIO E MANIPULAAO DOS DADOS............................................................. 38 3.3.1 Diretrios do Cassandra ............................................................................................... 39 3.3.2 Comandos bsicos de definio (DDL) ........................................................................ 40 3.3.3 Comandos bsicos de manipulao (DML) ................................................................. 43 4 ESTUDO DE CASO .......................................................................................................... 44 4.1 DESCRIO DO SISTEMA DE GERENCIAMENTO OTIMIZADO DA DISTRIBUIO SIGOD ...................................................................................................... 44 4.1.1 Interface do sistema ...................................................................................................... 46 4.2 MODELAGEM E CENRIO ATUAL DO BANCO DE DADOS ................................... 47 4.3 DIFICULDADES DA APLICAO ................................................................................ 49 4.4 MAPEAMENTO DO BANCO RELACIONAL PARA O MODELO NOSQL ................ 49 4.5 ANLISE COMPARATIVA ............................................................................................ 49 5 CONSIDERAES FINAIS ............................................................................................ 49 REFERNCIAS...................................................................................................................... 50

14

I NTRODUO O rpido crescimento dos sistemas Web e a necessidade de ter um contedo

orientado ao usurio tem provocado um significativo aumento no volume e no tipo de dado gerado, manipulado, analisado e arquivado pelas aplicaes. Esse contedo se caracteriza pela facilidade e disponibilidade dos dados, e informaes que sejam relevantes para o usurio. Tais volumes de conjuntos de dados tem imposto novos desafios e oportunidades em torno do armazenamento e da anlise dos mesmos. Paralelo a esse crescimento, os dados tambm tm se tornado, cada vez mais, semiestruturados e esparsos, ou seja, apresentam uma representao estrutural heterognea, no sendo completamente no estruturados, nem estritamente tipados. Isso difere das caractersticas mantidas por um BD relacional que apresenta esquemas pr-definidos e estruturas homogenias em nvel de atributos e tipos (string, date, etc.) [MELLO et al., 2000]. Dados Web se enquadram nessa definio de semiestruturados: alguns casos com descrio uniforme (um catlogo de produtos), em outros algum padro estrutural pode ser identificado (documentos no formato de artigo), ou ento no existem informaes descritivas associadas (um arquivo de imagem). Pode-se dizer que os dados semiestruturados so representados no prprio dado, ou seja, auto-descritivos [MELLO et al., 2000]. De uma forma geral, podemos citar como exemplo as pginas de sites de livrarias eletrnicas, referncias bibliogrficas, catlogos eletrnicos, sites de previso do tempo e outros. Dados desse tipo so denominados semiestruturados. As solues para resolver tais diferenas entre as estruturas relacionais e semiestruturadas, do ponto de vista do volume e da distribuio 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 tm sido identificados como NoSQL (Not Only SQL), ou seja, no podemos definir essa expresso como sendo de um nico produto ou tipo. Ela representa uma classe de produtos e uma coleo de conceitos de armazenamento e manipulao de dados. Entretanto, preciso mencionar que essa expresso passou por grandes discusses quanto ao seu significado. Nos primeiros conceitos foram utilizadas expresses como No SQL, No RDBMS, No 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 discusso de bancos de dados open source distribudos, se estabeleceu nas pesquisas referente a essa tecnologia. De maneira geral, o termo NoSQL define os bancos de dados que apresentam, em sua maioria, caractersticas no relacionais, distribudos, de cdigo aberto, escalveis horizontalmente, ausncia de esquema ou esquema flexvel, suporte a replicao e acesso via APIs simples [DIANA; GEROSA, 2010]. Os atuais sistemas que se enquadram como NoSQL so bastante variados, cada um deles com caractersticas diferentes. Diante disso, frequentemente, encontramos dificuldades em decidir qual sistema utilizar para certa situao ou certo caso, ao qual propomos uma soluo com bancos de dados no relacionais. Sero abordadas neste trabalho as principais categorias dos bancos de dados NoSQL, afim de se obter os critrios necessrios para tal deciso. Dentre elas foi selecionado uma para ser utilizada no estudo de caso que analisar de forma prtico-comparativa o Oracle (BD relacional) e o Cassandra (NoSQL). Ambos serviro no armazenamento de dados do Sistema de Gerenciamento Otimizado da Distribuio 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 anlise de um banco de dados NoSQL, em especial, o Cassandra, o qual ser abordado mais adiante, e por utilizar dados de vrias fontes e possuir um grande volume de dados. Tal caracterstica 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, alm de alcanar um dos principais fatores na satisfao do usurio com o sistema de banco de dados que o desempenho. Se o tempo de resposta de um sistema muito longo, consequentemente seu valor ser diminudo. Com a anlise ser possvel observar o comportamento do Cassandra submetido ao mesmo ambiente que est submetido o BD Oracle, bem como sua aplicabilidade em sistemas corporativos. 1.1 1.1.1 OBJETIVOS Objetivo geral Analisar comparativamente o banco de dados relacional Oracle e o no-relacional Cassandra aplicados em um sistema de gerenciamento otimizado da distribuio eltrica, a partir do estudo dos bancos de dados NoSQL.

16

1.1.2

Objetivos especficos Fornecer os conceitos essenciais que atuam nas construes dos produtos NoSQL; Realizar um estudo comparativo do desempenho dos bancos de dados Oracle e Cassandra, que sero avaliados pelas ferramentas DataStax Community Edition, JMeter, Benchmark Factory e YCSB. Podero ser verificados fatores como uso do processador, memria, disco, alm de aspectos como performance, escalabilidade, consistncia e disponibilidade.

Desenvolver estudo de caso prtico-comparativo entre bancos de dados NoSQL e bancos de dados relacionais.

1.2

ORGANIZAO DO TRABALHO Os captulos apresentados neste trabalho dividem-se em tpicos e subtpicos,

conforme descrito a seguir. O Captulo 2 apresenta a aplicabilidade e a necessidade dos mtodos NoSQL no armazenamento de dados, bem como a compreenso dos seus conceitos e caractersticas. Tambm sero abordados os principais modelos NoSQL de armazenamento de dados, assim como uma breve comparao entre eles afim de justificar a sua escolha do Cassandra para o estudo proposto. O Captulo 3 trs definies de modelagem, arquitetura e manipulao dos dados utilizados pelo Cassandra. No Captulo 4 descrito o estado atual do sistema de gerenciamento otimizado da distribuio SIGOD e realizado o estudo de caso a partir da utilizao de um banco de dados NoSQL, o Cassandra, comparando-o com o banco de dados relacional Oracle, atual banco de dados do sistema. O Captulo 5 apresenta a concluso e os trabalhos futuros pertinentes ao tema.

17

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 no serem relacionais, ou seja, ao contrrio dos BD relacionais eles lidam com dados no estruturados tais como arquivos de texto, email, multimdia, meios de comunicao social e grandes volumes de dados distribudos. A composio da Web , basicamente, distribuda num grande conjunto de dados semiestruturados, como pginas e websites, descritos em documentos HTML, o que expressa pouco sobre seus contedos. Alm de contedos multimdias, como imagens, sons e vdeos. Alguns autores propem que os dados extrados da Web devam passar por estruturao da sua natureza particular para em seguida armazen-los e manipul-los em bancos de dados relacionais [MELLO et al, 2000][MAGALHES et al, 2001]. Contudo, os BD NoSQL surgem como solues otimizadas, e favorecidas pelas caractersticas 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 HISTRICO Os bancos de dados no relacionais no so uma novidade dentre as tecnologias de armazenamento de dados, na verdade, o surgimento deles nos remete ao tempo em que as mquinas computacionais foram inventadas. Eles tm existido desde os mainframes, em locais especializados, e especificamente em locais de domnio diretrios hierrquicos de armazenamento, autenticao e credenciais de autorizao. No entanto, o mundo NoSQL ganha uma nova roupagem, e nasce em um momento importante da Web, com as aplicaes escalveis, distribudas e paralelas, e a computao nas nuvens. Com o aumento, tanto na velocidade como na conectividade Internet, os usurios passam a ter exigncias mais criteriosas quanto disponibilidade dos dados e de computao. Tais necessidades e mudanas que vem ocorrendo na Web proporcionam aos BD relacionais seu prprio conjunto de problemas quando aplicados a grandes quantidades de dados. Problemas estes relacionados eficincia de processamento, paralelizao eficaz, escalabilidade e custos. [TIWARI, 2011], e que sero abordados na seo 2.2 com mais detalhes.

18

Ao longo dos ltimos anos a empresa Google tem se destacado na construo de infraestruturas altamente escalveis para seu motor de busca e outras aplicaes, incluindo Google Maps, Google Earth, Gmail, Google Finance e Google Apps [TIWARI, 2011]. Uma das primeiras implementaes de um sistema no relacional surgiu em 2004, quando a Google lanou o BigTable, um banco de dados proprietrio de alta performance que tinha como objetivo promover maior escalabilidade e disponibilidade. A ideia central era justamente flexibilizar a forte estruturao utilizada pelo modelo relacional [BRITO, 2010], ou seja, construir uma infraestrutura escalvel para processamento paralelo de grandes quantidades de dados. E para isso se fez necessrio a implementao de um sistema de arquivos distribudo, um armazenamento de dados orientado a coluna de famlia (column-family-oriented), e um sistema distribudo de coordenadas [CHANG et al, 2006]. Estas e outras estruturas sero mais abordadas na seo 2.5, onde tambm sero apontados os principais produtos NoSQL para cada mtodo. Sem entrar tanto na linha exata do tempo, ou na histria de quem cunhou o termo NoSQL, necessrio destacar o surgimento de uma alternativa open source, liderada pelo Google, que lanou as bases para o rpido crescimento do NoSQL, que foi o Hadoop, seus subprojetos, e seus projetos relacionados. Tal sucesso do Google ajudou a impulsionar os conceitos de computao distribuda [TIWARI, 2011]. Algum tempo depois da Google mostrar seus interesses no processamento paralelo escalvel e no armazenamento de dados no relacionais distribudos, a empresa Amazon decidiu compartilhar um pouco da sua histria de sucesso, apresentando ideias de um conjunto de dados distribudos altamente disponveis e, eventualmente consistentes, nomeando o projeto de Amazon Dynamo [TIWARI, 2011]. Com o aval do NoSQL de dois gigantes da Web vrios novos produtos surgiram neste espao e muitos desenvolvedores comearam a usar seus mtodos em suas aplicaes, empresas e corporaes. 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 tambm tem contribudo com cdigo 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 no esto direcionados apenas a um produto ou sistema de gerenciamento, mas estende-se a toda sua classe, ou seja, est nas caractersticas e nos mtodos que o armazenamento de grandes volumes de dados na Web

19

vem formando. Conforme abordado no incio deste captulo, 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-relaes bem estabelecidas e sistematicamente referenciadas. Esses bancos tambm pressupem que os ndices podem ser consistentemente definidos em conjuntos de dados e que esses ndices podem ser uniformemente alavancados para uma pesquisa mais rpida e com um significativo ganho de performance [TIWARI, 2011]. Os SGBDs relacionais proporcionam aos usurios processos de validao, verificao e garantia da integridade dos dados, do controle de concorrncias, da recuperao de falhas, da segurana, do controle de transaes, da otimizao de consultas, etc.. Outra caracterstica importante do modelo relacional o processo de normalizao, que tem como objetivo aplicar regras sobre as tabelas do banco de dados, a fim de garantir a estruturao do projeto. Todos esses recursos ajudaram a manter os SGBDs relacionais em posio de destaque at ento. Entretanto, no conseguiram impedir o surgimento de certos problemas, principalmente devido ao crescimento acelerado dos volumes de dados presentes nos bancos de certas organizaes. De maneira geral esses problemas esto concentrados na dificuldade em conciliar tal modelo com a demanda por escalabilidade. Seus conceitos principais sero apresentados com mais detalhes na seo a seguir. 2.2.1 Escalabilidade e a Web 2.0 No correto afirmar que os SGBDs relacionais no so escalveis, mas o fato que essa no uma tarefa trivial. Vejamos, no esquema abaixo, uma demonstrao de uma aplicao Web evoluindo no volume de dados: Na Figura 1 vemos uma arquitetura simples de uma aplicao Web. Com o crescente aumento da massa de dados e medida que o sistema passa a receber um nmero maior de usurios, comeam a surgir os primeiros problemas de escalabilidade. Nesse momento, sem alterar a estrutura da referida figura, realizamos um upgrade no servidor, aumentando memria, processador e armazenamento; tal tcnica conhecida como Escalabilidade Vertical (scale up). Com essa tcnica se mantm os dados confiveis e concentrados num nico n, e utilizam-se as mesmas configuraes no sistema. Contudo,

20

existe um limite de capacidade do equipamento e, por que no, do prprio oramento durante as mudanas. Figura 1: Arquitetura Tradicional

Fonte: Prprio Autor A segunda opo seria utilizar a tcnica de Escalabilidade Horizontal (scale out), aumentando o nmero de servidores Web, conforme demonstrado na Figura 2. Nesse formato possvel alcanar nveis 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 utilizao direcionada s camadas das aplicaes, em especial para as aplicaes Web [BRITO, 2010]. Figura 2: Escalabilidade Horizontal

Fonte: Prprio Autor A abordagem de esquema compartilhado nos remete a projetar sistemas levando em considerao que eles necessitaro ser escalados quando no puderem mais atender s mtricas de desempenho de linha de base, como ocorre nas situaes mencionadas no incio desta seo, quando h aumento de usurios acessando o banco de dados simultaneamente ou quando o tamanho do banco de dados faz com que as consultas e atualizaes levem muito tempo para serem executadas.

21

Uma das formas mais utilizadas para lidar com essas situaes de escalabilidade em bancos de dados o sharding, que consiste de escalonar o prprio banco de dados, como pode ser visto na Figura 3. Figura 3: Esquema de Sharding

Fonte: Prprio Autor Essa tcnica 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 operaes que no dependam dos dados contidos naquele n, alm da sensvel minimizao do volume de dados por mquina devido o processo de distribuio. Contudo, essa abordagem vai de encontro com as caractersticas dos SGBDs relacionais, dado a sua dificuldade de adaptao estrutura lgica do modelo relacional. Os SGBDs relacionais utilizam a estratgia da escalabilidade vertical, reforando o servidor, diferentemente do sharding que trabalha com a escalabilidade horizontal, controlando seus dados de forma paralela em vrios servidores. Outro ponto importante quanto a obedincia aos critrios de normalizao, j que o processo de sharding tem caracterstica inversa, ou seja, a desnormalizao dos dados [BRITO, 2010]. Entretanto preciso destacar que o processo de sharding em BDs relacionais uma tarefa possvel de ser implementada, mas que retira deles a capacidade lidar com restries de dados, a realizao de junes de forma transparente, e de oferecer algumas de suas principais funcionalidades aos desenvolvedores de aplicaes [DIANA; GEROSA, 2010]. Em 2008 a rede social Twitter cogitou a utilizao dos conceitos de sharding na sua base de dados em MySQL. Entretanto as opes apresentadas por produtos NoSQL, em especial o Cassandra, se destacaram por serem mais escalveis e mais fceis de gerenciar do que as demais alternativas. Segundo Ryan King, engenheiro do Twitter, esses fatores influenciaram significativamente na deciso da empresa em mudar sua base de dados do MySQL para o Cassandra. O cluster de servidores MySQL, com um sistema de cache em memria, se tornou proibitivo, ou seja, alm do aceitvel com relao aos custos. Com isso a

22

empresa necessitou de um sistema capaz de crescer de forma mais automtica e com alta disponibilidade. O Cassandra proveu essa soluo e recebeu a migrao da maior, e talvez a mais dolorosa de manter, tabela. A tabela de status, que contm todos os tweets e retweets. Depois disso os novos projetos e a migrao de outras tabelas passaram a ser implantadas no Cassandra. Somente depois de mais testes o Twitter deixar o Cassandra em produo e desativar o MySQL [COMPUTER WORLD, 2010]. 2.3 GERENCIANDO TRANSAES E A INTEGRIDADE DOS DADOS Para entendermos transaes e integridade dos dados no mundo NoSQL, precisamos, antes, compreender a similaridade desses conceitos no ambiente relacional. Uma vez abordado essas noes ficar mais fcil de conceber como os conceitos transacionais so desafiados em grande escala nos ambientes distribudos, lugar onde se destaca os BDs NoSQL. ACID, que significa Atomicidade, Consistncia, Isolamento e Durabilidade, tornou-se o padro para se definir o mais alto nvel de integridade transacional em sistemas de banco de dados, bem como os requisitos necessrios que devem ser atendidos por uma transao [TIWARI, 2011]. Atomicidade: Conhecida como a propriedade do tudo ou nada, durante a operao de transao, nada do que inconsistente entre dois estados deve ser aceitvel. Por exemplo, uma transferncia bancria entre a conta A e B. Essa operao envolve duas etapas, dbito e crdito. A atomicidade implica que se, por alguma razo, o dbito obtiver sucesso e em seguida operao de crdito falhar, toda operao revertida ao estado anterior, ou seja, o estado inconsistente evitado. Quando ocorrer o sucesso a transao pode ser persistida em banco. Consistncia: Implica na obedincia a todas as regras e restries definidas no banco de dados, como validaes no tipo, relacionamentos por chaves estrangeiras, etc. Ou seja, uma transao deve conduzir um BD de um estado consistente para outro estado tambm consistente. Isolamento: As transaes devem funcionar completamente a parte, ou seja, relevante que os dados sejam acessados simultaneamente sem sofrer interferncia de operaes concorrentes. Pois com dois processos ou segmentos independentes manipulando o mesmo conjunto de dados, possvel que um interfira na transao do outro e ocorram falhas.

23

Durabilidade: Implica em tornar permanente o resultado de uma transao, ou seja, a operao transacional confirmada e assegurada. Deve-se garantir que as modificaes realizadas por uma transao 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 aplicao, reside num nico servidor ou n. Contudo, a partir do momento que os componentes dessa pilha so distribudos a mltiplos ns, passamos a encontrar dificuldades em implantar tais conceitos [TIWARI, 2011]. Passados os conceitos de ACID estamos prontos para explorar como esses fundamentos so aplicados em sistemas altamente distribudos. 2.3.1 Sistemas distribudos ACID Sistemas distribudos so conhecidos por suas diferentes formas, tamanhos, caractersticas tpicas, e so expostos a complicaes semelhantes. Consequentemente, quanto maior e mais distribudo for o sistema, maiores so os desafios, e as dificuldades se multiplicam. A Figura 4 demonstra, de forma simples, como esses sistemas esto estruturados. Temos duas aplicaes ligadas base de dados diferentes e todas s quatro peas de execuo em mquinas separadas. Figura 4: Sistemas distribudos ACID

Fonte: TIWARI (2011, p. 173) O desafio de oferecer o ACID no uma tarefa trivial, em sistemas distribudos esses princpios so aplicados utilizando conceitos previstos pelo XA (padro para processamento de transao distribuda especificada pelo consrcio X/Open), ou seja, utilizando um gerenciador de transaes distribudas ou gerenciador global de transaes. Contudo, mesmo com um coordenador central de isolamento, a implementao em vrias bases de dados extremamente difcil. Isto ocorre por causa da necessidade em garantir o

24

isolamento distribudo. Algumas tcnicas como two-phase-locking e two-phase-commit ajudam na diminuio dessas dificuldades [TIWARI, 2011]. No entanto, estas tcnicas levam ao bloqueio de operaes e a disponibilidade de partes do sistema durante os estados do processo de transao. Como pode ser visto na Figura 5, que exemplifica bem o cenrio utilizado por bancos de dados distribudos, as transaes no SGBD passam por um gerenciador de transaes (GT), que as encaminha para um escalonador, responsvel por decidir qual o processo que ser executado, de forma a proporcionar a iluso de execuo simultnea, e direcionar ao gerenciador de dados (GD). Este por sua vez, contm dois importantes componentes, o gerenciador de recuperao (GR) e o gerenciador de memria (GM), responsveis por acessar diretamente os dados e manter as combinaes, o controle de atualizaes imediatas e postergadas, e os pontos de confirmao do registro de log [FERREIRA; TAKAI, 2006]. Figura 5: BD Distribudo

Fonte: FERREIRA, TAKAI (2006) Em transaes de longa durao, as transaes baseadas em XA no funcionam devidamente, como por exemplo, mantendo os recursos bloqueados por um longo tempo. Por outro lado, existem estratgias alternativas, como operaes de compensao, que ajudam a implementar a fidelidade transacional em transaes distribudas de longa durao. Os desafios de indisponibilidade de recursos em transaes de longa durao aparecem diversos cenrios. Os problemas maiores ocorrem, especialmente, em ambientes onde mnima a tolerncia indisponibilidade de recursos e a queda do sistema. Uma maneira de avaliar os problemas envolvidos pela garantia ACID em sistemas distribudos entendendo trs fatores importantes: Consistncia, disponibilidade e tolerncia a particionamento. Estes fatores so os trs pilares do teorema de Brewer ou Brewes Theorem (CAP Consistency, Availability e Partition Tolerance), onde consistncia significa que uma

25

vez escrito um registro, este deve ficar disponvel para ser utilizado imediatamente. Availability ou disponibilidade refere-se concepo de assegurar que um sistema permanea ativo e por ltimo a tolerncia a particionamento ou falha, onde caracteriza um sistema por continuar a operar na presena de uma falha na rede [TIWARI, 2011]. Os princpios desse conceito esto em torno da integridade transacional escalvel e em sistemas distribudos. Ele afirma que em sistemas distribudos impossvel alcanar todos os trs fatores, ou seja, somente dois desses podem ser garantidos ao mesmo tempo. A Figura 6 demonstra essa relao entre os pilares do teorema de Brewer, de forma que necessrio sacrificar pelo menos um em favor dos outros dois. Isso diferente nos bancos de dados tradicionais, que no possuem essas caractersticas no design do sistema ou delegam isso para o sistema de arquivos (filesystem). Poder particionar os dados em diferente ns de um cluster um dos recursos que aparecem com frequncia nos bancos NoSQL [BREWER, 2000]. Figura 6: Teorema de Brewer - CAP

Disponibilidade (Availability)

CA N/A

AP

Consistncia (Consistancy)

CP

Tolerncia a Particionamento (Partition Tolerance)

Fonte: BREWER (2000) Sistemas NoSQL CP: Para sistemas que precisam da consistncia forte e tolerncia a particionamento, abrindo mo de parte da disponibilidade. Pode acontecer, caso haja particionamento e o sistema no entre em consenso, que uma escrita seja rejeitada. Os sistemas em sua maioria tentam evitar isso ao mximo, tanto que no normal a existncia de transaes distribudas e sim protocolos de consenso (algoritmos de gerenciamento e resoluo de consenso). A necessidade desses protocolos advm de sistemas distribudos, nos quais os processos precisam cooperar na realizao de tarefas a fim de garantir a progresso do sistema e os resultados corretos. De forma que os processos se comuniquem

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 confirmao [BREWER, 2000] [GODOI, 2007]. Exemplos desses sistemas so BigTable1, HBase2 e MongoDB3. Sistemas NoSQL AP: Representam os sistemas que jamais podem ficar offline, portanto no desejam sacrificar a disponibilidade. E para ter alta disponibilidade, mesmo com a tolerncia a particionamento, preciso prejudicar a consistncia. No podemos dizer que seria uma total inconsistncia, mas a ideia que os sistemas aceitem escritas sempre e tentam sincronizar os dados em algum momento depois, podendo, ento, ter uma janela de inconsistncia [BREWER, 2000]. Exemplos so o Cassandra 4, o Dynamo5 e o Riak6. Sistemas NoSQL CA: So os sistemas com consistncia forte e alta disponibilidade. Eles no sabem lidar com uma possvel falha de uma partio. Caso ocorra, o sistema inteiro pode ficar indisponvel at o membro do cluster voltar. Exemplos disso so algumas configuraes clssicas de bancos de dados relacionais [BREWER, 2000]. O processamento paralelo e fora de escala so mtodos comprovados e esto sendo adotados como modelos para escalabilidade e alto desempenho ao invs de ir aumentando gradualmente e construindo enormes super computadores. Os ltimos anos tem mostrado que estruturar esses enormes computadores caro e pouco prtico na maioria dos casos [TIWARI, 2011]. Adicionar um nmero de unidades de hardware em cluster e faz-los trabalhar em conjunto uma eficiente relao entre custo, recursos eficazes e solues eficientes. O surgimento da computao nas nuvens um testemunho desse fato. 2.4 USANDO NOSQL NA NUVEM Atualmente, a gerao de aplicativos populares, como os da Google e Amazon, alcanaram alta disponibilidade e capacidade para milhes de usurios em servios simultneos. Com expanso horizontal entre vrias mquinas, espalhadas por vrios centros de dados. Essas histrias de sucesso em aplicaes Web de grande escala, provam que, em ambientes escalados horizontalmente, solues NoSQL tendem a se destacar sobre os RDBMS. Tais ambientes foram batizados de nuvem e se escalabilidade e disponibilidade so sua prioridade, NoSQL , possivelmente, a configurao ideal para eles. Contudo, seria

1 2

http://research.google.com/archive/bigtable.html 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 situaes, tanto o relacional como o no-relacional, so utilizados em combinao. Depende muito da escala necessria, da estrutura dos dados e das expectativas de integridade transacional da aplicao. Algumas opes de NoSQL na nuvem so 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 computao em nuvem tem passado por um crescimento contnuo, e cada vez mais propensa a adoo dos servios dos bancos de dados na nuvem, os produtos NoSQL tendem a alavancar ainda mais, ou seja, proporcionando a muitos desenvolvedores a oportunidade de comear a pensar num banco de dados como um servio de persistncia [TIWARI, 2011]. 2.5 PRINCIPAIS MODELOS DE ARMAZENAMENTO DE DADOS NOSQL Nesta seo abordaremos os tipos mais comuns de bancos de dados NoSQL, apresentando suas diferenas bsicas com os bancos de dados relacionais, as principais implementaes e seu contexto na Web. 2.5.1 Key/value stores (chave/valor) Nesse modelo os dados so 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 binrio. Tais estruturas so extremamente populares porque fornecem eficincia quanto a disponibilidade de acesso aos dados, ou seja, tempo constante de execuo. Alguns mantm os dados na memria 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 operaes de manipulao so bem simples, como get() e set(), que permitem retornar e capturar valores [LSCIO; OLIVEIRA; PONTES, 2011].

7 8

http://aws.amazon.com/pt/simpledb/ 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: Prprio Autor Dentre os bancos de dados NoSQL, so os que suportam mais carga de dados e que possuem maior escalabilidade, entretanto no permitem a recuperao de objetos por meio de consultas mais complexas. Alguns exemplos so BerkeleyDB12, SimpleDB e Voldemort13. 2.5.2 Document databases (orientado a documentos) O modelo orientado a documentos so colees 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 indexao de documentos no s pelo identificador, mas tambm por suas propriedades, e a elaborao 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 [LSCIO; OLIVEIRA; PONTES, 2011]. Dentre os bancos de dados orientados a documentos temos o MongoDB e o CoucheDB. Os bancos de dados orientados a documentos esto tomando cada vez mais fora no mbito comercial. Entre suas principais caractersticas, est a escalabilidade vertical de fcil manuteno e instalao, no grava campos em branco, rpido e flexvel. Todavia eles apresentam replicao desnecessria, pouca documentao, possveis frustraes na modelagem do projeto e os desenvolvedores podem se confundir facilmente [MATTEUSSI,
12 13

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 manipulao de dados, a utilizao desses sistemas pode ser a soluo mais adequada. Exemplificando o agrupamento das informaes 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 orientao a documento. Tabela 1: Tabela Relacional
Id 1 2 3 4 Nome Joo Lisa Pedro Carla Sobrenome Gomes Dias Santos Azevedo Idade 28 25 29 31

Fonte: Prprio Autor Tabela 2: Orientado a Documento

Id: 1 Nome: Joo Sobrenome: Gomes Idade: 28 Id: 3 Nome: Pedro Sobrenome: Santos Idade: 28 Id: 2 Nome: Lisa Sobrenome: Dias Idade: 25 Id: 4 Nome: Carla Sobrenome: Azevedo Idade: 31

Fonte: Prprio Autor 2.5.3 Graph databases (orientado a grafo) A adoo de um banco de dados orientados a grafos, assim como qualquer soluo NoSQL, passa fatores bastante comuns, como necessidade de alta escalabilidade e disponibilidade, flexibilidade de esquema e ganho de desempenho. Eles permitem a criao de modelos de dados extremamente complexos e, ainda, manter uma considervel facilidade em pesquisar dados. Aliado a isso esto as caractersticas que tornaram os bancos de dados relacionais ferramentas to reconhecidas no mercado, como transaes ACID e linguagens simples de pesquisa. Este modelo possui trs componentes bsicos: os ns (so as vrtices dos grafos), os relacionamentos (so as arestas) e as propriedades (atributos) dos ns, conforme possvel observar na Figura 8 [LSCIO; OLIVEIRA; PONTES, 2011]. Nela est indicado que uma pessoa possui interesse em determinados produtos. Que por sua vez possuem relao

30

com uma categoria. O cliente se relaciona com a compra e tambm pode possuir relacionamentos com outros clientes. Cada n possui propriedades e so interligados pelas setas de relacionamento. Estes tambm podem possuir propriedades, como por exemplo, o nvel de interesse do cliente, nesse caso podendo ser de 1 a 5. Com uma complexidade maior, esses bancos de dados guardam objetos, e no registros como os outros tipos de sistemas NoSQL. As buscas nesse formato de banco de dados so realizadas atravs da navegao desses objetos. Alguns exemplos que utilizam esses conceitos so: Neo4J, BigData e InfoGrid. Figura 8: Demonstrando o relacionamento de informaes 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 espao por valores nulos. Simplesmente por no armazenar uma coluna quando um valor no 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 primrio, muitas vezes referida como chave primria [TIWARI, 2011]. Bigtable e seus clones so exemplos de uso dessa metodologia. Eles tendem a chamar essa chave primria de linha de chave (row-key). Alm disso, as unidades de dados so ordenadas com base nessa linha de chave. A ideia no salvar os dados em linhas, como estamos acostumados pelos bancos relacionais. Os dados sero salvos atravs de colunas e no oferecem junes e chave composta. Com orientao a colunas tambm podemos aplicar, de forma mais fcil, projees 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 no precisar ter todas as colunas da outra linha. Cada linha tem uma chave nica, o que torna os seus dados acessveis. Assim, embora no seja errado dizer que o Cassandra seja orientado a coluna, mais til pensarmos nisso como uma indexao, como pode ser visto na Figura 9. Abordaremos os conceitos do Cassandra, com mais detalhes, no prximo captulo. Figura 9: Famlia de colunas dos usurios do Twitter

Fonte: http://demoiselle.sourceforge.net/docs/guide-cassandra/1.0-v1/html_single/ O BD relacional possui como caracterstica a orientao a linhas, ou seja, os dados so armazenados em uma linha e aps o ltimo elemento dessa linha vem o primeiro elemento da linha seguinte. Enquanto que o BD orientado a coluna armazena a mesma coluna em sequncia, com o final de uma coluna seguida do primeiro elemento da coluna seguinte [TIWARI, 2011]. possvel observar uma tabela simples na Figura 10: Tabela. Em um BD relacional estes dados seriam armazenados da seguinte maneira: 1, 321. Antnio Marcos, 87651, Maria Antonieta; 2, 123, Joo 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; Antnio Marcos, Joo Nunes; Anderson Guimares; 87651... Figura 10: Tabela de dados

Fonte: Prprio Autor 2.6 CONSIDERAES DO CAPTULO Os conceitos apresentados neste captulo denotam a importncia de conhecer bem as ferramentas de armazenamento do NoSQL j que, pela variedade, torna-se difcil comparlas e decidir por qual soluo aplicar. Dessa forma importante considerar quais so as necessidades computacionais do cenrio em que sero 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, necessria uma anlise

32

comparativa entre os principais modelos NoSQL disponveis afim de decidir corretamente qual aplicar. Tabela 3: Anlise comparativa NoSQL Modelo Aplicaes Tpicas Cache de contedo (Foco em escalar para imensas quantidades de dado, criado para lidar com carregamento massio), logging etc. Aplicaes Web (Similar ao armazenamento chave valor, mas o banco de dados sabe qual o valor). Redes sociais, recomendaes (foco em modelar as estruturas dos dados, interconectividade). Pontos Fortes Pontos Fracos

Armazenamento Chave/Valor (Key/value stores).

Pesquisas rpidas.

Dados armazenados no tem esquema.

Armazenamento orientado a documentos (Document databases)

Tolerante a dados incompletos

Query performance, sem sintaxe de consulta padro.

Armazenamento orientado a grafos (Graph databases)

Armazenamento orientado a colunas (Column oriented store)

Algoritmos grficos, como caminho mais curto, conectividade, relacionamentos, etc. Pesquisas rpidas, Sistemas de arquivos boa distribuio de distribudos armazenamento de dados. Fonte: VARDANYAN (2011)

Tem que atravessar todo o grfico para obter uma resposta definitiva. No fcil de agrupar.

API de baixo nvel.

Para o estudo de caso deste trabalho o modelo NoSQL adotado foi o armazenamento orientado a colunas por atender melhor as necessidades da aplicao, como pesquisas mais rpidas, distribuio e projees sobre os dados, e apresentar caractersticas semelhantes aos modelos relacionais, o que facilita sua implementao 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 operaes de escrita no armazenamento e processar grandes quantidades de dados distribudos em muitas mquinas. Seus conceitos e caractersticas sero mais bem abordados no captulo 3.

33

CASSANDRA O Apache Cassandra um sistema de armazenamento de dados distribudos,

orientado a coluna, open source, que se difere dos SGBDs relacionais. Criado no Facebook e tem sido utilizado em produo por vrias empresas da Web, incluindo o prprio Facebook, o Twitter, a Cisco, a Digg, entre outras. Sua popularidade se destaca por caractersticas como fcil escalabilidade, consistncia, rpida execuo, alta disponibilidade, poder de armazenamento e ofere um esquema livre de modelo de dados. preciso destacar que, embora no seja incorreto referir o Cassandra como orientado a coluna, ele no relacional. Ou seja, para qualquer determinada linha possvel ter uma ou mais colunas, no precisando ter as mesmas colunas das outras linhas, como um modelo relacional. mais fcil pensar nisso como uma indexao, onde cada linha tem uma chave nica que torna seus dados acessveis. Isto significa que no necessrio 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 cenrios onde existem mudanas no negcio, adio ou alterao nas caractersticas com frequncia, utilizao de metodologia gil onde no possvel levar meses para uma anlise, e principalmente adicionar ou remover campos sem interromper o servio [HEWITT, 2011].

3.1 O MODELO DOS DADOS NO CASSANDRA

De maneira simples um banco de dados relacional possui a prpria base de dados, que contm tabelas, nomeadas, e nelas existem uma ou mais colunas, que tambm 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 no tenham valor. Mais tarde esses dados podem ser consultados ou atualizados utilizando expresses SQL que atendam aos critrios da linha como identificadores, chaves primrias, 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

Fonte: Prprio Autor

34

Por no informar muito sobre seu significado necessrio acrescentar identificadores, ou seja, nomes as valores de forma a combinar com cada um coforme representado na Figura 12. Com isso possvel saber os nomes de cada valor, sendo uma estrutura um pouco mais rica de se trabalhar. Figura 12: Mapa nome/valor

Fonte: Prprio Autor Contudo, mesmo sendo uma melhoria, essa estrutura s funciona com instncias de determinadas entidades, como por exemplo, pessoa, usurio e etc., no permitindo armazenar vrias entidades com a mesma estrutura. O conjunto nome/valor representa a estrutura bsica contida no Cassandra, a Column ou coluna, acrescida de um timestamp que fornece quando foi a ltima atualizao (Ver Figura 13). Figura 13: A estrutura de uma coluna

Fonte: HEWITT (2011) Nesse momento necessrio algo que agrupe as colunas de forma enderevel, ou seja, uma linha que possua um identificador (Row Key). O Cassandra define algo chamado de Column Family ou famlia de colunas, que representa um agrupamento lgico de dados semelhantes, algo anlogo as tabelas no modelo relacional. De forma resumida as estruturas bsicas do Cassandra so: Column (Coluna) e a Column Family (famlia de Coluna) que armazena linhas de semelhantes, mas no iguais, e conjuntos de colunas como possvel 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

Msicos: Jorge: email: jorge@jgrock.com instrumento: baixo Cludio: instrumento: guitarra Banda: Jorge: telefone: 8855-9977 ColumnFamily 1 RowKey 1 ColumnName: Valor ColumnName: Valor RowKey 2 ColumnName: Valor ColumnFamily 2 RowKey 1 ColumnName: Valor

Fonte: Prprio Autor O Cassandra permite a criao de outra dimenso 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 coleo de pares nome/valor, ou seja, Row Key endereando uma coluna que aponta para o valor, enquanto a Super Column Family contm a Row Key apontando para uma coluna, que aponta para subcolunas. Estas endeream o valor, ou seja, uma linha na Super Column Family que contm colunas, cada uma contendo subcolunas como descrito na Figura 16 [HEWITT, 2011]. Figura 16: Super Column Family

Fonte: HEWITT (2011) A seo 3.2 abordar detalhes sobre as configuraes do Cassandra, mas a princpio importante definir que o Cassandra provavelmente no a melhor escolha quando tratamos de armazenamento de dados em um nico n, por ter sido especificado para ser distribudo sobre vrias mquinas operando como uma nica instncia ao usurio final, ou seja, sua estrutura mais externa o cluster, chamado de anel, por atribuir os dados ns do cluster, organizando-os em um anel. Cada n mantm uma rplica para diferentes faixas de dados, de maneira que se um estiver indisponvel existe outro para responder as solicitaes [HEWITT, 2011].

36

Nesse contexto, o cluster um armazenador de Keyspaces que so as responsveis 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 semelhana entre o modelo de dados do Cassandra e do BD relacional. Figura 17: Keyspace
Base de dados no relacional Tabela no relacional

Fonte: Prprio Autor

3.2 ARQUITETURA
No Microsoft SQL Server duas bases de dados so mantidas, a master usada para manter informaes sobre espao em disco, utilizao, configuraes do sistema, e as notas gerais de instalao do servidor. E tempdb onde so armazenados resultados intermedirios 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 operaes e no armazenamento de metadados, que so um conjunto de dados que descrevem outros dados, algo semelhante a um dicionrio de dados. Estes metadados possuem informaes como o nome do n e do cluster, definies de keyspace e esquema para suportar o carregamento dinmico, onde as definies de esquema so armazenadas em duas column families, CF schema (usurios, migraes, etc.) e CF records (registros das alteraes feitas). Esta keyspace interna no permite modificaes [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 ns so 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 alterao existente repassando aos ns escravos. Estes, por sua vez, so submetidos a atualizar seus dados com o mestre [HEWITT; TIWARI, 2011].

37

Por outro lado, o Cassandra tem um modelo de distribuio peer-to-peer, de forma que qualquer n possui a mesma estrutura do outro, ou seja, no h um mestre que atua de forma diferente aos demais ns, como observado na Figura 18. Isso o torna extremamente escalvel e tolerante a falhas deixando o n ainda disponvel para leituras e escritas. Contudo, extrema escalabilidade possui um custo, que neste caso a fraca consistncia proporcionada pelo modelo peer-to-peer, mas que no caracteriza uma total inconsistncia [TIWARI, 2011]. Figura 18: Rede Peer-To-Peer

Fonte: Prprio Autor A facilidade em escalar permite que novos ns sejam adicionados de forma mais simples, ou seja, por possurem comportamentos idnticos, para adicionar um novo servidor, basta inseri-lo ao cluster. O novo n no aceitar imediatamente os pedidos, pois necessita aprender a topologia da rede e tambm aceitar a responsabilidade pelos dados. Isso ocorre, em boa parte, de maneira automtica. 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 escalvel, mas que possui uma eventual consistncia necessita de um protocolo de comunicao para detectar possveis falhas entre os ns. O Cassandra se baseia na utilizao do Gossip, que como a prpria traduo do termo sugere, algo semelhante a uma fofoca humana, cujo objetivo detectar possveis falhas utilizando mensagens que so propagadas pela rede. Isto ocorre de maneira sistemtica 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 confirmao ao Gossiper. Se durante este processo a comunicao falhar isso indica que possivelmente o

38

n esta indisponvel, ou seja, o Gossiper possui uma lista dos ns que esto ativos e inativos [TIWARI, 2011]. O protocolo Gossip comumente empregado em grandes sistemas que possuem redes descentralizadas e muitas vezes usado como um mecanismo automtico de replicao em bases de dados distribudas [HEWITT, 2011].

3.3 DEFINIO E MANIPULAAO DOS DADOS

At a verso 0.6 do Cassandra suas configuraes e definies de keyspaces, clusters, colomn families, eram atravs do arquivo conf.xml, e que posteriormente foi convertido para YAML. A partir da verso 0.7 essas configuraes e definies passaram a ser realizadas atravs da API Thrift ou interface de linha de comando (cassandra-cli) como cliente padro, dando suporte a operaes de DDL Data Definition Language, de forma semelhante ao SQL. Contudo, um importante conceito foi inserido a partir da verso 0.8, uma linguagem extremamente parecida com o SQL, chamada CQL, que foi definida em duas especificaes: CQL 2.0 e CQL 3.0. Ambas com suporte a colunas dinmicas, contudo apenas a especificao CQL 3.0 d suporte a chave primria compostas. [HEWITT, 2011]. necessrio destacar que, a cada nova verso, o Cassandra tem evoludo consideravelmente em aspectos como compresso de dados, gerenciamento de memria e disco, nvel de compactao, e principalmente desempenho (escrita e leitura), quando comparado a verso 0.6 e verso 1.0 (2010), conforme demonstrado na Figura 19 [ELLIS, 2011]. Figura 19: Evoluo do desempenho no Cassandra

Fonte: ELLIS (2011)

39

3.3.1

Diretrios do Cassandra O Cassandra obtido atravs do cdigo fonte (podendo ser compilado na prpria

mquina) e atravs dos arquivos binrios, que depois de descompactado resulta no diretrio principal (apache-cassandra-x.x.x) da verso, dividindo-se em 7 subdiretrios conforme definidos na Tabela 4: Tabela 4: Diretrios do Cassandra Diretrio bin Descrio Contm os executveis que inicializam o Cassandra Server, Client e os utilitrios para inspeo e configurao de clusters. Onde se encontram todos os arquivos de configurao do Cassandra, conf como diretrios de armazenamento, nomes de keyspaces e column families, logs. interface javadoc lib Contm o arquivo cassandra.thrift, que a API cliente. Encontra-se a documentao gerada pelas classes do Java. Contm todas as bibliotecas externas que o Cassandra utiliza no seu funcionamento como Json, Collections Google, e Apache Commons. Por possuir sua prpria linguagem de consulta chamada CQL, as verses pylib mais recentes possuem esse diretrio que contm alguns drives do CQL para python. Contm ferramentas que o Cassandra disponibiliza como, por exemplo, o tools cassandra-stress, que uma ferramenta feita em Java para a realizao de testes de stress em um cluster. Fonte: Prprio Autor Contudo, existe uma importante soluo gratuita disponibilizada pela empresa Datastax. A DataStax Community Edition 14 - (DCE) uma ferramenta Web que consiste de componentes como a verso atual do Apache Cassandra, Ops Center Community Edition, como a primeira soluo 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 definio e manipulao dos dados so bens semelhantes aos utilizados em SQL e sero vistos nas sees 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: Diretrio Datastax Community Edition

Fonte: Prprio Autor 3.3.2 Comandos bsicos de definio (DDL) Os comandos bsicos da linguagem podem ser observados executando o comando

help conforme Figura 21. Figura 21: Comandos CQL

Fonte: Prprio Autor CREATE KEYSPACE: Utilizado na criao da base de dados (Figura 22). A mesma operao utilizando a DataStax Community Edition pode ser visto na Figura 23. Figura 22: Create Keyspace

Fonte: Prprio Autor

41

Figura 23: Create Keyspace utilizando DCE

Fonte: Prprio Autor CREATE TABLE: Utilizado na criao 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 padro (standard) ou super (super), compare_with e default_validation_class, que so classificaes que a CF pode possuir para efeitos de comparao e ordem de classificao (AsciiType, BytesType, LexicalUUIDType, IntegerType, LongType, TimeUUIDType, ou UTF8Type). Figura 24: CREATE TABLE

Fonte: Prprio Autor Figura 25: CREATE TABLE utilizando DCE

Fonte: Prprio 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 definies sejam realizadas de maneira mais gil. A Figura 26 demonstra a utilizao desta ferramenta e a possibilidade de ter uma viso mais ampla das estruturas existentes e da modelagem da base de dados. Figura 26: Datastax Opscenter Edition - Modelagem

Fonte: Prprio Autor Na criao das column families os tipos de dados podem ser definidos conforme a Tabela 5. Tabela 5: Tipos de dados
Tipo CQL ascii bigint blob boolean counter decimal double float int text timestamp uuid varchar varint Descrio US-ASCII caracteres string 64 bits Bytes arbitrrios (sem validao), expressos em hexadecimal Verdadeiro ou falso Distribudo valor do contador (64 bits de comprimento) Varivel de preciso decimal 64 bits ponto flutuante IEEE-754 32 bits de ponto flutuante IEEE-754 Inteiro de 32 bits UTF-8 string codificada Data/hora, codificados como 8 bytes Tipo 1 ou 4 UUID UTF-8 string codificada De preciso arbitrria inteira

Fonte: Documentao do Apache Cassandra 1.0

43

3.3.3

Comandos bsicos de manipulao (DML) O SQL contm comandos bsicos de manipulao 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 insero de dados e uma consulta logo em seguida. Figura 27: Insert e Select utilizando CQL

Fonte: Prprio Autor Os dados existentes nas column families tambm podem ser consultados utilizando a funcionalidade DATA EXPLORER da Datastax OpsCenter Comunity, conforme a Figura 28 Figura 28: Data Explorer

Fonte: Prprio Autor

44

ESTUDO DE CASO O sistema de gerenciamento otimizado da distribuio SIGOD utilizado

atualmente pelo Grupo Energisa. Empresa que atua nas reas de distribuio, transmisso e comercializao de energia eltrica, concentrada principalmente nos estados de Sergipe, Paraba, Minas Gerais e Rio de Janeiro. Segundo a mesma, cobrindo uma rea de aproximadamente 91.180 Km e 5.205 GWh de energia distribuda, atendendo a cerca de 2,5 milhes de clientes 15. Tal caracterstica de crescimento dos consumidores acarreta na necessidade de oferecer servios cada vez melhores e geis, utilizando tecnologias eficientes. Uma destas melhorias se refere ao atendimento de ordens de servio (OS), sejam elas de carter emergencial ou comercial. Os atendimentos destas OSs so fiscalizados pelo regulador ANEEL Agncia Nacional de Energia Eltrica, cuja misso proporcionar condies favorveis ao mercado de energia eltrica e equilbrio entre os agentes e a sociedade. Este acompanhamento da ANEEL abrange o acompanhamento de indicadores como DIC (Durao de interrupo por unidade consumidora), FIC (Frequncia de interrupo por unidade consumidora), DMIC (Durao mxima por unidade consumidora), de forma a aferir a qualidade do servio prestado.

4.1 DESCRIO DO SISTEMA DE GERENCIAMENTO OTIMIZADO DA DISTRIBUIO SIGOD

O SIGOD um sistema de gerenciamento e automao da fora de campo, desenvolvido internamente pelas empresas da Energisa e com o objetivo de possibilitar o envio de ordens de servios OS do centro de operao para os eletricistas em campo. De forma que estas so 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), atravs de GPS e geoprocessamento, os processos de despacho/envio e acompanhamento, bem como a orientao das equipes de campo, atravs de recursos grficos das equipes e OSs sobre o mapa (topografia, hidrografia e arruamento) integrado com a rede eltrica.

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: Prprio Autor O sistema tambm conta com um ambiente embarcado (Windows

Mobile/Smartphone) que proporciona as equipes de campo realizao de sincronismos com a base de dados permitindo a realizao dos atendimentos das OSs. A Figura 30 demonstra a arquitetura do sistema e como as bases de dados esto distribudas para o sincronismo. Figura 30: Arquitetura do SIGOD

Fonte: Prprio Autor

46

4.1.1

Interface do sistema O sistema constitudo de trs mdulos de produo, compostos por: Ambiente Embarcado: Citado anteriormente, desenvolvido para ambiente

operacional Windows Mobile, composto por vrias telas e utilizado pelas equipes de campo durante atendimento (Figura 31). Figura 31: Interface do embarcado

Fonte: Prprio Autor Ambiente Corporativo: Este ambiente composto pelo mdulo de despacho (Figura 32) e a interface de mapas (Figura 33), onde os operadores gerenciam as equipes. Figura 32: Mdulo de despacho

Fonte: SIGOD, 2012

47

Figura 33: Interface de mapas

Fonte: SIGOD, 2012 Este ambiente possibilita a parametrizao de regies e equipes com base na responsabilidade de cada rea, enviando e recebendo OSs. possvel, ainda, acompanhar o desempenho em tempo real na execuo das tarefas, agendar tarefas programadas, formar equipes, reprogramar a OS do smartphone em campo e enviar para outra equipe.

4.2 MODELAGEM E CENRIO ATUAL DO BANCO DE DADOS

Todas as informaes de referncia base de mapas so gravadas em banco de dados apontando para coordenadas geogrficas, composta por postes, cabos, equipamentos e consumidores, de forma que toda a rede eltrica representada graficamente dentro dos padres vigentes. A Figura 34 demonstra alguns dos requisitos existentes, exemplificando as necessidades do sistema com relao ao gerenciamento das equipes, a visualizao 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 informaes comerciais, de faturamento, de atendimento e etc. Alm das informaes tcnicas oriundas do SGD Sistema de Gerenciamento da Distribuio. Essas bases de dados seguem o modelo relacional, com armazenamento em banco de dados Oracle, e so constantemente acessadas pelo SIGOD formando a base de dados utilizada pelo sistema. Tal acesso se utiliza de recursos de sincronizao a fim de manter seus dados sempre atualizados com os demais sistemas.

49

4.3 DIFICULDADES DA APLICAO 4.4 MAPEAMENTO DO BANCO RELACIONAL PARA O MODELO NOSQL 4.5 ANLISE COMPARATIVA
5 CONSIDERAES FINAIS

50

REFERNCIAS

ALMEIDA, Adriano. Neo4J na Prtica, MUNDOJ. Curitiba, n. 51, jan. e fev. 2012, p. 19. BREWER, Eric . Towards robust distributed systems. Simpsio ACM Princpios de computao distribuda (PODC), 2000. Disponvel 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: Anlise Comparativa. In: III CONGRESSO TECNOLGICO 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. Disponvel em http://computerworld.uol.com.br/tecnologia/2010/02/23/crescimento-faz-twittertrocar-o-mysql-pelo-cassandra/ Acesso em 12/05/2012. DIANA, Maurcio de; GEROSA, Marco Aurlio. NoSQL na Web 2.0: um estudo comparativo de bancos no-relacionais para armazenamento de dados na Web 2.0. IX Workshop de Teses e Dissertaes em Banco de Dados, Belo Horizonte, 2010. Disponvel em: http://www.lbd.dcc.ufmg.br/colecoes/wtdbd/2010/sbbd_wtd_12.pdf Acesso em: 07/04/2012. ELLIS, Jonathan. Whats new in Cassandra 1.0: Perfarmance. Outubro, 2011. Disponvel em: http://www.datastax.com/dev/blog/whats-new-in-cassandra-1-0-performance Acesso em: 08/09/2012. FERREIRA, Joo Eduardo; TAKAI, Osvaldo Kotaro. Controle de Concorrncia e Recuperao de Transao. Disponvel em http://www.ime.usp.br/~jef/bd10.pdf Acesso em 12/08/2012. GODOI, Ana Flvia Barreto de. Uma ferramenta para comunicao confivel em sistemas P2P baseada em grupos de peers. Dissertao (Mestrado em Informtica)-UFPR, Curitiba, 2007. HEWITT, Eben. Cassandra: The definitive guide. Sabastopol, Editora OReilly, Ed. 1, 2011. LSCIO, Bernadette F.; OLIVEIRA, Hlio Rodrigues de; PONTES, Jonas C. de Sousa. NoSQL na Web 2.0: Um estudo comparativo de bancos no-relacionais para armazenamento de dados na Web 2.0. VIII Simpsio Brasileiro de Sistemas Colaborativos, 2011, Rio de Janeiro. Disponvel em: http://www.addlabs.uff.br/sbsc_site/SBSC2011_NoSQL.pdf Acesso em: 12/04/2012.

51

MAGALHES, Karine V.; LAENDER, Alberto H. F.; SILVA, Altigran S. da. Uma abordagem para armazenamento de dados semi-estruturados em bancos de bados relacionais. XVI Simpsio Brasileiro de Banco de Dados (SBBD), Belo Horizonte, 2001. Disponvel em: http://www.lbd.dcc.ufmg.br:8080/colecoes/sbbd/2001/017.pdf Acesso em: 07/04/2012. MATTEUSSI, Kassiano Jos. Prottipo de interface web com PHP para gerenciamento de banco de dados CouchDB. Trabalho de Concluso de Curso (Graduao em Cincia da Computao). Universidade Comunitria da Regio de Chapec, Santa Catarina, 2010. MELLO, Ronaldo dos S.; DORNELES, Carina F.; KADE, Adrovane; BRAGANHOLO, Vanessa de P.; HEUSER, Carlos Alberto. Dados semi-estruturados. Simpsio Brasileiro de Banco de Dados (SBBD) - Tutorial, Joo Pessoa, 2000. Disponvel em http://www.dcc.ufrj.br/~braganholo/artigos/tutorial.pdf Acesso em 03/04/2012. STROZZI, Carlos. NoSQL: A relational database managament system, 1998. Disponvel em: http://www.strozzi.it/cgi-bin/CSA/tw7/I/en_US/NoSQL/Home%20Page Acesso em: 28/08/2012. TIWARI, Shashanki. Professional NoSQL. Indianpolis, Editora Wiley, Ed. 1, 2011. VARDANYAN, Mikayel. Picking the right NoSQL database tool, 2011. Disponvel em http://blog.monitis.com/index.php/2011/05/22/picking-the-right-nosql-database-tool/ Acesso em 01/09/2012