O documento discute as diferenças entre bancos de dados tradicionais (SQL) e bancos de dados NoSQL, focando em como a computação em nuvem levou ao surgimento dos bancos NoSQL para atender melhor às demandas de desempenho e escalabilidade. O documento também categoriza os principais tipos de bancos de dados NoSQL.

1. NoSQL x SQL: Banco de Dados em Nuvens Computacionais
Carlo de Siqueira Pires
Pós-graduação em Redes e Segurança de Sistemas
INF - Instituto de Informática – Universidade Federal de Goiás (UFG)
Caixa Postal 131 – 74001-970 – Goiânia – GO – Brasil
carlopires@gmail.com
Abstract. This paper present a brief overview of cloud computing and
databases, focusing on differences between those ones called as NoSQL and
the traditional ones. The concepts are presented using a simple and clear
language in order to to ease the lecture by people with few knowledge in
databases. In the end, it is expected that the reader have a better
understanding of such technologies and know more the main details to
consider when to choose between these kind of products.
Resumo. Este artigo apresenta um breve apanhado sobre nuvens
computacionais e bancos de dados, concentrando-se nas diferenças entre os
conhecidos como NoSQL e os tradicionais. Os conceitos são apresentados
através de uma linguagem clara e objetiva, visando facilitar a leitura por
pessoas com pouco conhecimento em bancos de dados. Ao final, espera-se
que o leitor tenha uma melhor compreensão dessas tecnologias, bem como
conheça mais os principais detalhes a se considerar na escolha de tais
produtos.
1. Introdução
A popularização crescente da Internet, a partir da década de 1990, provocou o
surgimento de uma nova classe de aplicações de rede que vai muito além da publicação
e leitura de conteúdo online. O uso que tais aplicações faz da rede mundial vem
crescendo num ritmo muito forte desde então. Para dar suporte a esse crescimento, as
tecnologias de rede também evoluíram extraordinariamente, tanto em hardware quanto
em software. Duas das mais importantes destas tecnologias são a computação em
nuvem (do inglês, cloud computing) e os bancos de dados NoSQL (do inglês, Not only
SQL databases).
2. Computação em Nuvem (Cloud Computing)
A computação em nuvem consiste num conjunto de tecnologias integradas que faz uso
da virtualização para emular hardware e apresentar um ambiente compatível com as
necessidades específicas de cada solução de software que se deseje implantar. Essa
personalização do ambiente computacional possibilita um melhor uso do hardware,
aumentando a capacidade dos fornecedores de aplicativos em oferecer mais software
com menos hardware.

2. Através da virtualização, o gerenciamento do hardware fica muito mais
facilitado, permitindo a configuração de ambientes sofisticados, envolvendo redes e
servidores, com um clique de mouse.
Algumas empresas se especializaram para oferecer hardware virtualizado como
serviço. Esse tipo de produto é conhecido como IAAS1 (do inglês, Infrastructure as a
Service). A mais notável é, sem dúvida, a Amazon2, uma empresa americana pioneira na
venda desse tipo de serviço. As tecnologias utilizadas pela Amazon para fornecer IAAS
são tão prevalentes que seus concorrentes utilizam os mesmos protocolos3 para fornecer
produtos compatíveis.
3. Bancos de Dados SQL
Bancos de dados é um tópico extenso da ciência da computação que vem evoluindo
desde a década de 1970. O processo de estruturar informação, armazená-la para
posterior recuperação é, por si só, um campo de estudo a parte. Nesse trabalho, apenas
referenciamos os produtos de banco de dados conhecidos como tradicionais, sem entrar
em maiores detalhes.
Tais produtos compartilham entre si duas características principais: o uso da
linguagem SQL4 para manipulação dos dados e o suporte das propriedades ACID5 no
acesso e armazenamento dos dados.
Dentre os bancos de dados tradicionais podemos listar os seguintes: MySQL,
PostgreSQL, Oracle, SQLite, SQL Server e DB2. Estes produtos são populares e
comumente encontrados em conteúdo ou projetos disponíveis na Internet.
3.1. Uso de banco de dados SQL em nuvens computacionais
É difícil encontrar fontes confiáveis que contabilizem o uso de bancos de dados em
nuvens computacionais, mas é sugestivo dizer que MySQL seja, provavelmente, o
banco tradicional mais usado em tais ambientes. Isso se deve ao fato de MySQL possuir
uma enorme gama de opções em escalabilidade horizontal, bem como inúmeros ajustes
de performance, com vários fornecedores independentes.
Escalar bancos tradicionais em nuvens, ou seja, aumentar a capacidade do banco
através da adição de máquinas virtuais, traz consigo um custo de gerenciamento
considerável. Esse custo é tão impactante que força desenvolvedores de soluções a
repensarem as opções de persistência, fazendo melhor uso das estruturas de dados e, até
mesmo, criando soluções específicas de armazenamento por aplicação.
4. Bancos de Dados NoSQL
A computação em nuvem trouxe consigo a necessidade de rever as opções em
persistência de dados. Os bancos de dados SQL, antes tratados como a bala de prata do
armazenamento de dados já não são capazes de responder às demandas de performance,
1 http://pt.wikipedia.org/wiki/Computação_em_nuvem#Tipologia
2 http://www.amazon.com/
3 http://aws.amazon.com/pt/
4 http://pt.wikipedia.org/wiki/SQL
5 http://pt.wikipedia.org/wiki/ACID

3. escalabilidade e flexibilidade das aplicações modernas. Essa deficiência levou ao
surgimento de um movimento da indústria que rompeu com o padrão SQL e criou
inúmeras soluções de armazenamento na tentativa de alcançar melhores resultados em
persistência.
Tais soluções foram, em grande parte, motivadas pelas nuvens computacionais
porque os bancos de dados tradicionais não foram projetados para executar em
máquinas virtualizadas. Ao contrário, as otimizações desses bancos pressupõem um
ambiente vertical [Nascimento, Rosa, Porto e Soares 2013], que faz uso do máximo de
recursos de CPU, memória e armazenamento que o hardware hospedeiro dispuser.
Na nuvem, frequentemente, o hardware alocado é maximizado no requisito alvo
da solução de software, liberando os demais recursos para outras máquinas virtuais com
outros fins. Por exemplo, uma solução de cache para pequenas porções de dados
frequentemente acessadas demanda muito mais memória em RAM (acesso rápido) que
em disco; para tal solução, o hardware virtualizado poderia ser alocado com mais
memória RAM e memória em disco suficiente apenas para inicializar o sistema.
Entretanto, seria necessário medir se o banco de dados escolhido para a aplicação teria a
performance exigida em tal configuração.
Além de otimizações para a nuvem, problemas de escalabilidade, tolerância a
falhas e performance insuficiente levaram ao surgimento de uma miríade de produtos
conhecidos por romper com parâmetros sagrados da teoria de bancos de dados, tais
como ACID e SQL. Esses produtos vieram compor uma nova classe de banco de dados,
conhecida como NoSQL, responsável por fazer funcionar grandes players da Internet,
tais como Google, Amazon, Facebook e Twitter.
4.1. Conceito de NoSQL
Não existe um consenso sobre o que é um banco de dados NoSQL. Provavelmente o
mais aceitável é o que se considera NoSQL as soluções de armazenamento e
manipulação de dados projetadas sem o compromisso de suportar a linguagem SQL e as
propriedades ACID que consagraram os bancos de dados tradicionais.
5. Tipos de bancos de dados NoSQL
Para alcançar resultados melhores que os bancos tradicionais, os projetistas de bancos
de dados NoSQL optaram pelo descompromisso com padronização na implementação
de seus produtos, visando atender suas expectativas de armazenamento. Essa liberdade,
gerou uma larga lista de produtos de bancos de dados heterogêneos, difícil de
categorizar e comparar. Christof Strauch coletou uma série de taxonomias de bancos
NoSQL [Strauch 2011] a partir de várias fontes. Para esse trabalho, decidimos
classificar apenas quanto a estruturação e manutenção da informação armazenada.
5.1. Estruturação dos dados armazenados
Ao armazenar a informação, os bancos de dados SQL estruturam a informação em
tabelas e linhas. Em contrapartida, os modelos NoSQL normalmente usam outros
formatos, mais adequados em atingir os objetivos de performance ou escalabilidade.

4. • Chave-valor – do inglês, key-value. Bancos que suportam esse tipo de
armazenamento oferecem o máximo de simplicidade e velocidade na gravação e
recuperação das informações. Podem ser uma boa opção se a aplicação vai lidar
com dados simples, como por exemplo, arquivos, ou imagens. Alguns exemplos
de produtos são: Redis, Riak, DynamoDb, Google LevelDB, Amazon
SimpleDB, Project Voldemort, Oracle NoSQL Database Key Value Pairs, além
de outros.
• Documental – do inglês, document store. Os produtos que suportam esse tipo de
armazenamento já estruturam a informação em um nível acima aos de
chave-valor. Possibilitando recursos de recuperação mais elaborados, como por
exemplo, buscas textuais complexas. Alguns exemplos são: MongoDB,
CouchDB, Cassandra, Hypertable, HBase, além de outros.
• Grafos – Estruturam a informação na forma de um grafo, possibilitando a
recuperação de informações complexas com uma linguagem muito simples. Por
exemplo, uma rede social, com vários tipos de relacionamentos pode ser
facilmente armazenada em um grafo social, possibilitando consultas do tipo:
quem se interessa (facebook like) pelos produtos que X comentou na linha do
tempo da empresa Y. Alguns exemplos são: Neo4J, Twitter FlockDB,
VertexDB, InfinityGraphDB, InfoGrid, além de outros.
Exitem vários outros tipos de estruturação de dados, mais e menos complexos.
Porém, nos concentramos nos mais populares.
5.2. Manutenção e recuperação da informação
Quanto a manutenção da informação armazenada os bancos NoSQL são bastante
flexíveis, podendo suportar várias configurações num mesmo produto.
• Em memória – A redução do custo das memórias RAM provocou o surgimento
de alguns bancos que armazenam a informação em disco apenas para garantir
sua durabilidade, enquanto que toda a manipulação ocorre em memória. Toda a
massa de dados é carregada na memória antes assim que o banco inicia. Tais
produtos são extraordinariamente rápidos e oferecem o máximo de performance
no acesso aos dados. A limitação é, naturalmente, a quantidade de memória que
a máquina virtualizada tem. Alguns produtos, como o Redis, por exemplo,
podem utilizar a memória de mais de uma máquina virtual e permitir alguma
escalabilidade. Alguns exemplos são: Redis, Memcache, MemcacheDB,
Scalaris, Aerospike, além de outros.
• Em disco (HD e SSD) – Outra classe de produtos, prefere armazenar as
informações gravadas em disco, seja HD ou SSD. A maioria dos bancos NoSQL
observados para esse trabalho fazem um esforço enorme para obter o máximo de
performance na gravação e recuperação das informações em disco ou SSD. Por
exemplo, o banco Cassandra, ao gravar um registro, primeiro grava
sequencialmente (evitando provocar o deslocamento da cabeça do disco) o
registro em disco, depois envia os dados para a memória e ordena

5. adequadamente. Posteriormente, um outro processo reorganiza a informação e a
grava definitivamente num arquivo imutável no disco. Outros produtos, como o
MongoDB, por exemplo, preferem apostar que o disco é um item que não falha
frequentemente e, por causa disso, grava sempre em memória para ter mais
performance e, de tempos em tempos, grava a memória no disco. São várias as
técnicas utilizadas pelos bancos NoSQL para alcançar seus objetivos em termos
de gravação, de modo que é necessário fazer uma análise caso a caso para
selecionar a melhor opção a partir da aplicação alvo. Alguns exemplos:
MongoDB, Riak, Amazon SimpleDB, Google LevelDB, etc.
6. Conclusão
Os bancos de dados NoSQL são a resposta da indústria às deficiências de performance,
escalabilidade e complexidade dos bancos SQL tradicionais. Eles romperam com ACID
na busca por seus objetivos, sejam maior performance, maior escalabilidade ou maior
simplicidade.
As nuvens computacionais colaboraram para que o movimento NoSQL
acontecesse ao salientar as deficiências dos bancos tradicionais em máquinas
virtualizadas.
É importante salientar que os bancos SQL ainda são a principal opção para
desenvolvedores, principalmente para aplicações críticas, onde as propriedades ACID e
operações transacionais são necessárias. Ainda que haja NoSQL ACID ou transacionais,
a linguagem SQL é um padrão de fato que persiste fortemente.
As soluções de bancos de dados NoSQL trazem benefícios reais quando
aplicadas adequadamente.
Embora estas soluções sejam difíceis de comparar porque são muito
especializadas, cabe aos projetistas, desenvolvedores ou implantadores calcular os prós
e contras da utilização das mesmas em suas aplicações.
Referências
Costa, R. e Costa, T., (2012). SQL e NoSQL Escalabilidade em Data Stores. DCC -
Faculdade de Ciências da Universidade do Porto.
C. Strauch, (2011). NoSQL Databases. Stuttgart Media University. Disponível em:
http://www.christof- strauch.de/nosqldbs.pdf.
Nascimento Jr, A. J., Rosa, P. F., Porto, I. O. e Soares, M. dos S., (2013). Padrões e
diretrizes arquiteturais para escalabilidade. FACOM-UFU.
Naito, D. da S. e Rosa, E. V., (2010). Monografia de Graduação sob o título "Utilização
de Banco de Dados em Computação nas Nuvens". Faculdade de Tecnologia de São
José dos Campos.
Chang, F., Dean, J., Ghemawat, S., Hsieh, W. C., Wallach, D. A., Burrows, M.,
Chandra, T., Fikes, A., Gruber, R. E., (2006). Bigtable: A Distributed Storage
System for Structured Data. Communications of the ACM.

6. DeCandia, G., Hastorun, D., Jampani, M., Kakulapati, G., Lakshman, A., Pilchin, A.,
Sivasubramaninan, S., Vosshall, P. e Vogels, W., (2007). Dynamo: Amazon’s Highly
Available Key-value Store. Amazon.com
Corbett, J. C., Dean, J., Epstein, M., Fikes, A., Frost, C., Furman, J., Ghemawat, S.,
Gubarev, A., Heiser, C., Hochschild, P., Hsieh, W., Kanthak, S., Kogan, E., Li, H.,
Lloyd, A., Melnik, S., Mwaura, D., Nagle, D., Quinlan, S., Rao, R., Rolig, L., Saito,
Y., Szymaniak, M., Taylor, C., Wang, R. e Woodford, D., (2012). Spanner: Google’s
Globally-Distributed Database. Google, Inc.
NoSQL databases [online]. Disponível em: http://nosql-database.org. Acessado em
Junho de 2013.
Redis database [online]. Diponível em: http://redis.io. Acessado em Junho de 2013.
MongoDB database [online]. Disponível em: http://www.mongodb.org. Acessado em:
Junho de 2013.
Riak database [online]. Disponível em: http://basho.com/riak. Acessado em: Junho de
2013.
MySQL database [online]. Disponível em: http://www.mysql.com. Acessado em: Junho
de 2013.
Oracle database [online]. Disponível em: http://www.oracle.com/br/products/database.
Acessado em Junho de 2013.
PostgreSQL database [online]. Disponível em: http://www.postgresql.org. Acessado em
Junho de 2013.
SQLite database [online]. Disponível em: http://www.sqlite.org. Acessado em Junho de
2013.
IBM DB2 database [online]. Disponível em: http://www.ibm.com/software/data/db2.
Acessado em Junho de 2013.
Amazon DynamoDB [online]. Disponível em: http://aws.amazon.com/pt/dynamodb.
Acessado em Junho de 2013.
Google LevelDB database [online]. Disponível em: http://code.google.com/p/leveldb.
Acessado em Junho de 2013.
Amazon SimpleDB [online]. Disponível em: http://aws.amazon.com/pt/simpledb.
Acessado em Junho de 2013.
Project Voldemort [online]. Disponível em: http://www.project-voldemort.com.
Acessado em Junho de 2013.
Oracle NoSQL Database Key Value Pairs [online]. Disponível em:
www.oracle.com/technetwork/database/nosqldb/overview. Acessado em Junho de
2013.
CouchDB database [online]. Disponível em: http://couchdb.apache.org. Acessado em
Junho de 2013.