Curso: Data Science

Disciplina: Bancos de Dados para Big Data (NoSQL)

Professor: Guilherme Piccin
Tópico 02 Agregados, características e particularidades de cada tipo de
banco NoSQL e casos de uso

Particularidades dos Agregados

Os bancos de dados NoSQL não seguem a notação ACID como os bancos relacionais.
Os bancos NoSQL suportam consistência atômica na manipulação de cada agregado
unitariamente, mas não de forma transacional para vários objetos agregados em uma
única transação. Logo, mesmo sendo um objeto com várias estruturas complexas em seu
interior, a garantia de atomicidade se limita às fronteiras deste mesmo objeto
unitariamente. Em outras palavras, bancos NoSQL empregam o teorema ACID limitado
ao agregado em si.

Costuma-se dizer que os bancos NoSQL não possuem modelo (schema) explícito (e
gerenciado pelo SGBD), mas na verdade eles possuem um schema implícito que é
controlado/gerenciado pela aplicação principal. Logo, pode haver uma validação lógica
das condições na persistência e manipulação dos objetos.

Consulta e relacionamento de agregados no banco NoSQL

A consulta é diferente em cada tipo de NoSQL. Nos bancos de chave-valor a busca é

sempre feita pela chave e não é possível consultar atributos de valor dos agregados,
enquanto nos bancos de Documentos a consulta pode ser feita com atributos do
agregado. Nos bancos de famílias de colunas as consultas são baseadas na estrutura
das colunas de cada keyspace.

Do relacionamento de agregados, não temos o mesmo conceito de relacionamento que

nos bancos relacionais com sua restrição de integridade, chaves estrangeiras e outras
formas de controle. Parte da responsabilidade de relacionamento entre agregados
possivelmente será resolvida numa junção das capacidades implementadas na aplicação
e a organização dos agregados no banco NoSQL.

Relatórios e funcionalidades tradicionais podem precisar de revisão e serem

implementadas de novas maneiras. Mas não entenda errado: a escalabilidade e
distribuição do poder de processamento de dados nos bancos NoSQL é superior ao dos
bancos tradicionais e relacionais. É importante conhecer novas ferramentas e formas de
implementação, pois tudo terá uma aplicabilidade adequada e outras não recomendadas.

Há também a possibilidade de criação de relacionamento entre os agregados através dos

atributos de identificação única e unitária, sendo estes geridos pela aplicação. Logo, é
possível criar uma “chave estrangeira” num agregado que referencia outro agregado.

Visões e consumo de dados calculados ou reduzidos

Além das consultas de cada objeto, geralmente em aplicações complexas, a necessidade

de montarmos visões sobre os dados. Ou seja, novas representações independentes da
forma como eles são organizados, persistidos e acessados. Isso é muito comum em
bancos relacionais, pois temos o conceito de views (visões) e views materializadas.

Uma visão é como uma tabela relacional (é uma relação), mas é definida pela
computação sobre as tabelas básicas. Quando acessamos uma visão, o banco de
dados computa os dados nela – uma forma útil de encapsulamento.
(Sadalage, Pramod J.; Fowler, Martin. NoSQL Essencial, p. 56, Novatec Editora)

Nos bancos NoSQL, as visões deverão ser gerenciadas e orquestradas pela aplicação
ou por plataformas de processamento de dados externos à aplicação, como funções de
redução e mapeamento (map-reduce). É possível adotar diferentes abordagens para
implementação das visões, materializadas ou não. Estas podem ser incrementais, onde
cada estágio de consulta, aglomeração e redução dos dados é persistido e servirá como
base para os próximos estágios de processamento e para outras funcionalidades de
consulta que se beneficiarão dessa estruturação intermediária.

Tipos de Bancos NoSQL: Documentos (document store)

Considerados um banco de dados de tabela hash simples onde os agregados são objetos
de negócio geralmente em formato JSON (Javascript object notation), e podem ser
acessados pela sua chave ou pelo conteúdo de algum atributo em sua estrutura.

Naturalmente possuem modelo (schema) flexível, onde o SGBD não fará a validação do
modelo ou estrutura. Por definição, não existem ou não deveriam existir atributos em
branco (ou nulo) dentro de um objeto agregado num banco de Documentos, visto que ele
foi projetado para eficiência e flexibilidade – e para endereçar a incompatibilidade de
impedância dos bancos relacionais tradicionais.

A escalabilidade do banco de dados de Documentos pode ser alcançada com o

processamento distribuído entre vários nós (servidores isolados), e a sincronia e
consistência deles será obtida através de algoritmos e regras específicos. A consistência
de dados pode acontecer das seguintes maneiras: eventual, mestre-escravo, quórum e
unanimidade (mais detalhes no tópico 3 desta disciplina).

São recomendados para: Gerenciamento de conteúdo (CMS – content management

system), aplicativos de comércio eletrônico com modelos e atributos flexíveis e em
constante evolução, registro de eventos (log) e análises de sistemas em tempo real.

Todavia, não são recomendados quando: modelos de negócio complexos e com forte
dependência de transações e consistência entre objetos/entidades, consultas a
agregados com dependência de relacionamento com outros objetos, consultas em
agregados muito distintos.

Suas principais implementaçõwes e versões disponíveis no mercado hoje em dia são o

MongoDB, CouchDB, ArangoDB, Google Firestore, Amazon Dynamo, onde todos esses
fornecem API’s em diversas linguagens para o desenvolvimento das aplicações.

Tipos de Bancos NoSQL: Chave-valor (key-value)

Similar aos bancos de dados NoSQL de documentos, os bancos de chave-valor são

tabelas hash simples, mas diferentemente dos bancos de Documentos a
consulta/consumo de objetos agregados é feito somente pela chave. Não é possível
consumir um objeto agregado pelo valor de algum de seus atributos e a maioria dos
bancos de chave-valor sequer providenciam funcionalidade para se consultar as chaves
existentes em seu data store.

É um dos bancos NoSQL com maior facilidade de escalar e também é considerado sem
modelo (schema) – geralmente a escalabilidade é feita através de partições no
namespace. Similar ao banco de Documentos, a atomicidade/consistência da transação
é garantida no nível do objeto agregado, mas não há funcionalidade de transação multi-
objetos. Além de sua fácil escalabilidade também é resistente a falhas, onde estas são
consideradas como isoladas quando acontecem em somente um ou poucos nós do
cluster.

Na ótica das aplicações, os dados são acessados através de API’s específicas de cada
fornecedor/implementador de bancos chave-valor.

São muito utilizados para memória rápida de sistemas, principalmente os Web-based

com as sessões de usuários sendo armazenadas dessa forma (cache), e muitos se
utilizam da funcionalidade TTL (time-to-live), para a auto destruição de objetos após o
prazo de expiração ser alcançado.
São recomendados para objetos de sessão em aplicativos Web, perfis de
usuários/preferências, dados de carrinhos de compra, memória de acesos rápido em
objetos comumente consultados, embora não sejam recomendados quando há
necessidade de consulta de atributos do agregado, ou quando se é necessário relacionar
um agregado com outro.

As principais instâncias no mercado hoje são Riak, Redis, BerkeleyDB e Dynamo.

Tipos de Bancos NoSQL: Famílias de Colunas (column family)

Tido como um dos mais complexos tipo de bancos NoSQL, os bancos de famílias de
colunas organizam seus registros em chaves de valores, mas os atributos agrupados em
famílias de colunas. A unidade básica de armazenamento é a coluna, pois ela é um par
de chave-valor (a chave é o nome da coluna) e seus valores são sempre armazenados
com um carimbo de tempo (timestamp).

Diferentemente de um banco relacional, cada “linha” (ou objeto) no banco de famílias de

colunas pode ter colunas diferentes e fundamentalmente exigem conhecimento prévio de
como os objetos serão consultados antes que o banco seja estruturado. Em outras
palavras, é um tipo que exige maior maturidade do time de desenvolvimento e também
do negócio em questão, pois a estruturação das colunas de acordo com a forma que os
dados serão consultados é primordial.

A consistência é garantida na linha, onde todas as suas colunas e estruturas poderão

fazer parte da mesma transação (garantia atômica). Em relação a escalabilidade e
disponibilidade, é um dos tipos de bancos NoSQL com disponibilidade mais agressiva,
pois conta com essa funcionalidade em seu alicerce arquitetural – e geralmente todos os
nós do cluster são considerados “mestres” (mais detalhes no tópico 3 desta disciplina).

Em uma de suas implementações mais famosas, o CassandraDB, chega a oferecer

linguagem proprietária de manipulação de objetos muito similar ao SQL: CQL –
Cassandra Query Language.

São bancos muito recomendados quando há uma necessidade por escala gigantesca
com muito I/O (input/output).

Tipos de Bancos NoSQL: Grafos (graphs)

O mais diferente dos tipos de bancos NoSQL e só se encaixa neste universo pois é ainda
menos parecido com os bancos relacionais. Se diferencia também por geralmente ser
single instance ao invés de ser executado em cluster. Não obstante, seu maior diferencial
é a forma como organiza os objetos: atributos e arestas, onde o que mais importa no
momento da consulta é a aresta (relacionamento entre um objeto e outro).

Os registros (nós) costumam ser pequenos, na maioria dos casos somente um atributo
texto simples e todas as arestas (relacionamentos), são montados em tempos de
persistência. Logo, suas consultas complexas são extremamente eficientes, pois o
relacionamento entre os objetos já está persistido e não precisa ser resolvido pelo SGBD.

Muito utilizados em redes sociais, roteamento logístico e rastreamento de objetos,

mecanismos de recomendação em sites de e-commerce.

Referências

SADALAGE, Pramod J.; FOWLER, Martin. NoSQL Essencial: Um guia conciso para o
Mundo emergente da persistência poliglota. Novatec Editora, 2013.
CUNHA, José Pedro; PEREIRA, José Luís. Column-based databases: estudo
exploratório no âmbito das Bases de Dados NoSQL. In: Atas de conferência da
Associação Portuguesa de Sistemas de Informação. 2016. p. 440-459.
MELO, Tiézer Costa de. Estudo de Caso de Bancos NoSQL no contexto de big data.
2017.
PEREIRA, Felipe S. et. Al. Utilização de Bancos de Dados NoSQL em Ambientes
Corporativos. E-RAV, v.3, v.1, 2013.
OLIVEIRA, Matheus Moreira Marques de. NoSQL Cassandra: um estudo de caso com
workflows de bioinformática. 2017.
RIBEIRO SECCO, Ricardo et al. Análise Comparativa Entre o banco de dados
Cassandra (modelo NoSQL) e o PostgreSQL (Modelo Relacional) em duas
diferentes organizações empresariais. In: Colloquium Exactarum. 2016
GARTNER. What Is Big Data? - Gartner IT Glossary - Big Data. 2015. Disponível em:
http://www.gartner.com/it-glossary/big-data
EVANS, Eric; FOWLER, Martin. Domain Driven Design. 2003