APS EstudodeCaso - NoSQL

8/17/2019 APS EstudodeCaso - NoSQL

1/14

1

ESTUDO DE CASO – BANCO DE DADOS NOSQL

Davi Pistorello1

Fábio Giordani2

Kaie Guex3

Resumo: Os bancos de dados relacionais são amplamente utilizados como solução de

armazenagem em diversos tipos de sistemas, mas devido ao crescimento das empresas e daquantidade de dados que movimentam as novas aplicações da web 2.0, novas abordagens

estão sendo desenvolvidas e empregadas, como é o caso dos bancos de dados NoSQL. São

soluções que vem sendo adotadas e consolidadas por grandes empresas de tecnologia para

solucionar os novos desafios que estão surgindo com o grande volume de dados movimentado

pelos sistemas da atualidade. Neste artigo será feita uma análise do que é um banco de dados

NoSQL e serão demonstradas quais as necessidades que este modelo de banco de dados veio

atender no atual mercado de TI, conceituando-o junto a outros modelos existentes,

procurando saber qual sua real vantagem e desvantagem em relação a estes.

Palavras Chave: NoSQL, Escalabilidade, Banco de dados, web 2.0.

1 Introdução

O setor de tecnologia da informação, TI, sempre procurou atender as

demandas conforme a necessidade do seu tempo, demandas que ficam cada vez mais

complexas devido ao crescimento do uso da internet e as rápidas mudanças e inovações deste

mercado. O ritmo da inovação no armazenamento de dados acelerou significativamente na

última década, e com isso as ferramentas para gerenciamento também precisaram ser

repensadas sobre o desempenho do armazenamento e controle sobre o acesso aos dados. A

1 Aluno do Curso de Tecnólogo em Análise e Desenvolvimento de Sistemas 2 Aluno do Curso de Tecnólogo em Análise e Desenvolvimento de Sistemas 3 Aluno do Curso de Tecnólogo em Segurança da Informação


2/14

2

abordagem mais inteligente no gerenciamento de armazenamento de grandes dados inclui

um conjunto de ferramentas, serviços, software e hardware. Grandes empresas como o

Twitter já relataram problemas em administrar sua grande quantidade de dados e a seu

constante crescimento. Para lidar com este problema a solução adotada em foi migrar seu

banco dados relacional para um banco de dados não-relacional, o NoSQL (Not Only SQL), no

caso do Twitter foi selecionado o banco de dados Cassandra, que promete escalabilidade, alta

disponibilidade, sem comprometer o desempenho. O Cassandra inicialmente foi criado pelo

Facebook , que abriu seu código-fonte para a comunidade em 2008, e de acordo com o

engenheiro Avinash Lakshman [1] tem o poder de escrever 2500 vezes mais rápido em um

grande banco de dados de 50 Gb do que o MySQL.

O NoSQL aparece como uma solução para atender esta necessidade iminente de

processamento de grandes montantes de dados que as empresas estão achando custosas

realizar com um banco de dados relacional. As grandes preocupações com os dados criaram

uma oportunidade para que as pessoas pensem na hora sobre as suas necessidades de

armazenamento de dados, e algumas equipes de desenvolvimento podem ver que o uso deum banco de dados NoSQL ajudam na sua produtividade, simplificando o acesso do banco de

dados, mesmo que eles não tenham a necessidade de escalar além de uma única máquina.

2 Referencial Teórico

2.1 NoSQL

Apesar de estar em maior evidência hoje, segundo Sadalage e Fowler o termo

NoSQL foi utilizado pela primeira vez em 1998 referenciado a um banco de dados de código

aberto que não utilizava a linguagem SQL. Mais tarde em 2009 este termo ganhou mais força

quando utilizado em uma conferência de defensores de banco de dados não-relacionais em

San Francisco. A principal vantagem de um tipo de banco de dados não relacional é que,

diferente da abordagem tradicional, eles lidam bem com dados desestruturados, tais como e-

mails, dados multimídia e dados provenientes de mídias sociais (Leavit, 2010).


3/14

3

Os bancos de dados, antes o hierárquico e o de rede, até chegarmos ao banco de

dados mantido pelas relações entre as tabelas o modelo relacional, não foram projetados para

funcionar de forma eficiente em clusters. Desta maneira, procurando atender à necessidade

das grandes empresas, desenvolvedores de bancos de dados passaram a pensar novas

estratégias de armazenamento, estratégias essas que os desprenderiam de trabalhar nas

regras que o modelo relacional impunha.

O desenvolvimento próprio começa, segundo Levitt, principalmente em empresas

da web 2.0, gigantes como a Google e Amazon foram pioneiras, criando bancos de dados

NoSQL para trabalharem com sua enorme quantidade de dados, chamados de BigTable e

DynamoDB. NoSQL, não se define a um tipo banco de dados de fato, mas a uma característica

comum, segundo Fowler 2012:

a) Não utilizam o modelo relacional nem a linguagem SQL;

b) São de código aberto (Open source);

c) Desenhados para utilização em grandes cluster;

d) Baseados nas necessidades da web 2.0;e) Não existe um esquema, permitindo que campos possam ser adicionados a

qualquer registro. Ausência de esquema ou esquema flexível;

f) Suporte à replicação nativo;

g) Acesso via APIs simples.

2.2 Tipos NoSQL

As categorias nas quais o NoSQL pode ser agrupado são definidas como chave-

valor, orientado a colunas, orientado a documentos e orientado a grafos.

2.2.1 Chave-valor

Podendo também ser definida como key-value ou tabela de hash, essa categoria

é conhecida como sendo um modelo de fácil implementação, uma vez que os dados serão


4/14

4

armazenados e consultados utilizando-se de chaves hash, como definido no conceito

dicionário ou mapa de dados (DE DIANA e GEROSA, 2010).

Esse modelo permite visualizar o banco de dados em tabelas hash. Utilizando-se

da sua característica, simplicidade, o banco acaba por ser composto por inúmeras chaves,

onde cada uma delas está associada a um valor único.

Como exemplo de banco de dados desta categoria de NoSQL o DynamoDB acaba

sendo o mais difundido, pois além de ser fornecido como alternativa de armazenamento de

dados pela Amazon, esse foi utilizado com base para o desenvolvimento do Cassandra.

Segundo afirma Strauch (2011), o DynamoDB foi criado para ser um sistema de

consistência eventual, ou seja, quando uma operação for executada, o retorno da operação

acontece antes de todos os nós serem atualizados, ocasionando que leituras posteriores

possam retornar versões diferentes dos dados.

2.2.2 Orientado a colunas

Comumentemente relacionado ao tipo de armazenamento definido por Chang

(2006) em "BigTable: A distributed Storage System for Structured data", vários projetos além

do próprio BigTable utilizam este conceito de bancos de dados, que suportam um grande

número de colunas por linha e permitem buscas mais ágeis nos valores das colunas. Estas por

sua vez, podem possuir valores baseados em listas, sub colunas ou outras linhas com colunas.

Nesse modelo, a indexação dos dados é efetuada pela tripla formada pela linha,

coluna e data/hora. Para identificação, tanto a linha quanto a coluna são identificadas por

chaves e o timestamp, é um diferenciador entre as versões dos dados, segundo Lóscio, De

Oliveira e Pontes (2011).

Criado pela Google em 2004, o BigTable, foi uma das implementações pioneiras

de um sistema não relacional objetivando a promoção de uma maior escalabilidade e

disponibilidade (BRITO, 2010), contudo este modelo não suporta uniões, fazendo-se

necessária a tratativa de relacionamentos na aplicação e não em nível de banco de dados

como ocorre nos sistemas relacionais.


5/14

5

2.2.3 Orientado a documentos

Na categoria de NoSQL orientado a documentos, cada documento é

implementado como um objeto com um identificador único e possui um conjunto de campos.

Os documentos têm como característica a flexibilidade de seu esquema (definição),

permitindo assim que cada documento possa possuir seu próprio conjunto de campos sem

que seja seguido rigidamente um padrão de tabelas estruturadas (LÓSCIO, DE OLIVEIRA e

PONTES, 2011). Com esta abordagem, os desenvolvedores podem adicionar quantos campos

se fizerem necessários e de quaisquer tipos disponíveis, sem restrições estruturais.

O CouchDB, que desde 2008 pertence à Apache Software Foundation, é um dos

exemplos de banco de dados desta categoria. Uma característica interessante é que o controle

de concorrência dos dados é feito utilizando identificadores de sequência para cada uma das

versões do documento. Quando este é alterado por outro usuário desde a sua última leitura,

a aplicação é notificada e por sua vez combina ou descarta as alterações e por fim, após as

alterações serem confirmadas os dados são gravados.

2.2.4 Orientado a grafos

O modelo de grafos possui três elementos básicos: os vértices dos grafos (nós), as

arestas (relacionamentos) e os atributos (propriedades dos nós e dos relacionamentos)

(LÓSCIO, DE OLIVEIRA e PONTES, 2011).

A vantagem da utilização deste modelo se dá ao aplicá-lo em consultas mais

complexas na extração de dados por parte do usuário. Ao se comparar esse com o modelo

conceitual onde estas pesquisas exigiriam, em grande parte, uma melhor implementação da

aplicação que poderia ocasionar perda de desempenho, a orientação a grafos resultaria em

melhores resultados com relação ao tempo de retorno dessas informações.

OrientDB é um dos principais bancos de dados de NoSQL desta categoria.

Conforme definido pela própria Orient Technologies LTD: é um banco open source, escrito em

Java e mistura funcionalidade dos modelos orientados a documento e orientados a grafos e


6/14

6

permite a utilização com schema rígido quanto flexível, dando também suporte a SQL, que

permite a migração de programadores acostumados com o modelo relacional [2].

Na figura encontram-se exemplos de bancos de dados conforme os modeles descritos:

2.3 NoSQL x Relacionais

De acordo com Elmasri e Navathe (2006), bancos de dados Relacionais baseiam-

se no conceito de entidade e relacionamento, onde todos os dados são armazenados em

tabelas e separados de forma única tentando diminuir ao máximo a redundância. A

informação é criada pelo conjunto dos dados e é aí que entram as relações entre as tabelas.

As características mais marcantes deste modelo são: Tabelas, hierarquia, esquema definido,

mínima redundância, entidades, relacionamentos e transações ACID ( Atomicity, C onsistency,

I solation e Durability em inglês).


7/14

7

a) A – Atomicidade: Garante que as transações sejam atômicas (indivisíveis). A

transação será executada totalmente ou não será executada.

b) C – Consistência: Garante que o banco de dados passará de uma forma consistente

para outra forma consistente.

c) I – Isolamento: A propriedade de isolamento garante que a transação não será

interferida por nenhuma outra transação concorrente.

d) D – Durabilidade: A propriedade de durabilidade garante que o que foi salvo, não

será mais perdido.

Bancos de dados NoSQL abrem mão destas propriedades, ganhando em

flexibilidade, disponibilidade, desempenho e menor tempo de resposta a consultas, valendo-

se da abordagem BASE (Basically Available, Soft state e Eventual consistency em inglês) [3].

a) BA – (Basically Available) Basicamente Disponível – Prioridade na disponibilidade

dos dados.

b) S - (Soft-State) Estado leve – Não precisa ser consistente o tempo todo.

c) E – (Eventually Consistent) Eventualmente Consistente - torna-se consistente no

momento devido.

Ippolito (apud STRAUCH, 2011, p. 32) resume a propriedade em: “uma aplicação

funciona basicamente todo o tempo (disponibilidade básica), não necessita ser consistente

todo o tempo (estado leve), mas terá um estado consistente eventual (consistência

eventual)”.

Tal ideia se baseia no Teorema de Eric Brewer conhecido como Teorema CAP

(Consistency , Availability e Partition Tolerance), o qual afirma que é impossível para um

sistema computacional distribuído garantir, de forma simultânea, consistência,

disponibilidade e tolerância ao particionamento. Segundo esse teorema, um sistema

distribuído pode garantir apenas duas dessas três características simultaneamente. (Leite,

2010)


8/14

8

O teorema CAP em português significa: consistência, disponibilidade e tolerância

ao particionamento (no quadro representado pelo escalonamento) em uma comparação com

o banco de dados relacional (Brito, 2010 p.5):

Segundo Padalage e Fowler, diferentes aplicações têm diferentes necessidades

estruturais e de desempenho, por isso, sabendo que nem todos os dados podem ser

estruturados, os tipos de banco de dados NoSQL cresceram nos últimos anos.

Na Tabela 1 encontram-se comparações complementares entre os modelos.

BANCOS DE DADOS SQL BANCOS DE DADOS NOSQL Tipos Um tipo (banco de dados SQL) com

pequenas variações

Muitos tipos diferentes,

incluindo chave-

valor, orientados a documentos,

orientado a grafos e etc.

História de

Desenvolvimento

Desenvolvido em 1970 para lidar

com a primeira onda de aplicações

de armazenamento de dados

Desenvolvido em 2000 para

lidar com as limitações dos

bancos de dados SQL,

particularmente em matéria de


9/14

9

escala, replicação e

armazenamento de dados não

estruturados.

Exemplos MySQL, Postgres, Oracle Database MongoDB, Cassandra, HBase,

Neo4j

Modelo de

Armazenamento

de Dados

Os registros individuais (Ex:

“empregados”) são armazenados

como linhas em tabelas, com cadacoluna armazenando uma parte

específica de dados sobre esse

registro (Ex: “gerente”, “setor”,

etc.), bem como uma

planilha. Tipos de dados separados

são armazenadas em tabelas

separadas, e depois juntaram-se

quando as consultas mais

complexas são executadas. Por

exemplo, "escritórios" pode ser

armazenado em uma tabela, e

"empregados" em outra. Quando

um usuário quer encontrar o

endereço de trabalho de um

empregado, o motor de banco de

dados se junta ao "empregado" e

"escritório" mesas em conjunto

para obter todas as informações

necessárias.

Varia com base no tipo de banco

de dados. Por exemplo,

armazenagens chave-valorfuncionam de forma semelhante

aos bancos de dados SQL, mas

tem apenas duas colunas (“key ”

e “value”), com informações

mais complexas, por vezes,

armazenados dentro das

colunas "valor". Bancos de

dados documentais acabam

com o modelo de tabela-e-linha

por completo, armazenam todos

os dados relevantes juntos em

um único "documento" em

JSON, XML ou outro formato,

que pode agrupar valores

hierarquicamente.


10/14

10

Esquemas Estrutura e tipos de dados são

determinados com

antecedência. Para armazenar

informações sobre um novo item

de dado, toda a base de dados tem

de ser alterada, tempo durante o

qual a base de dados tem de ser

colocada no modo offline.

Tipicamente dinâmica. Os

registros podem adicionar novas

informações em tempo real, e

ao contrário de linhas da tabela

SQL, dados diferentes podem

ser armazenados juntos

conforme necessário. Para

alguns bancos de dados (por

exemplo, column-family ), é um

pouco mais desafiador para

adicionar novos campos

dinamicamente.

Escalabilidade Vertical, ou seja, um único servidor

deve ficar mais poderoso, a fim de

lidar com o aumento da

demanda. É possível espalhar

bancos de dados SQL ao longo de

muitos servidores, mas geralmente

uma significativa engenharia

adicional é necessária.

Horizontal, significa que um

administrador de banco de

dados pode simplesmente

adicionar mais servidores ou

instâncias de nuvem. O banco

de dados espalha

automaticamente dados entre

servidores conforme se faz

necessário.

Modelo de

Desenvolvimento

Mix de código-fonte aberto (por

exemplo, Postgres, MySQL) e de

código fechado (por exemplo,

banco de dados Oracle)

Open source

Suporta

Transações

Sim, as atualizações podem ser

configuradas para completar

totalmente ou não

Em determinadas circunstâncias

e em determinados níveis (por

exemplo, nível de documento

vs. nível de banco de dados)


11/14

11

Manipulação de

Dados

Linguagem específica utilizando

SELECT , INSERT e UPDATE . Ex:

SELECT campos FROM tabela

WHERE ...

Através de APIs orientadas a

objeto

Consistência Pode ser configurado para uma

forte consistência

Depende do produto. Alguns

fornecem consistência forte (por

exemplo, MongoDB), enquanto

outros oferecem consistênciaeventual (por exemplo,

Cassandra)

Tabela 1

2.4 Principais aplicações (cases)

Os principais utilizadores do NoSQL são empresas que processam uma enormequantidade de dados e esses dados devem estar acessíveis de forma rápida. Como exemplo

disso, pode ser citado o caso do Twitter . Em 2008, enquanto ainda utilizava o PostgreSQL, o

site que funciona como rede social ficou 84 horas for do ar. Em 2009, após a utilização do

Cassandra, esse tempo foi sensivelmente reduzido para 23 horas e 45 minutos [4].

Outros, exemplos de empresas que adotaram o modelo NoSQL são:

Empresa Banco de Dados

Bigtable Google

Dynamo Amazon

Hadoop Yahoo

Cassandra Facebook, Digg, Twitter, IBM, Netflix

Voldemort LinkedIn

MongoDB Engine Yard


12/14

12

3 Metodologia

O desenvolvimento deste artigo foi realizado através coleta de dados em livros,

pesquisas acadêmicas e visitas em portais de tecnologia em busca de dados que mostrassem

a real utilização e os detalhes de como o NoSQL está presente nas empresas de web 2.0,

detalhes de onde e como estão sendo utilizados nessas organizações. Após a coleta destes

dados buscamos identificar quais as características e vantagens que esse novo conceito de

armazenamento de dados em larga escala tem proporcionado para empresas como Google,

Amazon, Twitter e outras grandes da tecnologia atual.

4 Considerações Finais

De acordo com os apontamentos anteriores, percebe-se que as soluções NoSQL,

mesmo que empregadas por gigantes da tecnologia como a Google, não vieram substituir as

relacionais, que permanecem como principal opção para aplicações consideradas críticas, e

sim suprir novas demandas que surgiram com as inovações da Web 2.0.

Aplicações que movimentam uma massa de dados gigantesca, onde em alguns

casos pode passar de 15 Terabytes gerados diariamente, como é o caso do Facebook [3],

clamavam por alternativas que viabilizassem a escalabilidade, esquema flexível, alto

desempenho e alta disponibilidade, tornando o gerenciamento de seus dados muito mais

eficiente, mesmo que para isso tenham de se submeter a possiblidade de nem sempre ser

possível garantir que os dados estejam consistentes e de que haja um controle na

concorrência, dentre outras características dos banco de dados tradicionais.

Entre perdas e ganhos, conclui-se que são soluções diferentes para problemas

específicos, cabe aos desenvolvedores e projetistas mensurarem os pros e contras de cada

solução para cada tipo de problema.


13/14

13

5 Referencial Teórico

Pramod J Sadalage, Martin Fowler, NoSQL distilled : a brief guide to the emerging world of

polyglot persistence / Crawfordsville, Indiana. August 2012

Leavit, N. Will NoSQL Databases Live Up to Their Promise? 2010. Computer, 12. ISSN 0018-

9162

BRITO, R. W. Bancos de Dados NoSQL x SGBDs Relacionais:Análise Comparativa. InfoBrasil,2010. Disponível em: http://www.infobrasil.inf.br/userfiles/27-05-S4-1-68840-Bancos%20de%20Dados%20NoSQL.pdf . Acessado em: 15 out. 2014

LEITE, Gleidson Sobreira. Análise Comparativa do Teorema CAP Entre Bancos de Dados

NoSQL e Bancos de Dados Relacionais. 2010. 49 p. Monografia (Bacharel em Ciências da

Computação) – Faculdade Farias Brito, Fortaleza.

ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. 5ª. ed. [S.l.]: Addison Wesley, 2006.Acesso em: 21 maio 2012.

CHANG, F; Dean, J; GHEMAWATT, S; HSIEH, W. C. B;, DEBORAH A. W. M; CHANDRA, T; FIKES,A GRUBER, R. E. Bigtable: A Distributed Storage System for Structured Data, 2006 - OSDI '06

Proceedings of the 7th USENIX Symposium on Operating Systems Design and Implementation- Volume 7

DE DIANA, M.; GEROSA, M. A. NOSQL na Web 2.0: Um Estudo Comparativo de Bancos Não-Relacionais para Armazenamento de Dados na Web 2.0 . Workshop de Teses e Dissertaçõesem Banco de Dados. Belo Horizonte: [s.n.]. 2010.

LÓSCIO, B. F.; DE OLIVEIRA, H. R.; PONTES, J. C. D. S. NoSQL no desenvolvimento de aplicaçõesWeb colaborativas. Simpósio Brasileiro de Sistemas Colaborativos, Paraty, ago. 2011.Disponível em: http://www.addlabs.uff.br/sbsc_site/SBSC2011_NoSQL.pdf Acessado em: 17out 2014.

STRAUCH, C. NoSQL Databases. iiWAS '11 Proceedings of the 13th International Conferenceon Information Integration and Web-based Applications and Services, Nova Iorque, dez.2011. 278-283. Disponível em: http://dl.acm.org/citation.cfm?id=2095583 Acessado em: 10out. 2014.

[1] http://www.computerworld.com/article/2526317/database-administration/no-to-sql--

anti-database-movement-gains-steam.html

[2] ORIENTDB.Disponível em: https://github.com/orientechnologies/orientdb/ Acesso em:05 out. 2014.

[3] FHH: Facebook, Hadoop, and Hive. 2009. http://www.dbms2.com/2009/05/11/facebook-

hadoop-and-hive/

http://www.infobrasil.inf.br/userfiles/27-05-S4-1-68840-Bancos%20de%20Dados%20NoSQL.pdfhttp://www.infobrasil.inf.br/userfiles/27-05-S4-1-68840-Bancos%20de%20Dados%20NoSQL.pdfhttp://www.infobrasil.inf.br/userfiles/27-05-S4-1-68840-Bancos%20de%20Dados%20NoSQL.pdfhttp://www.addlabs.uff.br/sbsc_site/SBSC2011_NoSQL.pdfhttp://www.addlabs.uff.br/sbsc_site/SBSC2011_NoSQL.pdfhttp://www.addlabs.uff.br/sbsc_site/SBSC2011_NoSQL.pdfhttp://dl.acm.org/citation.cfm?id=2095583http://dl.acm.org/citation.cfm?id=2095583http://dl.acm.org/citation.cfm?id=2095583http://www.computerworld.com/article/2526317/database-administration/no-to-sql--anti-database-movement-gains-steam.htmlhttp://www.computerworld.com/article/2526317/database-administration/no-to-sql--anti-database-movement-gains-steam.htmlhttp://www.computerworld.com/article/2526317/database-administration/no-to-sql--anti-database-movement-gains-steam.htmlhttps://github.com/orientechnologies/orientdb/https://github.com/orientechnologies/orientdb/https://github.com/orientechnologies/orientdb/http://www.dbms2.com/2009/05/11/facebook-hadoop-and-hive/http://www.dbms2.com/2009/05/11/facebook-hadoop-and-hive/http://www.dbms2.com/2009/05/11/facebook-hadoop-and-hive/http://www.dbms2.com/2009/05/11/facebook-hadoop-and-hive/http://www.dbms2.com/2009/05/11/facebook-hadoop-and-hive/http://www.dbms2.com/2009/05/11/facebook-hadoop-and-hive/https://github.com/orientechnologies/orientdb/http://www.computerworld.com/article/2526317/database-administration/no-to-sql--anti-database-movement-gains-steam.htmlhttp://www.computerworld.com/article/2526317/database-administration/no-to-sql--anti-database-movement-gains-steam.htmlhttp://dl.acm.org/citation.cfm?id=2095583http://www.addlabs.uff.br/sbsc_site/SBSC2011_NoSQL.pdfhttp://www.infobrasil.inf.br/userfiles/27-05-S4-1-68840-Bancos%20de%20Dados%20NoSQL.pdfhttp://www.infobrasil.inf.br/userfiles/27-05-S4-1-68840-Bancos%20de%20Dados%20NoSQL.pdf


14/14

14

[4] “Twitter growth prompts switch from MySQL to 'NoSQL' database”.

http://www.computerworld.com/s/article/9161078/Twitter_growth_prompts_switch_from _MySQL_to_NoSQL_database. Acessado em 14/05/2010.

Documents

APS EstudodeCaso - NoSQL