NoSQL

Engenharia e Administração de Sistemas de Banco de Dados

Faculdade de Tecnologia / Universidade Estadual de Campinas

NoSQL
André Luís de Andrade Danelon

1. Introdução
O cenário atual, em relação à persistência de dados, passa por um momento onde é possível
observar o modelo relacional como o mais difundido, senão o mais usado.
Constantemente, até mesmo os profissionais da área preferem se tornarem céticos
usuários dos Sistemas de Gerenciamento de Bancos de Dados (SGBD) puramente relacionais,
para resolver problemas com estruturas muito dispares ao paradigma relacional, causando
limitações e trabalho excessivamente desnecessário.
Ferramentas NoSQL fornecem meios mais eficientes de armazenamento de grandes
volumes de dado, além de mecanismos de pesquisa de baixa latência, fatores importantes que
precisam ser considerados durante a escolha de uma solução de armazenamento de dados.

1.1. O que é NoSQL
Não se trata apenas de uma linguagem, mas sim de um conjunto de ferramentas e estruturas.
Esse conjunto consiste em diversas tecnologias capazes de resolver certos problemas de forma
mais específica, abordando cada cenário de uma forma bem particular.
Contudo, o objetivo do NoSQL não é substituir a linguagem SQL, como muitos pensam.
Sua proposta é (como o nome denomina: not only SQL – não apenas SQL) usar também
modelos não-relacionais, para trazer a melhor solução para um determinado problema.

1.2 Surgimento do NoSQL
É uma ironia incrível que o termo “NoSQL” tenha feito sua primeira aparição no final da
década de 1990 com o nome de um banco de dados relacional de código aberto (open source)
[Strozzi NoSQL]. Liderado por Carlo Strozzi, esse banco de dados armazena suas tabelas sob a
forma de arquivos ASCII, e cada tupla é representada por uma linha com os campos separados
por tabulações. O nome vem do fato de que o banco de dados não utiliza SQL como uma
linguagem de consulta. Em vez disso, ele é manipulado por meio de shell scripts, que podem
ser combinados em encadeamentos (pipelines) no Unix. Apesar da coincidência na
terminologia, o NoSQL de Strozzi não teve influência sobre os bancos de dados atuais
relacionados ao NoSQL.



O uso do termo “NoSQL” que conhecemos hoje é resultado de uma reunião realizada
no dia 11 de junho de 2009, em São Francisco, nos Estados Unidos, organizada por Johan
Oskarsson, um desenvolvedor de software de Londres. O exemplo do BigTable e do Dynamo
inspirou a criação de vários projetos, que faziam experimentações com armazenamentos
alternativos de dados, e discussões sobre o assunto haviam se tornado uma das partes
essênciais das melhores conferências sobre software daquela época. Johan estava interessado
em descobrir mais sobre esses novos bancos de dados enquanto estava em São Francisco para
um evento sobre Hadoop. Já que dispunha de pouco tempo, achou que não seria viável visitalos todos, de modo que decidiu organizar uma reunião em que todos pudessem estar
presentes e apresentar seu trabalho para quem estivesse interessado em conhecê-lo.
Johan queria um nome para a reunião – algo que fosse um bom hashtag para o
Twitter: curto, fácil de lembrar e sem muitos semelhantes no Google, de modo que uma
pesquisa que utilizasse esse nome encontrasse rapidamente a reunião. Ele pediu sugestões no
canal #cassandra do IRC e recebeu algumas, selecionando “NoSQL”, de Eric Evans (um
desenvolvedor na Rackspace, sem conexão com o Eric Evans do DDD – Domain Driven Design).
Embora tivesse a desvantagem de ser negativo e não descrever realmente esses sistemas, tal
opção satisfazia ao critério de hashtag. Naquela época, eles estavam pensando apenas em dar
um nome para uma reunião e não esperavam que se tornaria o nome da tendência tecnológica
como um todo [Oskarsson].
O termo “NoSQL” pegou como fogo em palha, mas nunca favoreceu uma definição
precisa. A chamada original [NoSQL Meetup] para a reunião pedia por “bancos de dados não
relacionais, distribuídos e de código aberto”. As palestras [NoSQL Debrief] lá realizadas foram
sobre Voldemort, Cassandra, Dynomite, HBase, Hypertable, CouchDB e MongoDB, mas o
termo nunca ficou limitado a esse grupo original. Não há uma definição genericamente aceita
nem uma autoridade para fornecer uma, de modo que os outros bancos de dados possam ser
classificados como NoSQL devido a algumas características comuns.

2. Características
2.1. Consultas
O primeiro fato óbvio é que banco de dados NoSQL não utilizam SQL. Alguns deles têm
linguagens de consulta, e faz sentido que elas sejam semelhantes ao SQL, facilitando o
aprendizado. A CQL do Cassandra é assim, “exatamente como SQL (exceto onde não é)” [CQL].
Todavia, até hoje ninguém implementou algo que se ajustasse à noção bastante flexível do
padrão SQL.



2.2. Open Source
Outra característica importante desses bancos de dados é que eles, geralmente, são projetos
de código aberto. Embora o termo NoSQL seja frequentemente aplicado a sistemas de código
fechado, existe uma noção de que seja um fenômeno de código aberto.

2.3. Clusterização
A maioria dos bancos de dados NoSQL é orientada pela necessidade de execução em clusters.
Isso tem uma influência sobre seu modelo de dados, assim como sobre sua abordagem
quando à consistência. Banco de dados relacionais utilizam transações ACID para lidar com
consistência em todo o banco de dados, o que é, inerentemente, conflitante com um ambiente
de clusters, de modo que os bancos de dados NoSQL oferecem uma gama de opções para
consistência e distribuição.
Entretanto, nem todos os bancos de dados NoSQL almejam a execução em clusters.
Bancos de dados de grafos consistem em um estilo de banco de dados NoSQL que utiliza um
modelo de distribuição semelhante aos bancos de dados relacionais, mas oferece um modelo
de dados que os torna mais eficientes na manipulação de dados com relacionamentos
complexos.

2.4. Schema-Free
Os bancos de dados NoSQL atuam sem um esquema, permitindo que sejam adicionados,
livremente, campos aos registros do banco de dados, sem ter de definir primeiro quaisquer
mudanças na estruturas. Isso é especialmente útil ao lidar com dados não uniformes e campos
personalizados, os quais faziam que os bancos de dados relacionais utilizassem nomes como
customField6 (campoPersonalizado6) ou tabelas de campos personalizados, que são difíceis de
processar e entender.

2.5. Map-Reduce
O padrão map-reduce (uma forma de Scatter-Gather [Hohpe e Woolf]) é uma forma de
organizar o processamento de maneira a aproveitar múltiplas máquinas de um cluster. Ao
mesmo tempo, mantém-se o quanto for possível do processamento e dos dados de que ele
precisa na mesma máquina. Esse padrão destacou-se pela primeira vez com o framework
MapReduce do Google [Dean e Ghemawat]. Uma implementação open-source amplamente
utilizada faz parte do projeto Hadoop, embora diversos bancos de dados incluam suas próprias



implementações. Assim como na maioria dos padrões, há diferenças nos detalhes entre essas
implementações. O nome “map-reduce” revela sua inspiração a partir das operações de
mapeamento e redução nas coleções em linguagens de programação funcional.

3. Técnicas de Escalabilidade
3.1. Sharding
Frequentemente, um armazenamento de dados fica extremamente ocupado, pois várias
pessoas estão acessando partes diferentes do conjunto dos dados. Nessas circunstâncias,
podemos suportar a escalabilidade horizontal, colocando partes diferentes dos dados em
servidores diferentes – uma técnica chamada de fragmentação (sharding).
A fragmentação é particularmente valiosa para a performance, pois pode melhorar o
desempenho de leitura e gravação. Utilizar a replicação, especialmente com cache, pode
melhorar muito o desempenho de leitura, mas faz pouco para aplicativos que tenham muitas
gravações. A fragmentação fornece uma maneira de ampliar horizontalmente as gravações.

3.2. Replicação mestre-escravo
Com a distribuição mestre-escravo, é possível replicar dados em múltiplos nodos. Um nodo é
designado como o mestre, ou primário, o qual é a fonte oficial dos dados e, geralmente, fica
responsável por processar quaisquer atualizações nesses dados. Os outros nodos são escravos,
ou secundários. Um processo de replicação sincroniza os escravos com o mestre.
A replicação mestre-escravo é mais útil para a escalabilidade quando há um conjunto
de dados com muitas leituras. É possível escalar horizontalmente para lidar com mais
solicitações de leitura, adicionando novos nodos escravos e assegurando-se de que todas as
solicitações de leitura sejam roteadas para os escravos. Entretanto, ainda haverá a limitação
pela capacidade do mestre de processar as atualizações e de transmiti-las adiante.
Consequentemente, não é um esquema bom para os conjuntos de dados com muito tráfego
de gravação, embora diminuir a carga do tráfego de leitura ajudará um pouco a lidar com a
carga de gravação.



4. Modelo de Dados
4.1. Banco de Dados de Chave-Valor
Um depósito de chave-valor é uma tabela hash simples, utilizada principalmente quando todo
o acesso ao banco de dados é feito por meio da chave primária. São depósitos de dados NoSQL
mais simples de utilizar a partir da perspectiva de uma API. O cliente pode obter o valor para
uma determinada chave, inserir um valor para uma chave ou apagar a mesma do depósito de
dados. O valor é um blob que o depósito de dados apenas armazena, sem se preocupar ou
saber o que há dentro dele; é responsabilidade do aplicativo entender o que foi armazenado.
Já que depósitos de chave-valor sempre fazem o acesso pela chave-primária, eles têm,
geralmente, um ótimo desempenho e podem ser escaláveis facilmente.
Alguns dos bancos de dados de chave-valor mais populares são o Riak, Redis (muitas
vezes chamado de servidor Data Structure), Memcached DB e suas variedades, Berkeley DB,
HamsterDB (especialmente apropriado para uso interno), Amazon DynamoDB (não é opensource) e Project Voldemort (implementação open-source do Amazon DynamoDB).
Em alguns armazenamentos de chave-valor, como o Redis, o agregado armazenado
não tem de ser um objeto do domínio, ou seja, ele pode ser qualquer estrutura de dados. O
Redis suporta o armazenamento de listas, conjuntos, hashes e pode fazer operações de
intervalos, diferença, união e intersecção. Esses recursos permitem que o Redis seja utilizado
de formas mais diferenciadas do que um depósito padrão de chave-valor.

4.2. Banco de Dados de Documentos
Os documentos são o principal conceito em bancos de dados de documentos. O banco de
dados armazena e recupera documentos, os quais podem ser XML, JSON, entre outros. Esses
documentos são estruturas de dados na forma de árvores hierárquicas e autodescritivas,
constituídas de mapas, coleções e valores escalares. Os documentos armazenados são
semelhantes entre si, mas não têm de serem exatamente os mesmos. Bancos de dados de
documentos armazenam documentos na parte do valor do armazenamento de chave-valor;
podemos pensar nele como um depósito de chave-valor, em que o valor pode ser examinado.
Na representação dos dados de um SGBDR, todas as colunas devem ser definidas e, se
não contiverem dados, são marcadas como vazias ou nulas (null). Em documentos, não há
atributos vazios; se um determinado atributo não for encontrado, supõe-se que não estava
configurado ou não era relevante para o documento. Os documentos permitem que novos
atributos sejam criados sem a necessidade de definição prévia ou de alteração nos
documentos existentes.



Alguns dos bancos de dados de documentos populares são MongoDB, CouchDB,
Terrastore, OrientDB, RavenDB e, é claro, o bem conhecido e muitas vezes criticado Lotus
Notes, que utiliza armazenamento de documentos.

4.4. Armazenamento em Família de Colunas
Bancos de dados de família de colunas armazenam dados em famílias de colunas como linhas
que tenham muitas colunas associadas, fazendo uso de uma chave de linha. Famílias de
colunas são grupos de dados relacionados que, frequentemente, são acessados juntos. Por
exemplo, muitas vezes acessamos as informações de perfil de um cliente ao mesmo tempo,
mas não seus pedidos.
O Cassandra é um dos bancos de dados de família de colunas mais popular, embora
existam outros, como HBase, Hypertable e Amazon DynamoDB. O Cassandra pode ser descrito
como rápido e de fácil crescimento escalar, com operações de gravação distribuídas pelo
cluster, que não possui um nodo mestre, de forma que tanto leitura quanto gravação podem
ser feitas por qualquer um de seus nodos.

4.5. Banco de Dados de Grafos
Bancos de dados de grafos permitem que sejam armazenadas entidades e também
relacionamentos entre essas entidades. Entidades também são conhecidas como nodos, os
quais possuem propriedades. Podemos pensar num nodo como uma instância de um objeto
do aplicativo. Os relacionamentos são conhecidos como arestas que podem ter propriedades.
As arestas têm significância direcional; nodos são organizados por relacionamentos, os quais
permitem que você encontre padrões interessantes entre eles. A organização do grafo permite
que os dados sejam armazenados uma vez e depois interpretados de formas diferentes
baseadas em relacionamentos.
Quando uma estrutura de dados como um grafo é armazenada num SGBDR, um único
tipo de relacionamento é armazenado (“quem é o meu gerente”, é um exemplo comum).
Adicionar outro relacionamento, geralmente, implica muitas alterações no esquema e uma
movimentação de dados, o que não é o caso quando se utiliza banco de dados de grafos.
Em bancos de dados de grafos, percorrer as junções ou relacionamentos é muito
rápido. O relacionamento entre nodos não é calculado no momento da consulta, mas, sim,
persistido na forma de um relacionamento. Percorrer relacionamentos persistidos é mais
rápido do que calculá-los a cada consulta.



Os nodos podem ter diferentes tipos de relacionamentos entre si, permitindo a
representação de relacionamentos entre as entidades do domínio, e possuir relacionamentos
secundários para categorias, caminhos, árvores cronológicas, quadtrees para indexação
espacial ou listas encadeadas para acesso ordenado. Uma vez que não há limite para o número
e para o tipo de relacionamento que um nodo pode ter, todos podem ser representados no
mesmo banco de dados de grafos.
Há muitos bancos de dados de grafos disponíveis, tais como o Neo4J, o Infinite Graph,
o OrientDB ou o FlockDB (que é um caso especial: um banco de dados de grafos que suporta
apenas relacionamentos em uma única profundidade ou listas de adjacência, na qual não pode
ser percorrido mais de um nível de profundidade para relacionamentos).

5. Referências Bibliográficas
FOWLER, MARTIN. NoSQL: Um Guia Conciso para o Mundo Emergente da Persistência
Poliglota. São Paulo: Novatec, 2013.
FOWLER, MARTIN. Polyglot Persistence. Disponível em:
http://martinfowler.com/bliki/PolyglotPersistence.html. Data de acesso: 26 set. 2013.
NOSQL BRASIL. Introdução ao NoSQL. Disponível em: http://nosqlbr.com.br/. Data de acesso:
26 set. 2013.
SILVA, FRANCISCO YURI TEIXEIRA. Introdução à Tecnologia NoSQL. Disponível em:
http://www.devmedia.com.br/introducao-a-tecnologia-nosql/27682. Data de acesso: 26 set.
2013.
VIEIRA, FELIPE. Introdução ao NoSQL. Disponível em:
https://www.youtube.com/watch?v=0f7ht6WTY6g. Data de acesso: 26 set. 2013.

NoSQL

Mais conteúdo relacionado

Mais procurados (20)

Semelhante a NoSQL (20)

Último (20)

NoSQL