Material para seminário com abordagem sobre NoSQL apresentada para avaliação da matéria de Banco de Dados II da Universidade de Vila Velha. Apresentação: https://www.slideshare.net/lorran33/seminrio-nosql Alunos: Iago Binow, Lorran Pegoretti, Luiz Marcon e Pedro Malta Universidade de VIia Velha.

1. Universidade de Vila Velha – UVV
Curso de Ciência da Computação – Turma CC4M
Banco de Dados II
Material para apresentação de seminário – 23/11/2012
NOSQL
Apresentação: http://pt.scribd.com/doc/114144652/
Grupo: Iago Binow, Lorran Pegoretti, Luiz Marcon e Pedro Malta
Professor: Sandro Tonini
Vila Velha
2012

2. “NoSQL is not about any one feature of any of the projects. NoSQL is not about
scaling, NoSQL is not about performance, NoSQL is not about hating SQL, NoSQL
is not about ease of use, NoSQL is not about sharding, NoSQL is not about
throughput, NoSQL is not about speed, NoSQL is not about dropping ACID, NoSQL
is not about Eventual Consistency, NoSQL is not about CAP, NoSQL is not about
open standards, NoSQL is not about Open Source and NoSQL is most likely not
about whatever else you want NoSQL to be about. NoSQL is about choice.”
Jan Lehnardt, CouchDB

3. Histórico
O termo NoSQL foi usado pela primeira vez em 1998 como o nome de um banco de dados
relacional de código aberto que não possuía um interface SQL. Seu autor, Carlo Strozzi, alega
que o movimento NoSQL “é completamente distinto do modelo relacional e portanto deveria ser
mais apropriadamente chamado “NoREL” ou algo que produzisse o mesmo efeito”. Porém o
termo só voltou a ser assunto em 2009 por um funcionário do Rackspace, Eric Evans, quando
Johan Oskarsson da Last.fm queria organizar um evento para discutir bancos de dados open
source distribuídos.
NoSQL são diferentes sistemas de armazenamento que vieram para suprir necessidades que
os bancos de dados tradicionais(Relacionais) são ineficazes. Muitas dessas bases apresentam
características muito interessantes como alta performance, escalabilidade, replicação, suporte
à dados estruturados e sub colunas.
O NoSQL surgiu da necessidade de uma performance superior e de uma alta escalabilidade.
Os atuais bancos de dados relacionais são muito restritos a isso, sendo necessário a
distribuição vertical de servidores, ou seja, quanto mais dados, mais memória e mais disco um
servidor precisa. O NoSQL tem uma grande facilidade na distribuição horizontal, ou seja, mais
dados, mais servidores, não necessariamente de alta performance. Um grande utilizador desse
conceito é o Google, que usa computadores de pequeno e médio porte, para a distribuição dos
dados, essa forma de utilização e muito mais eficiente e econômica. Além disso, os bancos de
dados NoSQL são muito tolerantes a erros.
No caso dos bancos NoSQL toda a informação necessária estará agrupada no mesmo registro,
ou seja, em vez de você ter o relacionamento entre várias tabelas para formar uma informação
ela estará em sua totalidade no mesmo registro.[1]
Descrição Wikipédia: NoSQL é um termo genérico para uma classe definida de banco de
dados não-relacionais que rompe uma longa história de banco de dados relacionais com
propriedades ACID. Outros termos equivalentes para esta categoria de bancos
é NF², N1NF (non first normal form), nested relational, dimensional, multivalue, free-
form, schemaless, document database e MRNN (Modelo Relacional Não Normalizado).
(Uma tabela está na 1FN, se e somente se, não possuir atributos multivalorados. Em outras
palavras podemos definir que a primeira forma normal não admite repetições ou campos que
tenha mais que um valor.)
Características
- Escalabilidade Horizontal (scale out)
Significa adicionar mais nós ao sistema, tais como adicionar um novo servidor e um sistema de
software que permita a distribuição do trabalho entre múltiplas máquinas. [2]
- Replicação – Escalar por duplicação de informações
Consiste na copia das informações em mais de um banco para aumentar a capacidade de
recuperar estas informações. Podem ser divididas em duas “arquiteturas” principais:

4. Master-Slave: Cada escrita em banco resulta em X escritas onde X é o número de
slaves. Neste caso um banco “Master” propaga cada write para os bancos “slaves”. Isto
aumenta a velocidade de leitura, mas não melhora a capacidade de escrita.
Multi-Master: Aumenta-se o número de Masters no sistema e assim aumenta a
capacidade de escrita.
- Schema-free
Um dos fatores que contribuem para um banco de dados NoSQL escalar é por causa da
ausência de um schema (schema free). Todos os novos bancos tem em comum que eles são
key-value stores, ou seja, salvam como o nome sugere, um conjunto de entradas formadas por
uma chave associada a um valor e o valor poderia ser de qualquer tipo, um binário ou string
que está sendo salvo de forma desnormalizada (schema-free).
- Clusterização
Basicamente compreende um banco de dados armazenado e gerenciado por mais de um
servidor, provê uma alta disponibilidade e um alto desempenho do sistema. Assim, a
organização se beneficia diminuindo o tempo de inoperabilidade do banco de dados. Esse
processo vem como uma solução para reduzir gastos com estrutura de hardware. [4]
- Mapreduce
É um algoritmo, patenteado pela Google para gerenciamento em larga escala. [3]
Existem duas fases:
Map: O nó principal recebe os dados, divide e partes menores e as envia aos outros
nós para serem processados. Ao final do processamento estes nós devolvem o resultado ao nó
principal.
Reduce: O nó principal combina as respostas obtidas pelos outros nós gerando o
resultado final do processamento.
- Sharding
Consiste em dividir os dados horizontalmente, ou seja, quebrar as tabelas, diminuindo o seu
número de linhas e separando-as em ambientes diferentes. Neste ponto todos os dados de
uma partição não devem conter referências aos dados de outras partições, sendo que os
dados em comum deverão ser replicados entre as bases. [3]
Classificação
Key/Value Store
Esse é o tipo de banco de dados NoSQL mais simples o conceito dele é uma chave e um valor
para essa chave, mas ele é o que aguenta mais carga de dados. Esses tipos de bancos de
dados são o que tem a maior escalabilidade. [1]
 Amazon SimpleDB
 Azure Table Storage
 Berkeley DB
 Chordless
 Dynomite
 GenieDB: GenieDB is designed to be a pragmatic solution to a widespread class of data
storage problems, with a high-performance native API alongside compatability with MySQL.

5.  GT.M / M.DB
 HamsterDB
 Hibari: Hibari is a production-ready, distributed, key-value, big data store. Hibari uses chain
replication for strong consistency, high-availability, and durability. Hibari has excellent
performance especially for read and large value operations.
 KAI
 KaTree
 Kumofs
 LightCloud
 Membase
 Memcachedb
 Mnesia
 NorthScale
 Orient Key/Value Server
 Pincaster
 PNUTS/Sherpa
 Project Voldemort: LinkedIn open source implementation of Amazon Dynamo key-value store
 Redis
 Riak: Dynamo-inspired key/value store that scales predictably and easily.
 Scalaris
 ScalienDB / Scalien Keyspace a distributed, consistent key-value store
 Tokyo Cabinet [5]
Wide Columns Store
Fortemente inspirados pelo BigTable do google eles suportam várias linhas e colunas, além
disso ele permite sub colunas. [1]
 BigTable
 Cassandra: a highly scalable second-generation distributed database, bringing together
Dynamo’s fully distributed design and Bigtable’s ColumnFamily-based data model.
 HBase
 Hypertable [5]
Document Store
Baseado em documentos XML ou JSON, podem ser localizados pelo seu id único ou por
qualquer registro que tenha no documento. [1]
 Colayer

6.  CouchDB
 FleetDB
 Jackrabbit
 Lotus Notes
 MongoDB
 OrientDB
 Raven DB
 ThruDB
 Terrastore [5]
Graph Store
Com uma complexibilidade maior esses bancos de dados guardam objetos e não registros
como os outros tipos de NoSQL. A busca destes itens são feitas pela navegação destes
objetos.
 AllegroGraph
 Bigdata
 Core Data
 DEX: a high-performance graph database written in Java and C++. Its main characteristic is its
performance storage and retrieval for large graphs, in the order of billions of nodes, edges and
attributes, implemented with specialized structures.
 Filament
 FlockDB
 HyperGraphDB
 InfiniteGraph
 InfoGrid
 Neo4j
 OpenLink Virtuoso
 Sones
 VertexDB
 Trinity: a graph database and computation platform over distributed memory cloud. As a
database, it provides features such as highly concurrent query processing, transaction,
consistency control. As a computation platform, it provides synchronous and asynchronous
batch-mode computations on large scale graphs.[5]
Exemplo
Facebook – Cassandra, 2008
Como identificamos, o NoSQL não é uma negativa ao SQL tradicional, apesar do que o
acrônimo aparenta. NoSQL procura suprir necessidades em que o SQL puro é engessado ou
as regras de consistência "ACID" (Atomicidade, Consistência, Isolamento e Durabilidade)

7. podem ser suprimidas ou são desnecessárias, ou então podem ser negligenciadas em busca
de maior escalabilidade.
Nesse cenário um ator de destaque é o Facebook. Não há como falar de necessidade de
escalabilidade sem citar essa máquina devoradora de Bytes, segundo o conceituado site
GIGAOM no artigo "Facebook shares some secrets on making MySQL scale" o Facebook
ingere mais de 500 terabytes de novas informações por dia. Há de se esperar que exista uma
solução inovadora e fantástica por trás disso tudo, na verdade não tanto, o Facebook utiliza
nas suas partes principais o bom e velho MySQL, bem, o MySQL tunado do Facebook, mas
ainda assim MySQL.
Porém para certos casos e atividades específicas o Facebook implementa tecnologia NoSQL,
inclusive já liberou opensource o Cassandra, hoje conduzido pela fundação Apache. Segundo
Avinash Lakshman, um dos incubadores do Cassandra e funcionário do Facebook, o
Cassandra foi desenvolvido para solucionar a busca no bate-papo do Facebook, o bate-papo
do Facebook foi um dos produtos mais complexos a ser desenvolvido, ele integra SMS, e-mail,
inbox e o chat online, um parte que recebe uma massiva quantidade de dados. A estrutura do
Cassandra é totalmente avessa a primeira forma normal, uma coluna pode ter várias colunas.
Veja como a estrutura é perfeita para um sistema de mensagens: uma coluna tem um nome,
um valor(que podem ser várias colunas) e um "timestamp". Hoje em dia o sistema de
mensagens funciona em cima de outra tecnologia NoSQL, o HBase, mas de funcionamento
parecido.
Outra parte importante em que o NoSQl aparece é na análise dos dados, ou na gerenciamento
do MetaDados do Facebook, essa parte é levada pela integração do HBase com o Hive, dados
mais antigos são transferidos do MySQL para o HBase, para formação de um Data Warehouse
e o Hive faz a análise desses dados, é possível inclusive fazer consultas SQL pelo Hive, em
cima do HBase, que não tem esse suporte.
Esses casos tendem a aumentar pois quando o Facebook construiu seu ambiente MySQL não
haviam tecnologias NoSQL, portanto há em sua base dados que não são estruturados ou são
semiestruturados. A medida que as tecnologias NoSQL amadurecem haverão mais
implementações em aplicações do mundo real. [7] [8] [9]
Os maiores mitos sobre NoSQL
NoSQL é escalável
Uma das grandes promessas dos bancos NOSQL consiste em dizer que eles são mais
escaláveis que os bancos de dados relacionais. O problema com esta mensagem que é
vendida por algumas empresas é que ela não é inteiramente verdade. Dizer que seu sistema
escala sozinho é vender um sonho. Ele pode até ser mais fácil de escalar se comparado a
outras soluções mas ainda sim exigira algum esforço para escalar.
Não precisamos de DBAs
No mundo dos bancos relacionais a figura do DBA sempre está presente. Com sistemas que
tem particularidades para cada vendor os DBAs ficam a cargo de instalar, configurar e manter
cada banco de dados em suas particularidades. Muita gente diz que quando se trabalha com
NoSQL não precisamos de DBAs. Acredito que talvez não no sentido tradicional, mas ainda
vamos precisar de alguém responsável por lidar com o banco e com o acesso aos dados. Esta
função pode vir a se tornar parte do trabalho de um desenvolvedor ou se tornar a função full
time de alguém no seu time que pode ser até um DBA com conhecimentos em NoSQL. Em
aplicações reais em produção muito provavelmente será necessário misturar bancos
relacionais e não relacionais, possuir alguém que navegue facilmente nos dois mundos em seu
time é uma grande vantagem.

8. NoSQL é mais econômico
Meia verdade. Muitos vendors de NoSQL afirmam que suas soluções vão baratear o custo dos
seus clientes. Em parte sim, em algumas situações o custo em usar um banco de dados
relacional pode ser proibitivo devido à escala ou a licenças envolvidas. Existem muitos casos
entretanto que uma solução relacional atende perfeitamente todas as necessidades do cliente
e ainda sim pode ser considerada barata. Bancos de dados open source como MySQL e
PosgreSQL são usados sem problemas por um grande número de aplicações com sucesso.
Conclusão
Se você está começando agora com o NoSQL, cuidado para não cair em armadilhas. Sempre
interaja com a comunidade, converse com outros desenvolvedores sobre suas experiências
reais com NoSQL e não se esqueça de deixar suas dúvidas nos comentários. Se você já
possui alguma experiência, quais outros mitos você vê com relação ao NoSQL ? [6]
Referencias:
 [1] “Introdução ao NoSQL.”
http://www.nosqlbr.com.br
 [2] Edmar Ferreira, “Escolhendo entre escalabilidade horizontal e escalabilidade
vertical”.
http://escalabilidade.com/2010/09/21/escolhendo-entre-escalabilidade-horizontal-e-
escalabilidade-vertical/
 [3] Edmar Ferreira, “Introdução ao NoSQL parte II”
http://escalabilidade.com/2010/04/06/introducao-ao-nosql-parte-ii/
 [4] InfoWester “Cluster: Principais Conceitos”,
http://www.infowester.com/cluster.php
 [5] “NoSQL”
http://nosql.mypopescu.com/kb/nosql
 [6] “Os Maiores mitos sobre NoSQL”
http://escalabilidade.com/2010/10/08/os-maiores-mitos-sobre-nosql/
 [7] “Inside Facebook Messages' Application Server”
https://www.facebook.com/note.php?note_id=10150162742108920
 [8] “Hive – The next generation data warehouse”
http://blogs.impetus.com/big_data/hadoop_ecosystem/Hive.do
 [9] “Cassandra – A structured storage system on a P2P Network
https://www.facebook.com/note.php?note_id=24413138919