Go eee ee ere
Banco de Dados
SECURIT em UTC Te
SUES
H Trabalhando com backup e restauracao
Magazine :
CREEL eee det.
Agendador de,
Saiba quando utilizar
noSQL
Conhega as bases de dados
como um complemento ao
modelo relacional
Banco de Dados Banco de Dados
Ce ee RRL BCE ORC UU ee)
ET On Ce Ce Cd Cee COE te) -Entendendo NoSQL
Conhecendo as bases de dados NoSQL como um
complemento ao modelo relacional
sucesso do modelo relacional costuma gerar a
(itso sr esc
possivel para o problema da persisténcia e
obtengao de dados. Dentre as consequéncias desta falsa
impressdo esté a auséncia de questionamentoa respeito
de quando este modelo deve ser aplicado, o que muitas
‘vezes leva equipes de desenvolvedores a projetar soli-
98es mais complexas que o necessério, caras do ponto
de vista computacional e diffceis de serem mantidas.
A emergencia de solugbes nao relacionais ~ 0s bancos
de dados NoSQL - trouxeram como grande ganho a TI
© fato de termos agora de forma acessivel outros mode-
los de persisténcia/consulta que nos permitem, em sua
comparacao com omodelo relacional, perceber de forma
‘mais clara suas limitagdes e 0s contextos nos quais este
de fato deveria ser aplicado.
Esta comparacio entre diferentes solugbes ce persistén-
ciae obtengao de dados trouxe outro ganho interessante
paraa comunidade de desenvolvedores: fato de terem
sido colocadas em primeiro plano quest0es até entéo
tidas como resolvidas como, por exemplo, os problemas
deescalabilidade decorrente do crescimento de tamanho
e complexidade das bases de dados relacionais, além
de também por em cheque diversas préticas que até o
presente momento viamos como étimas.
E importante salientar que quando falamos sobre as i-
‘itagGes do modelo relacional ndo necessariamente nos
referimos a defeitos do modelo, mas sim na maior parte
das vezes da sua mé aplicagdo. Seria tolice apés mais de
40 anos da publicacio do artigo de Edgar F. Codd em
‘que 0 modelo relacional éapresentaco pela primeira vez
rotulé-locomo uma solugo ruim, muito pelo contrario:
desde que foi langada a primeira implementagao comer-
cial bem sucedida em 1979 pela Oracle de um SGBDR,
este se tomou o padrao da indkstria no que diz respeito
A armazenagem e obtengio de dados. Tamanho sucesso
no seria posstvel apenas com marketing, mas sim pelo
simples fato de ser uma solugdo que por todos estes anos
atendeu e bem as necessidades do mercado.
Entretanto, conforme 0 tamanho e a complexidade
1na modelagem dos bancos de dados foi aumentando,
6 SOL Magazine Eo 111
ie TO
Entendendo NoSQl:
‘Uma consequéncia interessante do uso em large escala do modelo
‘elacional éofato denos vermos aramente pensando.a seurespelto.
Dificimente nos questionamos sobre a sua unidade bésica que é 0
registro e quando este pode ser aplicado, Entretanto, 20 analisarmos
seus fundamentos, compreendemos algumas de suas limitegbes
bisicas no que diz espeito 8 modelagem de dados, que tem como
‘consequeéncia diretaos problemas de escalabllidade.
Neste contexto, 0 objetivo deste artigo & apresentar os conceltos
fundamentals por trés da bases de dados nao relacionals -NoSQL-e
‘como sua natureza nos ajuda a superar a lmitagSes impostas palo
‘modelo relacional.Serdo expostas as principals caractristcas desta
‘ategorade ferramentas as principaisimitacées do modelo elacional
efinalmente alguns modelosalternativos - documenta, chave-valor
earéfico que podem ser usados coma camplementos ousubsttutos
dos bancos de dados relacionas.
‘Em que stuagdoo tema itil:
‘A ubiquidade do modelo relacional muita vzescraaiustode
tratar do unico madelo de persisténcia exstene, acultando assim
suns principals deficiéncia.O conhecimento destaslimitagbese de
alteratvasqueassuprem aludam equipes de Ia obterem melhores
resultados através da simplificacao do cédigofonteaser escrito
nose escalabldade e performance. Assim, ¢importanteconhecer
2s pecllridades comuns 2 contexto das feramentas NeSQh para
poder tiraro maximo de suas caracteristias ‘o mercado sentiu de forma sensivel as limitagbes decorrentes da
‘nossa obsessio por representar qualquer informacdo sob a forma
delinhas ecolunas. A modelagem de dads se mostrava cada vez
‘mais dificil de ser feita, e nfo raro nos viemos na necessidade de
‘executarmos 0 exato oposto do que nos fora ensinado até ent:
dlesnormalizar os dados a fim de aumentar a performance de
rnossas consutas ¢ com isto tentar minimizar os graves proble-
mas de escalabilidade que néo batiam a nossa porta, mas sim
arrombavam-na. Tornava-se claro algo que até enti a maior parte
denés negava: fato de a maior parte das informagoes presentes
no mundo néo ser fortemente estruturada, mas sim 0 contrario.
Eneste momento hist6rico vemos a emergéncia de popularidade
das solugdes nao relacionais, isto 6, os hoje tao falados bancos de
dados NoSQL.
Entendendo o modelo relacional e sua principal limitagaona
modelagem de dados
‘Uma consequéncia interessante da ubiquidade do modelo rela-
cional €0 fato de nos vermosraramente pensando a seu respeito
Rarissimas vezes nos questionamos sobre a sua unidade bésica
que ¢ 0 registro e quando este pode ser aplicado. E interessante
que antes de tratarmos dos bancos de dados relacionais fagamos
uma breve discussdo a respeito desta estrutura de dados para,
assim, compreendermos algumas de suas limitagdes basicas no
que diz respeito & modelagem de dados, que tem como conse
quéncia direta os problemas de escalabilidacie mencionados na
introdugdo deste artigo.
Qual a esséncia ce um registro? Em um banco de dados rela-
cional é uma estrutura de dados bidimensional e homogénee. Por
homogéneo entenda algo que mantém suas propriedades em toda
2 sua extensio, ou seja, é uniforme. Um conjunto de ntimeros
inteizo ¢ internamente homogeneo, pois todos os seus elementos
compartilham exatamente das mesmas propriedades.Jéa carac-
teristica bidimensional do registro se deve ao modo como este &
sepresentado: verticalmente por suas linhas e horizontalmente
por seus atributos ou cokunas. E importante trtarmos da questo
dda homogeneidade, por nao se tratar de uma caracteristica auto
evidente para muitos de nés que encaram pela primeira vez 05
modelos nao relacionais.
‘A homogeneidade horizontal diz respeito aos campos que
compoem um registro. De forma ideal, em uma tabela todos os
registros que a comptem representam uma mesma entidade ou
seus subtipos. Sendo assim, énatural que todos possuam omesmo
conjunto de ateibutos: conjunto este ce tamanho fixe composto
ppor campos que, em sua forma mais basica s8o formados por trés
atributos: nome, tipo e tamanko. Claro, um campo pode possuir
‘mais atributos de acordo com o fornecedor do seu SGBDR, como
por exemplo desericio, regras de validagio, etc. Horizontalmen-
te, podemos dizer portanto que temos uma estrutura de dados
fortemente estruturada e rigida no sentido de que, uma vez em
produgio, a incluso, remosao ou edligdo de campos é um proce-
dimento caro tanto do ponto de vista computacional efinanceiro
dada a sua dificuldade de manutencdo,
Verticalmente a homogeneidade se manifesta sob a forma da
tabela que possui o papel de agregar légica e fisicamente todos
os registros que pertencam a um determinado tipo. O tipo
agrupado pela tabela normalmente ¢ evidenciado pelo nome
que damos aesta, como por exemple furcionério, imével, empresa,
ete, Cada campo manifesta sua homogeneidade verticalmente
quando sempre possui o mesmo significado entre os registros
que compoem uma tabela.
Umregistro éaplicado com sucesso quando hd homogeneidade
em suas duas dimens6es e tenhamos uma estrutura normaliza-
da, ou seja, quando nao ha a ocorréncia de campos repetidos ou
desnecessérios. Fica nitida a primeira limitagao do modelo
relacional: © contexto no qual registros devem ser aplicados
como estrutura de dados para representar as entidades de
nosso sistema,
Inicialmente o problema com esta limitagdo néo é claro: énormal
termos a impressio de que nossas tabelas armazenam registros
sempre referentes a uma mesma entidade, €os campos que usamos
em sua definico costumam servir para apenas um objetivo. Para
pagar esta ilusdo veremos alguns exemplos comuns no dia a dia
do desenvolvedorno qual a homogeneidade e a normalizacio dos
nossos registros se mostra um fator limitador.
‘Nosso primeiro exemplo envolve um cadastro de ativos. Um ati
vorepresenta um bem de uma empresa que encontra-se alocadoa
‘um departamento ou funcionério, Departamentos possuem como
identificador um nimero de quatro algarismos ¢ 0 funcionérios
seu CPF. Uma primeira modelagem da nossa tabela poderia ser
vista como no exemplo exposto na Figura 1
Figura, Nodelagem nial
Nesta solugio ingénua, o campo ALOCACAO_ID possti duplo
significado, pois é usado para representar tanto funcionérios
quanto departamentos, anulando portanto a homogeneidade ver-
tical da tabela: o mesmo campo pode possuir significados diferen-
tes de acordo com o registro. Além da perda de homogeneidade,
outro problema menos evidente diz respeito & seméntica de nossa
tabela. Se vista isoladamente, dificilmente um leitor poderia dizer
com preciso que ao usarmos quatro digitos estamos nos referindo
um departamento e que os demais ntimeros sio CPFs. Parte da
fungio basica da tabela que consiste em representar informasao
de forma clara esta perdida,
‘Uma possivel evolugio para o problema poderia ser a remosio
da coluna ALOCACAO_ID seguida da inclusio de duas novas
colunas, FUNCIONARIO_ID e DEPARTAMENTO. ID, represen-
tando respectivamente o funcionério eo departamento em queo
ativo se encontra alocado, conforme vemos na Figura 2.
{digo 171 +SQLMagazine 7 problema seméntico foi resotvido:isola-
damente sabemos que o ativo esté relacio-
nado a um funcionérioou departamento de
forma imediata conforme o preenchimento
de cada campo, Além disto, torna-se mais
{écil relacionar nossa tabela com as que
armazenam os dados de nossos funcioné-
ios e departamentos, garantindo assim a
integridade referencial. Infelizmente, novos
desafios se apresentam. Caso seja necessé-
rioalocar um ative aumaentidade queno
seja um funcionério ou um departamento,
como por exemplo, uma empresa terceiriza-
da, faz-senecesséria aincluséodeumnovo
campo. Nossa tabela também apresenta um
problema semantico sutil: dado que um
objeto ndo pode estar em dois lugares a0
‘mesmo tempo, como garantir que apenas
campo FUNCIONARIO_ID ou DEPARTA-
MENTO_ID sejam preenchidos?
‘Outro problema é que temos agora uma
tabela esparsa, Se 99% dos ativos forem
alocados apenas a departamentos, em
apenas 1% dos casos 0 campo FUNCIO-
NARIO_ID seré preenchido. Temos assim
‘uma tabela esparsa, ou seja, uma tabelana
qual existam campos que raras vezes S80
preenchidos, o que gera como problemao
consumo desnecessério de espago de ar-
mazenagem e aumento na complexidade
das consultas que precisamos escrever e
do cédigo que precisamos implementar
para lidar com estas jungbes.
Um segundo exemplo bastante co-
mum ocorre na implantado de ERPs.
Nao raro o cliente possui a necessidade
de campos customizados. Dado que 0
cédigo fonte principal do sistema cos-
tuma ser «nico, uma solugéo comum
6 a presenga de campos “genéricos”
Figura 2, Segunda madelagem
pais cemel_—_[oscuim
a[Automével 1109]
2|Moto [osa.070.005-12
alNotebook 3200]
‘)rojetor [os1.070.001-14
[choeoate
reicaca Isemtemper
Icerourador
“TINFO_C8"PO JO INT
OVALER VAROHER( AS)
? mT
°CATEGORIA_10 NT
Figura 4, Una soli para o problema dos campos varies
8 SOL Magazine Edo 111
de tipos variados que so usados pelo
usuério de acordo com as convensdes
que este venha a adotar dentro da sua
empresa. Outra forma bastante popular
de ocorréncia desta situacdo é a pre-
senga de campos textuais normalmente
chamados de “Observacées”, aonde
qualquer tipo de dado possa ser inserido.
Na Figura 3 podemos ver um exemplo
deste tipo de tabela no qual os proble-
mas de perda semantica e ocorréncia de
tabela esparsa voltam a ocorrer.
Nos dois exemplos podemos observar
claramente que na realidade estamos
lidando com informagdes semiestrutura-
das: ha a presenca de campos que raras
vezes sio usados ou, ainda pior, a alta
probabilidade de ocorréncia de campos
nao previstos no projeto da aplicagio.
E possivel solucionar parcialmente 0 pro-
blema desta semiestruturagio adotando
‘uma estrutura de tabelas que represen-
tem metainformagées referentes a estes
campos, tal como encontra-se ilustrado
na Figura 4
Esta solucdo baseia-se na ideia de que
a presenca dos campos adicionais pre-
sentes em tabelas cuja homogeneidade
foi perdida ocorre pelo fato da tabela
‘no possuir homogeneidade vertical, ou
seja,atabela armazena registros de tipos
variados. Para tal, cria-se uma tabela
de categorias (CATEGORIA) que seré
relacionada & tabela problematica e seré
responsavel por definir o tipo de cada re-
gistro, A tabela CATEGORIA relaciona-
se meta informagdes (INFO_CAMPO)
que epresentam os campos relacionados
a cada categoria, Finalmente, teremos
uma tabela CAMPO, relacionada a
INFO_CAMPO e VENDA (nossa tabela
problemética) que armazena os valores
relativos aos campos relacionados & ca-
tegoria associada ao registro.
Fica claro que estamos lidando com
‘uma solugdo complexa que apenas nos
garante a homogeneidade horizontal de
uma tabela. Por definiclo, esta estratégia
jd pressupde a presenca de diferentes ti-
pos de entidade em uma mesma tabela e,
portanto, apenas alimenta o problema da
perda de homogeneidade vertical. Além
disto, o custo de implementagéo e manu- tengo desta estrutura de dados seré alto. Hé ainda problemas
relacionados ao tipo de cada novo campo, pois para que seja
‘uma solugio fécil de manter, internamente o campo VALOR
da tabela CAMPO deve ser textual para evitar a ocorréncia de
‘uma tabela esparsa, Do ponto de vista computacional, a solucéo
também é cara, pois necessita de diversas jungdes apenas para
garantir 0 preenchimento dos campos adicionais, Resumindo:
rosea solugio para o problema apenas piora a situacao.
Fica clara a grande limitagdo do modelo relacional no que diz
respeito 4 modelagem da informagio: s6 podemos aplicé-lo com
sucesso absoluto quando lidamos com entidades que possam
ser representadas por um modelo estritamente rigido e bem
estruturado, ou seja, quando registros possam ser aplicados.
(© modelo relacional nao se adapta bem a situagées aonde a
homogeneidade nao possa ser aplicada,
Escalabilidade
A capacidade de um sistema suportar um aumento substancial
de carga sem que seu desempenho piore ao ponto de torné-lo
indtil € 0 que costumamos chamar escalabilidade. No caso do
‘modelo relacional, quando mal aplicado seus problemas de es-
calabilidade se mostram de forma imediata quando nossas bases
dde dados atingem tamanhos enormes com, por exemplo, milhdes
de registros por tabela.
De modo geral, resolvemos este problema de forma vertical
ou horizontal. A solugéo vertical consiste em upgrades de hard-
ware como aumento de memdria ¢ substituicao e incluso de
novas CPUs, enquanto a horizontal se dé na distribuigdo do
processamento entre miiltiplos servidores. Das duas solugbes a
mais limitada ¢ a primeira, razao pela qual hé um forte foco na
implementagdo de SGBDs distribuidos, o que traz uma série de
problemas que precisam ser resolvidos, conforme veremos nas
proximas segbes,
Consisténcia e escalabilidade
Evidenciou-se os problemas de escalabilidade do modelo re-
lacional com o surgimento de bases de dados com tamanhos
colossais, As solugGes adotadas para o problema normalmente
se dio através de técnicas como particionamento de tabelas entre
_mailtiplos servidores, desnormalizacao de dados e outras (ler Nota
do DevMan 2).
‘A grosso modo, ha duas causas principais por trés dos problemas
de escalabilidade sofridos pelos SGBDRs. A primeira se deve justa-
‘mentea sua natureza relacional: enquanto executar jungdes entre
tabelas 6 uma tarefa relativamente barata para bases de dados de
tamanho pequeno ou médio, seu custo sobe significativamente ao
lidarmos com tamanhos maiores, haja visto anecessidade de exe-
ccutar comparagbes entre tabelas (ou partigdes) que, muitas vezes,
indo se encontram armazenadas fisicamente no mesmo servidor.
A segunda causa é decorrente do modo como a consisténcia dos
dados 6 obtida no modelo relacional, ou seja, éconsequéncia direta
dda sua implementacio rigida do modelo ACID, que é a base por
‘rds do seumecanismo transacional, assunto desta seco. Ao leitor
ainda nao familiarizado com oconceito de ACID, faz-se necessirio
que fagamos uma breve introducdo ao termo.
‘Uma transacio agrupa um conjunto de operages de alterasao
de dados (escrita, edigdo e exclusio) em uma unidade de trabalho
adotando o principio de que ou todas as operagies s2o executadas
com sucesso ou, em caso de falha de qualquer uma, 0s dados alte-
rados pela transagdo sejam revertidos ao estado original antes de
sua modificagao. Para que uma transacio seja totalmente segura,
faz-senecessério que esta esteja em concordancia com 0 ACID, que
um conceito adotado pela ciéncia da computacio para descrever
as caracterfsticas que toda transagdo deve possuir com o objetivo
de ser bem sucedida: Atomicidade, Consisténcia, Isolamento ¢
Durabilidade.
Patclnamento de tabels
0 parinanento de abel € una tice empegada em Banc de dates que aise em
Ahr samen na bela gandeen segments menoes, muta exes tlds er mas
deunserin etn projet mata otenp aes aoa se ance
rai il vit qu mad ites ee pei uma ns
Sowetranere nat ernest sees enpnertte cede una in
poorer em go ri faa gt sent amet Tt
Ue ue se ent present no as Sede asin mpemet
deaordcomo fond do abn de te
Atomicidade é a capacidade de agrupar operagSes em uma unti-
dade de trabalho que permita retornar a base de dados ao seu estado
anterior em caso de falha de uma das operagdes que compoem
a transagdo. Consisténcia € a garantia que uma vez finalizada,
‘com ou sem sucesso, os dads modificados pela transacio serdo
deixados em um estado consistente.
Finalmente, os dois atributos restantes que compoem uma
transagio sio a isolamento e durabilidade. Para que um SGBDR
que lida com uma quantidade significativa de dados seja viavel,
faz-se necessério que este possa executar simultaneamente mais
de uma transagdo. Esta execucio deve ser feita de forma isolavel,
‘ou seja, uma transagdondo deve ter acesso ao estado dos dados que
feign 111 +SOL Magazine 9 estejam sendo alterados por outa transagio concorrente,evitando
assima obten¢do de resultados incorretos, Para terminar, temo:
durabilidade:a garantia de que finalizada a transagio seus dados
sejam persistidos em uma unidade de armazenamento a fim de
‘que nao sejam perdidos em caso de reinicio ou finalizagao do
Processo responsével pela execugao do SGBDR.
Esta garantia de consisténcia obtida através de transagdes
que implementem 0 ACID completo vém com alto custo com-
putacional, que aumenta significativamente ao lidarmos com
tabelas distribuidas entre miiltiplos nés em uma rede, sendo
esta muitas vezes esparsa geograficamente.
Em um primeiro momento podermos ter a impressao de que
transagées t4o rigidamente implementadas sio uma necessi-
dade para qualquer situacdo: isto no é verdade. Transagées
100% ACID s40 um requisito de um pequeno subconjunto das
atividades computacionais: estas foram amplamente aceitas,
tem sua maior parte devido ao sucesso de sua aplicacio no mer-
cado financeiro, por exemplo, onde so uma necessidade real.
Entretanto, observando atividades mais corriqueiras em que o
valor da informasao nao seja tao alto, talvez 0 custo de termos
‘© ACID completo nao seja uma grande vantagem, certo?
Diversos bancos de dados NoSQL sao implementacios de tal
forma que 0 ACID seja apenas parcialmente implementado.
£ muito comum, por exemplo, que alguns SGBDs armazenem
todos os dados em meméria para cachear informacées, negando
a durabilidade dos dados. Outros so implementados como
processos de uma tinica thread, de tal modo que o isolamen-
to seja obtido como simples consequéncia do modo como 0
cédigo fonte do projeto foi arquitetado. Naturalmente, este
relaxamento do ACID na maior parte das vezes é configurével,
tornando posstvel, caso necessério, configurar 0 servidor para
obter suporte completo as quatro propriedades que compéem
‘uma transagdo totalmente segura, Nao hé uma resposta precisa
para quando este tipo de configuraco deva ser adotado, pois
0 casos variam bastante de acordo com a situagéo.
© conceito chave ao tratarmos a escalabilidade na imple-
mentacdo de um SGBD distribuido € consisténcia. Dado um
sistema composto por miltiplos nés, como sincronizé-los de
10 SQL Magazine + Ecicio 111,
tal forma que possamos ter dados minimamente consistentes,
isto é, consultando qualquer um dos nés, como ter certeza de
estarmos obtendo o valor correto devidamente atualizado?
Um dos maiores ganhos obtidos com a emergéncia do NoSQL.
foi oquestionamento do pr6prio conceito de consisténcia. Com-
prometendo parcialmente a consisténcia, diversas implemen-
tages de SGBDs néo relacionais obtém ganhos significativos
de performance e escalabilidade. Popularizou-se os conceitos
de consisténcia forte e fraca, que podem inclusive ser descritos
algebricamente tal como faremos neste momento.
Imagine um sistema composto por Nnés, cada qual contendo
‘uma e6pia de determinada informagio acessada por um iden-
tificador. Dentre estes nds ha pelo menos um responsével por
receber as requisigdes provenientes dos clientes e repassé-las
0s demais, garantindo assim a sua sincronizagio. Chamaremos
este componente de “né coordenador” (NC), sendo o responsé~
vel por atuar em dois momentos fundamentais relacionados &
consisténcia dos dados.
(O primeiro momento diz respeito A ago de escrita, Ao receber
uma requisigao deste tipo, o NC deveré informar todos os nés
(incluindo a si préprio) a respeito da operacio. O nimero de
1n6s cuja operagao de escrita foi bem sucedtida seré representado
pela varidvel W.
J4 0 segundo momento ¢ 0 da consulta. Ao obter uma requi-
sigo deste tipo, o NC deverd consultar todos os demais nés
Gncluindo a si mesmo novamente) a respeito do valor relacio-
nado a chave recebida, O mtimero de nés que retornou o mesmo
valor para esta consulta é representado pela variavel R.
Convencionou-se chamar de consisténcia forte quando 0
numero de escritas acrescido do niimero de consultas bem
sucedidas for maior que o ntimero de cépias de determinada
informagao, ou seja, quando R + W > N. Se R + W <= N, temos
aconsistencia fraca, & interessante observar que normalmente
a consisténcia fraca (ou leve) é muitas vezes temporéria. Caso
em um primeiro momento seja obtido um valor desatualizado,
passado algum tempo na maior parte das implementacdes de
bancos de dados NoSQL passamos a obter o valor correto.
‘Como ficou claro, a obtengao de consisténcia forte é muito
mais cara do ponto de vista computacional e aumenta significa-
tivamente conforme o numero de nds que compoem um SGBD
distribufdo aumenta. Por se tratar de um requisito basico de
praticamente todas as implementagdes dos SGBDRs atuais, €
mais uma razdo pela qual estes sistemas possuem sérios pro-
blemas de escalabilidade e performance ao atingirem bases de
dados de maior tamanho.
Naturalmente, esta é uma brecha explorada por diversas solu-
ses NoSQL, que ao oferecerem consisténcia fraca temporaria
dos seus dados ultrapassam a largos passos os bancos de dadios
relacionais.
Oteorema CAP
No ano 2000 o norte-americano Eric Brewer fez uma apresen-
tagio que entrou para a histéria da ciéncia da computacéo influenciou de maneira marcante a implementagdo de todo
sistema distributdo a parti daquele momento, especialmente
0s nao relacionais, Foi apresentado 0 teorema CAP, que prova
6 ser possivel a qualquer sistema distribuido implementarno
‘méximo duas das trés caracteristicas abaixo:
+ Consisténcia: todos osnés de um sistema distribufdo acessam
exatamente a mesma informacio a qualquer momento;
Disponibilidade (Availability: toda requisigéo recebida pelo
sistema geraré uma resposta
¢ Tolerancia a falhas (Partition Tolerance} o sistema continua a
funcionar caso um ou mais de seus nés enfrente dificuldades,
Dado estar provada a incapacidade de existirem sistemas dis-
tribuicos que atendam aestes trs requisitos, hé dois caminhos
a serem seguidos: continuar tentando ou simplesmente tirar
proveito da situacao. Naturalmente, as bases de dados NoSQL.
tiraram proveito da segunda escolha. Na Figura podemos ver
quais as escolhas feitas por alguns dos SGBDs mais conheci
atualmente de acordo com este prinetpio.
Disponibilida
Bancos de dados
relacionals CouchD8, Riak
Consistencla edis, MongoDB,BigTable
Figura. Alar do eorema AP
Dada a natureza de um SGBDR no qual haja tabelas distri-
buidas entre mais de um n6, faz-se natural que alta disponi-
bilidade e consisténcia dos nés seja o foco. Para entender a
razao por tras deste principio, basta levar em consideragao 0
fato de que uma das operagdes mais comuns ao lidarmos com
estas bases de dados diz respeito justamente a juncdo de dados
entre tabelas. Dificilmente obteriamos consisténcia caso um
16 responsével por armazenar parte de uma tabela nao esteja
disponivel.
Obtensao de alta disponibilidade dos nds 6 uma tarefa dificil,
Sendo assim, é natural que seja cada maior atencao a consis-
tencia e tolerdncia a falhas. Nestes casos ¢ comum que cada
6 possua uma c6pia dos dados. Caso uma instancia esteja
indisponivel, outra normalmente esta disponivel permitindo
executar a consulta ou escrita novamente sem maiores proble-
‘mas. Ao lidarmos com escrita neste caso, esta ser posterior-
a i i
mente replicada aos nés que se encontravam indisponfveis no
‘momento da falha sem problemas.
NosaL
‘Apés tanto falarmos sobre o modelo relacional chegou a hora
de tratar a questo NoSQL. O que este nome significa de fato?
Interpretado literalmente, temos a negacdo da linguagem SQL,
‘mas sabemos que vai além disto: estamos lidando na realidade
com toda uma gama de sistemas gerenciadores de banco de
dados que néo seguem 0 modelo relacional.
Ao pensarmos em banco de dados dois modelos devem ser
Jevados em consideracto: persisténcia, isto ¢, a organizacao fisica
dos dados e pesquisa. NoSQL implica, na maioria das vezes,
«em modelos mais simples que os adotados pelo relacional. Um
dos principais objetivos dos desenvolvedores destas solugSes
6 a partir de uma abordagem mais simplista do problema da
persisténcia eobtencao dos dads, trazer maior previsibilidade,
performance e escalabilidade & TI. Uma das ideias bésicas por
trés deste movimento é a de que alternativas mais simples de
persisténcia e obtengio de dados geram sistemas menos comple-
x08, mais féceis de manter e, ao menos em teoria, também mais
performaticos e escaléveis.
Modelo de pesquisa: negando.o SQL
‘Ao pensarmos em uma Kinguagem de consulta 6 natural que
© primeiro nome que venha & mente seja SQL. Novamente, de
to acostumados & sua presenga, raras vezes analisamos sua
natureza. Entendero diferencial ferecido pelos sistemas NoSQL
requerrefletir sobre o que estes se opGem: uma das linguagens
mais bem sucedidas da histéria da computacio.
SQL ¢ uma linguagem declarativa: 0 programador nao precisa
se preocupar como os dados sfo obtidos, mas sim o que deve
ser retornado pelo SGBDR. A responsabilidade pela escotha da
melhor estratégia de busca é de um componente arquitetural
fundamental nestes sistemas: 0 otimizador de consultas, que
20 liberar © desenvolvedor deste fardo the oferece um ganho
significatvo de produtividade. Outro aspecto benéfico funda-
mental do SQL ¢ 0 fato de ser uma linguagem relativamente
simples que permite seu uso por programadores “casuais’,
caracteristica esta que é um dos principais fatores por trés do
sucesso em sua adogio.
Infelizmente nem tudo so flores: o prego que se paga pela
natureza declarativa do SQL ¢ imprevisbilidade do custo com-
putacional de nossas constltas. Conforme o tamanho da base de
dlados aumenta e sua modelagem se torna mais complexa, no
so raras as vezes em que o otimizador de consultas opta por
estratégias equivocadas e passa a necessitar do auxitio de um
DBA ou profissional experiente que se dedicard a monitorar e
modificar a estrutura do banco de dados em busca de melhor
performance e escalabilidade
Ja do lado NoSQL percebe-se claramente a tendéncia oposta.
(bserva-se uma abordagem menos decarativa e maisimperativa,
‘muitas vezes transferindo-se a responsabilidade pela definicio
Figo 11 SQL Magazine 11 das estratégias de busca do SGBD para a aplicagéo que 0 usa,
‘Osdesenvolvedores abrem mao dos ganhos de produtividade em
tzoca de uma maior previsibilidade no comportamento de seus
sistemas, obtendo muitas vezes ganhos significativos de perfor-
‘mance ¢ escalabilidade. Outra consequéncia desta transferéncia
-E2 redusao do custo operacional, uma vez. que a figura do DBA
‘s=orna menos necesséria
Modelos de persisténcia: auséncia de esquema
‘Uma caracteristica comum a maior parte das solugbes NoSQL
és auséncia de rigidez na estruturagdo dos dados. Nega-se a
‘homogeneidade vertical: enquanto em SGBDRs ¢ obrigatéria a
‘presenca de esquemas, isto 6, as meta informagies que definem
‘gual o conjunto de tamanko fixo de campos e seus respectivos
fipos, nomes e regras de validagto, temos agora estruturas de
“dados mais livres, cuja responsabilidade pela organizacio in-
‘ema 6 transferida do SGBD para a aplicagio que as manipula.
‘Osregistros sedem seu lugar para estruturas de dados flexiveis,
{gbe do obrigam a existencia de atributos e, com isto, natural-
‘rente oferecem uma solugao muito mais eficiente para o real
‘problema da organizacdo dos dados que no éahomogencidade
‘borizontal, mas sim a vertical. Trata-se de um fato bésico na ge-
‘Encia de qualquer informagio: para que um conjunto de dados
‘sea bem organizado, o primordial é que possamos agrupar
‘em um conjunto apenas informag6es referentes a um tipo de
‘extidade. O letor deve se lembrar neste momento que a homo-
{gencidade vertical, tal como mostramos no inicio deste texto, €
igo dificil de ser obtido em estruturas de dados que preguem
= homogeneidade horizontal.
Enormal que esta auséncia de esquema se mostre confusa em
‘um primeiro momento, Para clarificar os conceitos,trataremos
‘agora de alguns dos principais modelos adotados pelas bases
de dados NoSQL.
Omodelo chave-valor
‘Omaissimples dos paradigmas adotados pela solugdes NoSQL
40 chave-valor. Seu princfpio bésico de funcionamento consiste
fem executar consultas 20 banco de dados usando um tinico
aiributo: a chave identficadora. Na realidade, temos a imple-
‘mentagio de uma tabela de hash: ma estrutura de dados que
ros permite obter informagOes a partir de chavesidentificadoras
‘com custo constante (ox quase)
© funcionamento destas estruturas é simples, Toda consulta
to banco de dados se dé apenas por uma chave identificado-
ra, que pode ser tanto um texto simples como uma matriz. de
bytes, 0 que pode variar de acordo com o SGBD escolhido. Ao
receber uma consulta representada por esta chave,o sistema iré
processé-la usando uma funcdo transformadora, responsavel por
Converter a chave em um valor numérico epresentando o encle-
rego de meméria ou armazenamento aonde o dado se encontra
F interessante observar que no modelo chave-valor 0 esquema
de persisténcia 6 também dos mais simples: a grosso modo, 0s
ddados sio armazenados como um conjunto de bytes, que seré
12 SQLMagazine «digo 111
interpretada de volta pelo driver de acesso ou até mesmo pela
propria aplicacdo que originou a consulta.
Na Figura 6 podemos ver um exemplo de funcionamento desta
cestratégia: ao buscar os dados de uma pessoa identificada pela
chave “pessoa:1", a funcio transformadora converterd esta chave
‘em um endereso de armazenamento aonde encontram-se infor-
mages relativas a esta. O segundo exemplo, bastante comum,
6 usado para obter de volta um arquivo binérrio, representado
pela chave “arquivo:3”.
Figura 6 equemstizaco do fundonamento do made chave-rlor
E importante salientar que a chave também pode ser usada em
sistemas distribuidos para identificar o servidor aondea informa-
ose encontra, tal como ilustramos na Figura 7, que na realidade
¢ uma ampliacio do exemplo exposto na Figura 6. Nestes casos,
hg um ou mais nés do sistema que executam a funcao de coorde-
nadores, responséveis por identificar 0 servidor alvo e também,
‘no raro, armazenar informagoes.
Figura 7.0 wsode chavesnadetiiagio de serioresem sistemas dtbudes
‘A modelagem de dados no modelo chave-valor é em sua maio-
ria, definida pelas convengbes adotadas na nomeacio das chaves..
‘Um padrao bastante comum na industria consiste em identificar
6 tipo de entidade armazenado em uma chave pot seu prefixo.
Sendo assim, chaves como pessoal, pesson:2 e pesson:3 identifi
cariam informacbes relativas a pessoas, sendo 0 prefixo usado
para representar o identificador de cada caso, Relacionamentos também so representados da mesma forma. Sendo assim, uma
-modelagem possivel nestes casos pode ser estabelecida usando-
se amesina estratégia de definigdo baseada em prefixos. A chave
pessondscompras por exemplo pode representar a lista de compras
da pessoa com identificador 4
‘Observe que ha aqui uma tendéncia imperativa: 0 desenvolve-
dor implementa um algoritmo que descreve como 0s dados s80
‘obtidos. No exemplo acima citado, este algoritmo consistiria na
concatenagao textual a fim de obtermos um valor especttico.
‘Um uso bastante comum do modelo chave-valor se dé quando
precisamos lidar com estruturas de dados sem esquema e cujo
principal modo de acesso se dé por sua chave identificadora.
A grande vantagem nestes casos se dé pelo fato de termos um
tempo de acesso a informacao significativamente mais curto:
ro € necessério um otimizador de consultas e, levando em
consideracao 0 fato da fungao transformadora ser normalmente
‘um algoritmo de execugéo répida, temos a garantia de que nosso
tempo de resposta seré sempre homogeneo, pois a estrutura
bésica da consulta ~ apenas uma chave ~ ¢ sempre a mesma
E sem sombra de dividas o modelo de persisténcia com maior
previsibilidade conhecido,
(Outro uso bastante comum desta categoria de bancos de dados se
{48 como mecanismo de cache, evitanclo assim que a execucio de
procedimentos computacionais caros repetidos sejam executados
repetidas vezes levando em consideracéo os mesmos parémetzos
(er Nota do DevMan 2). Dado que a esmagadora maioria dos
SGBDs do tipo chave-valor implementam mecanismos de expira-
‘glo de chaves, isto os torna a ferramenta ideal na implementacio
deste tipo de ferramenta.
Para finalizar, dado 0 acesso mais répido a informagio, é tam-
bém o modelo apropriado para aquelas situagées nas quais &
necesséria a atualizacio com alta frequéncia ce uma determinada
informagio cujoacesso se dé apenas por sua chaveidentificadora
como, por exemplo, informag6es estatisticas como contadores de
acesso e na inckstria de jogos, aonde dados como placar e estado
dos jogadores precisa ser atualizado com alissima frequéncia,
As implementagdes mais populares deste modelo atualmente
io 0 Redis, Memeached, SimpleDB e Infinispan,
Omodelo documental
‘© modelo documental tem se mostrado um dos mais populares
por resolver de forma bastante interessante o problema da homo-
‘geneidade vertical e também por ser o mais cil de ser comparado
‘a0 mundo relacional.
Ao invés de tabelas, temos colegGes, que so as responséveis
pot agrupar as informagdes referentes as entidades pertencentes
uma mesma categoria. Nao ha registros, mas sim documents.
‘Um documento é simplesmente um conjunto de atributos, nor-
almente representados sob o formato JSON, tal como podemos
verna Listagem 1 em que os dados do sistema de ativos tratado
zo inicio do artigo sao armazenados em uma mesma colecio que
chamaremos de “ativos’.
LUstagom 1. Exemple de documentoe
303
nome"Fuscat
tipo Auroméver,
fabrcante-Volsager,
cor'verdet
AateAlocamenti“¥/1/201%
prevsacDevoluca:“1/1/2100"
a
i303
‘nomeNotebook
tipe"Compurador,
memoir
rocessadon*Crel7,
programas [JDK -Notepad Grail
Etigo 111 «SQL Magazine 13 Podemos dizer que 0 documento é um “anti-registro”. Ao
contrério do registro, 0 ntimero de atributos nao ¢ fixo, no
hé obrigatoriedade a respeito da presenca de um ou outro €
nada impede que o tipo do atributo varie de documento para
documento, ou seja, nao hé homogencidade horizontal
Otermo coluna também nao se aplica ao modelo documental,
‘mas sim atributo, Isto porque um atributo de mesmo nome pode
aparecer em mais de um documento armazenando valores de
tipos diferentes.
Na Listagem 1 vemos estes princfpios de forma nitida.
A homogeneidiade vertical foi garantida: nossa colegdo arma-
zena ativos, porém dado que cada ativo é de um tipo diferente,
em cada documento existem atributos que sio obrigatoriamente
comuns a todos (id, nome, tipo, alocador) e, em cada documen-
to, de acordo com seu tipo, encontram-se presentes apenas os
atributos que thes dizem respeito. Nao hé razao pela qual deva
existir 0 atributo placa em um documento usado para repre-
sentar um computador.
Curiosamente, apesar do modelo de persisténcia documental
ser radicalmente diferente do relacional, instintivamente so
bastante semelhantes quando levamos em consideragéo omodo
como buscamos informagées em ambos 0s casos. Ao contrério
do modelo chave-valor que s6 nos possibilita efetuar pesquisas
por um identificador, agora podemos novamente escrever con-
sultas declarativas, exatamente como estamos habituados na
linguagem SQL que, alids, também pode ser aplicada em bases
documentais através de ferramentas que simulam a execugao
de consultas deste tipo. O modo como as consultas sto escritas
no modelo documental varia de acordo com a implementacao
mas, a grosso modo, so executadas de forma similar & exposta
na Listagem 2, em que buscamos por todos os ativos do tipo
“Automével”
Ustagem 2 Consulta om ua base documenta no Monge
atvosfindtiporAutoméver)
14 SOL Magazine «Edicéo 111
Podemos facilmenteimaginara consulta expostanna Listagem2
se fosse implementada em SQL: “select *from ativos where tipo =
‘Automével”, Talvez esta proximidade no modo como obtemos
1s informag6es seja um dos fatores que tenham tornado tio
popular 0 modelo documental entre os programadores habi-
‘tuados com o paradigma relacional.
‘A maneira como a modelagem de dados ¢ feita também sofre
profundas modificagSes quando comparada a0 modo como
trabalhamos no modelo relacional. Enquanto no segundo nosso
foco esté em minimizar a redundancia de dados a partir do
relacionamento entre tabelas, vemos 0 exato oposto nos bancos
de dados documentais. Apesar de também podermos criar
relacionamentos entre documentos, vemos a minimizacio de
seu tso ¢ a maximizacfo das agregacdes.
Por agregacao deve serentendido o procedimento de agrupar
em um mesmo documento subdocumentos que, no modelo
relacional, corresponderiam a jungées no modelo relacional.
Logicamente ha o risco de termos um custo maior de manuten-
‘¢40 dos dados devido & sua repetigo mas, em contrapartida,
20 obtermos um documento, evitamos a ocorréncia de jungoes:
© SGBD nos retorna o documento inteito de uma tinica vez,
nos fornecendo com isto um ganho imenso de performance, 0
que muitas vezes compensa o risco. Além disto, é interessante
observar que uma vez tenhamos um custo alto de manutengio
de dados, sempre podemos implementar relacionamentos entre
documentos a fim de obter uma base de dados com o minimo
de informagdes redundantes.
principal uso do modelo documental ocorre justamente
nas situagdes em que registros nao s4o a estrutura de dados
apropriada na modelagem do sistema, ou seja, quando hé uma
grande variacao entre os atributos que compéem cada entidade
que pertenca a determinada categoria, exatamente como ocorre
zo sistema de ativos exposto como exemplo neste artigo. Sendo
ha previsibilidade a respeito da aparigao de novos atributos
em seu sistema, 0 modelo documental se apresenta como uma
alternativa que deve ser levada em consideragao.
‘Outro uso bastante comum do modelo documental ocorre em
sistemas que precisem lidar com arquivos digitais. Bases de dados
documentais so excelentes para armazenar este tipo de informa-
fo e seus respectivos atributos, 0 que os torna uma alternativa
excelente na implementacao de sistemas de gestio eletronica de
documentos (GED). Nestes casos, um dos atributos é usado para
armazenar 0 conjunto de bytes que representa 0 arquivo digital
€.0s demais as metainformagdes relacionadas ao mesmo.
Atualmente as implementagdes mais populares do modelo
documental so 0 MongoDB e CouchDB.
O modelo baseado em grafos
© foco do modelo baseado em grafos est no relacionamento
entre as entidades. Como 0 proprio nome jé nos diz, nossa
rmetéfora agora serd o grafo: a estrutura de dados que usamos
quando precisamos modelar o relacionamento entre divas ou
mais entidades em tum sistema. Para melhor entender este paradigma, faz-se necessério por-
tanto que conhegamos sua metéfora basica: o grafo. Um grafo
um objeto que possi dois componentes: 0 vértice, que repre-
senta aentidade e a aresta, que representa seu relacionamento
com outra entidade. A aresta pode ser uni ou bidirecional. Na
Figura 8 podemos ver como esta estrutura de dados é repre-
sentada graficamente.
Aresta 5. / Vartice
Figura 8 Reoresenarogrfia deum gate
Como pode ser observado na Figura 9, 0s relacionamentos
entre entidades pode ser uni ou bidirecional. Nao faz senti-
do pensar, por exemplo, em uma amizade unidirecional, ao
contrério das relagdes de chefia ¢ paternidade, claramente
unidirecionais. Estes relacionamentos, representados em um.
sgrafo sob a forma de arestas so 0 que realmente agrega valor
aos bancos de dados baseados em grafos.
£ facil entender o valor que este tipo de SGBD nos fornece.
Para tal, voltando-se a Figura 9, deixo como exercicio ao leitor
imaginar como seria a modelagem em um banco de dados re-
lacional de uma consulta que retornasse todas as pessoas que
so chefiadas por alguém e também sejam avis. Dica: em nosso
exemplo apenas Joca deveria ser retornado, Outro exemplo de
™modelagem difcil de ser feita em um banco de dados relacional
sio relasées bidirecionais como a de “amizade” presente em
nosso exemple
Figura. Erenplo de gro
© modo como pesquisamos em bases baseadas em gra-
fos pode se dar tanto declarativa quanto imperativamente.
No modo imperativo normalmente as pesquisas se dao de for-
‘ma navegacional. A consulta que deixamos como exercicio a0
leitor poderia ser implementada, em pseudo cédigo, tal como
na Listagem 3.
LUstagem 3. Consulta navepsconal em um gafo
1. Varies com chele = todos os wrtices que possuem
aestas de entada do tipo "Chet
2. Para cada um dos vrtices com chef, me etme
*squeles que seem pas de pesioas que também seam pls,
J consultas declarativas irdo variar de acordo com o forne-
cedor do SGBD. Um projeto interessante que permite unificar
diferentes fornecedores é 0 Gremlin, que fornece uma lin-
guagem de consulta bastante interessante que podemos ver
‘exemplificada na Listagem 4, Como pode ser visto, em apenas
‘uma linha conseguimos resolver de maneira bastante fécil 0
problema que propusemos ao leitor. No caso, serdo retornados
todos os vertices que recebem como entrada uma aresta do
tipo “Chefia’, e que gerem como aresta de safda do tipo “Pai”
duas vezes, ou seja, todas as pessoas chefiadas por alguém e
que sejam também avs,
LUstagem 4. Usando a inguagem Gremin
in( Chefs ou Par outePa
O interessante dos SGBDs baseados em grafos € 0 fato de
Possuirem caracteristicas documentais, Tanto arestas quanto
Vértices possuem um ntimero arbiteério de atributos, o que
torna este paradigma de persisténcia ideal ao lidar com situ-
agdes nas quais o registro nfo seja a estrutura de dados mais
adequada na modelagem do sistema eos relacionamentos entre
as entidades exercem funcSo fundamental,
Das aplicagdes mais famosas do modelo baseado em gra-
fos estd a implementacio de redes sociais como Facebook €
Linkedin: sistemas nos quais o foco esté nitidamente no rela-
cionamento entre entidades, e dos quais conseguimos extrair
informag6es importantes como a listagem de amigos dos amigos
‘ow mesmo de pessoas que provavelmente conhecamos com base
em nossos ciclos de amizades.
Cutra aplicacéo bastante interessante dos bancos de dados
‘r4ficos 640 aplicagdes que precisem lidar com roteamento de
vefculos, tal como ocorre em cadeias de distribuigao e trans
porte. Neste tipo de sistema modelamos 0s possiveis pontos de
Parada como vértices e as distancias como arestas, Com base
nesta organizasio, podemos extrair importantes informagoes
como caminhos mais curtos, mais baratos, et.
De modo geral, qualquer situacio na qual seja necessério lidar
com o relacionamento entre objetos, SGBDs baseados em grafos
Esicdo 111 +SQL Magazine 15 Patel (o foh1 0]
se mostram uma alternativa muito interessante. Atualmente
as implementagSes mais famosas deste modelo so 0 Neos] e 0
OrientDB.
NoSQL ou SQL: qual usar?
‘Tendo visto todas as opgbes expostas neste artigo, o leitor
deve se perguntar neste momento a respeito de qual caminho
seguir em seus sistemas. Como jé era de se esperar, nao hé uma
resposta geral para o problema, visto que cada situacio possui
requisitos especiais que, muitas vezes, ndo se repetem com tanta
frequéncia. Entretanto, a grosso modo 0 que se observa € uma
abordagem hibrida do problema. NoSQL nao deve ser visto como
‘uma alternativa excludente, mas sim complementar a modelagem
de sistemas.
‘Se por exemplo a maior parte do seu projeto pode ser modelada
adotando o registro como estrutura de dados basica e apenas uma
funcionalidade especifica requer o processamento de relaciona-
‘mentos de forma intensa, por que no manter dois SGBDs, um
relacional e outro baseado em grafos? Hé com certeza o maior
‘custo de manutengo com relagdo a sineronizaglo entre bases
de dados distintas, entretanto, como pudemos ver no decorrer
deste artigo, nfo existe uma solucio capaz de atender a todas as
‘nocessidadles de persistencia e obtengio de dados em um sistema
0 “No” de NoSQL nao deve ser entendido como um mero néo,
‘mas sim como um “nao apenas” (Not Only)
Outro exemplo interessante de abordagem mista ocorre, como
Você também pode gostar
- The 7 Habits of Highly Effective People Personal WorkbookNo EverandThe 7 Habits of Highly Effective People Personal WorkbookNota: 4 de 5 estrelas4/5 (2515)
- Habit 6 Synergize: The Habit of Creative CooperationNo EverandHabit 6 Synergize: The Habit of Creative CooperationNota: 4 de 5 estrelas4/5 (2499)
- Habit 3 Put First Things First: The Habit of Integrity and ExecutionNo EverandHabit 3 Put First Things First: The Habit of Integrity and ExecutionNota: 4 de 5 estrelas4/5 (2507)
- How to Win Friends and Influence People: Updated For the Next Generation of LeadersNo EverandHow to Win Friends and Influence People: Updated For the Next Generation of LeadersNota: 4 de 5 estrelas4/5 (2326)
- Art of War: The Definitive Interpretation of Sun Tzu's Classic Book of StrategyNo EverandArt of War: The Definitive Interpretation of Sun Tzu's Classic Book of StrategyNota: 4 de 5 estrelas4/5 (3321)
- Never Split the Difference: Negotiating As If Your Life Depended On ItNo EverandNever Split the Difference: Negotiating As If Your Life Depended On ItNota: 4.5 de 5 estrelas4.5/5 (3294)
- Pride and Prejudice: Bestsellers and famous BooksNo EverandPride and Prejudice: Bestsellers and famous BooksNota: 4.5 de 5 estrelas4.5/5 (20479)
- The Perfect Marriage: A Completely Gripping Psychological SuspenseNo EverandThe Perfect Marriage: A Completely Gripping Psychological SuspenseNota: 4 de 5 estrelas4/5 (1120)
- The Subtle Art of Not Giving a F*ck: A Counterintuitive Approach to Living a Good LifeNo EverandThe Subtle Art of Not Giving a F*ck: A Counterintuitive Approach to Living a Good LifeNota: 4.5 de 5 estrelas4.5/5 (20054)
- The Subtle Art of Not Giving a F*ck: A Counterintuitive Approach to Living a Good LifeNo EverandThe Subtle Art of Not Giving a F*ck: A Counterintuitive Approach to Living a Good LifeNota: 4 de 5 estrelas4/5 (5810)
![American Gods [TV Tie-In]: A Novel](https://imgv2-2-f.scribdassets.com/img/audiobook_square_badge/626321117/198x198/22ab6b48b6/1712683119?v=1){kind=icon}
