Banco de Dados para Big Data

Prévia do material em texto

Indaial – 2020
Banco de dados 
para Big data
Prof. Geomar André Schreiner
1a Edição
Copyright © UNIASSELVI 2020
Elaboração:
Prof. Geomar André Schreiner
Prof. Daniel dos Santos Brandão
Prof. Fabiano Berlinck Neumann
Prof.ª Mariana Araújo Pereira
Este livro foi feito com a parceira com a Sagah
Revisão, Diagramação e Produção:
Centro Universitário Leonardo da Vinci – UNIASSELVI
Ficha catalográfica elaborada na fonte pela Biblioteca Dante Alighieri 
UNIASSELVI – Indaial.
Impresso por:
S378b
 Schreiner, Geomar André
 Banco de dados para big data. / Geomar André Schreiner. – Indaial: 
UNIASSELVI, 2020.
 206 p.; il.
 ISBN 978-65-5663-123-3
 ISBN Digital 978-65-5663-117-2
1. Big data. - Brasil. 2. Banco de dados. – Brasil. Centro Universitário 
Leonardo Da Vinci.
CDD 004
III
apresentação
Caro acadêmico!
No decorrer deste material exploraremos as diferentes facetas dos 
problemas e soluções para armazenar e manipular grandes quantidades de 
dados. Consideramos Big Data uma grande quantidade de dados que são 
acessadas ou inseridas constantemente por diversas fontes. Bancos de Dados 
Relacionais são utilizados há décadas para armazenar e consultar dados de 
maneira segura e confiável. No entanto, com o surgimento do Big Data, os 
bancos de dados relacionais foram colocados em xeque, já que foram desen-
volvidos em um contexto de armazenamento diferente e não são adequados 
para os novos requisitos que tais dados exigem. 
Dessa forma, é natural que novas soluções emergissem para tratar 
de problemas que o modelo relacional de dados não é mais capaz de tratar. 
Nesse sentido, esses novos modelos surgem com o intuito de tratar proble-
mas que o modelo de dados relacional não é adequado para tratar, e não para 
substituir esses BDs. Vários novos BDs foram surgindo nos últimos anos, 
assim como arquiteturas capazes de lidar com as características do Big Data. 
Neste livro didático, estudaremos as características dessas novas soluções 
para entendermos quando e como devemos utilizá-las. 
O livro de Banco de Dados para Big Data está dividido em três unida-
des. A Unidade 1 apresenta conceitos gerais sobre bancos de dados NoSQL 
(Not Only SQL), a descrição das principais famílias, bem como a descrição de 
cada uma delas. Na Unidade 2, estudaremos o papel do particionamento de 
dados e das arquiteturas distribuídas frente aos desafios impostos por cená-
rios de Big Data. Por fim, a Unidade 3 apresenta o conceito de sharding e seu 
papel na distribuição e processamento de dados semiestruturados.
Aproveitamos a oportunidade para destacar a importância de desen-
volver as autoatividades, lembrando que essas atividades não são opcionais. 
Elas objetivam a fixação dos conceitos apresentados. Em caso de dúvida na 
realização das atividades, sugerimos que você entre em contato com seu tu-
tor externo ou com a tutoria interna da UNIASSELVI, não prosseguindo as 
atividades sem ter sanado todas as dúvidas que irão surgindo. 
Bons estudos!
IV
Você já me conhece das outras disciplinas? Não? É calouro? Enfim, tanto para 
você que está chegando agora à UNIASSELVI quanto para você que já é veterano, há 
novidades em nosso material.
Na Educação a Distância, o livro impresso, entregue a todos os acadêmicos desde 2005, é 
o material base da disciplina. A partir de 2017, nossos livros estão de visual novo, com um 
formato mais prático, que cabe na bolsa e facilita a leitura. 
O conteúdo continua na íntegra, mas a estrutura interna foi aperfeiçoada com nova 
diagramação no texto, aproveitando ao máximo o espaço da página, o que também 
contribui para diminuir a extração de árvores para produção de folhas de papel, por exemplo.
Assim, a UNIASSELVI, preocupando-se com o impacto de nossas ações sobre o ambiente, 
apresenta também este livro no formato digital. Assim, você, acadêmico, tem a possibilidade 
de estudá-lo com versatilidade nas telas do celular, tablet ou computador. 
 
Eu mesmo, UNI, ganhei um novo layout, você me verá frequentemente e surgirei para 
apresentar dicas de vídeos e outras fontes de conhecimento que complementam o assunto 
em questão. 
Todos esses ajustes foram pensados a partir de relatos que recebemos nas pesquisas 
institucionais sobre os materiais impressos, para que você, nossa maior prioridade, possa 
continuar seus estudos com um material de qualidade.
Aproveito o momento para convidá-lo para um bate-papo sobre o Exame Nacional de 
Desempenho de Estudantes – ENADE. 
 
Bons estudos!
NOTA
V
VI
Olá, acadêmico! Iniciamos agora mais uma disciplina e com ela 
um novo conhecimento. 
Com o objetivo de enriquecer seu conhecimento, construímos, além do livro 
que está em suas mãos, uma rica trilha de aprendizagem, por meio dela você terá 
contato com o vídeo da disciplina, o objeto de aprendizagem, materiais complementares, 
entre outros, todos pensados e construídos na intenção de auxiliar seu crescimento.
Acesse o QR Code, que levará ao AVA, e veja as novidades que preparamos para seu estudo.
Conte conosco, estaremos juntos nesta caminhada!
LEMBRETE
VII
UNIDADE 1 - BANCOS NOSQL ...........................................................................................................1
TÓPICO 1 - BANCOS NOSQL ...............................................................................................................3
1 INTRODUÇÃO .......................................................................................................................................3
2 MOTIVAÇÃO ..........................................................................................................................................3
3 MODELOS DE DADOS ........................................................................................................................9
RESUMO DO TÓPICO 1........................................................................................................................12
AUTOATIVIDADE .................................................................................................................................13
TÓPICO 2 - BANCOS CHAVE-VALOR ..............................................................................................15
1 INTRODUÇÃO .....................................................................................................................................15
2 MODELO DE DADOS E ARQUITETURA .....................................................................................15
3 ATIVIDADE PRÁTICA REDIS ..........................................................................................................20
RESUMO DO TÓPICO 2........................................................................................................................25
AUTOATIVIDADE .................................................................................................................................26
TÓPICO 3 - BANCOS ORIENTADOS A DOCUMENTOS ............................................................27
1 INTRODUÇÃO .....................................................................................................................................27
2 MODELO DE DADOS E ARQUITETURA .....................................................................................28
3 ATIVIDADE PRÁTICA MONGODB ...............................................................................................37
RESUMO DO TÓPICO 3........................................................................................................................42
AUTOATIVIDADE .................................................................................................................................43
TÓPICO 4 - BANCOS ORIENTADOS A COLUNAS.......................................................................45
1 INTRODUÇÃO .....................................................................................................................................45
2 MODELO DE DADOS E ARQUITETURA.....................................................................................46
3 ATIVIDADE PRÁTICA CASSANDRA............................................................................................52
RESUMO DO TÓPICO 4........................................................................................................................56
AUTOATIVIDADE .................................................................................................................................57
TÓPICO 5 - BANCOS ORIENTADOS A GRAFOS ..........................................................................59
1 INTRODUÇÃO .....................................................................................................................................59
2 MODELO DE DADOS E ARQUITETURA .....................................................................................60
3 ATIVIDADE PRÁTICA NEO4J..........................................................................................................64
RESUMO DO TÓPICO 5........................................................................................................................74
AUTOATIVIDADE .................................................................................................................................75
UNIDADE 2 - PARTICIONAMENTO DE BANCO DE DADOS ..................................................77
TÓPICO 1 - PARTICIONAMENTO DE DADOS .............................................................................79
1 INTRODUÇÃO .....................................................................................................................................79
2 DESAFIOS DO BIG DATA .................................................................................................................79
3 LIMITAÇÕES DO PARTICIONAMENTO DE DADOS ..............................................................81
4 BENEFÍCIOS DO PARTICIONAMENTO DE DADOS ...............................................................83
sumário
VIII
5 GERENCIAMENTO DE PARTICIONAMENTO ...........................................................................84
6 DESAFIOS DO PARTICIONAMENTO DE DADOS ...................................................................86
7 ESTRATÉGIA DE PARTIÇÃO ...........................................................................................................87
RESUMO DO TÓPICO 1........................................................................................................................89
AUTOATIVIDADE .................................................................................................................................90
TÓPICO 2 - APLICAÇÕES SIMPLES UTILIZANDO FRAMEWORKS DE BIG DATA ..........93
1 INTRODUÇÃO .....................................................................................................................................93
2 FUNCIONAMENTO DO MAPREDUCE .........................................................................................93
3 INTERFACES PARA UTILIZAÇÃO DO HADOOP MAPREDUCE ..........................................95
4 CONCEITO DO CONTADOR DE PALAVRAS COM MAPREDUCE ......................................96
5 APLICAÇÃO COM O HADOOP MAPREDUCE ...........................................................................97
6 APLICAÇÃO COM O MAPREDUCE NO SPARK ......................................................................100
RESUMO DO TÓPICO 2......................................................................................................................103
AUTOATIVIDADE ...............................................................................................................................104
TÓPICO 3 - OVERVIEW DE FRAMEWORKS DE STREAM DE BIG DATA ...........................105
1 INTRODUÇÃO ...................................................................................................................................105
2 CONHECENDO O SPARK STREAMING ....................................................................................105
3 FLUXOS DISCRETIZADOS (DSTREAMS) ..................................................................................107
4 SPARK STREAMING E OUTROS FRAMEWORKS ...................................................................109
4.1. SPARK STREAMING E SPARK STRUCTURED STREAMING .............................................109
4.2. SPARK STREAMING, APACHE FLINK E APACHE STORM ...............................................110
5 INGESTÃO DE DADOS COM O SPARK STREAMING EM JAVA ........................................112
6 ETAPAS PARA CRIAR UM PROGRAMA COM SPARK STREAMING ................................112
RESUMO DO TÓPICO 3......................................................................................................................117
AUTOATIVIDADE ...............................................................................................................................118
TÓPICO 4 - FRAMEWORKS DE ARMAZENAMENTO NÃO ESTRUTURADOS .................119
1 INTRODUÇÃO ...................................................................................................................................119
2 ECOSSISTEMA HADOOP E HDFS ...............................................................................................119
3 ARQUITETURA ..................................................................................................................................120
4 TOLERÂNCIA A FALHAS ...............................................................................................................121
5 ARMAZENAMENTO EM NUVEM ................................................................................................122
5.1. AMAZON S3 .................................................................................................................................123
5.2 MICROSOFT AZURE STORAGE ................................................................................................124
5.3 GOOGLE CLOUD STORAGE ......................................................................................................125
5.4 IBM CLOUD STORAGE ...............................................................................................................125
6 HDFS ON-PREMISE E ARMAZENAMENTO EM NUVEM .....................................................126
7 OPERAÇÕES SOBRE DADOS NÃO ESTRUTURADOS ..........................................................128
RESUMO DO TÓPICO 4......................................................................................................................130
AUTOATIVIDADE ...............................................................................................................................131
UNIDADE 3 - DADOS SEMI-ESTRUTURADOS E SHARDING ...............................................133
TÓPICO 1 - FRAMEWORKS DE ARMAZENAMENTO SEMIESTRUTURADOS .................135
1 INTRODUÇÃO ...................................................................................................................................135
2 CARACTERÍSTICAS DOS BANCOS DE DADOS NoSQL ......................................................135
3 ONDE GUARDAR DOCUMENTOS E GRAFOS ........................................................................137
4 OPERAÇÕES COM DADOS SEMIESTRUTURADOS ..............................................................140
RESUMO DO TÓPICO 1......................................................................................................................144
AUTOATIVIDADE ...............................................................................................................................145
IX
TÓPICO 2 - SHARDING ......................................................................................................................147
1 INTRODUÇÃO ...................................................................................................................................147
2 O QUE É SHARDING? ......................................................................................................................1473 UTILIZANDO SHARDING EM CLUSTERS ...............................................................................151
3.1 CLUSTER LOCAL E REMOTO ...................................................................................................153
3.2 RELAÇÃO ENTRE SHARDING E ÍNDICES ............................................................................154
3.3 UTILIZANDO ÍNDICES EM BANCOS DE DADOS ................................................................155
RESUMO DO TÓPICO 2......................................................................................................................158
AUTOATIVIDADE ...............................................................................................................................159
TÓPICO 3 - FRAMEWORKS QUE UTILIZAM SHARDING COMO
 FORMA DE DISTRIBUIÇÃO ......................................................................................161
1 INTRODUÇÃO ...................................................................................................................................161
2 ARQUITETURA DO SHARDING ..................................................................................................161
3 SHARDING BASEADO EM HASH ...............................................................................................164
4 SHARDING BASEADO EM INTERVALOS .................................................................................165
5 SHARDING BASEADO EM DIRETÓRIO....................................................................................165
6 FRAGMENTAÇÃO NO APACHE CASSANDRA .......................................................................166
7 HASH CONSISTENTE ......................................................................................................................168
8 FRAGMENTAÇÃO NO MONGODB ............................................................................................170
RESUMO DO TÓPICO 3......................................................................................................................185
AUTOATIVIDADE ...............................................................................................................................186
REFERÊNCIAS .......................................................................................................................................189
X
1
UNIDADE 1
BANCOS NOSQL
OBJETIVOS DE APRENDIZAGEM
PLANO DE ESTUDOS
A partir do estudo desta unidade, você deverá ser capaz de:
• conhecer a motivação para o surgimento dos Banco de Dados (BDs) NoSQL;
• caracterizar de maneira geral os BDs NoSQL e suas principais diferenças para 
o modelo relacional;
• apresentar os diferentes modelos de BDs NoSQL;
• dialogar sobre os diferentes modelos de dados de BDs NoSQL e suas 
aplicações.
Esta unidade está dividida em cinco tópicos. No decorrer da unidade 
você encontrará autoatividades com o objetivo de reforçar o conteúdo 
apresentado.
TÓPICO 1 – BANCOS NOSQL
TÓPICO 2 – BANCOS CHAVE-VALOR
TÓPICO 3 – BANCOS ORIENTADOS A DOCUMENTOS
TÓPICO 4 – BANCOS ORIENTADOS A COLUNAS
TÓPICO 5 – BANCOS ORIENTADOS A GRAFOS
Preparado para ampliar seus conhecimentos? Respire e vamos 
em frente! Procure um ambiente que facilite a concentração, assim absorverá 
melhor as informações.
CHAMADA
2
3
TÓPICO 1
UNIDADE 1
BANCOS NOSQL
1 INTRODUÇÃO
Os Bancos de Dados (BDs) sempre tiveram um lugar de destaque em se 
tratando de sistemas da computação, porém, atualmente, com as grandes quan-
tidades de dados a serem armazenados (Big Data), os BDs ganham ainda mais 
destaque (STONEBRAKER, 2012). Praticamente, todas as aplicações acessadas 
utilizam algum meio de armazenamento de dados. Durante décadas, os dados fo-
ram armazenados através do modelo relacional de dados. Com o surgimento da 
Web e a popularização da internet, cada vez mais pessoas utilizam as aplicações 
de maneira on-line, trazendo à tona os limites do modelo relacional.
 
Com essa motivação foram surgindo novos modelos de dados com foco 
na grande escalabilidade e alta disponibilidade dos sistemas, criando um novo 
paradigma de armazenamento de dados (CATTELL, 2011). Esse novo paradigma 
de armazenamento foi batizado de NoSQL (Not Only SQL). Esses BDs não se-
guem o modelo de dados relacional, propondo novas formas de armazenamento 
(BERMAN, 2013). 
No decorrer desta unidade, iremos explorar o paradigma de BDs não rela-
cionais, apresentando de maneira mais detalhada a motivação para o surgimento 
desses novos BDs. Desse modo, suas principais características serão exploradas e 
comparadas com as do já conhecido modelo relacional de armazenamento. Além 
disso, serão apresentados os novos modelos de dados e quais as principais carac-
terísticas de cada um deles.
2 MOTIVAÇÃO
Em geral, BDs relacionais são utilizados há décadas em grande escala 
para o armazenamento e manipulação eficiente dos mais variados domínios de 
aplicação (SADALAGE; FOWLER, 2019). O modelo relacional de dados foi pro-
posto por Edward Codd em 1970. Nesse sentido, o modelo de dados relacional é 
baseado em uma abstração sobre os dados que definem uma estrutura de entida-
des (tabelas) e seus relacionamentos.
Como você já deve saber, grande parte do sucesso do modelo relacional 
deve-se à padronização imposta por ele e de sua poderosa linguagem de consul-
tas: a SQL (Structured Query Language) (SILBERSCHATS; KORTH; SUDARSHAN, 
2012). A linguagem SQL é baseada na teoria de conjuntos e permite que o usuário 
UNIDADE 1 | BANCOS NOSQL
4
manipule os dados a fim de obter os resultados desejados. Graças ao modelo de 
dados relacional e à SQL, todos os BDs relacionais compartilham diversas carac-
terísticas. Dessa forma, aprendendo os fundamentos sobre o modelo relacional e 
a SQL somos capazes de utilizar as ferramentas de qualquer Sistema Gerenciador 
de Banco de Dados (SGBD) relacional. Cada SGBD possui suas peculiaridades e 
seu dialeto de SQL, porém, como dito, todos possuem uma mesma base.
Outra característica importante do modelo relacional, compartilhada pe-
los SGBDs, é a possibilidade de o usuário executar transações. Uma transação 
é uma série de operações consideradas críticas que devem ser executadas com 
um bloco único e indivisível (bloco atômico) (SILBERSCHATS; KORTH; SUDAR-
SHAN, 2012). Essas operações devem ser executadas em sua totalidade. Assim, 
caso algum erro ocorra durante a execução uma transação, esta deve falhar e as 
operações que já haviam sido executadas com êxito devem ser desfeitas. 
Imagine a seguinte situação: você está sacando seu dinheiro de um caixa 
eletrônico. A operação de saque é uma transação que será executada no sistema do 
seu banco, que possivelmente é um BD relacional. Você passa algumas informações 
e, através delas, algumas operações serão executas para que o caixa eletrônico lhe 
dê seu dinheiro. De maneira geral, o sistema executará as seguintes operações:
(i) validar suas informações pessoais (conta, agência e senha);
(ii) verificar seu saldo;
(iii) se o saldo for suficiente, reduzir o montante do saque do saldo atual;
(iv) salvar o novo saldo;
(v) efetivar o saque liberando o dinheiro. 
Agora, imagine que entre os passos (iv) e (v) falte energia, desse modo, a 
transação teria retirado o dinheiro do saque de sua conta, porém o caixa eletrônico 
não iria mais liberar o dinheiro já que a transação terminou. Erros desse tipo 
não podem ser tolerados em uma instituição financeira, bem como em outras 
aplicações. Dessa forma, todo banco relacional deve possuir suporte às transações 
compatíveis com as propriedades ACID (Atomicidade, Consistência, Isolamento 
e Durabilidade) (SILBERSCHATS; KORTH; SUDARSHAN, 2012).
Cada uma das propriedades ACID garantem que o comportamento das 
transações em um BD relacional seja sempre o mesmo (ABADI, 2009). Cada letra 
da sigla ACID tem o seguinte significado:
• A: a propriedade de atomicidade deve garantir que a transação seja executada 
como um todo, ou seja, caso exista uma falha,as operações executadas devem 
ser desfeitas (rollback). 
• C: a consistência assegura que os dados respeitem as restrições de integridade 
criadas pelo usuário (tipos de dados, chaves primárias, chaves estrangeiras, 
entre outras). 
• I: o isolamento garante que as transações sejam executadas em paralelo, sem 
que nenhuma afete a execução da outra, normalmente essa propriedade é im-
plementada através de locks e latches.
TÓPICO 1 | BANCOS NOSQL
5
• D: a propriedade de durabilidade diz respeito ao armazenamento efetivo das 
informações, ou seja, o resultado das operações da transação deve ter sido ar-
mazenado no disco para que a transação seja efetivada.
As propriedades ACID são um dos principais atrativos dos BDs relacio-
nais, porém elas acarretam em processamento extra. Por exemplo, a propriedade 
de atomicidade necessita de logs e outros mecanismos para permitir, caso ne-
cessário, que o sistema realize um rollback. Já a propriedade isolamento acarreta 
operações de locks, que deixam outras transações (usuários) esperando sua vez 
para acessar aos recursos.
Os BDs Relacionais foram criados, como vimos, há décadas e sua essên-
cia continua a mesma. Ao longo dos anos, o paradigma foi sendo modificado, 
algoritmos melhorados e novas funcionalidades foram sendo desenvolvidas. No 
entanto, sua arquitetura com crescimento vertical (para melhorar o sistema, deve 
ser melhorado o hardware) e operações baseadas em disco (todas as transações 
dependem da gravação no disco para obterem êxito) permanecem inalteradas 
(STONEBRAKER, 2012).
Com o surgimento da Web, muitas demandas mudaram. Atualmente, 
muitas aplicações necessitam lidar com grandes quantidades de dados que, 
geralmente, caracterizam-se por serem heterogêneos e não possuírem um es-
quema bem definido. Esses dados são comumente denominados de Big Data 
(BERNAN, 2013). 
Em termos gerais, Big Data são grandes quantidades de dados gerados 
com certa velocidade por fontes diferente, esse conceito será melhor descrito na 
Unidade 3. Apesar de os BDs relacionais serem usados há décadas como meio 
seguro de armazenamento, eles se mostram ineficientes para o gerenciamento 
de Big Data (STONEBRAKER, 2012). Isso se deve principalmente pelo compro-
metimento do desempenho com verificações de consistência dos dados, proces-
samento de consultas complexas, manutenção das propriedades ACID, entre 
outras, e a representação rígida e estruturada dos dados através de esquemas 
(ABADI, 2009).
Locks e Latches são importantes mecanismos de controle dos Bancos de 
Dados. Locks são estruturas lógicas utilizadas pelo SGBD para manter a consistência entre 
transações, não permitindo que duas transações escrevam o mesmo dado. Latches são 
bloqueios criados sobre estruturas de dados físicas armazenadas no disco. 
IMPORTANT
E
UNIDADE 1 | BANCOS NOSQL
6
Dessa forma, para suprir os requisitos impostos pelo processamento de 
Big Data, novas arquiteturas de BDs foram propostas (STONEBRAKER, 2012). 
Geralmente, essas novas arquiteturas utilizam recursos de alta disponibilidade 
e escalabilidade atrelados ao paradigma da computação na nuvem, paradigma 
baseado na capacidade de processamento e armazenamento de grandes volumes 
de dados por centros distribuídos geograficamente (ABOUZEID, 2009). 
A quantidade de dados gerados, armazenados e processados atingiu es-
calas inéditas com a Web 2.0, a partir disso nasceram os chamados BDs NoSQL 
(DIANA; GEROSA, 2010). Perceba que estamos falando em um contexto especí-
fico, todas as aplicações, pelo menos a maioria, utilizavam o modelo relacional 
de dados, conforme o volume e a variedade dos dados foi aumentando, o mo-
delo relacional começou a apresentar alguns problemas dada sua natureza de 
processamento. 
Os desenvolvedores começaram a questionar o uso de uma estrutura tão 
rígida para o armazenamento de dados, sendo que algumas aplicações não neces-
sitam dessa rigidez. Aliado a isso, ainda temos o fato de que a escalabilidade do 
modelo relacional é baseada no crescimento vertical (escalonamento vertical), ou 
seja, a melhora do desempenho do SGBD pode ser efetuada acrescentando mais 
recursos ao servidor, o que torna o processo caro.
Escalabilidade horizontal: consiste em adicionar uma nova máquina no clus-
ter, visando aumentar a capacidade do sistema distribuído.
Escalabilidade vertical: trata-se do upgrade em um servidor já existente na rede, podendo ser 
a substituição, a reposição ou a adição de novos recursos, como memória ou discos rígidos.
FONTE: <https://bit.ly/2X5p0uD>. Acesso em: 28 mar. 2020.
NOTA
Considerando os pontos falhos dos BD relacionais, os BDs NoSQL 
foram propostos como BDs essencialmente distribuídos, que são baseados no 
crescimento horizontal (escalonamento horizontal). Desse modo, para melhorar 
o desempenho do sistema, o usuário pode adicionar máquinas ao conjunto que 
compõe o BD (cluster). 
Na construção do cluster, máquinas um pouco mais antigas que estavam 
em desuso podem ser utilizadas para melhorar o desempenho do SGBD. Esses 
novos BDs podem ser definidos como BDs que não seguem o modelo relacional 
de dados e possuem seis propriedades (CATELL, 2011):
TÓPICO 1 | BANCOS NOSQL
7
I. Escalonamento horizontal. 
II. Armazenamento de dados complexos de maneira distribuída.
III. Interface de acesso ou protocolo de acesso simples para manipulação dos 
dados.
IV. Sem suporte ou relaxamento das propriedades ACID.
V. Alta disponibilidade.
VI. Esquema flexível ou até ausência de esquema.
No entanto, é importante compreender que não se trata de afirmar que os 
BDs NoSQL são perfeitos e vieram para substituir os BDs relacionais, pelo contrário, 
os BDs são na verdade complementares. Os BDs NoSQL surgiram para suportar re-
quisitos que o modelo relacional não conseguia, porém eles não tratam do mesmo 
tipo de problema. Como dito, os BDs NoSQL não possuem suporte da ACID, assim, 
não podem ser utilizados em ambientes que necessitam de transações.
O termo NoSQL, da forma que é conhecido atualmente, surgiu em 2009 
cunhado por Johan Oskarsson (SADALAGE; FOWLER, 2019). Na época, o surgi-
mento do Big Table (desenvolvido pela Google) e Dynamo (desenvolvido pela Ama-
zon) com suas arquiteturas distribuídas, baseadas em alta disponibilidade e cres-
cimento horizontal, inspiraram o surgimento de diversos projetos de BDs NoSQL. 
Esses projetos já eram discutidos em algumas conferências, mas Johan 
queria conhecer mais sobre o assunto, discutindo suas vantagens e desvantagens. 
Desse modo, pensou na época em organizar uma “reunião” para discutir essas 
novas tecnologias de BDs não relacionais. Johan precisava de um nome para esse 
encontro, e através de um canal de IRC (Internet Relay Chat) do banco de dados 
Cassandra pediu sugestões. O nome NoSQL foi sugerido por Eric Evans e foi 
adotado de imediato (SADALAGE, 2012). 
O termo NoSQL, apesar de ter um impacto negativo por ser visto como a 
negação do SQL, resume bem os BDs desenvolvidos para esse movimento. Vale 
ressaltar também que não existe uma descrição formal para os BDs NoSQL, desse 
modo, para caracterizar um banco como NoSQL, devemos observar as caracterís-
ticas citadas anteriormente.
Como esses BDs não seguem o modelo relacional, a linguagem de consul-
ta SQL não é aplicável a eles (CATTELL, 2011). Assim, não existe um padrão de 
consulta que possa ser utilizado em todos os BDs NoSQL, cada um possui uma 
forma diferente de consulta (SOTENEBREAKER, 2012). 
O BD NoSQL Cassandra, por exemplo, possui uma linguagem de consul-
ta própria denominada de CQL (Cassandra Query Language). Essa linguagem de 
consulta se assemelha em muitos aspectos ao SQL, porém não possui a mesma 
expressividade, e o tratamento das informações se dá de forma diferente já que o 
Cassandra utiliza um modelo de dados diferente.
Outro exemplo de linguagem de consulta é o MongoDB (Figura 1). No 
exemplo é visto uma consulta sendo realizada tanto em linguagem SQL, bem 
UNIDADE 1 | BANCOS NOSQL
8
como utilizando o MongoDB. O MongoDB é um NoSQLmuito conhecido, e sua 
linguagem de consulta é baseado em documentos JSON. No decorrer dos nossos 
estudos, vamos aprender mais sobre o MongoDB e sua linguagem de consulta. No 
entanto, como pode ser observado, ela se difere consideravelmente do padrão SQL.
FIGURA 1 – MAPEAMENTO SQL PARA LINGUAGEM DO MONGODB
FONTE: O autor
Na Figura 1 (A), a tabela pessoas é mapeada para a coleção de documentos 
“pessoas” do Mongo – Figura 1 (B). Perceba também que a seleção da SQL (WHE-
RE) é mapeado para o primeiro parâmetro do “fi nd”. Mais detalhes sobre a lingua-
gem de consulta do MongoDB serão apresentados no Tópico 3 desta Unidade. 
O mais próximo de um padrão de consulta que os BDs NoSQL possuem 
é o engajamento da comunidade – de desenvolvedores – de prover acesso aos 
dados através de uma API (Application Programming Interface) de acesso baseada 
em REST (Representational State Transfer). A API REST defi ne um gerenciamento 
de dados unifi cado através da Web, utilizando as interfaces de acesso get, put, 
delete e post. No entanto, é importante ressaltar que isso não pode ser considerado 
um padrão, já que alguns BDs NoSQL não têm acesso via REST. Essa falta de pa-
dronização se deve ao fato de não existir um conceito totalmente fechado acerca 
deste paradigma. Como já dito, defi nimos se o BD é ou não um NoSQL baseado 
em um conjunto de propriedades. 
Para entender um pouco mais sobre o conceito de API REST confi ra o artigo O 
que é API? REST e RESTful? Conheça as defi nições e diferenças! que está disponível em: 
https://becode.com.br/o-que-e-api-rest-e-restful/. 
DICAS
TÓPICO 1 | BANCOS NOSQL
9
Agora conhecemos a motivação para o surgimento dos BDs NoSQ e 
também as principais funcionalidades que um BD NoSQL deve possuir. Além 
disso, sabemos que os BDs NoSQL não seguem o modelo relacional. Já que 
não seguem, qual o modelo de dados que os NoSQL possuem? O que é um 
modelo de dados afinal? Essas perguntas são de suma importância para um bom 
entendimento dos BDs NoSQL e serão respondidas no próximo tópico.
 
3 MODELOS DE DADOS
Um modelo de dados pode ser conceituado como uma combinação de 
estruturas para organizar um conjunto de dados (ATZENI; BUGIOTTI; ROSSI, 
2012). Dessa forma, vemos o modelo de dados como a forma com que o BD 
organizará e armazenará seus dados fisicamente. Como você deve estar imagi-
nando, já que o modelo de dados é como o BD organiza seus dados, ele interfere 
diretamente no desempenho do BD. Desse modo, temos que conhecer a fundo 
os modelos de dados existentes e entender qual o mais adequado para cada tipo 
de problema.
Normalmente, somos apresentados ao modelo relacional de dados, 
aprendemos suas abstrações (organização dos dados em tabelas) e como utilizá-
-lo (SQL), e o usamos em todas as situações. Como visto anteriormente, ele não é 
o mais indicado para tratar grandes quantidades de dados. Os BDs NoSQL não 
seguem o modelo relacional e, para variar, não possuem um modelo de dados 
padrão, ou seja, cada BD NoSQL tem seu modelo de dados e suas especificações.
Felizmente, os modelos de dados utilizados na implementação de BDs 
NoSQL podem ser sumarizados em quatro modelos de dados principais: chave-
-valor, orientado a colunas, orientado a documentos e orientado a grafos (SADA-
LAGE; FOWLER, 2019). Dessa forma, qualquer modelo de dados de NoSQL pode 
ser classificado em uma dessas categorias, mesmo que internamente ele trabalhe 
de forma diferente dos demais. 
O modelo de dados chave-valor é o mais simples de todos. Nesse mode-
lo, você apenas dispõe de pares chave-valor como estrutura de armazenamento. 
A chave representa o identificador único para um determinado “valor”. Para a 
maioria dos BDs, a chave pode ser representada por qualquer vetor de caracte-
res (exemplo: “pessoa.1”). O valor, que é atrelado à chave, é um valor atômico 
(indivisível) que pode conter qualquer tipo de dado (outros pares chave–valor, 
um inteiro, entre outros), sendo considerado uma “caixa-preta”. Uma impor-
tante característica desse modelo de dados é que os BDs apenas permitem pes-
quisar pela chave e não pelo valor já que este é uma incógnita e não segue um 
padrão. Apesar de soar estranho não poder realizar busca pelo valor, essa sim-
plificação faz com que a busca por uma chave seja muito rápida. Geralmente, 
a busca por uma chave em um BD chave-valor é O (1), ou seja, com uma única 
operação é encontrada a chave procurada. Sendo assim, é ótimo para pesquisas 
em que se possui a chave, mas não pode ser utilizado para buscas que envolvam 
informações armazenadas no campo de valor.
UNIDADE 1 | BANCOS NOSQL
10
O modelo orientado a colunas é semelhante ao chave-valor. Na verdade, 
podemos dizer que ele é uma especialização do modelo chave-valor. O modelo 
orientado a colunas organiza seus dados com base em uma distribuição por co-
lunas (propriedades), esta organização é mais complexa que a anterior e permi-
te consultas com filtro em valores de colunas. Conforme descrito por Sadalage 
(2012), esse modelo de dados é composto por uma keyspace (base de dados), fa-
mílias de colunas, conjuntos de colunas acessadas com base em uma chave única, 
colunas e seus respectivos valores. Famílias de colunas tem a ideia de agrupar 
colunas que possuam um domínio em comum (exemplo: conjunto de colunas que 
representam pessoas). Cada conjunto de colunas possui uma chave de acesso, 
como se fosse uma chave primária de um BD relacional, e este conjunto repre-
senta um conjunto de características de uma ocorrência (exemplo: informações 
pessoais de uma pessoa). Por fim, cada coluna de um desses conjuntos possui 
um nome e um valor. A principal diferença para o modelo chave-valor é que o 
modelo orientado a colunas permite consultas mais complexas que envolvam o 
valor das colunas.
O modelo de dados orientado a documentos armazena seus dados baseado 
em uma organização de documentos. Ele utiliza o conceito de coleção de docu-
mentos, em que cada documento é acessado também a partir de uma chave única 
e atômica (CATTELL, 2015). Da mesma forma que um objeto em um BD orientado 
a objetos, um documento é composto por uma série de atributos, cujo valor pode 
ser simples ou complexo. Considera-se um atributo simples aquele que possui um 
valor atômico, e um atributo complexo aquele que possui um conteúdo multivalo-
rado ou um conteúdo organizado em uma estrutura, como uma lista, um registro 
ou um conjunto. Esse modelo de dados é basicamente composto por um BD, um 
conjunto de coleções de documentos, documentos, atributos e valores. Assim como 
o modelo colunar, o modelo orientado a documentos permite consultas complexas 
sobre os valores de cada atributo. Adicionalmente, a orientação a documento pos-
sui uma estrutura mais flexível facilitando a inclusão dos dados. 
O modelo de dados orientado a grafos possui uma estrutura de armaze-
namento baseada em grafos de acesso (ABADI, 2009). Geralmente, dizemos que 
os três primeiros modelos de dados são baseados em chave de acesso, pois todos 
compartilham essa noção. O modelo orientado a grafos é consideravelmente dife-
rente dos demais. Sua estrutura, assim como uma estrutura de grafo tradicional, 
é baseada em nós e arestas. Cada nó armazena um nome e uma série de atributos 
e valores. Os nós são conectados por arestas que possuem um nome, e opcional-
mente uma série de atributos e valores. Devido a sua natureza de organização, o 
modelo de grafos é o mais especializado de todos. Ele é muito indicado para mo-
delar relacionamentos entre objetos e para realizar consultas que envolvam esses 
relacionamentos. No entanto, seu uso para o armazenamento de informações que 
não possuam relacionamento é desencorajado, já que o processo de busca no gra-
fo pode se tornar custoso.
Como podemos ver cada um dos modelos de dados possui característi-
cas únicas e aplicações específicas. Claro que nestas poucas linhas não é possível 
TÓPICO 1 | BANCOS NOSQL
11
entender a fundo como cada um desses modelos de dados trabalha e quando de 
fato cada umdeve ser utilizado. Dessa forma, nos próximos tópicos, trataremos 
separadamente de cada um dos modelos de dados, abordando suas característi-
cas principais e quais os problemas que podem ser resolvidos por cada um deles. 
Além disso, para cada modelo de dados que estudaremos, serão realizados al-
guns testes práticos para aprofundar os conceitos.
12
Neste tópico, você aprendeu que:
• Os BDs relacionais foram utilizados durantes anos como fonte segura de 
armazenamento e consulta de dados, porém eles não são adequados para lidar 
com os requisitos impostos pelo Big Data.
• Os BDs NoSQL possuem arquitetura distribuída baseada em alta disponibilidade 
e crescimento horizontal. Eles surgiram para lidar com as demandas que os 
BDs relacionais não eram capazes.
• Os BDs NoSQL não vão acabar com o uso de BDs relacionais, eles tratam de 
problemas diferentes e são complementares.
• Os BDs NoSQL não seguem o modelo relacional de dados e, geralmente, não 
possuem acesso via SQL. Além disso, não existe um padrão de consulta para 
esses BDs.
• Os BDs NoSQL podem ser caracterizados em quatro diferentes modelos de 
dados: chave-valor, orientado a colunas, orientado a documentos e orientado a 
grafos.
RESUMO DO TÓPICO 1
13
1 Considere as seguintes características do projeto de um Banco de Dados:
I- Alta disponibilidade e esquema rígido.
II- Relaxamento das propriedades ACID aliado à alta disponibilidade.
III- Linguagem de consulta padrão.
IV- Escalonamento horizontal.
Sobre as características que os BDs NoSQL possuem, assinale a alternativa 
CORRETA:
a) ( ) I, apenas.
b) ( ) III e IV, apenas.
c) ( ) II e I, apenas.
d) ( ) I, II e IV, apenas.
2 Disserte sobre os motivos que culminaram com o surgimento dos BDs 
NoSQL e quais as estruturas de dados que esses BDs utilizam.
3 O surgimento dos BDs NoSQL diminui de alguma forma a relevância dos 
BDs relacionais?
AUTOATIVIDADE
14
15
TÓPICO 2
BANCOS CHAVE-VALOR
UNIDADE 1
1 INTRODUÇÃO
No tópico anterior, conhecemos a motivação para a criação do 
paradigma NoSQL, discutimos suas características básicas e quais os modelos 
de dados existentes. Como dito anteriormente, é importante que você, como 
bom profissional, consiga entender os modelos de dados e suas aplicações. Dessa 
forma, quando confrontado com uma situação real será capaz de decidir qual o 
modelo de dados mais se adequa aos seus problemas e qual o BD NoSQL (ou 
mesmo relacional) irá usar.
Dentre os quatro modelos de dados dos BDs NoSQL, o chave-valor é 
considerado o mais simples. Apesar desse modelo de dados ser simples, isso não 
implica que ele seja ruim ou possa ser menosprezado. É devido à simplicidade desse 
modelo que ele possui um desempenho excelente, quando utilizado corretamente.
Neste tópico, conheceremos mais a fundo o modelo de dados chave-valor 
e explorar suas principais características entendendo seu funcionamento básico. 
Ao estudar sobre o modelo chave-valor, você terá uma noção de como o modelo 
de dados se comporta, traçando um paralelo com os BDs relacionais. Além disso, 
vamos dar uma olhada no Redis, um BD NoSQL chave-valor, compreendendo 
como ele trabalha, em quais plataformas pode ser utilizado e como é sua 
linguagem de consulta.
2 MODELO DE DADOS E ARQUITETURA
De maneira geral, podemos dizer que um BD chave-valor é uma grande 
tabela de hash, em que cada linha é um par chave-valor (SADALAGE; FOWLER, 
2019). Sendo a chave um identificador único e o valor um conjunto de informações 
visto como atômico (CATTELL, 2011). Sendo assim, ele é muito indicado para 
quando as buscas no BD são por um valor específico e único (uma chave primária). 
O Quadro 1 apresenta um mapeamento simples entre os conceitos básicos 
de um BD relacional com os envolvidos em um banco chave-valor. Perceba 
que um BD relacional pode suporta mais de uma base de dados em uma única 
instalação, porém, geralmente, BDs chave-valor não possuem múltiplas bases de 
dados. O conceito de tabela relacional não se relaciona diretamente com nenhum 
conceito comum a todos os BDs NoSQL chave-valor. Assim, todos os dados 
UNIDADE 1 | BANCOS NOSQL
16
(pares chave-valor) são armazenados diretamente no cluster. Alguns BDs NoSQL, 
como o Redis, criam uma estrutura que se assemelha ao conceito de tabela. Essa 
estrutura é chamada de bucket, porém é encontrada em poucos BDs.
Perceba que os BDs chave-valor apenas permitem consultas nas chaves. As 
consultas sobre os valores se tornariam muito custosas, pois exigem que todos os registros 
sejam analisados. Por isso dizemos que o valor armazenado para uma determinada chave é 
uma caixa-preta: pode possuir qualquer estrutura interna, mas não podemos realizar fi ltros 
nessas estruturas.
IMPORTANT
E
 QUADRO 1 – MAPEAMENTO RELACIONAL PARA CHAVE-VALOR
Banco Relacional NoSQL Chave-Valor
Base de dados Cluster
Tabela (relação) –
Linha (tupla) Par chave-valor
Identifi cador da tupla Chave
FONTE: O autor
Como vimos no Quadro 1, um par chave-valor do modelo é visto como 
uma tupla para o modelo relacional, e o identifi cador de uma tupla, ou mesmo o 
conjunto de chaves primárias de uma determinada tupla, é visto como a chave. 
A Figura 2 apresenta uma visão de um BD NoSQL, o qual possui quatro pares 
chave-valor.
FIGURA 2 − VISÃO DE UM BD CHAVE-VALOR
FONTE: O autor
TÓPICO 2 | BANCOS CHAVE-VALOR
17
Apesar de estarmos traçando este paralelo entre o modelo relacional e 
o chave-valor, é importante ressaltar que eles se diferem em muitos aspectos. 
Mesmo que uma tupla relacional possa ser mapeada para um par chave-valor 
não devemos considerar, necessariamente, esse mapeamento ao criar nossa base 
de dados. A construção, ou definição de uma chave para o BD chave-valor, é 
crítica e deve ser devidamente planejada.
Além disso, sempre é importante manter em mente que o valor armazenado 
pode ser de qualquer tipo. Pode ser um texto puro, um vetor de números, outros 
pares chave-valor e assim por diante. Dessa forma, o valor sempre é visto como 
uma caixa-preta. 
Como vimos anteriormente, em um BD chave-valor, uma chave deve 
ser única e, usualmente, somente são permitidas consultas sobre as chaves e 
não sobre os valores atrelados a elas. Assim, imagine que você foi incumbido de 
projetar um BD chave-valor para armazenar os dados de um BD relacional. Você 
possui duas tabelas: Diretores (id, nome, prêmios) e Filmes (id, nome, diretor – 
chave estrangeira para Diretores –, ano) sendo id a chave primária de ambas as 
tabelas (Figura 3). Considerando essas duas tabelas, imagine que você propõe o 
mapeamento direto de tuplas. Desse modo, chaves primárias serão mapeadas 
para chaves (do par chave-valor) e os dados da tupla serão compactados e 
armazenados no valor (do par chave-valor). O primeiro problema enfrentado é 
que como o atributo id é a chave primária das duas tabelas nada impede que 
exista um id com valor 1 para Filmes e um id com valor 1 para a tabela Diretores. 
Dessa forma, nossa estratégia não funciona.
FIGURA 3 – DB CINEMA
FONTE: O autor
Nesse sentido, a situação proposta trata-se de um problema simples de 
contornar, pois podemos concatenar o valor da chave primária com o nome da 
tabela, eliminando o problema. A Figura 4 apresenta uma visão dessa ideia. 
Perceba que temos as chaves constituídas da concatenação do nome da tabela e 
UNIDADE 1 | BANCOS NOSQL
18
um valor inteiro (que é o valor para o id). Como valor podemos criar um JSON 
com todas as informações da tupla.
FIGURA 4 – MODELO CHAVE-VALOR BD CINEMA
FONTE: O autor
Agora imagine que necessitamos fazer algumas consultas nessa base de 
dados. Por exemplo, realizar a busca de qual ano que o filme The Godfather foi 
lançado. Como já discutimos anteriormente este tipo de consulta não pode ser 
executada em um BD chave-valor. Como você sabe, esses BDs apenas permitem 
a consulta na chave. Sendo assim, não é possível realizar essa consulta. Com 
este modelo apenas poderíamos buscar a informação de um determinado filme, 
por exemplo, mostrar as informações doFilme com id 1, em que buscando pela 
chave ‘filme.1’ é possível obter o valor que nos possibilita mostrar ao usuário. 
Geralmente, esses bancos permitem a execução de expressões regulares para 
busca das chaves. Com isso, poderíamos listar todos os filmes com uma consulta 
do tipo ‘Filmes.*’.
Dessa forma, imaginamos que você está se perguntado para que serve 
este tipo de BD já que não nos possibilita fazer consultas complexas? De fato, 
o uso desse tipo de BD é bem restrito. Normalmente, eles são utilizados para 
realizar algum tipo de cache do sistema. A busca por uma chave neste BD se dá 
em complexidade de O (1) mais rápida do que qualquer índice implementado 
por algum BD relacional. A Oracle utiliza em seu BD relacional um BD chave-
valor (de desenvolvimento próprio) para gerenciar o buffer e otimizar o acesso a 
algumas informações.
TÓPICO 2 | BANCOS CHAVE-VALOR
19
Outra aplicação interessante é a utilização de um BD chave-valor para 
armazenar o carrinho de compras em um e-commerce. Cada acesso de um usuário 
gera um cookie de identificação de seção. Esse identificador pode ser utilizado 
como a chave do par chave-valor. O valor seriam os produtos escolhidos pelo 
cliente, o identificador de cada item e a quantidade de cada item.
A consistência desses BDs é outro ponto que devemos conhecer para ado-
tarmos seu uso. A consistência, como você deve imaginar, é feita de maneira distinta 
de um BD relacional. BDs chave-valor, usualmente, apenas consideram operações 
(inserção, leitura ou exclusão) sobre dados de uma única chave. Cada banco possui 
sua implementação de consistência, mas geralmente estes BDs são conhecidos por 
disponibilizar consistência eventual, ou seja, após a execução de uma determinada 
operação, esta será replicada entre os elementos do cluster, mas essa replicação irá 
demorar um curto espaço de tempo. Em um modelo fortemente consistente (rela-
cional), o usuário esperaria que o dado fosse replicado e então retornaria sucesso. 
Em um BD com consistência eventual não existe essa espera, a operação retorna 
sucesso e eventualmente a replicação seria completa. É importante ressaltar que 
essa janela de inconsistência, enquanto a replicação ocorre, é curta.
Como dito no Tópico 1, BDs NoSQL possuem como uma das suas caracte-
rísticas a escalabilidade horizontal. No caso do BDs chave-valor, a escalabilidade 
se dá baseada em particionamento dos dados, ou seja, cada um dos nós do cluster 
armazena uma partição dos dados. Os dados são particionados baseados no valor 
da chave. Quando novos nós são adicionados ao cluster, eles ficam responsáveis 
por novas partições dos dados, mantendo o balanceamento de carga no sistema 
(SADALAGE; FOWLER, 2019). A fim de atingir alta disponibilidade, os sistemas 
replicam as partições entre os nós, facilitando o acesso aos dados.
Até agora discutimos como os BDs chave-valor armazenam seus valores, 
como funcionam internamente e algumas situações em que podemos utilizar es-
ses BDs. No entanto, quando definitivamente não devemos utilizar esses BDs? 
Uma situação clara em que não podemos utilizar esses BDs é quando ne-
cessitamos modelar qualquer tipo de relacionamento entre os dados já que eles 
não suportam ligações entre diferentes chaves. Outra situação na qual não se 
aconselha seu uso é em situações em que precisamos consultar os dados armaze-
A notação O (1) significa que é uma busca feita em tempo constante. A letra O 
representa uma notação denominada “Big O” (grande O), que é empregada para mensurar a 
complexidade de algoritmos de busca. Para entender melhor sobre o Grande O, leia o artigo 
Notação Big O, disponível em: http://jkolb.com.br/notacao-big-o/.
DICAS
UNIDADE 1 | BANCOS NOSQL
20
nados para uma determinada chave, pois esse tipo de BD não suporta esse tipo de 
consulta, e, por fim, quando necessitamos armazenar múltiplas chaves ao mesmo 
tempo. Como vimos, tais BDs apenas garantem consistência por chave. Assim, se 
for necessário armazenar mais de uma chave por vez em uma transação, não há 
garantias que todas as chaves serão de fato inseridas.
Agora passamos por todas as etapas necessárias: conhecemos o modelo 
de dados chave-valor, sabemos como ele funciona e quando devemos ou não o 
usar. É importante ressaltar que cada BD chave-valor possui suas peculiaridades 
de funcionamento, e quando você optar por um desses produtos deve conhecer 
suas características para melhor usar sua estrutura.
Existem vários BDs chave-valor no mercado, dentre eles:
• Riak, que você poderá acessar através do link: https://riak.com/.
• Redis, que você poderá acessar através do link: https://redis.io/.
• Volrdemort, que você poderá acessar através do link: https://www.project-voldemort.com/.
• Memcached, que você poderá acessar através do link: https://memcached.org/.
INTERESSA
NTE
Então está na hora de “colocarmos a mão na massa” e ver como é a 
linguagem de um destes BDs na realidade. No próximo subtópico, faremos uma 
atividade prática utilizando o Redis.
3 ATIVIDADE PRÁTICA REDIS
O Redis é um dos representantes mais famosos da família dos BDs 
NoSQL chave-valor. É um projeto de código aberto disponibilizado desde 2009 
de maneira gratuita. Como todo BD chave-valor, o Redis possui como principal 
estrutura de armazenamento chaves e seus respectivos valores.
Um ponto interessante sobre o Redis é que ele possui uma arquitetura em 
memória, isto é, seus dados são persistidos apenas na memória principal (RAM). 
Opcionalmente, o usuário pode configurá-lo para persistir periodicamente seus 
dados em disco, mas por padrão seus dados são mantidos apenas na memória 
principal. Através de sua arquitetura em memória, o Redis se diferencia dos 
demais BDs (orientados a disco), evitando a latência gerada pelas leituras e 
escritas no disco. Dessa forma, escritas e leituras nesse BD são muito rápidas já 
que não necessitam buscar informações no disco.
A linguagem de consulta implementada pelo Redis é simples e permite 
apenas consultas baseadas na chave de acesso das informações. Assim, utilizando 
TÓPICO 2 | BANCOS CHAVE-VALOR
21
o Redis não é possível realizar buscas com base nos valores armazenados para 
uma chave. Isso faz com que seu uso seja limitado a buscas em que conhecemos 
os elementos da chave.
Para o nosso exemplo, não será necessária a instalação do Redis em sua 
máquina. Um ponto interessante desse BD é que ele disponibiliza uma interface 
on-line com um tutorial para que os usuários possam conhecer sua linguagem 
e ter o primeiro contato. Caso você tenha interesse de realizar a instalação em 
sua máquina, a instalação é muito simples e rápida. Mais informações sobre a 
instalação podem ser encontradas no link: htt ps://redis.io/download.
Para dar início ao primeiro contato com o Redis, abra o seu navegador de 
internet (não há restrição de navegador) e acesse o link de testes do Redis: htt p://
try.redis.io/. Após acessar o link, você visualizará a interface representada pela 
Figura 5.
 A parte inferior da Figura 5 (retângulo menor – 1) conta com uma entrada 
de dados, na qual digitaremos nossos comandos. O segundo retângulo (retângulo 
maior – 2) demarca a área de resposta, em que serão exibidos os resultados de 
nossas consultas. Perceba que esse é um ambiente muito semelhante ao terminal 
de comandos.
FIGURA 5 – INTERFACE DE ACESSO REDIS
FONTE: O autor
Para começar, digite na área de entrada de dados (retângulo 1) o comando 
“HELP”. Esse comando apresentará todos os comandos que o Redis suporta 
(Figura 6). Perceba que a lista de comandos não é muito grande comparada ao 
número de elementos que a linguagem SQL permite. No entanto, tenha em mente 
que o Redis possui uma linguagem de consulta mais simplista.
UNIDADE 1 | BANCOS NOSQL
22
FIGU RA 6 – RESULTADO COMANDO HELP
FONTE: O autor
O primeiro passo para utilizarmos o Redis foi dado, mas precisamos 
adicionar dados a essa nossa nova base de dados. Para acionar um par chave-
valor ao Redis, basta utilizar o comando SET. O comando SET é usado naforma 
“SET nome_chave valor”. O comando retorna “OK” se a chave foi inserida com 
sucesso (Figura 7, primeira linha). O comando “SET” também aceita a inclusão de 
valores complexos (Figura 7, terceira linha). Outra característica importante do 
comando SET é que é possível criar um timer que fará com que esse par-chave-
valor se apague automaticamente. A última linha da Figura 7 insere um valor que 
será apagado automaticamente após 20 segundos. 
FIGURA 7 – COMANDO SET
FONTE: O autor
Agora que inserimos dados precisamos verifi car se esses dados foram de 
fato armazenados na nossa base de dados. Para isso usaremos o comando GET. 
O comando GET retorna o valor armazenado para uma determinada chave. Para 
buscar o dado basta usar a sintaxe “GET nome_chave”. A primeira linha da Figura 
8 apresenta a busca pela chave “curso”, e a última através da variável “valor_
complexo”. Vale ressaltar que a busca por uma chave é case sensitive, ou seja, faz 
distinção entre caracteres maiúsculos ou minúsculos (segunda linha da Figura 8). 
Perceba, pela Figura 8, que quando uma chave não é encontrada pelo sistema é 
retornado o valor “nil”.
TÓPICO 2 | BANCOS CHAVE-VALOR
23
FIGURA 8 – RESULTADO COMANDO GET
FONTE: O autor
Outra operação muito importante no BD é como excluir uma informação 
que já não serve mais. Para remover um valor no Redis basta utilizar o comando 
“DEL”. O comando DEL irá, com base na chave ou chaves passadas por parâmetro, 
apagar seus respectivos dados retornando o número de registros afetados. A 
sintaxe do comando segue o formato “DEL nome_chave”. A primeira linha da 
Figura 9 apresenta a exclusão do valor armazenado para a chave “curso”. Caso a 
chave passada para o DEL não exista, ele retorna 0 (Figura 9, segundo comando). 
Perceba que você pode passar mais de uma chave para o comando DEL, apagando 
múltiplos registos ao mesmo tempo (Figura 9, quinta linha). 
FIGURA 9 – COMANDO DEL
FONTE: O autor
Nesse momento, você deve estar se perguntando qual será o comando 
para realizar atualizações nos dados, porém sistemas chave-valor geralmente não 
possuem um comando para atualização. Como o valor armazenado para uma 
determinada chave é tratado como atômico, não são permitidas atualizações nele. 
Caso seja necessário realizar uma operação de atualização, é necessário excluir a 
informação e depois inseri-la novamente.
UNIDADE 1 | BANCOS NOSQL
24
Obviamente os comandos do Redis não se limitam a apenas operações 
básicas de CRUD (create, read, update e delete). Um comando muito útil quando 
estamos utilizando esse BD é o comando “KEYS”. O comando KEYS retorna todas 
as chaves armazenadas na base de dados. Como parâmetro podem ser passadas 
expressões regulares para encontrar chaves que sigam certo padrão. A sintaxe do 
comando é simples: para buscar todas as chaves da base você executa “KEYS *”. 
Caso você necessite achar chaves específi cas poderá passar uma expressão 
regular como parâmetro, por exemplo, “KEYS *o” para buscar todas as chaves 
que terminem com a letra “o”. Imagine que inserimos os dados de fi lmes e 
diretores apresentados na modelagem da Figura 4. A Figura 10 apresenta os 
resultados de consulta: (i) todos os registros cadastrados, e (ii) as chaves que 
mapeiam informações de fi lmes. Apesar de muito útil, o uso do comando KEY é 
desaconselhado em ambiente de produção, pois ele iterará sobre todas as chaves 
armazenadas, o que pode mitigar o desempenho.
FIGURA 10 – CONSULTAS UTILIZANDO KEY
FONTE: O autor
O Redis possui muitas outras funções, tais como: manipular documentos 
JSON, suporte a estruturas de lista e pilha, entre outras. 
Espero que essa rápida introdução tenha esclarecido algumas eventuais 
dúvidas no funcionamento prático de um BD chave-valor e que sirva de ponto de partida 
para que você continue explorando diferentes estruturas e consultas que o Redis permite 
utilizar. Você pode encontrar informações detalhadas sobre os comandos do Redis e seu 
funcionamento diretamente no link: https://bit.ly/3gsQRwa.
DICAS
25
RESUMO DO TÓPICO 2
Neste tópico, você aprendeu que:
• Os BDs chave-valor possuem um modelo de dados simples, baseado em chaves 
únicas que apresentam um valor associado. Esse valor pode ter qualquer 
estrutura, sendo tratado pelo modelo como uma caixa-preta.
• Os BDs chave-valor possuem uma linguagem de consulta simples que, 
geralmente, apenas permitem consultas nas chaves. Pesquisas nos valores 
tornariam o sistema mais lento, sendo assim não são permitidas consultas com 
base neles.
• O acesso aos dados armazenados em um BD chave-valor é bastante rápido, 
pois os valores são armazenados de maneira otimizada baseada na chave.
• Esses BDs utilizam particionamento de dados para facilitar o suporte à 
escalabilidade. Além disso, a fim de suportar alta disponibilidade, as partições 
dos dados são replicadas entre os nós do cluster.
• Os BDs chave-valor são indicados para uso em que a busca de dados é sempre 
feita por um identificador único.
26
1 Cite as principais características do modelo NoSQL chave-valor explicando 
como o BD dá suporte a elas.
2 Descreva uma aplicação real para um BD chave-valor. Defina em qual 
problema você usaria esse tipo de BD e argumente sobre o motivo de sua 
decisão.
AUTOATIVIDADE
27
TÓPICO 3
BANCOS ORIENTADOS A DOCUMENTOS
UNIDADE 1
1 INTRODUÇÃO
Até agora conhecemos os BDs NoSQL de maneira geral. Sabemos que es-
ses BDs possuem diferentes modelos de dados e que cada um serve para um tipo 
de aplicação. Além disso, já exploramos o modelo de dados mais simples, o cha-
ve-valor, conhecendo suas estruturas e quando devemos utilizá-lo.
Seguindo nossos estudos pelo paradigma de BDs NoSQL, iremos agora 
conhecer o modelo de dados orientado a documentos. Esse modelo pode ser visto 
como uma especialização do modelo de dados chave-valor. Como dito anterior-
mente, esse modelo de dados pertence à categoria dos BDs NoSQL baseados em 
chave de acesso, já que, assim como o modelo de dados chave-valor, tem seu 
acesso baseado na busca por chaves.
Essa informação deve ter feito você pensar o porquê da existência desse 
modelo já que é semelhante ao chave-valor e também possui acesso via chave ou 
identificador único. Como vimos anteriormente, o modelo chave-valor é muito 
simples e apesar de ser rápido não permite que sejam realizadas pesquisas que 
não estejam relacionadas à chave. Dessa forma, existia a necessidade de BDs que 
tivessem uma linguagem de consulta mais robusta que não se limitasse apenas a 
consultas pela chave.
BDs com modelo de dados orientado a documentos permitem o arma-
zenamento de estruturas mais complexas que o modelo chave-valor, assentindo 
que o usuário possa realizar consultas nos valores armazenados dentro dessas 
estruturas. Além disso, os BDs dessa categoria possuem linguagens de consulta 
mais robustas, com funções de agregação, agrupamento, entre outras.
Neste tópico, veremos como um BD NoSQL orientado a documentos ar-
mazena e manipula seus dados. Exploraremos quais técnicas tais BDs utilizam 
para prover suporte à alta escalabilidade e alta disponibilidade. Ademais, como 
no tópico anterior, realizaremos uma atividade prática utilizando o MongoDB, 
visando ao seu primeiro contato com um BD orientado a documentos.
28
UNIDADE 1 | BANCOS NOSQL
2 MODELO DE DADOS E ARQUITETURA
Como o nome já sugere, os BDs NoSQL orientados a documentos pos-
suem como estrutura central de armazenamento o documento. Sendo assim, 
esses BDs armazenam e manipulam documentos que podem ser JSON, BSON 
(Binary JSON), XML (Extensible Markup Language) ou qualquer outro (SADA-
LAGE; FOWLER, 2012). Tais documentos, geralmente, são autodescritivos com 
estruturas hierárquicas em forma de árvore. 
Podemos pensar neste BD como sendo um BD chave-valor, em que os da-
dos armazenados para o valor podem ser consultados e manipulados (CATTELL, 
2015). Dessa forma, nestes BDs temos uma chave associada a um documento com 
estrutura própria. Os documentos armazenados podem não possuir semelhançaestrutural, ou seja, o usuário é livre para defi nir como os dados serão organiza-
dos no documento. Desse modo, como se trata de documentos, a sintaxe de cada 
modelo deve ser devidamente respeitada. 
BDs orientados a documentos geralmente possuem uma estrutura de 
armazenamento muito semelhante entre eles. A grande maioria possui uma es-
trutura baseada em um conceito geral que representa a base de dados. A base 
é constituída por coleções de documentos defi nidas pelo usuário. Cada coleção 
de documentos possui um nome único e pode ser vista como um diretório que 
agrupa documentos semelhantes. As coleções de documentos são constituídas 
por múltiplos documentos. Cada documento deve possuir um nome/chave que o 
identifi que unicamente dentro da coleção de documentos. Além disso, os docu-
mentos são basicamente constituídos de atributos com seus respectivos valores. 
O valor de um atributo pode ser de diversos tipos, desde um valor inteiro atômi-
co a conjuntos de dados ou mesmo outros documentos. Esta estrutura pode ser 
visualizada na Figura 11.
 FIGURA 11 – EXEMPLO DE UM BD ORIENTADO A DOCUMENTOS
FONTE: O autor
TÓPICO 3 | BANCOS ORIENTADOS A DOCUMENTOS
29
Como você deve ter percebido, a estrutura de um BD orientado a 
documento é comparável à estrutura de um BD relacional. Claro que os conceitos 
se diferem pela natureza com que são tratados, porém é possível traçar um 
paralelo entre os conceitos. O Quadro 2 apresenta uma forma de mapeamento 
entre os conceitos do modelo relacional para o modelo orientado a documentos. 
Perceba que uma coleção de documentos pode ser vista como uma tabela, já que, 
em essência, ambas agrupam dados relacionados a um mesmo tipo de objeto/
entidade. Cada uma das linhas de uma tabela poderia ser mapeada para um 
documento pertencente à coleção, tendo em vista que representa um registro de 
certo objeto ou entidade. Considerando uma tupla com seus valores, o documento 
mapearia cada uma das colunas como um atributo e seu respectivo valor. Por fim, 
a chave primária ou identificador da tupla, pode ser vista como nome ou chave 
de acesso de um documento.
QUADRO 2 – MAPEAMENTO BD ORIENTADO A DOCUMENTOS PARA RELACIONAL
Banco Relacional NoSQL documento
Base de dados Base de dados
Tabela (relação) Coleção de Documentos
Linha (tupla) Documento
Identificador da tupla Nome/Chave Documento
FONTE: O autor
Esse mapeamento não necessariamente é o correto, tudo depende da for-
ma com que os dados serão acessados. Na verdade, tal mapeamento deve ser 
visto como um guia conceitual para traçar um paralelo entre os dois modelos e 
não como guia definitivo de mapeamento entre modelos. Geralmente, não faz 
muito sentido realizar esse tipo de mapeamento. Veja que se você sempre realizar 
esse mapeamento, você estará atrelando a estrutura de sua aplicação ao modelo 
relacional sem que seu BD seja relacional. Desse modo, isso pode condizer com 
seu problema e suas consultas, mas também pode ocasionar sérios problemas de 
desempenho nas consultas.
Vamos fazer um exemplo simples. Considere novamente o BD Cinema 
apresentado no Tópico 2. Lembre-se que esse BD possui duas tabelas: Filmes e Di-
retor. A Tabela Filmes contém algumas informações básicas de filmes e uma chave 
estrangeira para o diretor responsável pelas gravações. A Tabela Diretor apenas 
possui um identificador único, o nome do diretor e quantos prêmios ele recebeu. A 
Figura 12 apresenta o mapeamento do BD relacional Cinema para o modelo de do-
cumentos baseado nas regras de mapeamento propostas. Perceba que as tabelas fo-
ram mapeadas para coleções de documentos. A coleção de documentos Filmes, por 
exemplo, possui três documentos, cada um mapeando uma tupla da tabela Filmes. 
O documento possui como chave o valor da chave primária de cada tupla (coluna 
id) e é constituído dos atributos que mapeiam as colunas das respectivas tuplas.
30
UNIDADE 1 | BANCOS NOSQL
FIGURA 12 – BD CINEMA MAPEADO PARA O MODELO DOCUMENTO
FONTE: O autor
Considerando isso, imaginamos que você ficou com uma dúvida: no BD 
relacional a coluna diretor da tabela Filmes é uma chave estrangeria para a tabela 
diretores, então, os BDs NoSQL possuem chaves estrangeiras?
Apesar do valor da coluna da Tabela Filmes ter sido mapeado para o atri-
buto ‘diretor’ dos documentos, não existe uma relação de chave estrangeira, ou 
seja, não existe garantia nenhuma de integridade que o valor do atributo exista 
na coleção de documentos Diretores. Este é um ponto importante dos modelos 
NoSQL em geral: a fim de dar melhor desempenho ao acesso aos dados, restri-
ções de integridade referencial são deixadas de lado e esses BDs não suportam 
esse tipo de função. Sendo assim, como sabemos que o valor armazenado no 
atributo diretor no documento “1” da coleção Filmes de fato se refere a um valor 
em outra coleção? A resposta é simples: você deve criar um método via aplicação 
que verifique. No entanto, como você deve imaginar, isso se torna pesado, e não 
é uma boa prática. Nesse sentido, indicamos que se você necessita muito desse 
relacionamento não use esse tipo de mapeamento. 
BDs NoSQL orientados a documentos geralmente não permitem chaves 
estrangeiras. Existem algumas exceções: o MongoDB, por exemplo, permite que 
você crie ligações entre documentos, é como se fosse um atalho para encontrar 
um documento pertencente a outra coleção de documentos. Apesar de se asseme-
TÓPICO 3 | BANCOS ORIENTADOS A DOCUMENTOS
31
lhar com uma chave estrangeira, a referência a documentos implementada pelo 
MongoDB não deve ser considerada para emular chaves estrangeiras. 
Vamos imaginar então que em nosso BD não precisamos mais nos impor-
tar com a integridade referencial, ou seja, nosso sistema está bem construído e 
para todo Filme cadastrado existe sempre um diretor correspondente. Dessa for-
ma, não precisamos nos importar com a restrição de uma chave estrangeira, e a 
inclusão de registros, por consequência, é mais rápida já que não realiza esse tipo 
de validação. Contudo, uma consulta recorrente em nossa base de dados é buscar 
os filmes e o nome do diretor que o dirigiu. Através do modelo relacional essa 
seria uma consulta simples de realizar, bastaria utilizar uma junção. O problema 
é que BDs NoSQL, em sua grande maioria, não possuem suporte à operação de 
junção. 
Perceba que a operação de junção faz total sentido quando pensamos 
no modelo relacional. Como o modelo é baseado na teoria de conjuntos, basi-
camente, estamos pegando dois conjuntos e executando uma intersecção (SIL-
BERSCHATS; KORTH; SUDARSHAN, 2012). Quando pensamos no modelo de 
dados NoSQL de documentos, isso perde o sentido já que agora temos diretórios 
(coleções) e documentos. Além disso, como vimos no Tópico 1, sistemas NoSQL 
primam pelo desempenho, e operações de junção são pesadas. Então, já que não 
podemos utilizar junções, como poderemos retornar os dados de cada filme com 
seus respectivos diretores? Uma possível solução é implementarmos na aplicação 
nosso próprio algoritmo de junção. Claramente essa não é uma boa opção, pois 
demanda tempo e, considerando que algoritmos de junção são complexos, prova-
velmente acabaríamos perdendo desempenho ao executá-los.
Uma solução interessante para esse problema é a utilização do conceito 
de agregados. BDs NoSQL geralmente utilizam o conceito de agregado para per-
mitir que o usuário possa interagir com estruturas de armazenamento mais com-
plexas. Perceba que quando estamos manipulando informações com o modelo 
relacional, tudo se baseia na execução de operações em tuplas, sendo que tudo 
é executado tupla a tupla. Muitas vezes, como quando utilizamos uma operação 
de junção, precisamos combinar tuplas em um registro mais complexo. O concei-
to de agregação é, basicamente, armazenar esses dados em uma estrutura mais 
complexa com mais subníveis.
Vamos pensar novamente em nosso exemplo, modelamos nosso BD 
orientado a documentos considerando que cada tabela viraria uma coleção de 
documentos, pois os conceitos têm semelhanças.Se utilizarmos o conceito de 
agregados podemos considerar que na verdade algumas tabelas poderiam ser 
mapeadas como um atributo complexo de um documento. Considerando isso, 
poderíamos mudar nosso mapeamento inicial do BD Cinema para mapear as tu-
plas da tabela “Diretores” diretamente para valores complexos em seus pares 
(chaves-estrangeiras) nos documentos da coleção Filmes. A Figura 13 apresenta 
uma representação deste novo modelo de mapeamento.
32
UNIDADE 1 | BANCOS NOSQL
FIGU RA 13 – MAPEAMENTO BD CINEMA BASEADO EM AGREGADOS
FONTE: O autor
Perceba que nessa nova versão de nosso modelo existe apenas uma 
coleção de documentos: a coleção de Filmes. Os dados referentes ao diretor de 
cada um dos fi lmes foram armazenados com o respectivo fi lme. Perceba que 
dessa forma temos apenas um documento que contém todas as informações 
referentes a um fi lme. Assim, não existe mais a necessidade de uma junção para 
obter as informações. Assim, para se obter as informações dos fi lmes com seus 
respectivos diretores, basta buscar todos os fi lmes e exibir apenas as informações 
que precisamos. 
Dessa forma, pode-se perceber que essa solução resolve de fato o problema, 
mas cria alguns possíveis novos problemas. Um desses problemas é que na hora 
de inserir um novo fi lme é possível escrever as informações do diretor erradas e 
deixar a base de dados inconsistente. De fato, isso pode ocorrer, e se você optar 
por uma solução desse tipo deve ter em mente os problemas que ela pode gerar. 
Veja que a solução deste problema é mais simples que implementar um algoritmo 
de junção.
Outro problema que você deve ter notado é que os diretores se repetem 
para os fi lmes, sendo assim serão armazenadas informações redundantes, mas 
isso não é necessariamente um problema. O modelo relacional foi criado em uma 
época em que o armazenamento era muito caro, desse modo, para mitigar esses 
TÓPICO 3 | BANCOS ORIENTADOS A DOCUMENTOS
33
custos, foram criadas as regras de normalização que evitam dados redundantes 
e outras situações. Atualmente, o custo de armazenamento é muito mais barato, 
computadores pessoais já são equipados com discos rígidos com armazenamento 
na casa dos Terabytes. 
Quando é realizado a modelagem de um banco de dados NoSQL, a partir 
de qualquer modelo de dados, deve esquecer esse tipo de limitação. Não se deve 
pensar em tabelas normalizadas, a estrutura de dados é diferente. Devemos focar 
no desempenho das consultas que iremos executar. No caso de nosso exemplo, 
eliminamos a necessidade de uma junção armazenando os dados juntos.
Para esse problema isso seria uma boa solução, pois o uso de agregados 
é muito difundido e encorajado nos BDs orientados a documentos. No entanto, 
deve ser utilizado com cuidado. Para nosso exemplo, essa é uma solução muito 
elegante, pois o agregado de Diretores é pequeno. Devemos tomar cuidado com 
o tamanho dos agregados utilizados. BDs orientados a documentos permitem a 
inclusão de agregados dentro dos agregados, e isso pode gerar documentos muito 
grandes. Quando você utiliza essa abordagem deve ter em mente que alguns BDs 
limitam o tamanho dos documentos que são armazenados ou mesmo que são 
retornados em uma consulta. Assim, se seu documento for muito grande, o BD 
pode ter que adotar uma técnica que retorne o documento em partes menores, o 
que influenciará diretamente no desempenho do seu sistema.
Sempre que você for planejar a utilização de um BD orientado a documento 
temos que ter em mente as limitações que ele impõe. O modelo é muito flexível e 
permite que o usuário defina a estrutura do documento livremente, mas isso deve 
ser realizado com certo cuidado.
Como você já deve ter imaginado, os BDs orientados a documento são 
livres de um esquema, ficando a critério do utilizador a estrutura que será 
utilizada. Inclusive, não existe uma definição formal de esquema mesmo para 
a coleção de documentos. Assim, é possível colocar documentos de diferentes 
estruturas na mesma coleção. Se quisermos podemos adicionar um novo atributo 
aos filmes que cadastrarmos a partir de agora, por exemplo. Para isso, basta 
adicionar o atributo aos novos documentos e quando realizar uma consulta com 
base nesse novo atributo os documentos que não o possuem não serão exibidos. 
Alguns BDs específicos, como o MongoDB, permitem opcionalmente que 
o usuário defina um esquema para documentos em uma mesma coleção. Assim, 
é possível criar uma série de regras estruturais, utilizando DTD (Document Type 
Definition), para que todos os documentos de uma certa coleção tenham essa 
estrutura. Depois de definida a DTD, todos os documentos da coleção devem 
seguir essa estrutura. Qualquer documento fora da especificação não será 
adicionado. Agora você deve ter pensado: mas como assim um esquema para um 
BD NoSQL? Ser livre de esquema não era uma característica interessante?
34
UNIDADE 1 | BANCOS NOSQL
Ser livre de esquema não significa necessariamente não suportar um 
esquema. Os BDs NoSQL atacam diversas frentes de novas aplicações e, 
eventualmente, um esquema pode ser necessário. Esse esquema possui um 
custo, uma inclusão em uma coleção de documentos livre de esquema é mais 
rápida do que em uma que o possua. Isso é meio óbvio, já que quando existe 
um esquema deve ser feita uma verificação de validade do documento sobre o 
conjunto de regras. Esse é o ônus do uso de um esquema: as inclusões ficam um 
pouco mais lentas. O bônus é que as consultas ficam mais rápidas já que com uma 
estrutura rígida o BD pode otimizar mais as consultas. Dessa forma, podemos nos 
questionar: já que torna as consultas mais rápidas, devemos usar sempre?
A resposta é não! Sempre devemos considerar o problema que se está 
tratando. Devemos ser capazes de medir se irá ou não valer a pena utilizar 
o esquema de dados, ou seja, medir se o ganho em desempenho será tão 
recompensador para valer a pena abrir mão da flexibilidade. Veja que, mesmo 
usando o esquema, ainda assim temos uma inclusão, que tende a ser mais rápida 
que uma realizada no modelo relacional. O modelo relacional deve garantir 
todas as propriedades ACID, enquanto os BDs NoSQL relaxam ou ignoram essas 
propriedades.
Agora que conhecemos o modelo de dados orientado a documentos 
e sabemos como o armazenamento de dados funciona precisamos entender as 
outras características desse modelo. Existem diversos sistemas NoSQL orientados 
a documentos, vejamos alguns exemplos: 
• MongoDB.
• CouchDB.
• RavenDB.
• LotusNotes.
Todos eles possuem suas estruturas de armazenamento e algoritmos de 
manipulação. O MongoDB, por exemplo, utiliza documentos no formato BSON 
para armazenar seus dados, já o CouchDB utiliza JSON. Apesar disso, todos 
compartilham algumas características de funcionamento.
BDs orientados a documento, geralmente, possuem uma arquitetura 
baseada em réplicas através de nós mestre e nós escravos/trabalhadores, ou 
O DTD (Document Type Definition) é uma estratégia para estruturar 
documentos. Para conhecer mais sobre ele, acesse a página do W3Schools que explica esse 
conceito com exemplos. Disponível em: https://www.w3schools.com/xml/xml_dtd.asp.
DICAS
TÓPICO 3 | BANCOS ORIENTADOS A DOCUMENTOS
35
seja, um nó mestre é responsável por manter a versão mais atual dos dados e é 
responsável por receber e executar as operações de escrita (inserção, atualização e 
exclusão). Esse nó é ligado a nós configurados como trabalhadores que armazenam 
réplicas dos dados. Essas réplicas são utilizadas apenas para leitura. Caso o nó 
mestre pare de funcionar, um dos nós trabalhadores tomará seu lugar. O número 
de réplicas é configurado pelo usuário. 
BDs orientados a documentos suportam diferentes níveis de consistência. 
Por padrão, a fim de maximizar o desempenho na escrita e leitura de registros, 
o sistema suporta consistência eventual, assim como os BDs chave-valor. Deve-
se lembrar que os BDs NoSQL sacrificam as propriedades ACID para obter um 
bom desempenho e serem capazes de lidar com grandes quantidades