Universidade de Brasília - Semantic Scholar · A importância deste estudo de caso é álidav tanto para a área de bioinformática quanto para a computação, pois seu desenvolvimento

Universidade de BrasiacuteliaInstituto de Ciecircncias Exatas

Departamento de Ciecircncia da Computaccedilatildeo

Um Estudo Sobre a Utilizaccedilatildeo do Banco de DadosNoSQL Cassandra em Dados Bioloacutegicos

Rodrigo Cardoso Aniceto

Renecirc Freire Xavier

Monograa apresentada como requisito parcial

para conclusatildeo do Bacharelado em Ciecircncia da Computaccedilatildeo

Orientadora

Profa Dra Maristela Terto de Holanda

Brasiacutelia

Universidade de Brasiacutelia UnB

Instituto de Ciecircncias Exatas

Bacharelado em Ciecircncia da Computaccedilatildeo

Coordenadora Profa Dra Maristela Terto de Holanda

Banca examinadora composta por

Profa Dra Maristela Terto de Holanda (Orientadora) CICUnB

Profa Dra Edna Dias Canedo FGAUnB

Profa Dra Maria Emilia M T Walter CICUnB

CIP Catalogaccedilatildeo Internacional na Publicaccedilatildeo

Aniceto Rodrigo Cardoso

Um Estudo Sobre a Utilizaccedilatildeo do Banco de Dados NoSQL Cassandra

em Dados Bioloacutegicos Rodrigo Cardoso Aniceto Renecirc Freire Xavier

Brasiacutelia UnB 2014

117 p il 295 cm

Monograa (Graduaccedilatildeo) Universidade de Brasiacutelia Brasiacutelia 2014

1 SGBDs 2 Nuvem Computacional 3 NoSQL 4 Cassandra

5 Dados Bioloacutegicos 6 DataStax

CDU 0044

Endereccedilo Universidade de Brasiacutelia

Campus Universitaacuterio Darcy Ribeiro Asa Norte

CEP 70910-900

BrasiacuteliaDF Brasil

Profa Dra Maristela Terto de Holanda (Orientadora)

CICUnB

Profa Dra Edna Dias Canedo Profa Dra Maria Emilia M T Walter

FGAUnB CICUnB

Coordenadora do Bacharelado em Ciecircncia da Computaccedilatildeo

Brasiacutelia 27 de fevereiro de 2014

Dedicatoacuteria

Dedico a minha famiacutelia amigos e todos aqueles que buscam o avanccedilo da tecnologiapara uma sociedade melhor

Success is not nal failure is not fatal it is the courage to continue that countsWinston Churchill

Agradecimentos

Agradeccedilo a Deus minha famiacutelia e amigos que com muita paciecircncia souberam lidarcom a dedicaccedilatildeo para este trabalho Agradeccedilo tambeacutem a Doutora Maristela Terto deHolanda que nos apoiou acompanhou e esteve sempre presente para nos instruir Por magradeccedilo ao meu companheiro de trabalho natildeo soacute pela ajuda aqui mas tambeacutem pelosoacutetimos momentos de descontraccedilatildeo em meio a tanto trabalho

Eu tambeacutem

Resumo

Por meio do avanccedilo das tecnologias voltadas a escalabilidade de um banco de dados ouso de bancos voltados a performance que administram uma massiva quantidade de dadostornou-se mais acessiacutevel Esses bancos de dados satildeo conhecidos como bancos NoSQL e satildeoum novo paradigma computacional De forma teoacuterica este trabalho apresenta vantagense desvantagens desses bancos e aprofunda-se em carateriacutesticas do Cassandra

Em termos praacuteticos tendo em vista que os dados gerados pela bioinformaacutetica satildeo degrande volume e necessitam de um armazenamento de alta performance esse trabalhopropotildee o armazenamento destes dados no banco NoSQL Cassandra Para isto foramrealizados dois estudos de caso um com duas e outro com quatro maacutequinas trabalhandoem um mesmo banco do Cassandra Estes estudos mostraram um avanccedilo ao escalar osrecursos fiacutesicos do banco tornando a inserccedilatildeo e a consulta mais ecientes sendo este umaalternativa para dar suporte aos projetos na aacuterea de bioinformaacutetica

Palavras-chave SGBDs Nuvem Computacional NoSQL Cassandra Dados BioloacutegicosDataStax

Abstract

Through the advancement of technologies focused on the scalability of a databasethe use of databases oriented to performance that manage massive amounts of data hasbecome more accessible These databases are known as NoSQL and are a new computingparadigm This work presents advantages and disadvantages of these NoSQL databasesand delves into features of Cassandra

In the practical part given that the data generated by bioinformatics are a largevolume and need a high-performance storage this work proposes the storage of such datain a NoSQL database Cassandra It were made two case studies one with two machinesworking on the same database of Cassandra and the other with four machines workingsimilarly the rst one These studies showed an improvement in scaling the physicalresources of the database making more ecient operations on the database working asan alternative to support researches in the eld of bioinformatics

Keywords SGBDs Cloud Computing NoSQL Cassandra Biological Data DataStax

Sumaacuterio

1 Introduccedilatildeo 111 Problema e Hipoacutetese 212 Motivaccedilatildeo 213 Objetivo 2

131 Objetivos Especiacutecos 214 Estrutura do Trabalho 3

2 Computaccedilatildeo em Nuvem 421 Deniccedilotildees de Computaccedilatildeo em Nuvem 422 Grid Computing e Utility Computing 7

221 Grid Computing 7222 Utility Computing 9

23 Caracteriacutesticas Essenciais da Nuvem 1024 Modelos de Serviccedilo 1125 Modelos de Implantaccedilatildeo 12

3 Caracteriacutesticas e Diferenccedilas entre Bancos de Dados Relacionais e NatildeoRelacionais 1431 Bancos de Dados Relacionais 14

311 Normalizaccedilatildeo 15312 Limitaccedilotildees 16

32 Bancos Natildeo Relacionais NoSQL 17321 Caracteriacutesticas do NoSQL 17322 Modelos de Bancos NoSQL 18323 Limitaccedilotildees 21

4 Cassandra 2341 Deniccedilatildeo e Modelo de Dados 23

411 Caracteriacutesticas Gerais 23412 Modelo de Dados 25413 Interaccedilatildeo com o Banco 27414 Limitaccedilotildees 28

42 Arquitetura do Sistema 28421 Distribuiccedilatildeo e Replicaccedilatildeo de Dados 29422 Niacuteveis de Consistecircncia 31

5 Estudo de Caso e Implementaccedilatildeo 3351 Caracteriacutesticas dos Dados da Bioinformaacutetica 3352 Desenvolvimento da Aplicaccedilatildeo Cliente 3453 Arquitetura do Ambiente de Nuvem 38

6 Resultados e Discussatildeo 3961 Inserccedilatildeo e Extraccedilatildeo dos FASTQ Referentes ao Fiacutegado e Rim 4062 Comparativo com Banco de Dados Relacional 42

7 Conclusotildees e Trabalhos Futuros 45

Referecircncias 46

Lista de Figuras

21 Modelo de cloud adaptado de [14] 522 Modelos e papeis [53] 12

31 Hierarquia das formas normais [39] 1632 Aplicaccedilotildees e organizaccedilatildeo por modelos de dados [54] 1933 Aplicaccedilotildees e organizaccedilatildeo por modelos de banco de dados Adaptada de [42] 22

41 Exemplo de uma famiacutelia de colunas estaacutetica e uma dinacircmica Adaptado de[19] 26

42 Estruturas da escrita e leitura no banco [22] 2743 Estrutura de um cluster Adaptado de [29] 3044 Estrutura de um cluster com particionador aleatoacuterio Adaptado de [29] 31

51 Exemplo de FASTQ 3352 Modelo de dados do banco 3653 Etapas da Inserccedilatildeo 3754 Etapas da Extraccedilatildeo 38

61 Interface do OpsCenter 4062 Comparativo Entre Inserccedilotildees 4263 Comparativo Entre Extraccedilotildees 4364 Graacuteco Comparando Cassandra e Implementaccedilatildeo Relacional 44

Lista de Tabelas

21 Deniccedilotildees de Cloud tabela adaptada de [57 10] 6

61 Arquivos Fiacutegado 4062 Arquivos Rim 4163 Duas Maacutequinas 4164 Quatro Maacutequinas 4165 Arquivos Rim 43

Capiacutetulo 1

Introduccedilatildeo

De modo breve os bancos de dados satildeo denidos como um conjunto de dados relaci-onados entre si armazenados segundo uma determinada estrutura de forma que possamser recuperados quando necessaacuterio Eles costumam ter um sistema responsaacutevel por essearmazenamento e para o controle dos dados [31]

Entre os diferentes paradigmas de Bancos de Dados existe um que se destaca comouma nova opccedilatildeo que estaacute em crescimento trata-se da abordagem natildeo relacional voltadapara o problema e natildeo para a padronizaccedilatildeo Esse paradigma visa eliminar algumas dascaracteriacutesticas que podem ser desnecessaacuterias em um banco como as padronizaccedilotildees geraisa m de se obter um desempenho maior em situaccedilotildees mais especiacutecas

Um banco de dados que se enquadra nessas caracteriacutesticas eacute o Cassandra Ele estaacutedentro de uma subcategoria dos bancos natildeo relacionais chamada de bancos NoSQL e foiconstruiacutedo com seu uso voltado para grandes bases de dados e acesso remoto de altavelocidade [40] Por natildeo ser muito conhecido fora do ambiente acadecircmico e de algumasorganizaccedilotildees e do nuacutemero relativamente baixo de pesquisas sendo feitas com ele estebanco foi escolhido para ser usado nos experimentos desse trabalho a m de se obter suaperformance diante de determinados tipos de dados

O Cassandra assim como boa parte dos bancos NoSQL eacute voltado para um novo e maismoderno modelo de computaccedilatildeo chamando de computaccedilatildeo em nuvem A computaccedilatildeo emnuvem surgiu no nal dos anos 90 em conjunto com algumas das mudanccedilas que zeramcom que o uxo de dados na web crescesse drasticamente [34] Tais mudanccedilas zeramcom que surgissem o termo Big data [24] dados que ocupam grande espaccedilo e exigem certavelocidade de acesso durante o uso Uma caracteriacutestica importante da computaccedilatildeo emnuvem eacute visar a performance ao se trabalhar com Big Data

A computaccedilatildeo em nuvem eacute um modelo que permite acesso faacutecil em todo lugar e sobdemanda de uma rede de recursos de computaccedilatildeo conguraacuteveis (como exemplo redesservidores armazenamento aplicaccedilotildees e serviccedilos) que podem ser rapidamente providose fornecidos com o miacutenimo de esforccedilo de gerenciamento ou interaccedilatildeo com o provedor doserviccedilo [46]

A seguir satildeo expostos brevemente os tipos de dados a serem usados neste estudo decaso e os motivos para a escolha deles

A Bioinformaacutetica surgiu pela necessidade de ferramentas computacionais para a anaacute-lise de dados genocircmicos originados pelos sequenciadores dos projetos genoma Com ocrescimento nos estudos dessa aacuterea surgiu-se uma grande demanda por uma forma de

sequenciamento de mais baixo custo que estimulou o desenvolvimento de tecnologias desequenciamento massivamente paralelos produzindo milhotildees de sequecircncias em uma soacute ro-dada [49] Com o baixo custo uma quantidade muito maior de dados pode ser produzidaem um tempo muito menor No entanto a atual preocupaccedilatildeo natildeo eacute mais somente com oprocessamento mas tambeacutem com o armazenamento e a busca dos dados produzidos poisessa tarefa ainda gera muito custo

Sendo assim tecircm-se uma grande quantidade de dados sendo produzida de forma raacute-pida e estes dados tecircm como caracteriacutestica serem armazenados em grandes arquivos (daordem de GB) e tem-se uma diculdade quanto agrave persistecircncia destes podendo assim serconsiderados Big Data

Para isso a computaccedilatildeo em nuvem e seus bancos NoSQL podem ser aplicados nessestestes Com boas condiccedilotildees de terem resultados satisfatorios

11 Problema e Hipoacutetese

Como problema existe a diculdade no armazenamento do grande volume de dadosgerados por sequecircnciadores geneacuteticos A hipoacutetese dada eacute de que o banco de dados emnuvem Cassandra eacute adequado para a persistecircncia de tais dados

12 Motivaccedilatildeo

A importacircncia deste estudo de caso eacute vaacutelida tanto para a aacuterea de bioinformaacutetica quantopara a computaccedilatildeo pois seu desenvolvimento pode permitir

bull Uma alternativa ao armazenamento dos dados da bioinformaacutetica

bull Uma anaacutelise praacutetica em uma aacuterea nova dos bancos de dados que satildeo os BancosNoSQL

13 Objetivo

O principal objetivo desse trabalho eacute o estudo do comportamento do banco de dadosNoSQL Cassandra com dados da bioinformaacutetica buscando desenvolver uma implementa-ccedilatildeo adequada e vericar se eacute uma opccedilatildeo viaacutevel no aspecto performance

131 Objetivos Especiacutecos

Para alcanccedilar o objetivo geral do trabalho os seguintes objetivos especiacutecos foramdesenvolvidos

bull Denir uma metodologia para criar e manter um ambiente de nuvem do CassandraIsso inclui a escolha do sistema operacional da linguagem e das estruturas de dadosa serem usadas

bull Fazer um estudo de caso com os dados da Bioinformaacutetica testando a eciecircncia dainserccedilatildeo busca e extraccedilatildeo em um ambiente de nuvem do Cassandra A partir dissogerar comparaccedilotildees entre o desempenho das consultas no Cassandra e na implemen-taccedilatildeo relacional atual

bull A realizaccedilatildeo de testes variando o nuacutemero de maacutequinas com o Cassandra instaladovericando a variaccedilatildeo no resultado das consultas e buscas a m de se obter novosdados com esse acreacutescimo

14 Estrutura do Trabalho

A estrutura desse trabalho eacute apresentada a seguir

bull Capiacutetulo 2 Apresentaccedilatildeo dos conceitos baacutesicos de computaccedilatildeo em nuvem tais comodeniccedilotildees e as caracteriacutesticas essenciais aleacutem de modelos e diferentes classicaccedilotildeesque esses ambientes computacionais podem ter

bull Capiacutetulo 3 Eacute feita uma exposiccedilao das caracteriacutesticas e limitaccedilotildees dos bancos rela-cionais e dos bancos natildeo relacionais NoSQL Isso eacute feito para comparar o Cassandraem relaccedilatildeo aos outros bancos

bull Capiacutetulo 4 Destinado a detalhar o Cassandra mostrando sua origem suas ca-racteriacutesticas gerais e seu funcionamento interno Tambeacutem satildeo mostradas as suaslimitaccedilotildees e algumas informaccedilotildees uacuteteis de conguraccedilotildees dele

bull Capiacutetulo 5 Apresentaccedilatildeo de como foi criado e implementado o ambiente dos testesEacute mostrando como satildeo os dados de entrada e o ambiente de nuvem criado

bull Capiacutetulo 6 Exposiccedilatildeo dos resultados atingidos seguidos de uma breve anaacutelise destes

bull Capiacutetulo 7 Conclusotildees nais e possiveis trabalhos futuros

Capiacutetulo 2

Computaccedilatildeo em Nuvem

Neste capiacutetulo satildeo abordados conceitos fundamentais relacionados agrave um ambiente denuvem computacional tendo por base o modelo denido pelo NIST (National Instituteof Standards and Tecnology) [46] Esse modelo eacute composto por cinco caracteriacutesticas es-senciais trecircs modelos de serviccedilo e quatro modelos de implantaccedilatildeo Na Seccedilatildeo 21 satildeoapresentados os conceitos de computaccedilatildeo em nuvem e como esse modelo eacute vantajoso paratodas as partes envolvidas (fornecedor desenvolvedor e usuaacuterio nal) com o uso e forne-cimento do serviccedilo prestado A Seccedilatildeo 22 tem como foco dois modelos computacionaiso Grid Computing e o Utility Computing que satildeo precursores da computaccedilatildeo em nuvemque tornaram-na viaacutevel satildeo abordadas tantos as vantagens quanto as desvantagens destesdois modelos Na Seccedilatildeo 23 as caracteriacutesticas adotadas pelo NIST como essenciais paraque um ambiente seja caracterizado como computaccedilatildeo em nuvem satildeo descritas [53] ASeccedilatildeo 23 apresenta os trecircs modelos de serviccedilo que o ambiente de computaccedilatildeo em nuvempode prestar Por m as questotildees referentes ao modelo de acesso e disponibilidade doserviccedilo chamados de modelos de implantaccedilatildeo [46] satildeo abordados

21 Deniccedilotildees de Computaccedilatildeo em Nuvem

Vaacuterios autores criaram sua proacutepria deniccedilatildeo de computaccedilatildeo em nuvem [1 53] algu-mas destas podem ser vistas na Tabela 21 poreacutem uma das deniccedilotildees mais aceitas eacute adescrita pelo NIST que diz Computaccedilatildeo em nuvem eacute um modelo que permite um acessofaacutecil em todo lugar e sob demanda de uma rede de recursos de computaccedilatildeo conguraacuteveis(a exemplo redes servidores armazenamento aplicaccedilotildees e serviccedilos) que podem ser ra-pidamente providos e fornecidos com o miacutenimo de esforccedilo de gerenciamento ou interaccedilatildeocom o provedor do serviccedilo [46]

Trata-se de uma abstraccedilatildeo que oculta do usuaacuterio nal uma estrutura compartilhadapara a execuccedilatildeo de um serviccedilo na qual este usuaacuterio natildeo se preocupa com o funcionamentointerno do serviccedilo a disponibilidade ou ateacute mesmo se haacute risco de perda dos arquivos tudoisto ca a cargo de quem presta o serviccedilo de computaccedilatildeo em nuvem [53] Como eacute vistona Figura 21 algumas caracteriacutesticas criacuteticas presentes em uma nuvem computacional soacutepodem ser acessadas pelo desenvolvedor e o usuaacuterio nal tem acesso somente agrave aplicaccedilatildeo

As vantagens da computaccedilatildeo em nuvem descritas brevemente a seguir e mais detalha-das na Seccedilatildeo 23 afetam todas as partes ligadas agrave este modelo o usuaacuterio nal a empresaque aloca uma aplicaccedilatildeo na nuvem e a empresa que provecirc o serviccedilo de computaccedilatildeo em

nuvem O usuaacuterio nal passa a ter acesso a uma aplicaccedilatildeo a um serviccedilo ou apenas adocumentos de forma simples sem ser necessaacuterio grande conhecimento na aacuterea de tecno-logia nem mesmo uma plataforma de hardware com grande poder de processamento ouarmazenamento a uacutenica necessidade eacute uma conexatildeo com a internet As vantagens para ousuaacuterio tambeacutem passam pela privacidade pois o serviccedilo normalmente soacute eacute prestado aosusuaacuterios que possuem o coacutedigo de seguranccedila passam pela exibilidade seja na troca deum hardware ou ateacute mesmo na recuperaccedilatildeo do conteuacutedo em caso de furto do aparelho epassam pelo ganho econocircmico pois natildeo se faz mais necessaacuterio a troca de hardware paraacompanhar a tecnologia [1]

Figura 21 Modelo de cloud adaptado de [14]

Uma vez que o armazenamento e o processamento de uma aplicaccedilatildeo eacute terceirizadoa empresa que contrata a alocaccedilatildeo na nuvem pode dispor de mais espaccedilo fiacutesico Outravantagem ao se alocar uma aplicaccedilatildeo em um ambiente de computaccedilatildeo em nuvem eacute quenatildeo existe uma preocupaccedilatildeo com a atualizaccedilatildeo nem com a manutenccedilatildeo dos hardwareso que faz com que sejam reduzidos os gastos computacionais [53] aleacutem de natildeo ter quecontratar funcionaacuterios extras para dar suporte a esta aacuterea cando somente focada nodesenvolvimento e atualizaccedilatildeo da aplicaccedilatildeo

A prestadora do serviccedilo de computaccedilatildeo em nuvem tem a responsabilidade na atua-lizaccedilatildeo dos hardwares para que o processamento sempre esteja disponiacutevel e tambeacutem naredundacircncia das informaccedilotildees armazenadas evitando que conteuacutedo se perca caso existauma falha Para uma empresa que possui o ambiente e a aplicaccedilatildeo em nuvem a vantagemeacute a relaccedilatildeo com o usuaacuterio e a uniformidade do serviccedilo prestado pois tal serviccedilo seraacute omesmo independente do hardware utilizado pelo usuaacuterio

Tabela 21 Deniccedilotildees de Cloud tabela adaptada de [57 10]

Autorreferecircncia Ano DeniccedilatildeoR Buyya 2008 Uma nuvem computacional eacute um tipo de sistema distribuiacutedo e para-

lelo que consiste em um conjunto de computadores interconectadose virtualizados que satildeo providos dinamicamente e presentes comouma ou mais fontes de recursos baseados em contratos de serviccedilosestabelecidos atraveacutes de uma negociaccedilatildeo entre o provedor do serviccediloe o usuaacuterio

R Cohen 2008 Computaccedilatildeo em nuvem tenta abranger uma variedade de aspectosligados ao desenvolvimento que vatildeo desde a implantaccedilatildeo balance-amento de carga fornecimento de recursos modelo de negoacutecio earquitetura (como Web 20) Eacute o proacuteximo passo loacutegico em soft-ware A mais simples explicaccedilatildeo para a computaccedilatildeo em nuvem eacutedescrevendo-a como software centrado na internet

J Kaplan 2008 Computaccedilatildeo em nuvem eacute uma ampla variedade de serviccedilos baseadosna Web que visa permitir que os usuaacuterios obtenham uma gama decapacidades funcionais no formato pague o que usar que antesexigiam investimentos enormes em hardwaresoftware e habilidadesprossionais para adquirir A computaccedilatildeo em nuvem eacute a realizaccedilatildeodos ideais anteriores de Utility computing sem as complexidadesteacutecnicas ou preocupaccedilotildees de implantaccedilatildeo

A Ricadela 2008 Projetos de computaccedilatildeo em nuvem satildeo mais poderosos e resistentesa falhas do que sistemas de Grid mesmo os que foram desenvolvidosrecentemente

I Wladawsky Ber-ger

2008 O principal aspecto eacute virtualizar ou esconder do usuaacuterio a comple-xidade todos os softwares (ao longo do tempo) seratildeo virtualizadossendo gerenciado pelos sistemas eou prossionais que estatildeo emoutro lugar - na nuvem

22 Grid Computing e Utility Computing

A computaccedilatildeo em nuvem natildeo foi a primeira ideia de uma aplicaccedilatildeo ou serviccedilo queestivesse armazenado em um ambiente distribuiacutedo Mladen A Vouk chega ateacute mesmoa armar que a computaccedilatildeo em nuvem apenas eacute uma junccedilatildeo de aacutereas como a virtua-lizaccedilatildeo computaccedilatildeo distribuiacuteda Grid computing Utility computing redes e serviccedilos desoftware [58] Assim para se ter um bom entendimento do que se trata a computaccedilatildeo emnuvem eacute necessaacuterio conhecer Grid computing e Utility computing que satildeo seus precursoresprincipais

221 Grid Computing

Grid computing eacute uma arquitetura orientada a um serviccedilo ou aplicaccedilatildeo [58] pode serdenido como um sistema distribuiacutedo de noacutes heterogecircneos separados geogracamente emdiversos domiacutenios administrativos baseado em sua viabilidade capacidade performancecusto e requisitos dos usuaacuterios quanto agrave qualidade de serviccedilo [51]

A Grid surgiu em um momento em que os recursos fiacutesicos eram muito caros natildeo eraacessiacutevel um computador de alto processamento comeccedilando entatildeo a surgir os grandes datacenters Esse poder de processamento era usado para um nuacutemero limitado de aplicaccedilotildeesgeralmente criadas pelos proacuteprios usuaacuterios desses sistemas [45] que tinham geralmenteobjetivos cientiacutecos de caacutelculos em grande quantidade ou que fosse necessaacuteria alta precisatildeoCada aplicaccedilatildeo diferia muito uma da outra e seria impossiacutevel ter recursos de hardwaresucientes que servissem para cada aplicaccedilatildeo seria necessaacuterio um data center para cadauma delas

Em meados dos anos 80 surgiu a ideia de agregar essas aplicaccedilotildees dentro de diversosdata centers de forma que cada uma utilizasse o processamento de diversos data centersUm data center comportaria vaacuterios serviccedilos e cada serviccedilo se utilizaria de diversos datacenters esse eacute um modelo conhecido como network-centric computing [45] No iniacuteciodos anos 90 muito foi investido em termos de conhecimento para que a Grid computingcrescesse a meta era de dar a ilusatildeo de um recurso sempre disponiacutevel e de faacutecil acessocomo a energia eleacutetrica por isso foi dado esse nome (uma alusatildeo a eletrical grid)Diversos projetos foram construiacutedos a partir desse modelo alguns satildeo

bull Projeto Condor desenvolvido em 1984 na Universidade de Wisconsin com a meta defazer uma distribuiccedilatildeo de recursos entre todos os computadores de um departamentoda universidade [56]

bull Projeto Codine desenvolvido por volta dos anos 90 provia uma interface graacutecasimples para observar todos os recursos disponiacuteveis Era um projeto de coacutedigo abertoem parceria com a empresa Sun Microsystems Esse projeto foi muito similar aoCondor e a proacutexima geraccedilatildeo do Codine se tornou o Sun Grid Engine e era disponiacutevelgratuitamente na Internet [35]

bull Projeto Legion desenvolvido em 1993 na Universidade de Virginia tinha uma abor-dagem voltado agrave orientaccedilatildeo de objetos No entanto muitos serviccedilos para ambientesdistribuiacutedos natildeo eram orientados a objeto [36]

bull Projeto NimrodG desenvolvido em 1994 na Universidade de Monash Austraacuteliacom o objetivo de distribuir recursos para serviccedilos heterogecircneos [2 9]

O modelo de Grid computing proposto trazia grandes benefiacutecios seria possiacutevel teracesso aos recursos de hardware que estavam geogracamente distribuiacutedos em diversasorganizaccedilotildees Ele dava um acesso transparente e instantacircneo ao usuaacuterio da aplicaccedilatildeoProvia recursos extras para resolver problemas antes natildeo solucionaacuteveis devido agrave falta derecursos

Foi criada uma infraestrutura mais conaacutevel em que existia a possibilidade de agregarrecursos sob demanda em vaacuterios locais Isso para satisfazer uma necessidade de recursosque natildeo podem ser imprevistos Para esse modelo funcionar corretamente explorava-seos recursos que eram pouco ou ateacute mesmo natildeo utilizados pois de outra forma seriamdesperdiccedilados Essas vantagens tambeacutem afetaram o campo da manutenccedilatildeo do hardwarepois diminuiu o esforccedilo da gestatildeo se comparado a muacuteltiplos computadores com muacuteltiplossistemas independentes [60]

Por m o Grid computing tambeacutem traz uma reduccedilatildeo de custos com novos processado-res memoacuteria e locais para armazenamento de dados uma reduccedilatildeo do tempo de resoluccedilatildeode um processo pela maior quantidade de recursos e a consequecircncia eacute um aumento daprodutividade [51]

Na eacutepoca do desenvolvimento do Grid computing os serviccedilos utilizados na Internetnatildeo distinguiam quais lugares tem mais ou menos processamento para distribuem essesrecursos A ideia do Grid computing era realocar esses recursos ateacute mesmo agregarpara um maacuteximo ganho no desempenho e para soluccedilatildeo de problemas complexos quetrariam grandes vantagens Poreacutem olhando em retrospecto eacute possiacutevel perceber que omodelo teve diversas desvantagens fazendo com que o Grid natildeo tivesse o reconhecimentoesperado soacute voltando a tona recentemente quando a Cloud computing incorporou algumascaracteriacutesticas dele Algumas dessas desvantagens satildeo [58 51]

bull Os desenvolvedores eram difiacuteceis de encontrar por ser uma tarefa complexa erapreciso que os encarregados fossem muito capacitados Os desenvolvedores eramresponsaacuteveis tambeacutem pela manutenccedilatildeo e era necessaacuterio que eles fossem especiali-zados nas aacutereas de redes hardware armazenamento programaccedilatildeo de baixo niacutevelsistemas operacionais entre outras

bull Outra diculdade do Grid eacute que natildeo existia um controle formal de quantos recursoscada aplicaccedilatildeo poderia utilizar para solucionar seu processamento podendo fazercom que uma aplicaccedilatildeo demande tantos recursos quanto possiacutevel e prejudicando oprocessamento de outras aplicaccedilotildees

bull Uma das principais desvantagens foi a heterogeneidade dos recursos de hardware quesatildeo dispostos pois isso que desencadeia a diculdade na manutenccedilatildeo do hardwaree no controle da distribuiccedilatildeo destes

bull Outra desvantagem foi que o Grid foi criado para ser voltado somente para estudoscientiacutecos e a heterogeneidade dos domiacutenios administrativos(diferentes universidadese oacutergatildeos puacuteblicos) prejudicou o avanccedilo dessa tecnologia

bull As aplicaccedilotildees do Grid natildeo eram de faacutecil usabilidade natildeo havia tanta preocupaccedilatildeocom a interface do software e o usuaacuterio nal

Aleacutem de trazer essas desvantagens citadas o ambiente em que esse modelo foi criadonatildeo foi propiacutecio para seu desenvolvimento Desde o surgimento da Grid houveram diversas

transformaccedilotildees tecnoloacutegicas nas quais o computador pessoal se desenvolveu tanto quantoos cientiacutecos e o investimento voltou-se para esses visto que possuiam mais puacuteblico o quefez com que natildeo se prolongasse o desenvolvimento de uma computaccedilatildeo distribuiacuteda a niacuteveisde pesquisa mas sim para o usuaacuterio nal Apesar destas desvantagens algumas caracte-riacutesticas como compartilhamento de recursos e uma arquitetura voltada a uma aplicaccedilatildeoforam aprimorados e incorporados pela Cloud Computing

222 Utility Computing

Os estudos feitos utilizando o Grid computing deixaram claro que o processamentocomputacional seria mais ecaz se feito de forma distribuiacuteda em uma rede de computa-dores Em busca de estabelecer redes de recursos distribuiacutedos e oferecer o acesso a estesrecursos como serviccedilo foi criado o conceito de Utility computing O Utility computing foifortalecido com o pensamento de Gordon Bell o qual sugeriu em uma conferecircncia em 1992o uso da programaccedilatildeo paralela em massa [60 45] O Utility computing foi semelhante aoGrid poreacutem agora um modelo que natildeo era voltado somente as pesquisas cientiacutecas OUtility computing tem por objetivo prover um mecanismo de compartilhamento que tornamais ecaz o uso dessa infraestrutura de recursos computacionais para o usuaacuterio apenasquando requisitado por esse Os recursos que tem um potencial subutilizado podem serrealocados de forma que essa subutilizaccedilatildeo seja miacutenima [4]

Utility computing pode ser dividido em duas categorias o modelo de recursos de umservidor completo (full server utility model) [4] em que os recursos satildeo adquiridos e li-berados sob demanda e o modelo de recursos distribuiacutedos (shared utility model) [4] noqual uma quantidade limitada de recursos eacute explorada por muacuteltiplos usuaacuterios ao mesmotempo O modelo de recursos distribuiacutedos pode ser uma aplicaccedilatildeo dentro de um modelode recursos de um servidor completo No modelo de servidor completo satildeo usados meca-nismos de escalonamento porque haacute uma grande quantidade de requisiccedilotildees e o controleda aplicaccedilatildeo tem de ser preciso ao alocar e liberar recursos

Utility computing oferece vantagens tanto ao provedor como para o usuaacuterio Os usuaacute-rios pagam apenas pelo uso do processamento armazenamento e comunicaccedilatildeo entre umafonte e outra aleacutem do que o provedor entrega um serviccedilo que distancia o usuaacuterio nalda complexidade do hardware ele natildeo precisa mais se preocupar com manutenccedilatildeo nemmesmo com aquisiccedilatildeo de novos componentes para melhorar sua performance ou apenasse equiparar com a tecnologia utilizada [50] O grande gasto com novos harware se tornaum pequeno custo por um serviccedilo que se encaixa perfeitamente em seu perl sem perdaou sobra de recursos computacionais Jaacute pelo lado do provedor natildeo eacute necessaacuterio ter umtratamento exclusivo para cada usuaacuterio uma soluccedilatildeo virtualizada eacute congurada para quede forma dinacircmica satisfaccedila um grupo de pessoas Sendo essa alocaccedilatildeo de recursos dinacirc-mica ca faacutecil para o provedor realocar recursos para os usuaacuterios com maiores prioridadese isso faz com que a chance de existirem recursos subutilizados se tornem miacutenimas [4]

Como eacute possiacutevel observar o Utility computing caracteriza-se por um serviccedilo voltadoapenas para a infraestrutura de uma aplicaccedilatildeo que busca seguranccedila exibilidade baixocusto com energia e escalabilidade Com o tempo a Cloud Computing se desenvolveu e omodelo Utility computing foi incorporado como um modelo de serviccedilo da Cloud Compu-ting o Infrastructure as a Service que eacute tratado na Seccedilatildeo 23

23 Caracteriacutesticas Essenciais da Nuvem

Para classicar uma soluccedilatildeo como computaccedilatildeo em nuvem existem certas caracte-riacutesticas que foram adotadas como sendo essenciais [53] De modo que elas a denementre os outros paradigmas e mostram as qualidades necessaacuterias que um bom serviccedilo decomputaccedilatildeo em nuvem deve ter Satildeo elas [46]

Self-service sob Demanda

O usuaacuterio adquire o recurso computacional unilateralmente em que ele especique otamanho do espaccedilo para armazenamento e o tempo de processamento O hardware e osoftware dentro da computaccedilatildeo em nuvem podem ser recongurados automaticamente eessas alteraccedilotildees satildeo informadas ao usuaacuterio Podem ser criados pers diferentes para porexemplo a instalaccedilatildeo de softwares ou alteraccedilotildees nas conguraccedilotildees de rede

Amplo Acesso

Recursos disponiacuteveis por meio da rede seguindo padrotildees para acesso de diferentesdispositivos como notebooks ou celulares O acesso se faz com o uso de um navegador deinternet ou algum outro software leve fornecido pela proacutepria nuvem

Pooling de Recursos

Para atender a diversos usuaacuterios eacute criado um pool onde satildeo agrupados os recursoscomputacionais do provedor Eles satildeo dinamicamente atribuiacutedos e ajustados de acordocom a demanda dos usuaacuterios Os usuaacuterios natildeo precisam saber exatamente a localizaccedilatildeofiacutesica desses recursos apenas em um niacutevel mais alto como a localizaccedilatildeo geograacuteca apro-ximada (paiacutes estado datacenters) Os exemplos de recursos incluem armazenamentoprocessamento memoacuteria largura de banda de rede e maacutequinas virtuais

Elasticidade Raacutepida

Os recursos podem ser adquiridos ou removidos de forma raacutepida (automaacutetica ou natildeo)se houver uma variaccedilatildeo da demanda Tal caracteriacutestica daacute ao usuaacuterio a sensaccedilatildeo de queexistem recursos ilimitados que podem ser adquiridos a qualquer momento e em qualquerquantidade Normalmente essa caracteriacutestica eacute alcanccedilada fazendo-se uso de uma maacutequinavirtual que permite sua reconguraccedilatildeo durante a execuccedilatildeo

Serviccedilo Medido

O uso de recursos dos sistemas de computaccedilatildeo em nuvem deve ser medido e analisadopara conseguir uma otimizaccedilatildeo feito de forma automaacutetica Isso garante transparecircnciapara o provedor e para o usuaacuterio A automaccedilatildeo tambeacutem eacute realizada no niacutevel de abstraccedilatildeoadequado para o serviccedilo como no armazenamento processamento largura de bandae contas de usuaacuterio O uso de recursos pode ser monitorado controlado e reportadooferecendo transparecircncia tanto para o usuaacuterio quanto para o provedor do serviccedilo utilizado

24 Modelos de Serviccedilo

Diferentemente do Utility computing que era um modelo voltado para a infraestruturacomo um serviccedilo a computaccedilatildeo em nuvem possui trecircs modelos de serviccedilo o Softwarecomo Serviccedilo (SaaS) a Plataforma como Serviccedilo (PaaS) e a Infraestrutura como Serviccedilo(IaaS) [53] Tais modelos foram criados para se representar que tipo de padratildeo de arqui-tetura seraacute usado em determinado ambiente De acordo com o tipo de cliente ou de suanecessidade pode-se decidir o modelo mais adequado para se usar Estes quatro modelossatildeo melhores descritos a seguir

SaaS Software como Serviccedilo eacute o modelo que visa o usuaacuterio nal Trata-se da dis-ponibilizaccedilatildeo de softwares com propoacutesitos especiacutecos acessados pelo usuaacuterio atraveacutes dainternet Quando se fala em computaccedilatildeo em nuvem fora do meio acadecircmico ou empre-sarial que natildeo seja TI (Tecnologia da Informaccedilatildeo) normalmente eacute a este modelo que aspessoas se referem

Normalmente qualquer pessoa por meio de um ou mais dispositivos clientes com acessoa web pode fazer uso de seus recursos atraveacutes de uma interface simples e intuitiva Acomputaccedilatildeo em nuvem torna-se vantajosa ao usuaacuterio nal pois este desconhece e natildeotem poder para modicar a infraestrutura por traacutes do serviccedilo incluindo rede servidoresarmazenamento ou o sistema operacional usado pelo serviccedilo Cabe a ele fazer uso dosoftware e alterar apenas as conguraccedilotildees internas disponibilizadas

O processamento da aplicaccedilatildeo que eacute disponibilizada eacute descentralizado e o serviccedilo serprestado por meio da internet podendo ser usado a qualquer momento e tomando poucosrecursos da maacutequina exigindo apenas um programa para se fazer o acesso como umnavegador ou a proacutepria aplicaccedilatildeo cliente Outra vantagem eacute que devido a separaccedilatildeo entreo usuaacuterio e o ambiente onde se encontra o software eacute possiacutevel que se faccedila atualizaccedilotildeesno sistema independente do hardware usado pelo usuaacuterio a incorporaccedilatildeo de recursosnovos atualizaccedilotildees ou qualquer tipo de evoluccedilatildeo pode ser feito de maneira mais raacutepidaA noticaccedilatildeo ao usuaacuterio informando tais mudanccedilas eacute opcional

PaaS Plataforma como Serviccedilo como o nome sugere eacute uma plataforma de desen-volvimento para programadores implementarem aplicaccedilotildees em nuvem Quem utiliza esteserviccedilo satildeo os desenvolvedores eles tem controle sobre as aplicaccedilotildees colocadas na infra-estrutura e podem fazer uso de ferramentas disponibilizadas pela computaccedilatildeo em nuvempara auxiliar o desenvolvimento

Convencionalmente eacute oferecido ao usuaacuterio o ambiente em que iraacute trabalhar contendoum sistema operacional e o suporte para as linguagens de programaccedilatildeo ofertadas

O uso de PaaS pode ser visto como uma soluccedilatildeo estrateacutegica para empresas que queremterceirizar parte do processo de desenvolvimento tornado sua equipe responsaacutevel apenasem usar as ferramentas e ambientes prontos em seus projetos

IaaS Infraestrutura como Serviccedilo eacute classicado como o modelo de mais baixo niacutevelque pode ser oferecido em ambientes de computaccedilatildeo em nuvem Trata-se do espaccedilo emsi em que seratildeo colocados os dados softwares sistemas operacionais e qualquer tipo deaplicaccedilatildeo Eacute fornecida ao usuaacuterio uma interface para a administraccedilatildeo da infraestrutura

Seu funcionamento consiste na virtualizaccedilatildeo de recursos computacionais a m de segarantir a possibilidade de alteraccedilotildees como o aumento ou reduccedilatildeo de tais recursos demaneira dinacircmica

Na Figura 22 eacute mostrado como eacute feito o relacionamento entre os modelos e as pessoasque participam de alguma maneira do ambiente de computaccedilatildeo em nuvem Como podeser observado o provedor fornece pelo menos um dos modelos de serviccedilo da computaccedilatildeoem nuvem O desenvolvedor se utiliza do IaaS e do PaaS para forneccediler o modelo SaaS Ousuaacuterio nal somente consome o SaaS que pode ser tanto fornecido pelo provedor comopelo desenvolvedor

Figura 22 Modelos e papeis [53]

25 Modelos de Implantaccedilatildeo

Outro tipo de classicaccedilatildeo para ambientes de computaccedilatildeo em nuvem eacute o seu modelode implantaccedilatildeo referente ao acesso e a disponibilidade do serviccedilo As empresas podempossuir necessidades diferentes quanto a liberdade de uso de alguns de seus recursos

Para resolver esse tipo de situaccedilatildeo surgiu a ideia de ambientes mais restritos onde eacuteexigida uma autenticaccedilatildeo para se denir o niacutevel do usuaacuterio e prover os serviccedilos em quepossui autorizaccedilatildeo

Denem-se assim os modelos de implantaccedilatildeo da computaccedilatildeo em nuvem que satildeo qua-tro nuvem privada nuvem comunitaacuteria nuvem puacuteblica e nuvem hiacutebrida [46] Cada umdestes tipos eacute descrito a seguir

Nuvem Privada

No modelo de nuvem privada sua infraestrutura eacute guardada por um grupo ou orga-nizaccedilatildeo que eacute sua proprietaacuteria ou a terceirizou Fazem uso de poliacuteticas de acesso paralimitar seu uso interno em vaacuterias aacutereas tendo cada uma algum privileacutegio diferente Nocaso de usuaacuterios que natildeo pertencem a esse grupo ou organizaccedilatildeo o acesso natildeo eacute permitido

Nuvem Comunitaacuteria

Uma nuvem comunitaacuteria eacute compartilhada por vaacuterias organizaccedilotildees e suportada poralguma comunidade com objetivos em comum Esse modelo de implantaccedilatildeo pode sermantido remotamente ou ateacute localmente Sendo mantido por uma das empresas envolvidasou algum terceiro

Nuvem Puacuteblica

Como o nome sugere a nuvem puacuteblica eacute de acesso livre Nesse modelo qualquerpessoa com conhecimento sobre o serviccedilo pode acessar a nuvem sem que haja qualquerrestriccedilatildeo quanto as suas funcionalidades

Nuvem Hiacutebrida

Uma nuvem hiacutebrida eacute uma composiccedilatildeo de dois ou mais tipos de modelos de implan-taccedilatildeo Costumam ser soluccedilotildees uacutenicas que seguem algum padratildeo estabelecido para fazersuas conexotildees e garantir a portabilidade

Capiacutetulo 3

Caracteriacutesticas e Diferenccedilas entre

Bancos de Dados Relacionais e Natildeo

Relacionais

Bancos de dados podem ser classicados como relacionais e como natildeo relacionaisNeste capiacutetulo seraacute apresentada uma breve introduccedilatildeo a bancos relacionais na Seccedilatildeo 31e informaccedilotildees sobre bancos natildeo relacionais voltados para NoSQL na Seccedilatildeo 32

31 Bancos de Dados Relacionais

Um banco de dados eacute comumente denido como uma coleccedilatildeo de dados organizadose persistentes A tarefa de armazenar os dados e controlar a sua estrutura a niacutevel dehardware eacute do Sistema Gerenciador de Banco de Dados (SGBD) Eacute esse programa que faz ainterface entre os dados inseridos pelo usuaacuterio e o servidor onde os dados satildeo armazenados

A linguagem que o usuaacuterio deve usar para se comunicar com o banco eacute o SQL Umlinguagem de script declarativa fortemente baseada na aacutelgebra relacional Ela diferencia-se por sua simplicidade e pela facilidade de uso [39]

Todo banco de dados relacional eacute composto por tabelas que representam relaccedilotildees Daiacuteo nome relacional Cada tabela eacute um conjunto natildeo necessariamente ordenado de linhasou tuplas Essas linhas por sua vez compreendem uma seacuterie de campos onde estatildeoguardados os valores dos atributos Os atributos satildeo associados agraves colunas da tabela

Aleacutem das linhas natildeo estarem ordenadas tambeacutem eacute possiacutevel diferenciar um bancode dados de um arquivo convencional pela possibilidade de consultar os dados usandoqualquer criteacuterio adotado pelo usuaacuterio as consultas podem ser feitas de modo a permitirencontrar conexotildees complexas entre as informaccedilotildees com apenas uma uacutenica busca [39]

No modelo relacional dois conceitos satildeo fundamentais para o seu funcionamento demaneira correta atributos chaves de uma tabela e as restriccedilotildees de integridade

Atributo Chave

Um conceito de grande importacircncia para o entendimento das relaccedilotildees entre linhas detabelas em um banco relacional eacute o conceito de chave que podem ser classicada comochave primaacuteria e estrangeira

A chave primaacuteria eacute uma coluna ou combinaccedilatildeo delas cujos valores se distinguem detodas as linhas da tabela Seu papel eacute devido ao fato de ser uacutenica localizar qualquerlinha da tabela de maneira natildeo ambiacutegua Como iacutendice ela tambeacutem serve para representaruma entidade ao se fazer associaccedilotildees mais complexas [31]

A chave estrangeira tem o mesmo valor de uma chave primaacuteria sendo utilizada paraimplementar relacionamentos entre tabelas Seu uso serve para ser uma referecircncia a umoutro atributo permitindo a implementaccedilatildeo de dependecircncias dentro do banco de dadosEacute dever do SGBD vericar se quando uma chave primaacuteria eacute alterada todas as chavesestrangeiras que fazem referecircncia a ela tambeacutem sejam atualizadas [39]

Restriccedilotildees de Integridade

A integridade dos dados eacute um dos objetivos primordiais de um SGBD Os dadosde um banco satildeo classicados como iacutentegros quando reetem de maneira correta o queestatildeo querendo representar e satildeo consistentes entre si As restriccedilotildees de integridade satildeoregras que foram criadas como um mecanismo para garantir que essa consistecircncia sejamantida Para a abordagem relacional elas podem ser classicadas segundo Heuser comas seguintes categorias [39] integridade de domiacutenio integridade de vazio integridade dechave e integridade referencial

Integridade de domiacutenio satildeo restriccedilotildees que especicam que o valor de um campo tenhaque seguir o tipo de dados que foi denido para aquela coluna Natildeo eacute permitido que ousuaacuterio nal crie domiacutenios novos para a sua aplicaccedilatildeo mas apenas use os domiacutenios quejaacute estatildeo predenidos (real inteiro caracteres etc)

Integridade de vazio diz respeito a um campo poder receber o valor null e que sejaimpedido que o usuaacuterio quebre essa regra apoacutes deni-la Os campos marcados como chavesprimaacuterias natildeo podem ser deixados vazios

A integridade de chave eacute a restriccedilatildeo que dene que os valores de uma chave primaacuteriacomo em um identicador (ID) devem ser uacutenicos

E por uacuteltimo a integridade referencial dene que os valores de um campo que pertencea uma chave estrangeira devem ser sempre iguais aos da chave primaacuteria que eles referen-ciam Sendo feita uma alteraccedilatildeo em uma chave primaacuteria todos os valores das chavesestrangeiras referentes agravequele atributo devem ser atualizados

Todas essas restriccedilotildees satildeo de responsabilidade do SGBD estando o usuaacuterio livre de terque se preocupar com o comprimento dessas regras Vale ressaltar que o usuaacuterio tambeacutempode criar suas proacuteprias restriccedilotildees de integridade conforme seus objetivos sendo que nocaso delas ele escreva explicitamente o coacutedigo ou script que iraacute garanti-las [39]

311 Normalizaccedilatildeo

Um aspecto importante que deve ser lembrado ao se tratar de bancos de dados rela-cionais eacute a normalizaccedilatildeo Trata-se do termo forma normal uma regra formalizada quedeve ser seguida para que uma tabela seja considerada bem projetada Existem vaacute-rias formas normais sendo cada uma delas com um conjunto de regras diferente a mde classicar o projeto dos bancos Satildeo vistas aqui as trecircs primeiras formas normaisque satildeo as fundamentais para garantir um miacutenimo de redundacircncia para um bom modelode dados [31] A Figura 31 mostra a comparaccedilatildeo entre as formas normais no aspectoabrangecircncia

Primeira Forma Normal

Uma tabela encontra-se na primeira forma normal quando natildeo conteacutem tabelas aninha-das dentro dela ou seja informaccedilotildees natildeo diretamente relacionadas guardadas de maneiraredundante dentro da tabela

Segunda Forma Normal

Uma tabela estaacute na segunda forma normal quando aleacutem de estar na primeira formanormal natildeo apresenta dependecircncias parciais Uma coluna natildeo pode depender de apenasparte da chave primaacuteria portanto quando uma tabela possui apenas uma chave primaacuteriae estaacute na primeira forma normal ela jaacute estaacute na segunda forma normal

Terceira Forma Normal

Classica-se uma tabela na terceira forma normal quando estaacute na segunda formanormal e todo atributo natildeo chave for dependente de outro atributo que natildeo pertenccedilaagrave chave primaacuteria

Figura 31 Hierarquia das formas normais [39]

312 Limitaccedilotildees

Os dados inseridos em um banco de dados relacional cam em vaacuterias tabelas ligadasentre si por meio de chaves estrangeiras O modelo relacional natildeo obriga a criaccedilatildeo de umaestrutura de tabelas coesa assim programadores inexperientes podem projetar sistemascomplexos sem necessidade ou projetos que limitam o desenvolvimento futuro

Com o aumento da complexidade do projeto do banco torna-se mais difiacutecil fazer asua administraccedilatildeo e com o aumento das pessoas envolvidas a possibilidade de erros ouinconsistecircncias natildeo pode ser desprezada

Com o grande aumento do volume de dados em alguns casos o desempenho de bancosrelacionais jaacute natildeo eacute satisfatoacuterio devido ao crescimento do tempo de certas consultas [8]

Os bancos relacionais apresentam uma seacuterie de caracteristicas chamadas de ACID querepresentam atomicidade consistecircncia integridade e durabilidade dos dados Apesar deser um oacutetimo modelo pode se tornar um obstaacuteculo ao buscar-se uma maior liberdade deesquema ou mais recursos escalaacuteveis [59]

32 Bancos Natildeo Relacionais NoSQL

Os bancos de dados que natildeo apresentam todas as caracteriacutesticas ACID satildeo classicadoscomo bancos natildeo relacionais como eacute o exemplo do modelo de banco de dados orientadoa objetos [37 3] e do NoSQL (Not only Structured Query Language) Como o Cassandraeacute um banco NoSQL esta seccedilatildeo focaraacute nos bancos que seguem esse padratildeo

Deniccedilatildeo de NoSQL

O termo NoSQL foi usado pela primeira vez em 1998 para citar um banco de da-dos relacional open-source que omitia o uso de SQL o Strozzi NoSQL criado por CarloStrozzi [34] O nome veio pelo fato que o banco de dados natildeo utiliza o SQL como alinguagem de busca no lugar o banco utilizava scripts de shell Poreacutem o uso do termocomo hoje eacute conhecido natildeo se refere ao banco desenvolvido por Strozzi [34] Em 2009em uma conferecircncia conhecida como NoSQL Meetup que foi organizada por Johan Os-karsdon o criador do Lastfm [55] o termo foi utilizado novamente poreacutem referenciandobancos de dados natildeo relacionais Nessa conferecircncia cou claro que o uso do Amazons Dy-namo e do Google Bigtable (precursores do movimento NoSQL) estava se popularizandoprincipalmente no meio das start-ups e um novo conceito estava se formando [55]

Uma deniccedilatildeo de NoSQL eacute que ele eacute um conjunto de conceitos que permitem o pro-cessamento de dados de forma raacutepida e eciente com um foco em performance [43] Eacuteum modelo alternativo pensado para se modelar os dados sem ter que seguir os padrotildeesriacutegidos criados para o modelo relacional Como medida para se contornar esse problemaele foi proposto trazendo consigo planos de eliminar ou reduzir essa estruturaccedilatildeo [8] Paraevitar a perda de informaccedilotildees o NoSQL tem uma arquitetura distribuiacuteda tolerante a fa-lhas que se baseia na redundacircncia de dados em vaacuterios servidores Dessa forma o sistemapode ser escalado facilmente agregando mais servidores e assim a falha de um deles podeser tolerada

321 Caracteriacutesticas do NoSQL

Bancos NoSQL satildeo projetados para trabalharem com uma grande quantidade de dadosdistribuiacutedos Algumas caracteriacutesticas comuns em um banco de dados NoSQL satildeo [43]

bull Prover uma grande escalabilidade horizontal Essa caracteriacutestica consiste em cadaaplicaccedilatildeo ser capaz de aumentar seu nuacutemero de noacutes com a camada IaaS ou seja eacutea grande capacidade de requisiccedilatildeo de mais recursos de armazenamento e processa-mento

bull Prover uma baixa latecircncia Essa caracteriacutestica eacute obtida por meio da escalabilidadehorizontal que se caracteriza pela otimizaccedilatildeo do tempo de um grande processa-mento dividindo ele em vaacuterios pequenos processos que satildeo distribuiacutedos em diferentesmaacutequinas assim o tempo de resposta diminui para uma ordem de alguns poucosmilissegundos

bull Prover grande disponibilidade de acesso Essa caracteriacutestica eacute obtida por meio dogrande processamento que permite um acesso de um nuacutemero de usuaacuterio maior queos gerenciadores de bancos de dados relacionais

bull Prover um processamento de grandes dados seja uma grande quantidade de ciclosde leitura e escrita ou uma quantidade massiva de acessos de usuaacuterios

Existem cenaacuterios em que o tempo de resposta eacute mais relevante que a consistecircncia dosdados recebidos isso ocorre principalmente em serviccedilos que provecircm streaming de miacutedia(como muacutesicas ou lmes online) paacuteginas web com alto traacutefego de usuaacuterios (redes sociais)e casos em que se indexam um grande nuacutemero de documentos Nessas situaccedilotildees se ainformaccedilatildeo for recebida de forma atrasada para a proposta do serviccedilo jaacute natildeo seraacute maisuacutetil ou o grande nuacutemero de acessos faria com que o processamento do banco natildeo fosseeciente

Essas caracteriacutesticas estatildeo entre as vantagens que zeram com que o NoSQL se de-senvolvesse rapidamente no meio empresarial e no meio cientico quando lidam com umgrande volume de dados e aplicaccedilotildees web em tempo real

322 Modelos de Bancos NoSQL

No contexto de bancos de dados NoSQL eacute possiacutevel encontrar uma diversidade demodelos de dados a Figura 32 ilustra um conjunto de modelos e aplicaccedilotildees NoSQL

O armazenamento de dados do NoSQL que estaacute contido dentro do modelo natildeo re-lacional se difere do banco de dados relacional no aspecto que os sistemas de gerecircnciade banco de dados relacionais armazenam apenas dados estruturados em vaacuterias tabelase os sistemas de gerecircncia NoSQL armazenam tanto dados estruturados como dados natildeoestruturados dados estes armazenados em coleccedilotildees sem relacionamentos entre si assimsatildeo caracterizados como dados natildeo estruturados Por natildeo possuiacuterem relaccedilotildees geralmentenatildeo eacute possiacutevel fazer uma correlaccedilatildeo entre essas coleccedilotildees de dados por meio da linguagemde consulta Para otimizar a consulta a forma que os dados satildeo armazenados no banco eacutecrucial com esse m foram elaborados alguns modelos de armazenamento de dados natildeoestruturados orientado a documentos modelo chavevalor tabular e orientado a grafosA seguir satildeo apresentados esses modelos Eacute importante lembrar que muitas aplicaccedilotildees natildeose encaixam somente em um modelo de dados e essa eacute uma lista que estaacute em constantetransformaccedilatildeo

ChaveValor

Omodelo de armazenamento chavevalor foi o modelo precursor do movimento NoSQLpois a partir dos seus dois mais conhecidos expoentes o Amazon DynamoDB e o GoogleBigTable que foi observado em 2009 que os bancos de dados natildeo relacionais poderiamser uma alternativa aos modelos SQL [38]

Figura 32 Aplicaccedilotildees e organizaccedilatildeo por modelos de dados [54]

O armazenamento chavevalor eacute similar ao mapeamento feito em dicionaacuterios e enci-clopeacutedias Os dados satildeo endereccedilados por uma uacutenica chave Tendo os valores como apenasuma sequecircncia de bytes que natildeo apresentam signicado o sistema natildeo os interpreta ouos classica Portanto a uacutenica maneira de guardaacute-los eacute atraveacutes de chaves para cada valorarmazenado Por consequecircncia os valores satildeo isolados e completamente independentesum do outro tornando necessaacuterio que as relaccedilotildees sejam tratadas pela loacutegica de aplicaccedilatildeo

Devido tambeacutem a essa estrutura simples o banco de dados eacute livre de qualquer es-quema Novos valores podem ser inseridos a qualquer momento sem que haja conitoscom os dados jaacute guardados e natildeo afetando a disponibilidade do sistema O agrupamentochavevalor em coleccedilotildees eacute o uacutenico meio de se acrescentar uma estrutura ao banco dedados

Este modelo eacute uacutetil para se fazer operaccedilotildees simples que se baseiam em atributos inde-xados Uma vantagem desse modelo eacute a velocidade de suas consultas especialmente asusadas com mais frequecircncia [38]

Documento

Os bancos de dados que seguem esse modelo tecircm como o principal conceito os do-cumentos Eles os armazenam e os recuperam Esses documentos satildeo auto-descritivossatildeo estruturas de dados de aacutervores hieraacuterquicas que podem representar mapas coleccedilotildeese outros objetos Os documentos armazenados ali apresentam uma similaridade uns comos outros mas natildeo tecircm de ser exatamente a mesma formataccedilatildeo

Esses bancos de dados assemelham-se aos bancos chavevalor tanto que satildeo consi-derados por muitos como o proacuteximo passo de um armazenamento chavevalor simplespara estruturas de dados um pouco mais complexas e signicativas [55] Isso se daacute pelofato dos bancos de dados baseados em documentos armazenarem os documentos na partedo valor do armazenamento de chavevalor Eacute possiacutevel compreender os bancos de da-dos de documentos como bancos chavevalor nos quais eacute possiacutevel se pesquisar dentro deum campo Dentro dos documentos as chaves devem ser uacutenicas Para cada documentoexiste um identicador chamado ID que tambeacutem deve ser uacutenico e serve para identicar odocumento na coleccedilatildeo

A diferenccedila entre este modelo e o modelo chavevalor eacute que no modelo de documentosos valores natildeo satildeo ocultos para o sistema e podem ser buscados ou referenciados tambeacutemAssim estruturas mais complexas como objetos aninhados podem ser tratadas com maisconveniecircncia Uma outra vantagem de guardar dados em documentos JSON eacute o suportepara tipos de dados tornando o uso mais faacutecil para desenvolvedores

Assim como o modelo chavevalor o modelo de documentos eacute livre de restriccedilotildees deesquema Isso facilita inserir novos documentos ou atributos aos jaacute existentes durante aexecuccedilatildeo

Uma das vaacuterias vantagens desse modelo eacute a facilidade de migraccedilatildeo e integraccedilatildeo de basesde dados A organizaccedilatildeo dos atributos pode permitir tambeacutem uma facilidade maior de ge-rar estatiacutesticas [38] Os bancos mais conhecidos baseados em documento satildeo o MongoDBdesenvolvido pela 10gen open-source e o CouchDB desenvolvido pela Apache [34]

Orientado a Colunas

O modelo orientado a colunas tambeacutem conhecido como modelo tabular eacute um modelodesenvolvido para suportar uma quantidade muito grande de dados Trata-se de um mapade dados amplo persistente distribuiacutedo e multidimensional Como as informaccedilotildees natildeo satildeointerpretadas pelo banco de dados elas podem ter tamanhos variados e por consequecircnciadevem ser tratadas e organizadas pela camada de aplicaccedilatildeo Muacuteltiplas versotildees de umvalor satildeo armazenadas em ordem cronoloacutegica para se ter suporte a versionamentos e apossibilidade de se comparar a performance entre elas

As colunas podem ser organizadas em famiacutelias de colunas para facilitar a organizaccedilatildeoe o particionamento do banco podendo tambeacutem ser adicionadas a qualquer momentoEntretanto uma famiacutelia de colunas natildeo pode ser denida durante a execuccedilatildeo o que levaa uma menor exibilidade em relaccedilatildeo aos modelos chavevalor e documento [38]

O banco de dados Cassandra eacute uma implementaccedilatildeo do modelo tabular poreacutem com umconceito a mais chamado de super-colunas que permite ao Cassandra a possibilidade detrabalhar com estruturas de dados mais complexas Mais informaccedilotildees sobre o Cassandrae sobre esse modelo de dados satildeo apresentadas no Capiacutetulo 4

Orientado a Grafos

Diferente do modelo relacional e dos modelos natildeo relacionais vistos ateacute agora o modeloorientado a grafos se especializa no gerenciamento eciente de dados fortemente conec-tados Aplicaccedilotildees baseadas em dados com muitas relaccedilotildees satildeo mais adequadas para essemodelo de banco devido ao custo de fazer buscas com muitas conexotildees

Como o nome sugere esse modelo permite que o banco de dados apresente a forma deum grafo Conforme eacute denido em um esquema o sistema constroacutei um grafo onde cadanoacute possui uma par chave e valor Uma aplicaccedilatildeo deste modelo eacute para se encontrar umcaminho em sistemas de navegaccedilatildeo pois possui a facilidade de deslocar ao longo dos noacutescom eciecircncia [38]

Como apresentado nesse capiacutetulo o NoSQL eacute um gerenciador de banco de dadosexiacutevel e muito poderoso para armazenar e buscar diversos tipos de dados ainda assimele possui suas limitaccedilotildees O desenvolvimento de bancos de dados relacionais tem desatisfazer os quatro requisitos baacutesicos estipulados pelo padratildeo ACID que consistem ematomicidade consistecircncia isolamento e durabilidade

Recentemente em 2000 Eric Brewer propocircs em um simpoacutesio o teorema CAP ouTeorema de Brewer que elucida as limitaccedilotildees de sistemas escalaacuteveis e consequentementedo NoSQL As trecircs principais caracteriacutesticas segundo o teorema CAP satildeo [34] consistecircnciados dados (Consistency) disponibilidade (Availability) e toleracircncia ao particionamento(Partition Tolerance)

bull Consistecircncia propriedade que dita como e quando o sistema estaacute em uma versatildeoconsistente apoacutes a execuccedilatildeo de uma operaccedilatildeo Um sistema distribuiacutedo eacute consideradoconsistente se todos os usuaacuterios leitores tecircm a mesma visatildeo de uma atualizaccedilatildeo feitapor um usuaacuterio que escreve no sistema logo apoacutes essa atualizaccedilatildeo ser efetuada

bull Disponibilidade propriedade na qual um sistema eacute projetado e desenvolvido quepermita ao usuaacuterio ler e escrever a qualquer momento no banco de dados

bull Toleracircncia ao particionamento caracteriacutestica em que um sistema pode executarcorretamente apesar da divisatildeo fiacutesica da rede Tambeacutem pode ser compreendidocomo a habilidade de um sistema de lidar a adiccedilatildeo e remoccedilatildeo dinacircmica de noacutes derecursos Entende-se que um sistema com alta toleracircncia ao particionamento eacute umsistema altamente escalaacutevel

No entanto o teorema determina que em um sistema facilmente escalaacutevel soacute eacute possiacutevelgarantir apenas duas destas trecircs caracteriacutesticas pois elas tendem a se anular Desta formapode-se concluir que ao se ter disponibilidade e toleracircncia ao particionamento eacute impossiacutevelter consistecircncia pois um usuaacuterio poderia escrever e ler a qualquer momento mas dessaforma o banco de dados natildeo estaacute sempre conectado agrave versatildeo pessoal do usuaacuterio A soluccedilatildeopara esse caso eacute fazer com que o usuaacuterio tenha somente sua aplicaccedilatildeo atualizada qualqueraplicaccedilatildeo que eacute compartilhada natildeo tem acesso a uacuteltima versatildeo dos dados

Da mesma maneira ao se dar a liberdade do usuaacuterio ler e escrever a qualquer momentoe tendo como prerrogativa que todos os usuaacuterios estaratildeo vendo uma versatildeo consistente dosistema natildeo eacute possiacutevel permitir que a rede tenha uma divisatildeo fiacutesica pois a divisatildeo fiacutesicaquebraria o princiacutepio da consistecircncia

Por uacuteltimo ao se ter consistecircncia e toleracircncia ao particionamento eacute impossiacutevel que ousuaacuterio escreva e leia a todo momento Ao se dar essa liberdade de leitura e escrita osistema distribuiacutedo natildeo tem como se manter estaacutevel para todos que o veem A soluccedilatildeo eacute

o usuaacuterio fazer uma requisiccedilatildeo ao banco e aguardar a resposta A Figura 33 esquema-tiza esse comportamento tambeacutem satildeo mostrados nela exemplos de bancos de dados quepertencem a cada grupo de caracteriacutesticas

Figura 33 Aplicaccedilotildees e organizaccedilatildeo por modelos de banco de dados Adaptada de [42]

Capiacutetulo 4

Cassandra

Como dito em capiacutetulos anteriores o banco de dados NoSQL usado nesse trabalhofoi o Cassandra Este capiacutetulo descreve a deniccedilatildeo deste banco de dados assim comocaracteriacutesticas e funcionalidades pertinentes ao estudo de caso que foi realizado A Seccedilatildeo41 trata do modelo de dados do Cassandra e como o banco interpreta os dados coletadosdos servidores A Seccedilatildeo 42 aborda a arquitetura do Cassandra como eacute feito o armaze-namento do banco na estrutura fiacutesica Em especiacuteco a Seccedilatildeo 421 trata de como eacute feita adistribuiccedilatildeo e replicaccedilatildeo dos dados do Cassandra a Seccedilatildeo 422 descreve os trecircs principaisparticionadores do Cassandra a Seccedilatildeo 423 explica como eacute possiacutevel ajustar a consistecircnciados dados Na Seccedilatildeo 43 satildeo vistos alguns problemas que podem acontecer durante o usodo Cassandra

41 Deniccedilatildeo e Modelo de Dados

Segundo seus criadores Avinash Lakshman e Prashant Malik o Cassandra eacute um bancode dados distribuiacutedo massivamente escalaacutevel criado para armazenar uma grande quanti-dade de dados espalhados por vaacuterios servidores e ainda assim oferecer alta viabilidadede acesso e dados consistentes [44] Seu lanccedilamento ocorreu em 2008 como um projetoopensource desenvolvido e utilizado pelo Facebook para melhorar seu mecanismo de pes-quisa [44] Em 2009 foi adotado pela Apache Software Foundation [25] e hoje eacute usado porgrandes empresas como Netix [15 25] e Ebay [48] aleacutem de oacutergatildeos governamentais comoa NASA [47 11]

Em seu desenvolvimento baseou a arquitetura de seu sistema distribuiacutedo na arqui-tetura do Dynamo da Amazon enquanto seu modelo de dados eacute baseado no BigTabledo Google [44] Apesar do seu modelo de dados voltado a coluna o Cassandra permitea consulta como o modelo chave-valor caracteriacutestica que foi adotada do Dynamo [32]podendo assim ser considerado como um modelo hiacutebrido

411 Caracteriacutesticas Gerais

Dentre as principais caracteriacutesticas que tornam o Cassandra um banco de dados van-tajoso em diferentes situaccedilotildees pode-se listar [40] distribuiacutedo descentralizado escalaacutevelalta disponibilidade tolerante a falhas consistecircncia e alta performance Segue uma des-criccedilatildeo de cada um destes atributos

Distribuiacutedo e Descentralizado

Ele eacute capaz de executar em muacuteltiplas maacutequinas enquanto para o usuaacuterio aparentaestar executando em apenas uma Isso eacute usado para o aumento da performance ao sefazer operaccedilotildees paralelas e para conseguir uma maior seguranccedila devido a redundacircncia dedados

Diferente de outros bancos de dados em que os moacutedulos satildeo separados entre mestree escravos no Cassandra cada moacutedulo possui igual importacircncia Isso eacute chamado desimetria de servidor e eacute um dos fatores que torna a disponibilidade do sistema alta

Escalabilidade Elaacutestica

Escalabilidade eacute uma caracteriacutestica que faz o sistema manter a performance mesmocom o aumento do nuacutemero de requisiccedilotildees Mais maacutequinas podem ser adicionadas paraexecutar o processamento sem prejudicar o funcionamento do sistema sem a necessidadede reiniciar algum processo ou editar os comandos

Essa caracteriacutestica tambeacutem se refere ao caso de remover maacutequinas do sistema sem queele pare de funcionar

Disponibilidade e Toleracircncia a Falhas

De modo geral a disponibilidade de algum sistema estaacute na sua capacidade de comple-tar requisiccedilotildees Sempre existe a possibilidade de ocorrer um erro de hardware ou de quedados sejam corrompidos em algum momento de sua transmissatildeo O Cassandra buscareduzir as chances da ocorrecircncia desses erros fazendo uso de redundacircncias e realocaccedilatildeode recursos quando apresentam chances de falha Entretanto mesmo se ocorrer um erroele iraacute dar continuidade a um procedimento a m de obter um resultado nal apesarde estar parcialmente correto Essa eacute uma medida para evitar que todo um projeto secomprometa devido a pequenos erros

Consistecircncia

Consistecircncia refere-se essencialmente a capacidade de que sempre que for feita umaleitura o dado lido estaacute na sua versatildeo mais recente Apesar de parecer algo trivial trata-sede uma caracteriacutestica difiacutecil de conseguir em sistemas distribuiacutedos entre vaacuterios servidorescomo o Cassandra

O Cassandra faz uso de mecanismos para garantir essa consistecircncia mesmo quandoocorrem operaccedilotildees paralelas entretanto isso reduz a disponibilidade do sistema Esseconito deve ser resolvido pelo usuaacuterio pois lhe foi conferida a possibilidade de denirqual seraacute o grau de consistecircncia de sua aplicaccedilatildeo

Alta Performance

O banco de dados Cassandra foi desenvolvido para usar multiprocessamento e tirarvantagem disso Ele pode escalar por centenas de terabytes mantendo a consistecircnciaSeu uso eacute recomendado em ambientes que fazem uso dessas variaccedilotildees e precisam de altaperformance para poder ter acessos raacutepidos

412 Modelo de Dados

O Cassandra eacute um banco natildeo relacional portanto seu modelo de dados difere domodelo relacional pois natildeo eacute focado nas tabelas e relacionamentos entre essas em vezdisso ele eacute mais focado no desempenho das consultas a serem feitas Assim natildeo existeuma estrutura que estabelece os relacionamentos entre uma tabela e outra Como ditoseu modelo de dados era muito semelhante ao do BigTable inclusive ambos ainda possuemo mesmo conceito para famiacutelias de colunas [12] poreacutem o modelo do Cassandra jaacute sofreualteraccedilotildees desde a sua primeira distribuiccedilatildeo

Inicialmente o modelo de dados era constituiacutedo por trecircs estruturas as super colunasfamiacutelias de colunas colunas e linhas Cada famiacutelia de colunas possuiacutea um conjunto decolunas jaacute as super colunas continham um conjunto de colunas ou um conjunto de famiacuteliasde colunas [12] Recentemente na versatildeo 11 as super colunas foram descontinuadasdevido a importantes limitaccedilotildees como natildeo ser possiacutevel o uso de uma chave estrangeiraem uma super coluna e por performance pois para a operaccedilatildeo de leitura que qualquercoluna contida em uma super coluna era necessaacuterio carregar toda a super coluna para amemoacuteria [17] Na versatildeo 12 do Apache Cassandra os elementos essenciais do modelode dados satildeo os Keyspaces as famiacutelias de colunas as tabelas colunas e linhas que satildeodescritos a seguir [27]

bull Keyspace eacute o agrupamento de dados que se assemelha a um esquema em um banco dedados relacional poreacutem o keyspace tambeacutem possui informaccedilotildees sobre como os dadosseratildeo replicados ao longo do cluster (estrutura fiacutesica da nuvem que seraacute abordadaainda neste capiacutetulo) Toda a famiacutelia de colunas deve estar dentro de um keyspacegeralmente eacute criado um keyspace por aplicaccedilatildeo

bull As famiacutelias de colunas ou apenas tabelas satildeo um agrupamento de colunas ordenadaspor nome que eacute pesquisada por linha (uma caracteriacutestica de um modelo chave-valor)Cada uma consiste em colunas e uma chave primaacuteria A chave primaacuteria eacute o nome deuma coluna esta tem como conteuacutedo valores uacutenicos Para uma tabela que simulauma ou mais chaves secundaacuterias os valores destas chaves secundaacuterias da famiacutelia decolunas seratildeo os nomes de outras colunas que representam as chaves secundaacuterias

bull A coluna eacute a menor unidade para armazenar dados (caracteriacutestica de um modelo ori-entado a coluna) sendo composta pelos campos nome valor e um campo chamadotimestamp contendo um valor de tempo em que aquele dado foi inseridoatualizadoUma coluna de uma famiacutelia de colunas deve conter pelo menos em cada um deseus campos uma estrutura semelhante agrave chave primaria uma chave uacutenica chamadade row key

bull As linhas diferentemente das de um banco tradicional satildeo como um conjunto decolunas que possuem a mesma chave primaacuteria [27] Outra diferenccedila relacionadaagraves linhas eacute o espaccedilo alocado pelo mecanismo de armazenamento em um bancorelacional jaacute se aloca o espaccedilo para todas as colunas de uma linha ainda que seu valorseja NULL O mecanismo de armazenamento do Cassandra soacute aloca espaccedilo para ascolunas presentes em cada linha [33] possibilitando um menor esforccedilo computacionalao adicionar ou retirar uma coluna de uma tabela e criando dois tipos de famiacuteliasde colunas as estaacuteticas e as dinacircmicas

Famiacutelias de colunas estaacuteticas satildeo aquelas que usam um conjunto de nomes de colunasmais estaacutetico ou seja natildeo satildeo criadas novas colunas durante o acesso ao banco Elaassemelha-se mais a um banco relacional como pode ser visto na Figura 41 (a) os camposvazios satildeo poucos e os nomes das colunas satildeo os mesmos para cada row key As famiacuteliasde colunas dinacircmicas fazem um uso diferente para cada ceacutelula os dados em vez de seremarmazenados no campo valor de uma coluna satildeo armazenados no campo nome dacoluna Essa estrateacutegia eacute usada para se ter uma maior eciecircncia em consultas pois osdados podem ser preacute computados e entatildeo armazenados nos campos dos valores e cadalinha funciona como uma view [19] A Figura 41 (b) mostra um exemplo de famiacutelias decolunas dinacircmicas que fazem uso dessa estrateacutegia descrita

(a) Exemplo de uma famiacutelia de colunas estaacutetica

(b) Exemplo de uma famiacutelia de colunas dinacircmica

Figura 41 Exemplo de uma famiacutelia de colunas estaacutetica e uma dinacircmica Adaptado de[19]

Famiacutelias de colunas dinacircmicas soacute existem por duas caracteriacutesticas do Cassandra aprimeira jaacute discutida eacute a possibilidade de criar uma famiacutelia de colunas com um nuacutemerovariaacutevel de colunas sem prejudicar a alocaccedilatildeo de espaccedilo requisitada pelo banco A se-gunda caracteriacutestica eacute o fato da possibilidade de inserir dados em uma coluna sem denirantecipadamente quais tipos de dados seratildeo recebidos pelos campos valor Essa carac-teriacutestica eacute chamada de schema-free ou schemaless [40 33] e somente por isso podem sertrabalhados os dados que estatildeo no campo nome e inseridos no campo valor sem ser de-nido seu tipo No entanto apesar de ainda ser possiacutevel fazer uso de uma famiacutelia de colunas

schema-free foi considerado que para o desenvolvedor de um banco a deniccedilatildeo de tiposfacilitaria este trabalho portanto a partir da versatildeo 07 o Cassandra tem desencorajadoo uso dessa ferramenta e pode ser considerado como schema-optional uma vez que natildeo eacuteobrigatoacuterio seu uso [40]

413 Interaccedilatildeo com o Banco

As requisiccedilotildees de escrita no banco satildeo interpretadas de forma diferente do banco re-lacional Quando uma escrita ocorre o Cassandra armazena os dados em uma estruturana memoacuteria RAM chamada memtable jaacute a instruccedilatildeo de escrita eacute gravada em uma estru-tura no disco o Commitlog como pode ser visto na Figura 42 Estas escritas no disco(Commitlogs) permanecem ainda que no caso de uma falha de hardware [22] Ao seremexecutadas as escritas no banco o Cassandra aloca dinamicamente mais memoacuteria paraa memtable somente quando ultrapassado certo limite de memoacuteria que estes dados satildeodescarregados em disco nas SSTables e soacute entatildeo o Commitlog eacute apagado [22] Portantopara um dado ser escrito de forma mais raacutepida no disco riacutegido eacute preciso restringir a quan-tidade de memoacuteria limite para a memtable pois assim os dados seratildeo escritos de formamais raacutepida no Commitlog que ca em disco e natildeo na memoacuteria RAM poreacutem isto diminuia performance da consulta

Figura 42 Estruturas da escrita e leitura no banco [22]

A instruccedilatildeo de deletar tambeacutem eacute diferente uma tabela natildeo eacute deletada logo apoacutesa instruccedilatildeo A tabela eacute marcada na SSTable como uma tabela apagada e um processochamado de compactaccedilatildeo que executa a instruccedilatildeo e tambeacutem agrupra fragmentos de linhaspara otimizar a pesquisa que busque um dado no disco [20]

Como o Cassandra eacute orientado a coluna ao executar uma instruccedilatildeo de leitura deuma linha eacute preciso agrupar todas as SSTables que conteacutem colunas presentes na linhapesquisada Poreacutem antes de executar tal operaccedilatildeo uma estrutura chamada de Bloomlter presente em cada SSTable confere se a SSTable possui algum dado presente naquelaconsulta [21] Outra estrateacutegia que o Cassandra utiliza para melhorar a pesquisa eacute o uso deuma memoacuteria cache para as row keys que carregam-se todas as row keys de determinadatabela para a memoacuteria e para a linha que a carrega quando buscada [21]

Na versatildeo atual uma das uacutenicas limitaccedilotildees estruturais que realmente pode ser umproblema quando se usa o Cassandra em condiccedilotildees normais eacute o limite do nuacutemero deceacutelulas Em uma particcedilatildeo a quantidade maacutexima de ceacutelulas (linhas X colunas) eacute de 2milhotildees [7]

As outras limitaccedilotildees estatildeo relacionadas a linguagem Java como o limite da aacuterea dememoacuteria que a maacutequina virtual pode usar ou satildeo ligadas as consultas ao Cassandra comoseraacute abordado na Seccedilatildeo 42

Outra caracteriacutestica que natildeo eacute uma limitaccedilatildeo mas que eacute um fator que aumenta adiculdade de trabalho eacute a instalaccedilatildeo complicada do banco que pode ocasionar diferenteserros para usuaacuterios menos cuidadosos

42 Arquitetura do Sistema

Antes de descrever a estrutura do Cassandra propriamente dita existem alguns con-ceitos baacutesicos que podem ser vistos para facilitar o seu entendimento A seguir estatildeoalguns deles [26]

bull Cluster Um grupo de noacutes onde se armazena os dados Tambeacutem eacute possiacutevel criar umcluster de noacute uacutenico

bull Noacute Uma instacircncia fiacutesica do Cassandra Como visto natildeo haacute diferenccedila entre um noacutee outro pois o banco eacute descentralizado

bull Replicaccedilatildeo Eacute o processo de armazenamento de coacutepias dos dados em vaacuterios noacutespara garantir as caracteriacutesticas de conabilidade e toleracircncia a falhas O nuacutemero decoacutepias eacute denido pelo fator de replicaccedilatildeo

bull Particionador Um particionador serve para distribuir os dados de maneira uniformeentre os noacutes do cluster para que a carga seja balanceada

bull Data Center eacute um grupo de noacutes que estatildeo congurados em conjunto dentro de ummesmo cluster para ns de replicaccedilatildeo Natildeo eacute necessariamente um data center fiacutesico

bull CQL Abreviaccedilatildeo de Cassandra Query Language eacute uma linguagem de script usadopara ser a interface com o usuaacuterio do banco A abstraccedilatildeo de uma tabela possuindolinhas e colunas eacute bastante semelhante com a da linguagem SQL usada em bancosrelacionais Uma diferenccedila entre os dois eacute que o CQL eacute mais simplicado e natildeosuporta alguns recursos como joins presentes em bancos que utilizam SQL

O Cassandra eacute projetado para lidar com uma grande quantidade de dados em vaacuteriosnoacutes buscando eliminar a possibilidade de erros Sua arquitetura eacute baseada no entendi-mento de que falhas de sistema e de hardware podem e devem acontecer Ele abordaessas condiccedilotildees de falhas atraveacutes do emprego de um sistema distribuiacutedo onde todos osnoacutes estatildeo na mesma posiccedilatildeo hieraacuterquica e os dados satildeo distribuiacutedos entre todos os noacutes docluster

Todos os noacutes constantemente trocam informaccedilotildees pelo cluster e simultaneamente satildeogerados relatoacuterios em cada noacute contendo informaccedilotildees de todas as escritas para se manter a

durabilidade dos dados Os dados tambeacutem satildeo gravados em uma estrutura na memoacuteriachamado de memtable e escrita em um arquivo chamado de SSTable em disco quandoa estrutura em memoacuteria estiver cheia Todas os dados gravados satildeo automaticamenteparticionados e replicados em todo o cluster [23]

A arquitetura do Cassandra permite que um usuaacuterio (autenticado por login e senha) seconecte a qualquer noacute em algum data center e acesse os dados utilizando a linguagem CQLNormalmente um cluster apresenta uma keyspace por aplicaccedilatildeo Os desenvolvedorespodem executar comandos CQL atraveacutes do programa cqlsh ou atraveacutes de drivers emdiferentes linguagens de programaccedilatildeo [23]

421 Distribuiccedilatildeo e Replicaccedilatildeo de Dados

A distribuiccedilatildeo e replicaccedilatildeo de dados estatildeo relacionadas Isso acontece porque ele eacuteconcebido como um sistema rodando em uma rede sem hierarquia entre noacutes esse sistemafaz coacutepias dos dados e distribui as coacutepias entre um grupo de noacutes Os dados satildeo organizadospor tabela e identicados com uma chave primaacuteria Essa chave primaacuteria determina emqual noacute os dados seratildeo escritos coacutepia das linhas tambeacutem satildeo escritas e chamadas dereacuteplicas [23]

Noacutes Virtuais

Noacutes virtuais ou vnodes satildeo uma mudanccedila de paradigma Antes cada noacute possuiaapenas um uacutenico espaccedilo de memoacuteria em disco para armazenar os dados do Cassandra ecada noacute possuia um uacutenico token um nuacutemero inteiro que representava o iniacutecio da memoacuteriadisponiacutevel Os tokens satildeo denidos e distribuidos entre os noacutes pelo particionador de talforma que os tokens satildeo uacutenicos crescentes e que o valor do token subsequente determinao m do espaccedilo de memoacuteria do anterior e o iniacutecio do espaccedilo de memoacuteria em um proacuteximonoacute Com a criaccedilatildeo dos vnodes um noacute pode ter mais de um token A quantidade de noacutesvirtuais dentro de um mesmo noacute fiacutesico (estabelecida pelo desenvolvedor) que dita quantostokens um noacute fiacutesico teraacute Estes vnodes satildeo uma maneira de se simular um nuacutemero maiorde noacutes dentro de um noacute real inclusive satildeo tratados pelo particionador como um noacute real epor isso trazem algumas vantagens satildeo elas [23 28]

bull Otimizar o armazenamento quando cada linha a ser armazenada tem um tamanhopequeno

bull Natildeo eacute necessaacuterio usar meacutetodos para reequilibrar um cluster ao se adicionar ouremover noacutes Quando um noacute se junta ao cluster ele assume a responsabilidade poruma parcela de dados de outros noacutes Se um noacute falhar o seu conteuacutedo eacute distribuiacutedouniformemente entre outros noacutes do cluster

bull A reconstruccedilatildeo de um noacute sem conexatildeo eacute mais raacutepida pois envolve todos os outrosnoacutes do cluster

bull Facilita o uso de maacutequinas diferentes em um cluster Eacute possiacutevel colocar um nuacutemeroproporcional de vnodes em maacutequinas com capacidades de armazenamento diferentesentre si

A distribuiccedilatildeo dos noacutes dentro de um cluster pode ser mais facilmente entendida se forfeita uma analogia da forma de um anel Cada noacute eacute responsaacutevel por armazenar dadoscuja chave primaacuteria estaacute dentro de uma faixa de valor A Figura 43 ilustra essa estruturade anel e mostra como se comportam os vnodes dentro dela como pode ser observado nagura os vnodes satildeo criados sequencialmente de tal forma que natildeo alteram a estrutura doanel

Figura 43 Estrutura de um cluster Adaptado de [29]

Particionador

Um particionador eacute um gerador e distribuidor de tokens O token eacute um elementoessencial para a arquitetura do anel por isso eacute chamado de partitioner-dependent Cadanoacute tem um uacutenico e distinto token pois esse token determina a extensatildeo do armazenamentodos dados de cada noacute Essa extensatildeo que abrange um token a outro eacute uma abstraccedilatildeodas chaves de uma linha row keys atreladas a cada dado inserido no banco que seratildeoarmazenadas naquele noacute Assim a extensatildeo de um noacute inicia-se no token do noacute atual ateacute oproacuteximo valor de token no anel Para gerar e distribuir esses tokens o Cassandra oferecetrecircs opccedilotildees de particionadores para que o mais adequado seja escolhido para a aplicaccedilatildeoos principais particionadores satildeo [18]

bull O RandomPartitioner distribui os dados de forma que estejam balanceados peloanel Tal distribuiccedilatildeo do dado eacute feita a utilizando um hash MD5 sobre o valor decada row key Assim os tokens gerados satildeo do tipo inteiro com valores de 0 a 2127-1

bull ByteOrderedPartitioner eacute geralmente usado para uma particcedilatildeo de forma ordenadaAs row keys natildeo passam por uma funccedilatildeo de hash elas satildeo ordenadas lexicamentepelo byte da row key Assim os tokens gerados satildeo do tipo string com valores de(espaccedilo em branco) ateacute infin Esse particionador tem como desvantagem o caso dasrow keys serem muito similares faraacute com que os tokens tenham valores proacuteximose assim estes dados seratildeo armazenados em um mesmo noacute fazendo com que o anelseja desbalanceado e criando um gargalo na consulta pois natildeo se estaraacute utilizandoo potencial das outras maacutequinas no anel

bull O Murmur3Partitioner provecirc uma performance melhor que o RandomPartitioner etatildeo aleatoacuterio quanto pois cria um hash de 64-bits(com valores entre minus263 e +263)da row key

A Figura 44 ilustra um cluster com vnodes fazendo uso de um particionador aleatoacuterioA vantagem em relaccedilatildeo da estrutura da Figura 44 em relaccedilatildeo agrave Figura 43 (b) eacute que osdados cam mais dispersos e o anel melhor balanceado Por exemplo quando satildeo inseridas4 linhas em um banco o Casandra inseriraacute cada uma delas em um vnode diferente assimas 4 linhas seratildeo distribuiacutedas nos vnodes A B C e D Conforme a Figura 43 (b) vemosque estas linhas estaratildeo apenas no noacute fiacutesico 1 e 2 enquanto que em um anel que tem seusnoacutes vituais distribuiacutedos aleatoriamente representado na Figura 44 estas mesmas linhasestatildeo nos noacutes fiacutesicos 2 3 5 e 6 A vantagem de se ter um anel bem distribuiacutedo eacute que aconsulta eacute melhorada uma vez que eacute possiacutevel fazer mais consultas em paralelo

Figura 44 Estrutura de um cluster com particionador aleatoacuterio Adaptado de [29]

422 Niacuteveis de Consistecircncia

Como visto anteriormente consistecircncia refere-se a forma como satildeo mantidas as linhasatualizadas e sincronizadas em todas as suas coacutepias tendo como objetivo de que sempreque for feita uma leitura o dado lido estaraacute na sua versatildeo mais recente

Analisando essa situaccedilatildeo o Cassandra apresenta o conceito de consistecircncia ajustaacutevel(tunable consistency) em que para cada leitura ou escrita a aplicaccedilatildeo cliente pode deci-dir quatildeo consistentes os dados solicitados devem estar Isso eacute feito atraveacutes de alteraccedilotildeesno caminho que os dados fazem e no nuacutemero de copias geradas Aleacutem disso o Cassan-dra tambeacutem apresenta uma seacuterie de mecanismos embutidos para assegurar que os dadospermaneccedilam corretos em suas diferentes reacuteplicas [23]

Consistecircncia de Escrita

Os niacuteveis de consistecircncia podem ser ajustados para conseguir o equiliacutebrio entre tempode resposta e acuraacutecia No caso da leitura seguem alguns dos niacuteveis e suas caracteriacutesti-cas [23]

bull ANY Fornece baixa latecircncia e a garantia de que uma escrita nunca iraacute falharOferece a menor consistecircncia e a maior disponibilidade em relaccedilatildeo a outros niacuteveis

bull ONE Usado pelo maior nuacutemero de usuaacuterios pois os requisitos para conseguir aconsistecircncia natildeo satildeo rigorosos O noacute de reacuteplica mais proacuteximo do noacute que recebeu opedido eacute responsaacutevel por atender o pedido a natildeo ser que o sistema identique queaquele noacute natildeo estaacute com um desempenho aceitaacutevel nesse caso o controle eacute desviadopara outro noacute

bull QUORUM Fornece uma consistecircncia forte mas com a possibilidade de falha

bull ALL Eacute o que possui a maior consistecircncia e a menor disponibilidade entre todos osniacuteveis

De modo geral em todos os niacuteveis satildeo geradas coacutepias para as reacuteplicas dos noacutes Mesmoas que estatildeo em outra central de dados A principal diferenccedila entre os niacuteveis eacute o nuacutemerode reacuteplicas que se exige uma resposta informando que recebeu os dados

Consistecircncia de Leitura

Semelhantemente existem os niacuteveis de consistecircncia de leitura O Cassandra vericao nuacutemero de reacuteplicas que enviaram os dados e quatildeo recentes esses dados satildeo baseado navariaacutevel de tempo contida em cada linha Seguem alguns niacuteveis [23]

bull ONE Fornece a mais alta disponibilidade de todos os niacuteveis poreacutem apresenta amaior probabilidade de serem lidos dados antigos As reacuteplicas lidas podem natildeopossuir a versatildeo mais recente dos dados

bull QUORUM Garante uma forte consistecircncia se for toleraacutevel um certo niacutevel de falha

bull ALL Fornece a mais alta consistecircncia de todos os niacuteveis junto com a menor adisponibilidade tambeacutem

Capiacutetulo 5

Estudo de Caso e Implementaccedilatildeo

Neste capiacutetulo satildeo apresentados dois estudos de caso em que os dados da bioinformaacuteticasatildeo inseridos e retirados de um banco do Cassandra um contendo dois noacutes outro contendoquarto noacutes Aleacutem diso eacute feita uma comparaccedilatildeo do desempenho desses mesmos testes emum modelo relacional [41] Na Seccedilatildeo 51 satildeo apresentadas as informaccedilotildees referentes aosarquivos de entrada A Seccedilatildeo 52 descreve o ambiente de nuvem criado e tambeacutem comofoi feita a elaboraccedilatildeo do banco

51 Caracteriacutesticas dos Dados da Bioinformaacutetica

Como visto antes o objetivo desse trabalho eacute a obtenccedilatildeo de resultados em testes dedesempenho inserindo dados da bioinformaacutetica no Cassandra Os dados a serem inseridossatildeo arquivos bioloacutegicos no formato FASTQ [52] O formato FASTQ trata-se de um ar-quivo de texto que serve para armazenar uma sequecircncia bioloacutegica (geralmente sequecircnciade nucleotiacutedeos) e seus iacutendices de qualidade correspondentes Os dados satildeo codicadosusando caracteres ASCII para serem abreviados [52] A Figura 51 mostra um trecho deum arquivo FASTQ como exemplo

Figura 51 Exemplo de FASTQ

O arquivo eacute dividido em blocos chamados de SRSs (short read sequence) de 4 linhasque seguem uma periodicidade

Os seis arquivos utilizados para os estudos de caso foram usados em uma dissertaccedilatildeode mestrado [41] dos quais trecircs satildeo resultantes da ltragem dos dados resultantes do

sequenciamento de amostras de ceacutelulas do rim e os outros trecircs de ceacutelulas do fiacutegado Nocapiacutetulo 6 satildeo mostrados mais dados desses arquivos O sequenciamento de amostras deceacutelulas eacute um processo bioquiacutemico que tem como objetivo determinar a ordem das basesnitrogenadas da moleacutecula de DNA e a ltragem eacute o processo que tem por objetivo retirar asSRSs que tem uma baixa qualidade e podem afetar negativamente os estudos e trabalhoscom estes arquivos [41]

Para esse trabalho natildeo se faz necessaacuterio o conhecimento preciso do processo de ob-tenccedilatildeo desses dados bioloacutegicos uma vez que o foco eacute a performance do armazenamento eretirada deles no banco de dados Natildeo satildeo necessaacuterias alteraccedilotildees em seu conteuacutedo apenasa garantia de que natildeo seratildeo perdidas informaccedilotildees ao longo das inserccedilotildees e retiradas

52 Desenvolvimento da Aplicaccedilatildeo Cliente

Nessa seccedilatildeo eacute detalhado como foi preparado o ambiente onde ocorrem os testes Mos-trando inclusive as ferramentas que foram descartadas ao longo desse processo

Pentaho

O Cassandra eacute um software livre sendo assim satildeo desenvolvidas diversas distribuiccedilotildeesde terceiros para criar uma interface mais amigaacutevel incluir mais recursos ou softwaresde integraccedilatildeo Dentre essas soluccedilotildees foi-se considerado o Pentaho [13] um software deBusiness Intelligence (BI) para integraccedilatildeo de Big Data Apesar de sua interface intuitivafoi vericado apoacutes testes que o Pentaho eacute um software muito restrito Natildeo eacute possiacutevel ge-renciar os noacutes ou a maneira como eacute feita a distribuiccedilatildeo dos dados Ele tambeacutem apresentouincompatibilidades com a linguagem CQL e um poder muito pequeno de conguraccedilotildeesComo esses pontos levantados limitam o uso dos recursos que otimizam as interaccedilotildees como banco o Pentaho foi desconsiderado para este projeto

Cassandra-cli

Todas as distribuiccedilotildees do Cassandra trazem consigo dois clientes simples com interfacepelo shell para fazer iteraccedilotildees com o banco o Cassandra-cli e o cqlsh O Cassandra-clieacute uma ferramenta muito uacutetil sua linguagem de consulta eacute o CQL versatildeo 2 e conta commuitos recursos natildeo existentes no Pentaho dentre eles que um script seja executado jun-tamente a sua inicializaccedilatildeo para fazer iteraccedilotildees no banco Foi considerada a possibilidadede tratar o arquivo FASTQ inicial para criar um script a ser executado prontamente como Cassandra-cli Apesar de possuir essa funcionalidade bastante uacutetil o Cassandra-cli natildeotem suporte para criar nem trabalhar com famiacutelias de colunas utilizando o CQL versatildeo3 [16] Isso eacute um problema pois o CQL versatildeo 3 eacute o primeiro a utilizar virtual nodesque aceleram o processamento como visto no capiacutetulo anterior aleacutem de ser recomendadopela Apache a descontinuidade do uso do Cassandra-cli [5] Sendo assim essa abordagemtambeacutem foi desconsiderada

Por m foi utilizado o DataStax Enterprise Edition (DSE) versatildeo 31 que eacute umadistribuiccedilatildeo de terceiros (Third Party Distribution) do Cassandra fornecida pela empresa

DataStax Segundo a empresa Datastax o DSE eacute uma plataforma para dados Big Dataconstruiacuteda tendo como base o Apache Cassandra que gerencia e analisa dados em temporeal feita para maximizar o processamento dos bancos Cassandra Apache Hadoop ede uma ferramenta de busca chamada Apache Solr [6] Diferentemente das ferramentasanteriores que eram apenas clientes que se conectavam ao banco o DSE eacute uma plataformacompleta sendo possiacutevel ateacute mesmo gerenciar a instalaccedilatildeo em muacuteltiplos noacutes Assim aestrateacutegia nal foi a criaccedilatildeo de um cliente proacuteprio que se conecta ao banco e manteacutem asoperaccedilotildees com a ferramenta gerenciadora de clusters via browser chamada OpsCenterque faz parte do DSE

Caracteriacutesticas da Aplicaccedilatildeo

Assim ao elaborar a aplicaccedilatildeo cliente estabeleceu-se como requisitos funcionais que osistema

bull crie um keyspace

bull crie uma tabela que armazenaraacute um arquivo FASTQ

bull crie uma tabela com o nome dos FASTQs inseridos e os seus metadados

bull receba um arquivo de entrada contendo os dados do arquivo FASTQ e os insiraem uma tabela jaacute criada assim como seus metadados e nome do arquivo em outratabela

bull extraia todo o conteuacutedo de uma tabela com o conteuacutedo de um arquivo FASTQ

bull deleta a tabela e o keyspace

Como requisito natildeo funcional busca-se

bull Utilizar-se de uma API Java fornecida pela DataStax para se ter uma maior inte-graccedilatildeo entre a distribuiccedilatildeo do Cassandra e a aplicaccedilatildeo cliente desenvolvida

bull Uso da linguagem CQL3 para as iteraccedilotildees com o banco pois esta eacute a linguagem deconsulta atual do Cassandra e assemelha-se com o SQL

bull Uso de arquivos JSON pelo cliente que faz a inserccedilatildeo e retirada do banco Essaestrateacutegia foi adotada por ser mais simples tratar arquivos JSON em Java

bull Alto desempenho nas operaccedilotildees que fazem muito acesso ao banco

bull Pouco espaccedilo ocupado pelo banco nos servidores

bull Consistecircncia dos dados extraiacutedos do banco esse eacute o principal requisito a ser bus-cado pois caso natildeo sejam consistentes o mapemento geneacutetico natildeo teraacute os resultadoscorretos

Primeira Aplicaccedilatildeo

Foram criadas trecircs aplicaccedilotildees (ou programas) a primeira chamada de fastqTojsonserve para fazer o tratamento no arquivo FASTQ de entrada e dividiacute-lo em arquivos JSONmenores Apoacutes a execuccedilatildeo cada arquivo JSON gerado possuiacutea 500 mil SRSs que seriam

inseridas no banco em 10mil linhas cada linha sendo um agrupamento de 10 colunas ecada campo valor de uma coluna contendo 5 SRSs Esse programa foi implementadoem linguagem C tendo como objetivo a simplicidade da implementaccedilatildeo e a busca poruma boa performance nessa atividade secundaacuteria Assim inuecircnciar de maneira pequenao resultado nal

Segunda Aplicaccedilatildeo

A segunda aplicaccedilatildeo eacute o cliente do Cassandra desenvolvido em Java utilizando a API daDataStax Este cliente executa as seguintes operaccedilotildees criaccedilatildeo de um keyspace inserccedilatildeode todos os arquivos JSON resultantes da primeira aplicaccedilatildeo em uma uacutenica tabela e aextraccedilatildeo de uma tabela completa Todas as operaccedilotildees primeiramente se conectam aocluster em que o Cassandra da maacutequina foi congurado e satildeo desconectadas quandonalizadas

Algumas conguraccedilotildees do Cassandra soacute satildeo denidas no momento da criaccedilatildeo de seuesquema (keyspaces e famiacutelias de colunas) Outras descritas na seccedilatildeo seguinte tecircm deser denidas antes mesmo de se criar o ambiente de nuvem (criar o cluster) Foi criadoum uacutenico keyspace de nome bioData para o cluster que foi chamado de BIOClusterdentro do keyspace haviam todos os arquivos FASTQ Para se criar um keyspaces satildeoobrigatoacuterios os seguintes campos nome a estrateacutegia de alocaccedilatildeo das reacuteplicas e o fator dereplicaccedilatildeo A criaccedilatildeo de keyspaces e tabelas segue o modelo de dados da Figura 52

Figura 52 Modelo de dados do banco

A estrateacutegia de alocaccedilatildeo das reacuteplicas determina se elas seratildeo distribuiacutedas por uma redede diferentes cluster no caso a Estateacutegia de Topologia em Rede ou se seratildeo distribuiacutedasem um uacutenico cluster no caso da Estateacutegia Simples [6] Foi escolhida a EstrateacutegiaSimples por ser mais adequada a um ambiente de testes estaacutevel O fator de replicaccedilatildeoabordado no capiacutetulo passado trata de quantas reacuteplicas seratildeo distribuiacutedas ao longo doanel Por tratar-se de um ambiente de testes em que existia um controle para que natildeohouvesse falhas em nenhum noacute e pelo objetivo da monograa ser voltado agrave performance e

consistecircncia o nuacutemero de reacuteplicas ao longo do anel eacute de apenas uma Tendo que o nuacutemerode reacuteplicas interferem no tempo

Apoacutes criado o keyspace eacute possiacutevel executar a operaccedilatildeo de inserccedilatildeo no banco Antesda inserccedilatildeo eacute criada uma tabela de mesmo nome que o arquivo FASTQ original comonze colunas das quais dez abrigam uma pequena parte de um arquivo JSON (cercade 10 SRRs) cada uma delas tem aproximadamente 1MB de tamanho Um conjuntopequeno de colunas foi escolhido pois o Cassandra utiliza o particionador determinadopelo cluster para armazenar cada linha em um noacute ou noacute virtual diferente para dessaforma usar ao maacuteximo os recursos de todos os noacutes ao se executar uma leitura [28] Aocriar uma tabela em que as linhas satildeo um conjunto de muitas colunas a performance daleitura eacute prejudicada da mesma forma a escolha de um particionador que armazena cadalinha em um noacute ou em um conjunto pequeno de noacutes Assim que criada a tabela todosos arquivos JSON resultantes da primeira fase satildeo lidos sequencialmente e inseridos nestatabela Ao m da inserccedilatildeo uma uacutenica linha eacute inserida na tabela de metadados contendoo nuacutemero de linhas que aquela tabela possui e sua row key eacute o proacuteprio nome de arquivoFASTQ

Figura 53 Etapas da Inserccedilatildeo

Para a extraccedilatildeo de uma tabela primeiro eacute feita uma consulta agrave tabela de metadadospela chave que conteacutem o nome do FASTQ a ser retirado e o nuacutemero de linhas a serretirado eacute guardado Por ser uma aplicaccedilatildeo Java e os arquivos inseridos nas tabelas seremmuito grandes esta foi a melhor soluccedilatildeo para que a memoacuteria da Java Virtual Machine natildeoultrapassasse o limite nem fosse necessaacuterio percorrer toda a tabela contendo o FASTQpara encontrar o maior valor de linha Eacute importante enfatizar que o CQL natildeo possuinenhum comando que ordene a tabela pois como o Cassandra eacute voltado a Big Dataordenar uma tabela torna-se uma tarefa que consumiria quase todos os recursos poisteria que buscar tais valores em todos os noacutes do anel Assim que o nuacutemero de linhas eacute

obtido a seleccedilatildeo eacute feita linha a linha e escrita em um arquivo Este arquivo eacute temporaacuterioa ser tratado pela proacutexima aplicaccedilatildeo

Terceira Aplicaccedilatildeo

A terceira aplicaccedilatildeo transforma o arquivo temporaacuterio de saiacuteda no FASTQ denitivouma coacutepia do FASTQ original Ela apenas faz alteraccedilotildees no arquivo para que queidecircntico original de entrada tambeacutem foi feita em linguagem C Para a execuccedilatildeo de testesfoi criado um script para execuccedilatildeo no shell que automatiza o processo e apaga a cadafase os arquivos temporaacuterios

Nas Figuras 53 e 54 satildeo mostadas as aplicaccedilotildees e a maneira como elas se relacionamnos processos de inserccedilatildeo e retirada respectivamente

Figura 54 Etapas da Extraccedilatildeo

53 Arquitetura do Ambiente de Nuvem

Para criar um ambiente distribuiacutedo eacute necessaacuterio instalar em cada maacutequina (que iraacutecompartilhar os recursos) um Cassandra-agent Para estabelecer uma conexatildeo entre todosos agentes eacute necessaacuteria a conguraccedilatildeo de trecircs arquivos (cassandrayamlcassandra-topologyproperties e opscenterdconf) presentes em cada agente apoacutes a instalaccedilatildeo doCassandra Eacute importante ressaltar que a ediccedilatildeo desses trecircs arquivos possibilita o controlecompleto de todas as ferramentas agrave disposiccedilatildeo do Cassandra Poreacutem nesse trabalhoforam utilizadas algumas representaccedilotildees graacutecas dos dados presentes obtidas por meiodo software OpsCenter [30] (software da empresa DataStax) que dispotildee de uma interfacevia browser para conguraccedilatildeo gerecircncia e anaacutelise do ambiente de nuvem

Entatildeo pelo OpsCenter foi criado o cluster durante sua criaccedilatildeo foram congurados oparticionador e os vnodes Uma vez feita a escolha do particionador natildeo eacute possiacutevel mudaacute-la sem antes apagar todo o conteuacutedo da tabela Foi selecionado o MurMur3Partitionercomo particionador pois como citado no Capiacutetulo 4 eacute o que melhor distribui os dados deforma balanceada ao longo do anel Como citado no Capiacutetulo 4 uma maior quantidade denoacutes virtuais eacute mais adequado quando o tamanho de cada linha eacute pequeno Nesse estudode caso cada linha tem apenas dez colunas um tamanho em torno de 1MB assim foiselecionado para que cada noacutes possuiacutesse 256 noacutes virtuais pra otimizar o armazenamentopois 256 eacute o maior valor recomendado para noacutes virtuais dentro de um noacute fiacutesico [6]

Capiacutetulo 6

Resultados e Discussatildeo

Neste capiacutetulo satildeo apresentados os resultados dos dois estudos de caso um contendodois noacutes outro contendo quarto noacutes A Seccedilatildeo 61 descreve os resultados da inserccedilatildeo eextraccedilatildeo dos dados e uma discussatildeo sobre o ganho de desempenho com o aumento donuacutemero de maacutequinas e a seccedilatildeo 62 apresenta uma comparaccedilatildeo dos resultados do estudode caso feito com os resultados de um estudo de caso semelhante realizado em um bancode dados relacional

Para a avaliaccedilatildeo da performance e consistecircncia dos dados no banco foram realizadosdois estudos de caso um com uma nuvem constituiacuteda por duas maacutequinas outro umanuvem constituiacuteda por quatro maacutequinas O aumento no nuacutemero de maacutequinas tinha porobjetivo avaliar a escalabilidade do Cassandra e avaliar a melhora da performance dobanco A Nuvem criada com duas maacutequinas consistiam de uma maacutequina HP ProliantMl110G7 com processador Intel Xeon E3-122031 GHz com 6GB de memoacuteria RAM eoutra maacutequina semelhante mas com 8GB de memoacuteria RAM Para uma segunda etapade testes foram adicionadas mais duas maacutequinas ambas com processador Intel Core i7e 4GB de memoacuteria RAM Nos dois casos cada maacutequina utilizava o sistema operacionalUbuntu versatildeo 1204 possuiacutea um IP diferente

Os dados usados na nuvem computacional com duas e quatro maacutequinas satildeo os mesmosos seis arquivos FASTQ descritos anteriormente Estes mesmos dados foram utilizadosem uma dissertaccedilatildeo de mestrado da UnB que tratava da inserccedilatildeo e extraccedilatildeo em um bancorelacional Na dissertaccedilatildeo de mestrado foi utilizado apenas uma maacutequina um servidorHP (8 Intel(R) Xeron(R) de 8 CPUs de 213GHz e 32GB de memoacuteria RAM sobre osistema operacional Linux Server UbuntuLinaro 444-14 [41] Uma vez que os dadosda dissertaccedilatildeo de mestrado e desta monograa satildeo os mesmos eacute possiacutevel comparar comum banco relacional e um NoSQL Apesar da conguraccedilatildeo da maacutequina utilizada no casodo banco relacional ser superior agrave soma de todas as conguraccedilotildees das quatro maacutequinasusadas no banco do Cassandra foram utilizados os resultados do banco relacional parademonstrar que com a escalabilidade da computaccedilatildeo em nuvem eacute possiacutevel atingir umaalta performance em um paradigma de bancos de dados sem o uso de um servidor

Primeiramente para o estudo de caso em um banco NoSQL foram feitos testes decriaccedilatildeo de keyspaces tabelas inserccedilatildeo e retirada de dados FASTQ a niacutevel de localhost etrouxeram resultados positivos mostrando-se possiacutevel a execuccedilatildeo dessas operaccedilotildees com ocliente criado

Feito isso foi montada a estrutura proposta composta inicialmente por dois noacutes e exe-cutando o Cassandra na distribuiccedilatildeo DSE A Figura 61 mostra a interface do OpsCenteronde se pode ver o modelo de anel contendo os dois noacutes o espaccedilo ocupado pelos dadosjaacute inseridos eacute mostrado no campo Total Size com o valor de 56 GB Na gura tambeacutempode-se ver o menu lateral com as opccedilotildees de trocar entre as diferentes visotildees do banco econguraccedilotildees

Figura 61 Interface do OpsCenter

61 Inserccedilatildeo e Extraccedilatildeo dos FASTQ Referentes ao Fiacute-

gado e Rim

Como entrada inicialmente foram usados trecircs arquivos FASTQ com dados ltradostirados de ceacutelulas do fiacutegado Na Tabela 61 satildeo apresentadas as seguintes colunas nomedos arquivos tamanho arredondado e real e o nuacutemero de linhas que o arquivo JSONpossuia quando foi inserido no banco

Tabela 61 Arquivos Fiacutegado

Nome Tamanho Nuacutemero de LinhasSRR002321 90 GB (9046495358 bytes) 850933SRR002322 40 GB (4016123172 bytes) 358841SRR002323 32 GB (3202734904 bytes) 286563

Em seguida foram inseridos arquivos contendo os dados das ceacutelulas do rim Taisarquivos usados satildeo mostrados na Tabela 62

Tabela 62 Arquivos Rim

Primeiramente foi testado o desempenho das inserccedilotildees e retiradas desses arquivosusando uma rede composta por duas maacutequinas com o Cassandra instalado A Tabela 63mostra os resultados aproximados de inserccedilatildeo e extraccedilatildeo para cada um dos seis arquivosO campo tamanho foi mantido nessa gura para facilitar a visualizaccedilatildeo da sua relaccedilatildeocom o tempo

Tabela 63 Duas Maacutequinas

Nome Tamanho Tempo Inserccedilatildeo Tempo ExtraccedilatildeoSRR002321 90 GB 14m30s645ms 23m37s964msSRR002322 40 GB 6m10s471ms 9m41s018msSRR002323 32 GB 5m05s914ms 7m39s188msSRR002320 69 GB 11m25s899ms 14m25s120msSRR002324 38 GB 6m09s417ms 8m37s890msSRR002325 53 GB 8m43s330ms 12m23s855ms

O teste seguinte foi o da inserccedilatildeo usando uma rede composta por quatro maacutequinastendo como objetivo vericar se o aumento do nuacutemero de clusters iria alterar o desempe-nho do banco de dados A Tabela 64 apresenta resultados para esse teste

Tabela 64 Quatro Maacutequinas

Pode-se perceber que tanto o tempo de inserccedilatildeo quanto o tempo de extraccedilatildeo conrmama hipoacutetese de que o desempenho do banco melhora quando se usa mais maacutequinas Tal

caracteriacutestica estaacute relacionada aos proacuteprios objetivos do Cassandra no que diz respeitoagrave escalabilidade e a poliacutetica de replicaccedilotildees entre as maacutequinas a m de se garantir avelocidade

Com objetivo de ilustrar melhor a diferenccedila de tempo entre as inserccedilotildees com duas equatro maacutequinas foi criado o graacuteco ilustrativo da Figura 62

Figura 62 Comparativo Entre Inserccedilotildees

Da mesma maneira a Figura 63 ilustra a diferenccedila entre as extraccedilotildees com duas equatro maacutequinas

62 Comparativo com Banco de Dados Relacional

Finalizando o teste principal que pocircde ser feito nesse trabalho foi uma comparaccedilatildeoentre o tempo de inserccedilatildeo e exportaccedilatildeo dos dados ltrados da bioinformaacutetica usando oCassandra e usando um banco relacional Para isso eacute feita uma comparaccedilatildeo entre a somado tempo de todas as inserccedilotildees em sequecircncia do rim e do fiacutegado para duas e quatromaacutequinas com o resultado medido em outro trabalho [41] que fez o mesmo mas usandouma abordagem relacional A Tabela 65 mostra essa comparaccedilatildeo

Pode-se perceber que o tempo de inserccedilatildeo do Cassandra foi bem menor devido aoparalelismo e as outras vantagens que a abordagem natildeo relacional apresenta Entretantoquando se vai fazer um busca em toda a base de dados o desempenho dele se mostrouinferior Poreacutem natildeo se pode tomar essa medida como um resultado denitivo uma vezque a maacutequina da implementaccedilatildeo relacional era superior ao somatoacuterio das caracteriacutesticasde todas as maacutequinas usando o Cassandra Como visto na Seccedilatildeo 413 a leitura de umbanco no Cassandra eacute muito beneciada com a escalabilidade pois ao adicionar mais

Figura 63 Comparativo Entre Extraccedilotildees

Banco Tempo Inserccedilatildeo Total Tempo Retirada TotalCassandra (2 maacutequinas) 52m05s 1h16m25sCassandra (4 maacutequinas) 42m56s 53m49sImplementaccedilatildeo Relacional 1h51m54s 28m27s

maacutequinas maior eacute a quantidade de dados que podem ser armazenados na memtableque eacute a estrutura de mais raacutepido acesso no Cassandra pois o conteuacutedo permanece namemoacuteria RAM Como a quantidade de dados era superior ao somatoacuterio do tamanho damemoacuteria RAM das maacutequinas parte dos dados foi armazenado na SSTable e esta estruturaarmazena os dados no disco riacutegido tornando mais lento a consulta a eles Na Figura 64as diferenccedilas entre as implementaccedilotildees eacute mostrada de maneira visual

Fazer uma busca massiva e que natildeo pode ter nenhuma perda eacute uma tarefa complexaem um ambiente de nuvem distribuiacutedo pois satildeo necessaacuterias comparaccedilotildees entre as reacuteplicasa m de se assegurar que nenhum dado foi perdido ou corrompido Por outro lado amelhora no desempenho quando se aumentou o nuacutemero de maacutequinas eacute um indiacutecio deque para um nuacutemero maior de maacutequinas o Cassandra pode superar estaacute implementaccedilatildeorelacional o tornando uma opccedilatildeo viaacutevel para a bioinformaacutetica

Figura 64 Graacuteco Comparando Cassandra e Implementaccedilatildeo Relacional

Capiacutetulo 7

Conclusotildees e Trabalhos Futuros

Nessa monograa foi realizado um estudo acerca da persistecircncia de dados bioloacutegicosfazendo uso de uma tecnologia ainda pouco explorada por essa aacuterea que satildeo os bancosde dados em nuvem especicamente o banco Cassandra Antes da implementaccedilatildeo doestudo de caso foram analisadas quais as melhores caracteriacutesticas para desenvolver umaarquitetura de nuvem que possibilitasse a melhor performance e dados consistentes comos originais Foram avaliadas algumas ferramentas para serem usadas juntamente com oCassandra poreacutem foi escolhida a da DataStax Enterprise uma distribuiccedilatildeo do Cassandraem conjunto com o OpsCenter e a API em Java dentre outras Tais ferramentas possibi-litaram a criaccedilatildeo de uma nuvem e uma aplicaccedilatildeo cliente que atendia os requisitos ditadospelo modelo de dados e pelos dados bioloacutegicos utilizados

Os resultados obtidos possibilitaram visualizar uma otimizaccedilatildeo da inserccedilatildeo e consultaao Cassandra ao se adicionarem mais noacutes A inserccedilatildeo teve um ganho de performance deaproximadamente 17 e a retirada dos dados um ganho de mais de 25 se comparadosos resultados de duas e quatro maacutequinas Em comparaccedilatildeo com um banco de dadosrelacional a performance do banco tambeacutem foi satisfatoacuteria uma vez que os resultadosdo uso de quatro maacutequinas comuns se aproximou do resultado de um servidor contendoo banco relacional Isso indica uma possiacutevel vantagem do Cassandra uma vez que osrecursos computacionais deste banco podem ser cada vez mais escalaacuteveis o que traz umganho de performance

Como visto em capiacutetulos anteriores os bancos natildeo relacionais seguem o teorema CAPsendo que o Cassandra natildeo difere deles tendo como caracteriacutesticas a facilidade de parti-cionamento e a consistecircncia na visualizaccedilatildeo dos dados em todos os clientes que acessamo banco Essas duas caracteriacutesticas permitem que o Cassandra seja um banco que natildeoesteja sempre disponiacutevel pois ao se trabalhar oine diferentes visualizaccedilotildees do bancoseram criadas e o fundamento da consistecircncia dos dados seria desfeito

Acredita-se que a proposta aqui apresentada pode trazer um direcionamento no estudode novas abordagens de persistecircncia de dados Big Data bioloacutegicos Os resultados positivosservem de estiacutemulo para o avanccedilo destes estudos que podem levar agrave construccedilatildeo de umaaplicaccedilatildeo semelhante usando outros bancos NoSQL variaccedilotildees no nuacutemero de maacutequinas emum banco do Cassandra e ateacute mesmo a criaccedilatildeo do banco relacional no mesmo ambienteque este estudo de caso foi estabelecido para uma comparaccedilatildeo mais precisa

Referecircncias

[1] D J Abadi Data management in the cloud Limitations and opportunities IEEEData Eng Bull 32(1)312 2009 4 5

[2] D Abramson Giddy and L Kotler High performance parametric modeling withnimrodg Killer application for the global grid In Proceedings of the 14th Internati-onal Symposium on Parallel and Distributed Processing IPDPS 00 pages 520528Washington DC USA 2000 IEEE Computer Society 7

[3] K M Albarrak and E H Sibley Translating relational amp object-relational databasemodels into owl models In Information Reuse Integration 2009 IRI 09 IEEEInternational Conference on pages 336341 2009 17

[4] A Andrzejak M Arlitt and J Rolia Bounding the resource savings of utilitycomputing models Hewlett Packard Laboratories (HPL-2002-339) December 20029

[5] Apacheorg CassandraCli httpwikiapacheorgcassandraCassandraCli2013 [Online acessado 10-Novembro-2013] 34

[6] Apacheorg DataStax Enterprise 31 Documentation httpwwwdatastaxcomdoc-sourcepdfdse31pdf 2013 [Online acessado 06-Dezembro-2013] 35 36 38

[7] Apacheorg Limitations httpwikiapacheorgcassandra

CassandraLimitations 2013 [Online acessado 6-Dezembro-2013] 28

[8] R W Brito Bancos de dados nosql x sgbds relacionaisanaacutelise comparativa Tech-nical report Universidade de Fortaleza 2010 17

[9] R Buyya D Abramson and J Giddy Nimrodg an architecture for a resource ma-nagement and scheduling system in a global computational grid In High PerformanceComputing in the Asia-Pacic Region 2000 Proceedings The Fourth InternationalConferenceExhibition on volume 1 pages 283289 vol1 May 2000 7

[10] R Buyya C S Yeo and S Venugopal Market-oriented cloud computing Visionhype and reality for delivering it services as computing utilities In High Perfor-mance Computing and Communications 2008 HPCC 08 10th IEEE InternationalConference on pages 513 2008 viii 6

[11] Planet Cassandra The Five Minute Interview NASA httpwwwdatastax

comdevblogthe-five-minute-interview-nasa 2013 [Online acessado 3-Dezembro-2013] 23

[12] F Chang J Dean S Ghemawat W C Hsieh D A Wallach M Burrows T Chan-dra A Fikes and R E Gruber Bigtable A distributed storage system for struc-tured data ACM Trans Comput Syst 26(2)41426 jun 2008 25

[13] Pentaho Corporation Pentaho Big Data Analytics httppentahocomproductbig-data-analytics 2014 [Online acessado 10-Janeiro-2014] 34

[14] Zoho Creator Platform as a Service httpwwwzohocomcreatorpaashtml2013 [Online acessado 3-Dezembro-2013] vii 5

[15] S Curtis Netix foretells House of Cards success with Cassandrabig data engine httpnewstechworldcomapplications3437514

netflix-foretells-house-of-cards-success-with-cassandra-big-data-engine2013 [Online acessado 3-Dezembro-2013] 23

[16] DataStax Whats New in DataStax Enterprise 31 A Guide for Developers Archi-tects and IT Managers httpwwwdatastaxcomwp-contentuploads2013

07WP-WhatsNewDSE31pdf 2013 [Online acessado 6-Dezembro-2013] 34

[17] DataStax About Column Families httpwwwdatastaxcomdocs10ddl

column_family 2013 [Online acessado 6-Dezembro-2013] 25

[18] DataStax About Data Partitioning in Cassandra httpwwwdatastax

comdocs08cluster_architecturepartitioning 2013 [Online acessado 6-Dezembro-2013] 30

[19] DataStax About Data Partitioning in Cassandra httpwwwdatastaxcom

docs11ddlcolumn_family 2013 [Online acessado 6-Dezembro-2013] vii 26

[20] DataStax About deletes httpwwwdatastaxcomdocumentationcassandra12webhelpindexhtmlcassandradmldml_about_deletes_chtml 2013[Online acessado 9-Dezembro-2013] 27

[21] DataStax About reads httpwwwdatastaxcomdocumentationcassandra12webhelpindexhtmlcassandradmldml_about_reads_chtmlconcept_

ds_vrp_4qx_zj 2013 [Online acessado 9-Dezembro-2013] 27

[22] DataStax About writes httpwwwdatastaxcomdocumentationcassandra12webhelpindexhtmlcassandradmlmanage_dml_intro_chtmlconcept_

ds_g2s_y1w_zj 2013 [Online acessado 9-Dezembro-2013] vii 27

[23] DataStax Apache Cassandra 12 Documentation httpwwwdatastaxcom

documentationcassandra12pdfcassandra12pdf 2013 [Online acessado 6-Dezembro-2013] 29 31 32

[24] DataStax Big Data Beyond the Hype Why Big Data Matters to You httpwwwdatastaxcomwp-contentuploads201110WP-DataStax-BigDatapdf 2013[Online acessado 6-Dezembro-2013] 1

[25] Datastax Introduction to Apache Cassandra httpwwwdatastaxcom

wp-contentuploads201208WP-IntrotoCassandrapdf 2013 [Online aces-sado 3-Dezembro-2013] 23

[26] DataStax Key concepts httpwwwdatastaxcomdocumentation

gettingstartedgetting_startedgettingStartedKeyConcepts_chtml 2013[Online acessado 3-Dezembro-2013] 28

[27] DataStax The data model distilled httpwwwdatastaxcomdocumentation

gettingstartedgetting_startedgettingStarteddataModel_chtml 2013[Online acessado 3-Dezembro-2013] 25

[28] DataStax Virtual nodes in Cassandra 12 httpwwwdatastaxcomdevblogvirtual-nodes-in-cassandra-1-2 2013 [Online acessado 13-Dezembro-2013]29 37

[29] DataStax DataStax OpsCenter httpwwwdatastaxcomdevblog

upgrading-an-existing-cluster-to-vnodes-2 2014 [Online acessado 13-Janeiro-2014] vii 30 31

[30] DataStax DataStax OpsCenter httpwwwdatastaxcomwhat-we-offer

products-servicesdatastax-opscenter 2014 [Online acessado 13-Janeiro-2014] 38

[31] CJ Date Introduccedilatildeo a sistemas de bancos de dados Campus 2004 1 15

[32] G DeCandia D Hastorun M Jampani G Kakulapati A Lakshman A PilchinS Sivasubramanian P Vosshall and W Vogels Dynamo Amazons highly availablekey-value store SIGOPS Oper Syst Rev 41(6)205220 oct 2007 23

[33] J Ellis Schema in Cassandra 11 httpwwwdatastaxcomdevblog

schema-in-cassandra-1-1 2013 [Online acessado 3-Dezembro-2013] 25 26

[34] M Fowler and P J Sadalage NoSQL distilled a brief guide to the emerging worldof polygot persistence Addison-Wesley Professional 1 edition 2012 1 17 20 21

[35] K Gaj T El-Ghazawi N Alexandridis JR Radzikowski M Taher and F Vro-man Eective utilization and reconguration of distributed hardware resources usingjob management systems In International Parallel and Distributed Processing Sym-posium page 177 April 2003 7

[36] AS Grimshaw and A Natrajan Legion Lessons learned building a grid operatingsystem Proceedings of the IEEE 93(3)589603 March 2005 7

[37] M Gyssens J Paredaens J van den Bussche and D van Gucht A graph-orientedobject database model Knowledge and Data Engineering IEEE Transactions on6(4)572586 1994 17

[38] R Hecht and S Jablonski Nosql evaluation A use case oriented survey In Cloudand Service Computing (CSC) 2011 International Conference on pages 3363412011 18 19 20 21

[39] C A Heuser Projeto de Banco de Dados Sagra Luzzatto 4 edition 1998 vii 1415 16

[40] E Hewitt Cassandra - The denitive Guide OREILLY 1st edition 2010 1 2326 27

[41] R C Huacarpuma Modelo de dados para um pipeline de sequenciamento de altodesempenho transcritomico Masters thesis Universidade de Brasiacutelia 2012 33 3439 42

[42] N Hurst Visual Guide to NoSQL Systems httpblognahurstcom

visual-guide-to-nosql-systems 2013 [Online acessado 3-Dezembro-2013] vii22

[43] A Kelly and D McCreary Making Sense of NoSQL A Guide for Managers andthe Rest of Us by Ann Kelly and Dan McCreary Manning Publications Company2013 17

[44] A Lakshman and P Malik Cassandra A decentralized structured storage systemSIGOPS Oper Syst Rev 44(2)3540 April 2010 23

[45] D C Marinescu Cloud Computing Theory and Practice Elsevier Science Depart-ment of Electrical Engineering Computer Science University of Central FloridaOrlando FL 32816 USA 1 edition 2012 7 9

[46] P Mell and T Grance The NIST denition of cloud computing Technical reportNational Institute of Standars and Technology Information Technology LaboratoryJuly 2009 1 4 10 13

[47] J Patel Cassandra at NASA Meetup | DataStax HQ httpwww

planetcassandraorgblogpostcassandra-at-nasa-meetup-datastax-hq2013 [Online acessado 3-Dezembro-2013] 23

[48] J Patel Cassandra Data Modeling Best Practi-ces Part 1 httpwwwebaytechblogcom20120716

cassandra-data-modeling-best-practices-part-1 2013 [Online acessado3-Dezembro-2013] 23

[49] F Prosdocimi Bioinformaacutetica Manual do usuaacuterio Biotecnologia Ciecircncia e Desen-volvimento 29 nov 2002 2

[50] J W Ross and G Westerman Preparing for utility computing The role of itarchitecture and relationship management IBM Systems Journal 43(1)519 20049

[51] D Sharma and P Mittal Grid computing an overview International Journal ofScience Engineering and Technology Research (IJSETR) 2(3)606611 March 20137 8

[52] S A Simon J Zhai R S Nandety K P McCormick J Zeng D Mejia and B CMeyers Short-Read Sequencing Technologies for Transcriptional Analyses AnnualReview of Plant Biology 60(1)305333 jan 2009 33

[53] F R C Sousa L O Moreira and J C Machado Computaccedilatildeo em nuvem Concei-tos tecnologias aplicaccedilotildees e desaos ERCEMAPI 2009 SBC pages 150175 2009vii 4 5 10 11 12

[54] A Srivastava NoSQL NewSQL and MDM httpcdi-mdmblogspotcom

br201107nosql-newsql-and-mdmhtml 2013 [Online acessado 06-Dezembro-2013] vii 19

[55] C Strauch NoSQL Databases Stuttgart Media University 2011 17 20

[56] D Thain T Tannenbaum and M Livny Condor and the grid In Fran Berman Ge-orey Fox and Tony Hey editors Grid Computing Making the Global Infrastructurea Reality John Wiley Sons Inc December 2002 7

[57] L M Vaquero L Rodero-Merino J Caceres and M Lindner A break in the cloudstowards a cloud denition SIGCOMM Comput Commun Rev 39(1)5055 2008viii 6

[58] M A Vouk Cloud computing x2014 issues research and implementations InInformation Technology Interfaces 2008 ITI 2008 30th International Conferenceon pages 3140 2008 7 8

[59] G Wang and J Tang The nosql principles and basic application of cassandra mo-del In Computer Science Service System (CSSS) 2012 International Conference onpages 13321335 2012 17

[60] C S Yeo M D Assunccedilatildeo J Yu A Sulistio S Venugopal M Placek and R BuyyaUtility computing and global grids Technical Report arXivcs0605056v1 The Uni-versity of Melbourne April 2006 8 9

Dedicatoacuteria

Agradecimentos

Resumo

Abstract

Problema e Hipoacutetese

Motivaccedilatildeo

Objetivo

Objetivos Especiacuteficos

Estrutura do Trabalho


Definiccedilotildees de Computaccedilatildeo em Nuvem

Grid Computing e Utility Computing

Grid Computing

Utility Computing

Caracteriacutesticas Essenciais da Nuvem

Modelos de Serviccedilo

Modelos de Implantaccedilatildeo

Caracteriacutesticas e Diferenccedilas entre Bancos de Dados Relacionais e Natildeo Relacionais

Bancos de Dados Relacionais

Normalizaccedilatildeo

Limitaccedilotildees

Bancos Natildeo Relacionais NoSQL

Caracteriacutesticas do NoSQL

Modelos de Bancos NoSQL


Cassandra

Definiccedilatildeo e Modelo de Dados

Caracteriacutesticas Gerais

Modelo de Dados

Interaccedilatildeo com o Banco


Arquitetura do Sistema

Distribuiccedilatildeo e Replicaccedilatildeo de Dados

Niacuteveis de Consistecircncia


Caracteriacutesticas dos Dados da Bioinformaacutetica

Desenvolvimento da Aplicaccedilatildeo Cliente

Arquitetura do Ambiente de Nuvem


Inserccedilatildeo e Extraccedilatildeo dos FASTQ Referentes ao Fiacutegado e Rim

Comparativo com Banco de Dados Relacional


Referecircncias

Universidade de Brasiacutelia UnB

Instituto de Ciecircncias Exatas

Bacharelado em Ciecircncia da Computaccedilatildeo

Coordenadora Profa Dra Maristela Terto de Holanda

Banca examinadora composta por

Profa Dra Maristela Terto de Holanda (Orientadora) CICUnB

Profa Dra Edna Dias Canedo FGAUnB

Profa Dra Maria Emilia M T Walter CICUnB

CIP Catalogaccedilatildeo Internacional na Publicaccedilatildeo

Aniceto Rodrigo Cardoso

Um Estudo Sobre a Utilizaccedilatildeo do Banco de Dados NoSQL Cassandra

em Dados Bioloacutegicos Rodrigo Cardoso Aniceto Renecirc Freire Xavier

Brasiacutelia UnB 2014

117 p il 295 cm

Monograa (Graduaccedilatildeo) Universidade de Brasiacutelia Brasiacutelia 2014

1 SGBDs 2 Nuvem Computacional 3 NoSQL 4 Cassandra

5 Dados Bioloacutegicos 6 DataStax

CDU 0044

Endereccedilo Universidade de Brasiacutelia

Campus Universitaacuterio Darcy Ribeiro Asa Norte

CEP 70910-900

BrasiacuteliaDF Brasil

CICUnB

FGAUnB CICUnB

Dedicatoacuteria

Agradecimentos

Eu tambeacutem

Resumo

Abstract

Sumaacuterio

Referecircncias 46

Lista de Figuras

Lista de Tabelas

Capiacutetulo 1

13 Objetivo

Capiacutetulo 2

I Wladawsky Ber-ger

221 Grid Computing

Amplo Acesso

Pooling de Recursos

Serviccedilo Medido

Nuvem Privada

Nuvem Puacuteblica

Nuvem Hiacutebrida

Capiacutetulo 3

Relacionais

Atributo Chave

ChaveValor

Documento

Orientado a Colunas

Orientado a Grafos

Capiacutetulo 4

Cassandra

Consistecircncia

Alta Performance

412 Modelo de Dados

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

CICUnB

FGAUnB CICUnB

Dedicatoacuteria

Agradecimentos

Eu tambeacutem

Resumo

Abstract

Sumaacuterio

Referecircncias 46

Lista de Figuras

Lista de Tabelas

Capiacutetulo 1

13 Objetivo

Capiacutetulo 2

I Wladawsky Ber-ger

221 Grid Computing

Amplo Acesso

Pooling de Recursos

Serviccedilo Medido

Nuvem Privada

Nuvem Puacuteblica

Nuvem Hiacutebrida

Capiacutetulo 3

Relacionais

Atributo Chave

ChaveValor

Documento

Orientado a Colunas

Orientado a Grafos

Capiacutetulo 4

Cassandra

Consistecircncia

Alta Performance

412 Modelo de Dados

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Dedicatoacuteria

Agradecimentos

Eu tambeacutem

Resumo

Abstract

Sumaacuterio

Referecircncias 46

Lista de Figuras

Lista de Tabelas

Capiacutetulo 1

13 Objetivo

Capiacutetulo 2

I Wladawsky Ber-ger

221 Grid Computing

Amplo Acesso

Pooling de Recursos

Serviccedilo Medido

Nuvem Privada

Nuvem Puacuteblica

Nuvem Hiacutebrida

Capiacutetulo 3

Relacionais

Atributo Chave

ChaveValor

Documento

Orientado a Colunas

Orientado a Grafos

Capiacutetulo 4

Cassandra

Consistecircncia

Alta Performance

412 Modelo de Dados

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Agradecimentos

Eu tambeacutem

Resumo

Abstract

Sumaacuterio

Referecircncias 46

Lista de Figuras

Lista de Tabelas

Capiacutetulo 1

13 Objetivo

Capiacutetulo 2

I Wladawsky Ber-ger

221 Grid Computing

Amplo Acesso

Pooling de Recursos

Serviccedilo Medido

Nuvem Privada

Nuvem Puacuteblica

Nuvem Hiacutebrida

Capiacutetulo 3

Relacionais

Atributo Chave

ChaveValor

Documento

Orientado a Colunas

Orientado a Grafos

Capiacutetulo 4

Cassandra

Consistecircncia

Alta Performance

412 Modelo de Dados

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Resumo

Abstract

Sumaacuterio

Referecircncias 46

Lista de Figuras

Lista de Tabelas

Capiacutetulo 1

13 Objetivo

Capiacutetulo 2

I Wladawsky Ber-ger

221 Grid Computing

Amplo Acesso

Pooling de Recursos

Serviccedilo Medido

Nuvem Privada

Nuvem Puacuteblica

Nuvem Hiacutebrida

Capiacutetulo 3

Relacionais

Atributo Chave

ChaveValor

Documento

Orientado a Colunas

Orientado a Grafos

Capiacutetulo 4

Cassandra

Consistecircncia

Alta Performance

412 Modelo de Dados

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Abstract

Sumaacuterio

Referecircncias 46

Lista de Figuras

Lista de Tabelas

Capiacutetulo 1

13 Objetivo

Capiacutetulo 2

I Wladawsky Ber-ger

221 Grid Computing

Amplo Acesso

Pooling de Recursos

Serviccedilo Medido

Nuvem Privada

Nuvem Puacuteblica

Nuvem Hiacutebrida

Capiacutetulo 3

Relacionais

Atributo Chave

ChaveValor

Documento

Orientado a Colunas

Orientado a Grafos

Capiacutetulo 4

Cassandra

Consistecircncia

Alta Performance

412 Modelo de Dados

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Sumaacuterio

Referecircncias 46

Lista de Figuras

Lista de Tabelas

Capiacutetulo 1

13 Objetivo

Capiacutetulo 2

I Wladawsky Ber-ger

221 Grid Computing

Amplo Acesso

Pooling de Recursos

Serviccedilo Medido

Nuvem Privada

Nuvem Puacuteblica

Nuvem Hiacutebrida

Capiacutetulo 3

Relacionais

Atributo Chave

ChaveValor

Documento

Orientado a Colunas

Orientado a Grafos

Capiacutetulo 4

Cassandra

Consistecircncia

Alta Performance

412 Modelo de Dados

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Referecircncias 46

Lista de Figuras

Lista de Tabelas

Capiacutetulo 1

13 Objetivo

Capiacutetulo 2

I Wladawsky Ber-ger

221 Grid Computing

Amplo Acesso

Pooling de Recursos

Serviccedilo Medido

Nuvem Privada

Nuvem Puacuteblica

Nuvem Hiacutebrida

Capiacutetulo 3

Relacionais

Atributo Chave

ChaveValor

Documento

Orientado a Colunas

Orientado a Grafos

Capiacutetulo 4

Cassandra

Consistecircncia

Alta Performance

412 Modelo de Dados

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Lista de Figuras

Lista de Tabelas

Capiacutetulo 1

13 Objetivo

Capiacutetulo 2

I Wladawsky Ber-ger

221 Grid Computing

Amplo Acesso

Pooling de Recursos

Serviccedilo Medido

Nuvem Privada

Nuvem Puacuteblica

Nuvem Hiacutebrida

Capiacutetulo 3

Relacionais

Atributo Chave

ChaveValor

Documento

Orientado a Colunas

Orientado a Grafos

Capiacutetulo 4

Cassandra

Consistecircncia

Alta Performance

412 Modelo de Dados

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Lista de Tabelas

Capiacutetulo 1

13 Objetivo

Capiacutetulo 2

I Wladawsky Ber-ger

221 Grid Computing

Amplo Acesso

Pooling de Recursos

Serviccedilo Medido

Nuvem Privada

Nuvem Puacuteblica

Nuvem Hiacutebrida

Capiacutetulo 3

Relacionais

Atributo Chave

ChaveValor

Documento

Orientado a Colunas

Orientado a Grafos

Capiacutetulo 4

Cassandra

Consistecircncia

Alta Performance

412 Modelo de Dados

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Capiacutetulo 1

13 Objetivo

Capiacutetulo 2

I Wladawsky Ber-ger

221 Grid Computing

Amplo Acesso

Pooling de Recursos

Serviccedilo Medido

Nuvem Privada

Nuvem Puacuteblica

Nuvem Hiacutebrida

Capiacutetulo 3

Relacionais

Atributo Chave

ChaveValor

Documento

Orientado a Colunas

Orientado a Grafos

Capiacutetulo 4

Cassandra

Consistecircncia

Alta Performance

412 Modelo de Dados

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

13 Objetivo

Capiacutetulo 2

I Wladawsky Ber-ger

221 Grid Computing

Amplo Acesso

Pooling de Recursos

Serviccedilo Medido

Nuvem Privada

Nuvem Puacuteblica

Nuvem Hiacutebrida

Capiacutetulo 3

Relacionais

Atributo Chave

ChaveValor

Documento

Orientado a Colunas

Orientado a Grafos

Capiacutetulo 4

Cassandra

Consistecircncia

Alta Performance

412 Modelo de Dados

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Capiacutetulo 2

I Wladawsky Ber-ger

221 Grid Computing

Amplo Acesso

Pooling de Recursos

Serviccedilo Medido

Nuvem Privada

Nuvem Puacuteblica

Nuvem Hiacutebrida

Capiacutetulo 3

Relacionais

Atributo Chave

ChaveValor

Documento

Orientado a Colunas

Orientado a Grafos

Capiacutetulo 4

Cassandra

Consistecircncia

Alta Performance

412 Modelo de Dados

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Capiacutetulo 2

I Wladawsky Ber-ger

221 Grid Computing

Amplo Acesso

Pooling de Recursos

Serviccedilo Medido

Nuvem Privada

Nuvem Puacuteblica

Nuvem Hiacutebrida

Capiacutetulo 3

Relacionais

Atributo Chave

ChaveValor

Documento

Orientado a Colunas

Orientado a Grafos

Capiacutetulo 4

Cassandra

Consistecircncia

Alta Performance

412 Modelo de Dados

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

I Wladawsky Ber-ger

221 Grid Computing

Amplo Acesso

Pooling de Recursos

Serviccedilo Medido

Nuvem Privada

Nuvem Puacuteblica

Nuvem Hiacutebrida

Capiacutetulo 3

Relacionais

Atributo Chave

ChaveValor

Documento

Orientado a Colunas

Orientado a Grafos

Capiacutetulo 4

Cassandra

Consistecircncia

Alta Performance

412 Modelo de Dados

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

I Wladawsky Ber-ger

221 Grid Computing

Amplo Acesso

Pooling de Recursos

Serviccedilo Medido

Nuvem Privada

Nuvem Puacuteblica

Nuvem Hiacutebrida

Capiacutetulo 3

Relacionais

Atributo Chave

ChaveValor

Documento

Orientado a Colunas

Orientado a Grafos

Capiacutetulo 4

Cassandra

Consistecircncia

Alta Performance

412 Modelo de Dados

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

221 Grid Computing

Amplo Acesso

Pooling de Recursos

Serviccedilo Medido

Nuvem Privada

Nuvem Puacuteblica

Nuvem Hiacutebrida

Capiacutetulo 3

Relacionais

Atributo Chave

ChaveValor

Documento

Orientado a Colunas

Orientado a Grafos

Capiacutetulo 4

Cassandra

Consistecircncia

Alta Performance

412 Modelo de Dados

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Amplo Acesso

Pooling de Recursos

Serviccedilo Medido

Nuvem Privada

Nuvem Puacuteblica

Nuvem Hiacutebrida

Capiacutetulo 3

Relacionais

Atributo Chave

ChaveValor

Documento

Orientado a Colunas

Orientado a Grafos

Capiacutetulo 4

Cassandra

Consistecircncia

Alta Performance

412 Modelo de Dados

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Amplo Acesso

Pooling de Recursos

Serviccedilo Medido

Nuvem Privada

Nuvem Puacuteblica

Nuvem Hiacutebrida

Capiacutetulo 3

Relacionais

Atributo Chave

ChaveValor

Documento

Orientado a Colunas

Orientado a Grafos

Capiacutetulo 4

Cassandra

Consistecircncia

Alta Performance

412 Modelo de Dados

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Amplo Acesso

Pooling de Recursos

Serviccedilo Medido

Nuvem Privada

Nuvem Puacuteblica

Nuvem Hiacutebrida

Capiacutetulo 3

Relacionais

Atributo Chave

ChaveValor

Documento

Orientado a Colunas

Orientado a Grafos

Capiacutetulo 4

Cassandra

Consistecircncia

Alta Performance

412 Modelo de Dados

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Nuvem Privada

Nuvem Puacuteblica

Nuvem Hiacutebrida

Capiacutetulo 3

Relacionais

Atributo Chave

ChaveValor

Documento

Orientado a Colunas

Orientado a Grafos

Capiacutetulo 4

Cassandra

Consistecircncia

Alta Performance

412 Modelo de Dados

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Nuvem Privada

Nuvem Puacuteblica

Nuvem Hiacutebrida

Capiacutetulo 3

Relacionais

Atributo Chave

ChaveValor

Documento

Orientado a Colunas

Orientado a Grafos

Capiacutetulo 4

Cassandra

Consistecircncia

Alta Performance

412 Modelo de Dados

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Nuvem Privada

Nuvem Puacuteblica

Nuvem Hiacutebrida

Capiacutetulo 3

Relacionais

Atributo Chave

ChaveValor

Documento

Orientado a Colunas

Orientado a Grafos

Capiacutetulo 4

Cassandra

Consistecircncia

Alta Performance

412 Modelo de Dados

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Capiacutetulo 3

Relacionais

Atributo Chave

ChaveValor

Documento

Orientado a Colunas

Orientado a Grafos

Capiacutetulo 4

Cassandra

Consistecircncia

Alta Performance

412 Modelo de Dados

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

ChaveValor

Documento

Orientado a Colunas

Orientado a Grafos

Capiacutetulo 4

Cassandra

Consistecircncia

Alta Performance

412 Modelo de Dados

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

ChaveValor

Documento

Orientado a Colunas

Orientado a Grafos

Capiacutetulo 4

Cassandra

Consistecircncia

Alta Performance

412 Modelo de Dados

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

ChaveValor

Documento

Orientado a Colunas

Orientado a Grafos

Capiacutetulo 4

Cassandra

Consistecircncia

Alta Performance

412 Modelo de Dados

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

ChaveValor

Documento

Orientado a Colunas

Orientado a Grafos

Capiacutetulo 4

Cassandra

Consistecircncia

Alta Performance

412 Modelo de Dados

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Documento

Orientado a Colunas

Orientado a Grafos

Capiacutetulo 4

Cassandra

Consistecircncia

Alta Performance

412 Modelo de Dados

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Orientado a Colunas

Orientado a Grafos

Capiacutetulo 4

Cassandra

Consistecircncia

Alta Performance

412 Modelo de Dados

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Capiacutetulo 4

Cassandra

Consistecircncia

Alta Performance

412 Modelo de Dados

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Capiacutetulo 4

Cassandra

Consistecircncia

Alta Performance

412 Modelo de Dados

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Capiacutetulo 4

Cassandra

Consistecircncia

Alta Performance

412 Modelo de Dados

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Consistecircncia

Alta Performance

412 Modelo de Dados

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

412 Modelo de Dados

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Noacutes Virtuais

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Particionador

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Capiacutetulo 5

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Pentaho

Cassandra-cli

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Capiacutetulo 6

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

gado e Rim

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Capiacutetulo 7

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Dedicatoacuteria

Agradecimentos

Resumo

Abstract


Motivaccedilatildeo

Objetivo






Grid Computing

Utility Computing












Cassandra



Modelo de Dados














Referecircncias

Documents

Universidade de Brasília - Semantic Scholar · A importância deste estudo de caso é álidav tanto para a área de bioinformática quanto para a computação, pois seu desenvolvimento