9/28/2017 Pocket: Bancos de dados no relacionais e o movimento NoSQL

Bancos de dados no relacionais e o movimento

NoSQL
blog.caelum.com.br
October 30th, 2009

Nas grandes aplicaes web cada vez mais comum a quantidade de informaes ser
enorme, e ainda temos uma certeza: amanh teremos mais dados para armanezar. Como
lidar com isso de maneira e ciente?

Muito se fala ultimamente sobre os novos bancos no relacionais. Houve um encontro

inicial e a segunda conferncia tambm j aconteceu. O movimento acabou ganhando o
nome de NoSQL, at mesmo por que cada banco de dados tem uma maneira diferente de
se escrever queries.

A grande motivao para NoSQL resolver o problema de escalabildade dos bancos

tradicionais. Pode ser muito caro ou/e complexo escalar um banco SQL.

Esse movimento est bastante enraizado no open source. D para perceber isso at
mesmo pelos curiosos nomes dos projetos: Voldemort, MongoDB, Tokyo Tyrant e
CouchDB.

https://getpocket.com/a/read/63409366 1/8
9/28/2017 Pocket: Bancos de dados no relacionais e o movimento NoSQL

Apesar de grande quantidade desses bancos serem open source, o movimento ganhou
muita fora com a publicao de dois papers sobre implementaes proprietrias: o
Google Bigtable (que a Caelum usa atualmente) e o Amazon Dynamo. No por acaso so
duas empresas que lidam com uma quantidade enorme informaes. Outros grandes
nomes participam do movimento NoSQL: Yahoo! (Hadoop com HBase, Sherpa),
Facebook e Digg (Cassandra), LinkedIn (Voldemort), Mixi (Facebook do Japo) (Tokyo
Cabinet) e a Engine Yard (MongoDB).

Muitos acham que esses bancos de dados escalam simplesmento por causa da ausncia
de um schema (schema free), logo no h veri cao de integridade e de
relacionamentos. Mas seria s isso? O MySQL, nos seus primrdios, quando no fazia
tais veri caes, ainda assim no era rpido como esses novos competidores. Quais so
ento os segredos para tanta escalabilidade?

O Amazon Dynamo se destacou por causa da forma como o sistema escala. Cada n no
cluster comunica com outros ns (p2p) e faz ativamente parte da partio/replicao.
No tem um single-point-of-failure, mas essa facilidade de escalar no vem sem custo.

Todos os novos bancos tem em comun que eles so key-value stores, ou seja salvam,
como o nome sugere, um conjunto de enradas formadas por uma chave associada a um
valor e o valor poderia ser de qualquer tipo, um binrio ou string que est sendo salvo de

https://getpocket.com/a/read/63409366 2/8
9/28/2017 Pocket: Bancos de dados no relacionais e o movimento NoSQL

forma denormalizada (schema-free). Diferentemente dos bancos SQL no existe uma

esquema forte. Essa abordagem facilita a distribuio dos dados entre vrios servidores
onde cada servidor possui apenas uma fatia dos dados (shard).

O CouchDB um dos mais famosos no time dos key-value stores. Ele usa documentos
para de nir uma estrutura no banco, armazenando uma chave associada ao um
documento. Um documento apresentado como JSON. Por exemplo:

{
"Subject": "Bancos no relacionais"
"Author": "Nico Stepat"
"PostedDate": "10/15/2009"
"Tags": ["database", "nosql", "rest"]
}

Repare a estrutura dos dados de nido atravs da aplicao, o CouchDB no exige nada,
apenas um documento JSON.

https://getpocket.com/a/read/63409366 3/8
9/28/2017 Pocket: Bancos de dados no relacionais e o movimento NoSQL

Talvez o CouchDB cou famoso por causa da simples API REST e do uso do JSON, ou da
interface gra ca bonita ou por causa dos views interessantes usando Map-Reduce ou da
replicao Multi-Master ou por que foi escrito em Erlang (como esse e esse tambm).
Seja que for, a promessa principal do NoSQL sendo escalvel o CouchDB no
compriu ainda. Ele no distribudo sozinho, e precisa de ajuda externa para tal.

Outra forma de dar alguma estrutura aos dados cou famosa por causa do Google
Bigtable. A idia no salvar os dados em linhas como estamos acustomados pelos
bancos relacionais. Os dados sero salvos atravs de colunas. Veja a diferena:

Row-Oriented (3 rows presentes Nome, Salrio, Data):

Joo,1432.00,15/10/2009
Maria,1511.00,13/10/2009
Pedro,1721.00,01/10/2009

Column-Oriented (mesmo exemplo):

https://getpocket.com/a/read/63409366 4/8
9/28/2017 Pocket: Bancos de dados no relacionais e o movimento NoSQL

Joo,Maria,Pedro
1432.00,1511.00,1721.00
15/10/2009,13/10/2009,01/10/2009

No column-oriented vem primeiro TODOS os dados da primeira coluna Nome, depois a

segunda coluna Salario e por ltimo a coluna Data.

E isso altera algma coisa? Para o desenvolvedor que vai utilizar o banco de dados, a idia
que isso seja transparente, mas para quem desenvolveu o banco, h enormes
melhorias.

Isso no muito vantajoso quando for salvo apenas um registro, como cada coluna tem
que ser accessada separadamente. Tambm complica mais na recuperao de um registro
espec co (random-access) pelo mesmo motivo. Aqui a abordagem row-oriented tem
vantagens.

Por outro lado, usando colunas, podemos empacotar os dados melhor j que os dados
semelhantes, de mesmo formato, esto prximos um do outro. Gravando dados
empacotados em BDs traz grandes vantagens, porque podemos recuperar e armanezar
mais informaes em menos tempo.

https://getpocket.com/a/read/63409366 5/8
9/28/2017 Pocket: Bancos de dados no relacionais e o movimento NoSQL

Com colunas tambm podemos aplicar projees sobre os dados mais fcil. A segunda
vantagem importante principalmente para sistemas OLAP (online analytic process) que
usam esse tipo de pesquisas pesadamente.

Banco de dados orientados a coluna vo alm de um simples key-value store. Eles

representam normalmente um array/hash de 4 ou 5 dimenses, usando ou adaptando o
modelo proposto pelo BigTable.

Primeiramente, tambm temos tabelas s que eles chamem column-families. Como o

nome indica um column-family so vras colunas. Quais so essas colunas, a aplicao
de ne.

Cada coluna salva um valor. O grupo de colunas dentro de uma familia acessvel
atraves de uma chave (row-key). O esquema ca:

columnFamily parecido com uma tabela (tabela de colunas)

rowKey ID do grupo de colunas
column nome da coluna
value valor a salvar

Por exemplo, para apresentar dados sobre um DVD com a ID 234:

https://getpocket.com/a/read/63409366 6/8
9/28/2017 Pocket: Bancos de dados no relacionais e o movimento NoSQL

<dvds>.<234>.<nome> = 'Beleza americana'

<dvds>.<234>.<ator_principal> = 'Kevin Spacey'
<dvds>.<234>.<ano> = '1999'

ou para apresentar um usurio com joao.silva:

<usuarios>.<joao.silva>.<nome> = 'Joao Silva'

<usuarios>.<joao.silva>.<email> =
'joao.silva@foo.com'

e o relacionamento:

Normalmente salvo uma data automaticamente, ou seja, a estrutura completa ca:

Os bancos orientados a coluna no oferecem joins entre column-families nem chaves

compostas. A Google AppEngine, por exemplo, no aceita chaves compostas porque usa
o BigTable por baixo. Existem pequenas diferenas entre implementaes orientadas a
coluna.

https://getpocket.com/a/read/63409366 7/8
9/28/2017 Pocket: Bancos de dados no relacionais e o movimento NoSQL

Seria o incio do m dos bancos relacionais? Aderindo a um banco de dados no

relacional muita da responsibilidade de cuidar dos dados ca a cargo da aplicao. ela
que de ne como funcionam e como se relacionam os documentos. O banco ca com
certeza mais simples, escalavl e rpido, mas perdemos as conhecidas garantias dos
bancos relacionais. Como toda deciso arquitetural, escolher por bancos de dados no
relacionais apresenta um trade o : ACID ou BASE ou alguma coisa no meio. Vale a
pena? Cada caso deve ser estudado com cuidado. Algumas aplicaes usam bancos de
dados no relacionais para uma leitura e escrita temporria, atualizando um banco
relacional de tempos em tempos, tirando vantagem das duas estratgias.

Semana que vem, no Caelum Day in Rio conversaremos sobre muitos outros detalhes do
movimento NoSQL. Nos encontramos l!

Estude online na Alura

Programao, Mobile, Front-end, Design & UX, Infraestrutura e Business

https://getpocket.com/a/read/63409366 8/8