TCC Anderson v04 PDF

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
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
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. Davi Delgado 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
Sou grato a Deus por Sua infinita graa que me capacita e me fornece a inspirao necessria diante dos desafios e na realizao dos meus objetivos. A Wnea Leila, minha esposa e sempre presente namorada, responsvel por minha maior motivao e exemplo de esforo, pacincia, comprometimento, esperana, carter e de ser humano. Sou grato por sua confiana e dedicao que me fazem acreditar que sou capaz e que posso sempre ser algum melhor. A meus familiares por cada orientao, incentivo, compreenso, confiana e dedicao depositadas sobre mim, e que me direcionaram a caminhar sempre em frente a fim de concluir esta etapa to importante. Agradeo a todos os meus amigos, em especial a Michel Soares (in memoriam), por sua eterna amizade, e por seu grande exemplo e mensagem de vida. A todos os professores e ao Centro Universitrio de Joo Pessoa Unip, por sua grande contribuio na minha formao acadmica. A professora Ludmila de Almeida Pedrosa, por sua orientao, mas principalmente por acreditar neste trabalho e confiar na minha capacidade, transferindo seus conhecimentos de forma incansvel e dedicada. Agradeo aos meus amigos de turma Luan, Janailton, Fbio, Miguel e Maurcio, por todo apoio, incentivo e pacincia. Pelas contribuies em cada projeto, atividade e estudo. Enfim, a todos que, de maneira direta ou indireta, contriburam para minha formao e para a realizao deste trabalho.
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 o SGBD relacional Oracle e o NoSQL Cassandra aplicados ao Sistema de Gerenciamento Otimizado da Distribuio SIGOD, sistema utilizado atualmente no Grupo Energisa. 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 the relational DBMS Oracle and NoSQL Cassandra applied to the System Management Optimized Distribution - SIGOD, system currently used in Energisa Group. Keywords: NoSQL. Scalability. Database.
LISTA DE FIGURAS
Figura 1: Arquitetura Tradicional ........................................................................................ 21 Figura 2: Escalabilidade Horizontal .................................................................................... 21 Figura 3: Esquema de Sharding........................................................................................... 22 Figura 4: Sistemas distribudos ACID ................................................................................. 24 Figura 5: BD Distribudo .................................................................................................... 25 Figura 6: Teorema de Brewer - CAP ................................................................................... 26 Figura 7: Modelo Chave/Valor............................................................................................ 29 Figura 8: Demonstrando o relacionamento de informaes em grafos ................................. 31 Figura 9: Famlia de colunas dos usurios do Twitter .......................................................... 32 Figura 10: Tabela de dados ................................................................................................. 33 Figura 11: Lista de Valores ................................................................................................. 35 Figura 12: Mapa nome/valor ............................................................................................... 36 Figura 13: A estrutura de uma coluna.................................................................................. 36 Figura 14: Column Familly ................................................................................................. 37 Figura 15: Exemplo de column families .............................................................................. 37 Figura 16: Super Column Family ........................................................................................ 37 Figura 17: Keyspace ........................................................................................................... 38 Figura 18: Rede Peer-To-Peer ............................................................................................. 39 Figura 19: Evoluo do desempenho no Cassandra ............................................................. 41 Figura 20: Diretrio Datastax Community Edition .............................................................. 42 Figura 21: Comandos CQL ................................................................................................. 42 Figura 22: Create Keyspace ................................................................................................ 43 Figura 23: Create Keyspace utilizando DCE ....................................................................... 43 Figura 24: CREATE TABLE .............................................................................................. 43 Figura 25: CREATE TABLE utilizando DCE ..................................................................... 44 Figura 26: Datastax Opscenter Edition - Modelagem .......................................................... 44 Figura 27: Insert e Select utilizando CQL ........................................................................... 45 Figura 28: Data Explorer .................................................................................................... 46 Figura 29: Vises das mtricas de performace..................................................................... 46 Figura 30: Processo de envio e acompanhamento de OS's ................................................... 49 Figura 31: Arquitetura do SIGOD ....................................................................................... 49 Figura 32: Interface do embarcado ...................................................................................... 50 Figura 33: Mdulo de despacho .......................................................................................... 50 Figura 34: Interface de mapas ............................................................................................. 51 Figura 35: Diagrama de caso de uso .................................................................................... 52 Figura 36: MR das tabelas utilizadas no estudo ................................................................... 53 Figura 37: Mapeamento do MR Oracle para Cassandra ....................................................... 54 Figura 38: Criao do grupo de usurios no JMeter ............................................................. 56 Figura 39: Configurao da conexo JDBC ........................................................................ 57
Figura 40: Adicionando ouvintes no JMeter ........................................................................ 58 Figura 41: Select - Anlise de tempo de resposta para 10 usurios ...................................... 60 Figura 42: Select - Anlise de latncia para 10 usurios ...................................................... 60 Figura 43: Select - Anlise de tempo de resposta para 100 usurios .................................... 61 Figura 44: Select - Anlise de latncia para 100 usurios .................................................... 61 Figura 45: Select - Mdia do tempo de resposta para 100 usurios ...................................... 62 Figura 46: Select - Mnimo do tempo de resposta para 100 usurios.................................... 62 Figura 47: Select - Mximo do tempo de resposta para 100 usurios ................................... 63 Figura 48: Select - Valor da vazo das requisies atendidas com 100 usurios .................. 63 Figura 49: Select - Quantidade da carga transferida com 100 usurios ................................ 64 Figura 50: Select - Grfico de resultados do Cassandra com 1000 usurios ......................... 64 Figura 51: Select - Grfico de resultados do Oracle com 1000 usurios ............................... 65 Figura 52: Update - Anlise de tempo de resposta para 10 usurios ..................................... 65 Figura 53: Update - Anlise de latncia para 10 usurios .................................................... 66 Figura 54: Update - Anlise de tempo de resposta para 100 usurios ................................... 66 Figura 55: Update - Anlise de latncia para 100 usurios .................................................. 66 Figura 56: Update - Mdia do tempo de resposta para 100 usurios .................................... 67 Figura 57: Update - Mnimo do tempo de resposta para 100 usurios .................................. 67 Figura 58: Update - Mximo do tempo de resposta para 100 usurios ................................. 68 Figura 59: Update - Valor da vazo das requisies atendidas com 100 usurios ................. 68 Figura 60: Update - Quantidade da carga transferida com 100 usurios ............................... 69 Figura 61: Update - Grfico de resultados do Cassandra com 1000 usurios ....................... 69 Figura 62: Update - Grfico de resultados do Oracle com 1000 usurios ............................. 70
LISTA DE TABELAS
Tabela 1: Tabela Relacional ................................................................................................ 30 Tabela 2: Dados com formato orientado a documento ......................................................... 30 Tabela 3: Anlise comparativa NoSQL ............................................................................... 34 Tabela 4: Diretrios do Cassandra ....................................................................................... 41 Tabela 5: Tipos de dados..................................................................................................... 45 Tabela 6: Comandos de criao das Column Families ......................................................... 54 Tabela 7: Parmetros de um grupo de usurios .................................................................... 56 Tabela 8: Parmetros de uma requisio JDBC ................................................................... 57 Tabela 9: Volume e quantidade de registros no banco ......................................................... 58 Tabela 10: Comandos utilizados nos testes .......................................................................... 59 Tabela 11: Medidas analisadas ............................................................................................ 59
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 FTP File Transfer Protocol GT Gerenciador de Transaes GD Gerenciador de Dados GR Gerenciador de Recuperao HDFS Hadoop Distributed File System HQL Hipertable Query Language HTTP Hipertext Transfer Protocol JDBC Java Database Conectivity JSON JavaScript Objetct Notation MER Modelo Entidade Relacionamento MR Modelo Relacional 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 ............................................................................................................ 15 1.1 OBJETIVOS ................................................................................................................. 16 1.1.1 Objetivo geral............................................................................................................ 16 1.1.2 Objetivos especficos ................................................................................................. 17 1.2 ORGANIZAO DO TRABALHO ............................................................................. 17 2 NOSQL: O QUE E POR QUE UTILIZ-LO .......................................................... 18 2.1 CONTEXTO HISTRICO ........................................................................................... 18 2.2 OS DESAFIOS DOS BANCOS DE DADOS RELACIONAIS ...................................... 19 2.2.1 Escalabilidade e a Web 2.0 ........................................................................................ 20 2.3 GERENCIANDO TRANSAES E A INTEGRIDADE DOS DADOS ........................ 23 2.3.1 Sistemas distribudos ACID...................................................................................... 24 2.4 USANDO NOSQL NA NUVEM ................................................................................... 28 2.5 PRINCIPAIS MODELOS DE ARMAZENAMENTO DE DADOS NOSQL.................. 28 2.5.1 Key/value stores (chave/valor) ................................................................................... 28 2.5.2 Document databases (orientado a documentos)........................................................ 29 2.5.3 Graph databases (orientado a grafo) ......................................................................... 31 2.5.4 Column oriented store (orientado a colunas) ............................................................ 32 2.6 CONSIDERAES FINAIS DO CAPTULO .............................................................. 33 3 CASSANDRA ................................................................................................................ 35 3.1 O MODELO DOS DADOS NO CASSANDRA............................................................. 35 3.2 ARQUITETURA .......................................................................................................... 38 3.3 DEFINIO E MANIPULAAO DOS DADOS .......................................................... 40 3.3.1 Diretrios do Cassandra ........................................................................................... 41 3.3.2 Comandos bsicos de definio (DDL) ..................................................................... 42 3.3.3 Comandos bsicos de manipulao (DML) .............................................................. 45 3.4 CONSIDERAES FINAIS DO CAPTULO .............................................................. 47 4 ESTUDO DE CASO ...................................................................................................... 48 4.1 DESCRIO DO SISTEMA DE GERENCIAMENTO OTIMIZADO DA DISTRIBUIO SIGOD .................................................................................................. 48 4.1.1 Interface do sistema .................................................................................................. 50 4.2 MODELAGEM E CENRIO ATUAL DO BANCO DE DADOS ................................. 51 4.3 MAPEAMENTO DO BANCO RELACIONAL PARA O MODELO NOSQL ............... 53 4.4 ANLISE COMPARATIVA ........................................................................................ 55 4.4.1 Plano de teste com JMeter......................................................................................... 55 4.4.2 Resultados obtidos .................................................................................................... 58 4.5 CONSIDERAES FINAIS DO CAPTULO .............................................................. 70 5 CONSIDERAES FINAIS ........................................................................................ 71 REFERNCIAS ................................................................................................................. 73
15
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
16
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 propcio para a anlise de um banco de dados NoSQL, em especial, o Cassandra, o qual ser abordado no captulo 3, 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 OBJETIVOS
1.1.1 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.
17
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 utilizando as ferramentas DataStax Community Edition e JMeter. Podero ser verificados fatores como uso do processador, memria, disco, alm dos aspectos de performance.
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.
18
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 entrar 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.
19
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 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
20
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 integridade 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 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,
21
existe um limite de capacidade do equipamento e, por que no, do prprio oramento durante as mudanas. Figura 1: Arquitetura Tradicional
Fonte: Prprio Autor (2012)
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
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
22
quando o tamanho do banco de dados faz com que as consultas e atualizaes levem muito tempo para serem executadas. 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 [BRITO, 2010].
Figura 3: Esquema de Sharding
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. Podendo ser, inclusive, atravs da redundncia de servidores, ou mesmo acessando um armazenamento central ( storage central). 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 de 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
23
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 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, d urante 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.
24
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. 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)
25
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 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
26
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 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)
27
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 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 Cassandra4, 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.
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/
28
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 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
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/
29
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].
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
12 13
http://www.oracle.com/technetwork/products/berkeleydb/overview/index.html http://project-voldemort.com/voldemort/
30
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, 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
Tabela 2: Dados com formato 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
31
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 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)
32
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 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. Em um BD relacional
33
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
2.6
CONSIDERAES FINAIS 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 comparativa entre os principais modelos NoSQL disponveis afim de decidir corretamente qual aplicar.
34
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)
Algoritmos grficos, como caminho mais curto, conectividade, relacionamentos, etc. Pesquisas rpidas, boa distribuio de armazenamento de dados.
Tem que atravessar todo o grfico para obter uma resposta definitiva. No fcil de agrupar.
Armazenamento orientado a colunas (Column oriented store)
Sistemas de arquivos distribudos
API de baixo nvel.
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 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, pela sua popularidade em vrias empresas de TI em detrimento dos outros modelos orientado a coluna, mas principalmente, por ser capaz de lidar com carregamento pesados, suportar muitas operaes de escrita no armazenamento e processar grandes quantidades de dados distribudos em muitas mquinas [HEWITT, 2011]. Seus conceitos e caractersticas sero abordados no captulo 3.
35
CASSANDRA O Apache Cassandra um sistema de armazenamento de dados distribudos,
orientado a coluna, open source, que se difere dos SGBDs relacionais que so orientado linha. 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 oferece 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
36
Por no informar muito sobre seu significado necessrio acrescentar identificadores, ou seja, nomes aos valores de forma a combinar com cada um conforme 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
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].
37
Figura 14: Column Familly
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
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
38
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]. 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
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
39
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]. 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
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
40
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 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].
41
Figura 19: Evoluo do desempenho no Cassandra
Fonte: ELLIS (2011) 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, como diretrios de armazenamento, nomes de keyspaces e column families, logs. 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 mais recentes possuem esse diretrio que contm alguns drives do CQL para python. Contm ferramentas que o Cassandra disponibiliza como, por exemplo, o cassandratools stress, que uma ferramenta feita em Java para a realizao de testes de stress em um cluster.
conf interface javadoc lib
pylib
42
Contudo, existe uma importante soluo gratuita disponibilizada pela empresa Datastax. A DataStax Community Edition14 - (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 Shell e DataStax Community Edition, instalados no sistema operacional Windows 7 (Figura 20). Figura 20: Diretrio Datastax Community Edition
Fonte: Prprio Autor (2012) 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

14
http://www.datastax.com/products/community
43
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
Figura 23: Create Keyspace utilizando DCE
Fonte: Prprio Autor (2012) CREATE TABLE: Utilizado na criao das column families (Figura 24). O mesmo comando, utilizando a DataStax Community Edition, pode ser visto na Figura 25, 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
44
Figura 25: CREATE TABLE utilizando DCE
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
45
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 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 Figura 27 temos um exemplo que demonstra uma insero de dados e uma consulta logo em seguida.
Figura 27: Insert e Select utilizando CQL
46
Os dados existentes nas column families tambm podem ser consultados utilizando a funcionalidade DATA EXPLORER da Datastax OpsCenter Comunity, conforme apresentado na Figura 28. Alm disso, mtricas de anlise de performance do banco podem ser obtidas atravs da opo PERFORMANCE contida no menu. Nela esto disponveis vrios tipos de grficos que abrangem informaes como uso de CPU, memria, requisies de escrita e leitura, utilizao de disco, etc. (Ver Figura 29).
Figura 28: Data Explorer
Figura 29: Vises das mtricas de performace
47
3.4
CONSIDERAES FINAIS DO CAPTULO O Cassandra um banco de dados amplamente usado por empresas com grandes
conjuntos de dados ativos. A possibilidade de tratamento dos pontos de falhas existentes na rede e por ser desnecessria a utilizao de uma estrutura de cluster central torna-o tolerante a falhas, ou seja, propicia o suporte a replicao em vrios centros de dados e a substituio de ns sem tempo de inatividade. Esse modelo de estruturao permite ao banco de dados dispor de menor tempo de resposta e latncia para seus usurios.
48
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 clientes15. 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 30. 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
49
Figura 30: Processo de envio e acompanhamento de OS's
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 31 demonstra a arquitetura do sistema e como as bases de dados esto distribudas para o sincronismo.
Figura 31: Arquitetura do SIGOD
50
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 32).
Figura 32: Interface do embarcado
Fonte: Prprio Autor (2012) Ambiente Corporativo: Este ambiente composto pelo mdulo de despacho (Figura 33) e a interface de mapas (Figura 34), onde os operadores gerenciam as equipes.
Figura 33: Mdulo de despacho
Fonte: SIGOD, 2012
51
Figura 34: 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 35 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.
52
Figura 35: 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,
53
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.
4.3 MAPEAMENTO DO BANCO RELACIONAL PARA O MODELO NOSQL

O mapeamento do banco de dados Oracle para o Cassandra ocorre a partir de anlise da estrutura relacional contida no MR. importante destacar que para a anlise comparativa realizada neste trabalho sero utilizadas apenas algumas tabelas contidas no sistema, conforme a Figura 36, de modo que seja possvel estrutur-las tambm no Cassandra e permita o levantamento das informaes necessrias ao estudo. Figura 36: MR das tabelas utilizadas no estudo
Analisado as informaes do MR j possvel modelar as estrutura de Column Familes, como pode ser observado na Figura 37.
54
Figura 37: Mapeamento do MR Oracle para Cassandra
Na criao das column families mapeadas no MR foram utilizados os comandos CQL conforme exemplos descritos na Tabela 6. Tabela 6: Comandos de criao das Column Families
Local
CREATE TABLE Local ( local varchar PRIMARY KEY, distrito varchar, regional int, sigla varchar, descricao varchar); CREATE TABLE Regional ( regional int PRIMARY KEY, descricao varchar, tot_cli bigint);
Regional
ClientesAtingidos
CREATE TABLE ClientesAtingidos ( conta bigint PRIMARY KEY, num_ocorrencia int, ano_ocorrencia int, cod_empresa varchar); CREATE TABLE Motivos ( motivo int PRIMARY KEY, descricao varchar );
Motivos
SubMotivos
CREATE TABLE SubMotivos ( submotivo int PRIMARY KEY, motivo int, prioridade varchar, descricao varchar, abrangencia varchar);
Comunicacoes
CREATE TABLE Comunicacoes ( num_comunicacao int PRIMARY KEY, ano_comunicacao int, datahora timestamp, datahora_comb timestamp, tipo int, localidade varchar, conta varchar, endereco varchar, motivo int, submotivo int, reclamante varchar, referencia varchar, condicoes_tempo varchar, nome_usuario varchar, num_ocorrencia int, ano_ocorrencia int, bairro varchar, cod_atendimento varchar );
55
4.4 ANLISE COMPARATIVA

Nessa fase do estudo, onde ser realizada a anlise prtico-comparativa, iniciamse os testes de carga de stress nos SGDB Oracle e Cassandra. Para essa atividade ser utilizado o Apache JMeter16 na verso 2.8, e ser possvel coletar informaes relevantes quanto ao tempo de resposta das amostras, latncia, carga, vazo, etc. De modo que a obteno dos resultados oferea uma viso detalhada e abrangente na utilizao dos dois bancos de dados. 4.4.1 Plano de teste com JMeter
O plano de teste consiste da gerao de passos de execuo a fim de simular a utilizao dos sistemas e coletar informaes ou mtricas desse processo. O processo ocorre a partir da amostragem de resultados e valores, de modo que essas informaes podem representar falha na implementao, baixa performance, inconsistncia dos dados, dificuldade de manuteno, dentre outros problemas. A avaliao desses resultados vai permitir identificar as situaes onde o sistema no atende os requisitos de negcio [REZENDE, 2005; MARTINS, 2007]. Para a criao dos casos de teste, o JMeter deve ser previamente configurado conforme a seguir: Conexo JDBC: No diretrio de instalao do JMeter necessrio ser adicionado os arquivos JARs que fornecem os drives de conexo JDBC (Java Database Connectivity) de ambos os bancos analisados. Na pasta (~\apache-jmeter-2.8\lib) foram adicionados os arquivos ojdbc14.jar para conexo com Oracle e cassandra-jdbc-1.1.2.jar para conexo com o Cassandra. Para a conexo deste ltimo alm do JAR de conexo JDBC foi necessrio adicionar, tambm, os JARs contidos na pasta de instalao (~\Cassandra\lib) do Cassandra. Grupo de usurios (Thread Group): Aps serem adicionados os drives de conexo, a prxima etapa criar um grupo de usurios, onde definida a quantidade de usurios e o comportamento que das requisies ao SGBD. A configurao desses parmetros deve ser seguida conforme a descrio de cada um disposta na Tabela 7 e conforme Figura 38 clicando com o boto direito em plano de teste (Adicionar/Threads (Users)/Grupo de Usurios). Para o estudo proposto foi utilizado ambientes de 10, 100 e 1000 usurios.
16
http://jmeter.apache.org/
56
Tabela 7: Parmetros de um grupo de usurios

Parmetro
Nome
Descrio
Nome do Thread Group Indica qual procedimento ser executado em caso de erro durante uma requisio de teste, que so: - Continuar O erro ser ignorado e novas requisies sero disparadas. - Interromper Usurio Virtual Interrompe somente a Thread que disparou a requisio, os demais Threads continuaro. - Interromper Teste Todo o teste ser finalizado. Cada Thread considerado como um usurio que executar as requisies SQL, ento o nmero de usurios ser a quantidade de testes executados. Define quantos segundos o JMeter tem para por todas as Threads em execuo. Diz ao JMeter o nmero de vezes que o Thread Group ir executar, caso a opo infinito seja marcada o Thread Group ser executado infinitamente. Permite agendar um horrio de inicio e fim de uma execuo de teste.
Ao a ser Tomada aps Erro no Testador
Nmero de Usurios Virtuais Tempo de Inicializao (seg) Contador de Interao Agendador
Fonte: JNIOR; SILVA (2010)
Figura 38: Criao do grupo de usurios no JMeter
Configurao da Conexo e Requisio JDBC: O JMeter possui vrios testadores que podem ser adicionados ao grupo de usurio, como por exemplo requisio FTP (File Transfer Protocol), HTTP (Hipertext Transfer Protocol), entre outros. Nesse estudo ser utilizada a requisio JDBC clicando com boto direito no grupo de usurios (Adicionar/Testador/Requisio JDBC). neste elemento onde ser criado o comando SQL, podendo ser Select Statement, Update Statement, entre outras opes conforme as descries de cada parmetro na Tabela 8.
57
Tabela 8: Parmetros de uma requisio JDBC

Parmetro
Nome Nome da varivel Tipo de consulta Consulta
Descrio
Nome da requisio Define o nome de uma varivel que ser associada a um pool de conexes. Informa o tipo de consulta a ser realizada ( Update, Select, etc.). Onde escrito todo o comando da consulta SQL.
Fonte: JNIOR; SILVA (2010)
Para que essa requisio funcione, necessrio adicionar uma conexo JDBC conforme Figura 39. necessrio destacar o preenchimento dos parmetros: URL ( Uniform Resource Locator) do Banco de Dados e Classe do Driver JDBC. Foram utilizados os valores a seguir: a) ORACLE: - URL do Banco de Dados: jdbc:oracle:thin:@127.0.0.1:1521:XE - Classe do Driver JDBC: oracle.jdbc.driver.OracleDriver
b) CASSANDRA: - URL do Banco de Dados: jdbc:cassandra://localhost:9160/ks_sgd - Classe do Driver JDBC: cassandra.jdbc.driver.CassandraDriver Figura 39: Configurao da conexo JDBC
Para visualizar os resultados obtidos a partir da requisio JDBC necessrio ser adicionado ao grupo de usurio relatrios e/ou grficos que atendam a necessidade da anlise. Est ao pode ser realizada com a adio de ouvinte, como pode ser visto na Figura 40.
58
Figura 40: Adicionando ouvintes no JMeter
4.4.2 Resultados obtidos Os valores de volume e quantidade de registros obtidos aps a populao do banco de dados, no apenas no que se refere aos segmentos de tabelas, mas tambm aos ndices existentes, esto definidos na Tabela 9 e demonstra armazenar um total de 12 MB aproximadamente.
Tabela 9: Volume e quantidade de registros no banco
Tendo o ambiente configurado e o plano de teste definido, assim como a modelagem entre os bancos de dados, de modo que foi utilizada uma estrutura de tabelas
59
idnticas em ambos, a fim de se obter a total semelhana entre tamanho de dados, nmero de colunas ou linhas, e tipos dos dados entre a tabela relacional e a column family. As consultas e atualizaes realizadas no estudo sero direcionadas a tabela de ocorrncias pendentes (OcorrenciasPendentes no Cassandra e ocorrencias_pendentes no Oracle) e de localidade, respectivamente, a partir da mesma quantidade de usurios por segundo, acessando as mesmas tabelas nos dois bancos de dados. Os comandos utilizados esto descritos na Tabela 10.
Tabela 10: Comandos utilizados nos testes

Cassandra Consulta SELECT * FROM OcorrenciasPendentes Oracle SELECT * FROM ocorrncias_pendentes
Atualizao
UPDATE Local SET descricao = 'LOC PATOS DO IRERE' WHERE local = '168'
UPDATE local SET descricao = 'LOC PATOS DO IRERE' WHERE local = '168'
O computador onde foram realizados os testes possui as seguintes caractersticas: CPU Intel Core 2 Duo 2.20 GHz; Memria RAM 3,00 GB; Sistema Operacional Windows 7 Professional Service Pack 1 (32 Bits). Trs testes de busca e atualizao foram realizados, onde o nmero de usurios foi de 10, 100 e 1000 por segundo. Foram coletados resultados de latncia, tempo de resposta, mdia, mnimo, mximo, vazo e carga. As medidas obtidas no estudo comparativo so definidas conforme Tabela 11. Tabela 11: Medidas analisadas
Medida Latncia Tempo de Resposta Mdia Mnimo Mximo Vazo Carga Descrio Representa o tempo de concluso de um evento, sendo o tempo entre o incio e a percepo dos seus efeitos. Tem fundamental importncia quanto a performance do banco de dados, de modo que se atenda a expectativa do usurio, onde o tempo de resposta total o tempo gasto com CPU somado ao tempo consumido nos eventos de espera. Valor mdio das amostras, sendo medido em milissegundos. Menor tempo de resposta, sendo medido em milissegundos. Maior tempo de resposta, sendo medido em milissegundos. Representa o nmero de requisies atendidas por segundo. Representa a quantidade em KB transferidos por segundo.
60
Na anlise de busca (select) foi observado que o Cassandra obteve um considervel desempenho na recuperao dos dados quando comparado ao Oracle. Os resultados obtidos demonstram a capacidade computacional do NoSQL quanto ao processamento e a manipulao dos dados, ou seja, possvel notar que o tempo de resposta obtido pelo Cassandra (Figura 41) e a latncia (Figura 42) esto menores, confirmando sua eficincia em atender as demandas. Consulta com 10 threads por segundo:
Figura 41: Select - Anlise de tempo de resposta para 10 usurios
Figura 42: Select - Anlise de latncia para 10 usurios
61
Aumentando-se a o nmero de usurios para 100, algo que acontece frequentemente nas redes sociais, os resultados no foram to diferentes. O Cassandra apresentou melhor performance para ao atender a demanda. No entanto, analisando a Figura 43 e Figura 44, percebe-se que ambos os bancos de dados apresentaram uma linha crescente nos tempos de cada amostra, ou seja, a medida que o nmero de usurios aumentou, o tempo tambm aumentou.
Consulta com 100 threads por segundo:
Figura 43: Select - Anlise de tempo de resposta para 100 usurios
Figura 44: Select - Anlise de latncia para 100 usurios
62
A mdia dos tempos de resposta para os mesmos 100 usurios apenas comprova as diferenas obtidas, como mostra a Figura 45. De modo que analisando os tempos das 100 amostras, o Cassandra obteve um tempo, em mdia, mais eficiente.
Figura 45: Select - Mdia do tempo de resposta para 100 usurios
Quanto os resultados das requisies que tiveram o menor e o maior tempo de resposta entre todas as amostras, o Cassandra tambm obteve medidas melhores em relao ao Oracle, como poder ser observado na Figura 46 e Figura 47, respectivamente.
Figura 46: Select - Mnimo do tempo de resposta para 100 usurios
63
Figura 47: Select - Mximo do tempo de resposta para 100 usurios
J os valores de vazo e carga obtidos nos resultados demonstram que o Cassandra possui maior capacidade de processamento tendo em vista a nmero de usurios atendidos e de KBs transferidos por segundo (Ver Figura 48 e Figura 49). Isso tem grande representatividade no estudo, tendo em vista que o volume de dados e o nmero de usurios da aplicao esto em frequente crescimento.
Figura 48: Select - Valor da vazo das requisies atendidas com 100 usurios
64
Figura 49: Select - Quantidade da carga transferida com 100 usurios
Fonte: Prprio Autor (2012) Consulta com 1000 threads por segundo: Numa anlise geral dos resultados obtidos, quando submetidos a 1000 usurios, ambos os bancos de dados apresentaram mtricas crescentes. Principalmente o NoSQL, demonstrando a capacidade destes SGBDs lidarem com ambientes extremamente crescentes no sentido de volume de dados trafegados e nmero de usurios. Podem-se observar essas caractersticas analisando comparativamente a Figura 50 e a Figura 51, onde demonstram que o Cassandra obteve vazo e mdia no tempo de resposta bem melhores comparados ao Oracle.
Figura 50: Select - Grfico de resultados do Cassandra com 1000 usurios
65
Figura 51: Select - Grfico de resultados do Oracle com 1000 usurios
Na anlise de atualizao (update) as diferenas obtidas entre os tempos de resposta e latncia no foram to evidentes quando analisadas com 10 usurios (Figura 52 e Figura 53), o que ocorre diferente com resultados para atender a 100 usurios. A Figura 54 e Figura 55 demonstram que o Cassandra teve um desempenho bem melhor, sob o ponto de vista de ser um comando de simples atualizao, contudo submetido a demanda de 100 usurio, ou seja, o processamento de atualizao de um registro teve tempo de resposta e latncia menores na maioria das amostras. De modo geral suas medidas prevaleceram em relao ao Oracle. Atualizao com 10 threads por segundo: Figura 52: Update - Anlise de tempo de resposta para 10 usurios
66
Figura 53: Update - Anlise de latncia para 10 usurios
Fonte: Prprio Autor (2012) Atualizao com 100 threads por segundo: Figura 54: Update - Anlise de tempo de resposta para 100 usurios
Figura 55: Update - Anlise de latncia para 100 usurios
67
A Figura 56 mostra a mdia do tempo que os bancos levaram para responder as atualizaes, deixando evidente que o banco Cassandra levou menos tempo para concluir cada evento, apresentando, aproximadamente, 92% de melhor desempenho em comparao ao Oracle. Figura 56: Update - Mdia do tempo de resposta para 100 usurios
O tempo mnimo que o Oracle levou para responder as atualizaes foi o dobro do valor obtido pelo Cassandra, como pode ser visto na Figura 57.
Figura 57: Update - Mnimo do tempo de resposta para 100 usurios
68
J os valores encontrados de tempo mximo demonstram uma grande diferena entre os bancos. Na Figura 58 possvel perceber uma diferena de aproximadamente 81% no tempo de resposta entre o Oracle e o Cassandra.
Figura 58: Update - Mximo do tempo de resposta para 100 usurios
Os resultados obtidos de vazo e carga, analisados sob o ponto de vista da atualizao dos registros destacam o Cassandra quanto ao atendimento das requisies de um maior nmero de usurios, e de transferir uma quantidade maior de KBs, conforme a Figura 59 e Figura 60, respectivamente.
Figura 59: Update - Valor da vazo das requisies atendidas com 100 usurios
69
Figura 60: Update - Quantidade da carga transferida com 100 usurios
Fonte: Prprio Autor (2012) Atualizao com 1000 threads por segundo: De maneira semelhante ao resultado geral obtido no teste de busca com 1000 usurios, os dois bancos de dados atenderam com performance a demanda existente. Contudo o Cassandra obteve melhores resultados de vazo e mdia nos tempos de resposta das amostras, conforme a analise da Figura 61 e da Figura 62.
Figura 61: Update - Grfico de resultados do Cassandra com 1000 usurios
70
Figura 62: Update - Grfico de resultados do Oracle com 1000 usurios
4.5
CONSIDERAES FINAIS DO CAPTULO Um ponto importante extrado do estudo a necessidade da realizao dos testes
em tabelas do sistema com maior volume e quantidade de registros, como, por exemplo, a tabela cli_atingidos_pend. Pois as tabelas selecionad as para os testes se caracterizam por terem maior relevncia quanto a utilizao dos usurios, dado a sua importncia quanto a disponibilidade e comprometimento na gesto do atendimento das ocorrncias pendentes e no direcionamento das equipes por localidade, ou seja, mesmo no sendo elas as maiores tabelas nos respectivos bancos, as informaes obtidas nos testes no foram comprometidas. O Cassandra obteve resultados mais eficientes em relao ao Oracle, sob o ponto de vista de tempo de resposta, latncia, carga e vazo. Contudo as mtricas analisadas alm de demonstrarem o uso do Cassandra em ambientes de crescimento de carga e de usurios, destacam a importncia de integrar o mundo relacional e o NoSQL, ou seja, o Cassandra pode ser amplamente utilizado e possui caractersticas eficientes comparadas ao Oracle, mas a problemtica da integrao dos dados entre esses dois mundos a fim de ser obter cenrios de alta disponibilidade, distribuio e escalabilidade, algo que necessita de estudos bem mais aprofundados.
71
CONSIDERAES FINAIS A utilizao de solues NoSQL em ambientes, sejam corporativos ou no, uma
realidade e de resultados aparentemente visveis, sendo bastante til em aplicaes de frequente aumento no nmero de usurios e no volume de dados trafegados. Existem melhorias significativas no desempenho e na performance das requisies nesse tipo de banco de dados, em especial no modelo utilizado neste estudo, de modo que os resultados obtidos retratam diretamente as vantagens de utilizao de um SGBD orientado a coluna. Nesse contexto, este trabalho teve como objetivo geral, analisar comparativamente o banco de dados relacional Oracle e o NoSQL Cassandra aplicados em um sistema de gerenciamento otimizado da distribuio eltrica, a partir do estudo dos bancos de dados NoSQL. Dessa forma, foi possvel coletar informaes relevantes quanto ao tempo de resposta das amostras, latncia, carga, vazo, etc. De modo que a obteno dos resultados permitiu uma viso detalhada e abrangente da utilizao dos dois SGBDs. Com os resultados obtidos, pode-se concluir que, para o estudo de caso proposto, o Cassandra demonstrou, de forma satisfatria, resultados relevantes quanto ao desempenho e a performance. Observou-se que as mtricas encontradas, principalmente vazo e carga, retratam a capacidade do Cassandra ser utilizado em aplicaes que requerem baixo tempo de resposta e alta transferncia de dados. No se pode afirmar que os bancos NoSQL so solues perfeitas para todos os problemas encontrados, mesmo porque no foram realizados todos os testes necessrios para esse afirmativa ou mesmo realizado testes de todos os requisitos, contudo possvel concluir que tais modelos, apesar de caractersticas diferentes, sejam entre si ou com os modelos relacionais, podem auxiliar satisfatoriamente ambientes de alta carga e crescente nmero de usurios. Finalmente, espera-se que este trabalho sirva como base para o desenvolvimento de projetos que utilizem o NoSQL em detrimento do banco relacional, ou at mesmo projetos de integrao de dados entre esses dois mundos, uma vez que no foi possvel analisar outras situaes como solues distribudas, estruturas escalveis, meios e mecanismos de armazenamento NoSQL, anlises entre modelos NoSQL, etc. perceptvel que h um grande campo a se explorar nesta rea e que as possibilidades so das mais variadas. Como possveis trabalhos futuros, pode-se citar: Integrao de dados de bancos relacionais e NoSQL; Anlise crtica dos mediadores existentes na integrao de bancos NoSQL;
72
Uso de Business Intelligence associado a bancos NoSQL; Impactos e benefcios de solues NoSQL aplicadas nas redes sociais; Replicao de dados de banco relacionais e NoSQL; Replicao de dados em modelos NoSQL; SQL como linguagem utilizada em bancos NoSQL; Anlise prtico-comparativa com outros modelos.
73
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. JNIOR, Incio Inocenti; SILVA, Jaqueline Macedo da. Anlise de desempenho e carga de stress em sistemas de bancos de dados orientado a objetos. Trabalho de Concluso de Curso (Tecnlogo em Banco de Dados). Faculdade de Tecnologia de So Jos dos Campos, 2010, So Jos dos Campos.
74
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. 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. MARTINS, Jos C. Cordeiro. Tcnicas para gerenciamento de projetos de software. Rio de Janeiro, Editora Brasport, 2007. 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. REZENDE, Denis Alcides. Engenharia de software e sistemas de informao. Rio de Janeiro, Editora Brasport, Ed. 3, 2005. 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

TCC Anderson v04 PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

TCC Anderson v04 PDF

Загружено:

Авторское право:

Доступные форматы

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

ANDERSON GUIMARES MARQUES

Joo Pessoa PB 2012

ANDERSON GUIMARES MARQUES

Joo Pessoa PB 2012

ANDERSON GUIMARES MARQUES

___________________________________________________________ Profa Ms. Ludmila de Almeida Pedrosa Orientadora - UNIP

___________________________________________________________ Profa Ms. Davi Delgado Examinador - UNIP

___________________________________________________________ Profa Ms. Francisco Porfrio Examinador - UNIP

LISTA DE ABREVIATURAS E SIGLAS

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

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

Fonte: Prprio Autor (2012)

Fonte: Prprio Autor (2012)

Figura 3: Esquema de Sharding

Fonte: Prprio Autor (2012)

Figura 4: Sistemas distribudos ACID

Fonte: TIWARI (2011, p. 173)

Fonte: FERREIRA, TAKAI (2006)

Figura 6: Teorema de Brewer - CAP

Tolerncia a Particionamento (Partition Tolerance)

Fonte: BREWER (2000)

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/

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/

Figura 7: Modelo Chave/Valor

Fonte: Prprio Autor

Tabela 1: Tabela Relacional

Fonte: Prprio Autor (2012)

Tabela 2: Dados com formato orientado a documento

Fonte: Prprio Autor (2012)

Figura 8: Demonstrando o relacionamento de informaes em grafos

Fonte: ALMEIDA (2012)

Figura 9: Famlia de colunas dos usurios do Twitter

Figura 10: Tabela de dados

Fonte: Prprio Autor (2012)

Tabela 3: Anlise comparativa NoSQL

Armazenamento Chave/Valor (Key/value stores).

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)

Sistemas de arquivos distribudos

API de baixo nvel.

Fonte: VARDANYAN (2011)

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

3.1 O MODELO DOS DADOS NO CASSANDRA

Fonte: Prprio Autor (2012)

Figura 12: Mapa nome/valor

Fonte: Prprio Autor (2012)

Figura 13: A estrutura de uma coluna

Fonte: HEWITT (2011)

Figura 14: Column Familly

Fonte: HEWITT (2011)

Figura 15: Exemplo de column families

Fonte: Prprio Autor (2012)

Figura 16: Super Column Family

Fonte: HEWITT (2011)

Fonte: Prprio Autor (2012)

Figura 18: Rede Peer-To-Peer

Fonte: Prprio Autor (2012)

3.3 DEFINIO E MANIPULAAO DOS DADOS