LEANDRO DE GÓIS DA SILVA - repositorio.pgsskroton.com
35
Londrina 2017 LEANDRO DE GÓIS DA SILVA ARQUITETURA E APLICAÇÃO DE BANCOS DE DADOS NÃO-RELACIONAIS
Transcript of LEANDRO DE GÓIS DA SILVA - repositorio.pgsskroton.com
Londrina 2017
LEANDRO DE GÓIS DA SILVA
ARQUITETURA E APLICAÇÃO DE BANCOS DE DADOS NÃO-RELACIONAIS
Londrina
2017
ARQUITETURA E APLICAÇÃO DE BANCOS DE DADOS NÃO-RELACIONAIS
Trabalho de Conclusão de Curso apresentado à Universidade Pitágoras Unopar, como requisito parcial para a obtenção do título de graduado em Engenharia da Computação.
Orientador: Luiz Gabriel S. Viani
LEANDRO DE GÓIS DA SILVA
LEANDRO DE GÓIS DA SILVA
ARQUITETURA E APLICAÇÃO DE BANCOS DE DADOS NÃO-RELACIONAIS
Trabalho de Conclusão de Curso apresentado à Universidade Pitágoras Unopar, como requisito parcial para a obtenção do título de graduado em Engenharia da Computação.
BANCA EXAMINADORA
Prof(ª). Titulação Nome do Professor(a)
Prof(ª). Titulação Nome do Professor(a)
Prof(ª). Titulação Nome do Professor(a)
Londrina, __ de ________ de 2017.
Dedico este trabalho a Deus e a meus
pais Sebastião e Valdenice.
AGRADECIMENTOS
Agradeço primeiramente a Deus, que me concedeu saúde, sabedoria, coragem
e muito me abençoou durante esses cinco anos.
Fica meu agradecimento aos meus pais, que fizeram tudo que estava ao alcance
deles para que eu fizesse essa graduação e pelo apoio incondicional em todos esses
anos.
Agradeço a todos os professores que em minha caminhada me incentivaram e
contribuíram para o meu crescimento profissional e pessoal.
Agradeço aos meus colegas de classe, em especial aos meus amigos César e
Estella, pelo companheirismo e ajuda mútua durante os anos. Por fim, fica meu
agradecimento aos colegas de trabalho, amigos e todos que de alguma forma me
ajudaram, incentivaram e deram apoio na realização desse trabalho.
SILVA, Leandro de Góis da. Arquitetura e Aplicação de Bancos de Dados Não-Relacionais. 2017. 36 f. Trabalho de Conclusão de Curso (Graduação em Engenharia da Computação) – Universidade Pitágoras Unopar, Londrina, 2017.
RESUMO
A informação é essencial em sistemas computacionais, logo o armazenamento das informações também é importante. Ao longo dos anos foram criados modelos de bancos de dados que pudessem oferecer uma condição de armazenamento e manipulação de dados de forma satisfatória. Na década de 70, surgiu o Modelo Relacional, onde as informações são guardadas em repositórios chamados de tabelas formadas por tuplas e atributos. Desde então esse modelo se popularizou e expandiu-se de tal forma devido a seu fácil uso e entendimento. No alvorecer do novo milênio porém, houve um aumento significativo de informações, que foram se expandindo de maneira muito rápida, um ataque dos clusters e do BigData, por exemplo. Nessa era dos grandes volumes de dados a serem manipulados o modelo relacional começou a apresentar pontos em que se torna inviável o seu uso. Acontece então o surgimento de uma tecnologia, chamada de NO-SQL, com o propósito de se tornar uma alternativa ao uso de bancos de dados relacionais em aplicações que requerem o tratamentos de quantidades significativas de informações. Neste trabalho são apresentadas as circunstâncias do surgimento dessa nova tecnologia, abordadas as suas características e principais produtos disponíveis no mercado e para que tipo de aplicação cada modelo de dados é a melhor solução. Se trata de um estudo pautado em uma revisão de literatura, com um olhar crítico de autores que abordaram esse assunto anteriormente. Palavras-chave: Informação; Banco de Dados; Modelo Relacional; NO-SQL.
SILVA, Leandro de Góis da. Non-Relational Databases Architeture and Application. 2017. 36 f. Trabalho de Conclusão de Curso (Graduação em Engenharia da Computação) – Universidade Pitágoras Unopar, Londrina, 2017.
ABSTRACT
Information is essential on computer systems, storing this information are equally important. Through the years, it was created several kinds of databases that provided conditions for store and manipulate the information in a satisfactory way. From the 70's, the Relational Model emerged, where information is saved in repositories called tables and formed by tuples and attributes. Since then, due its easier usage and understanding, the Relational Model has expanded and became the most popular database model. At the dawn of the new millennium, there was a significant increase of information to be stored, which in turn have been expanding dramatically fast, as for example, a clusters and BigData attack. In this age of large volumes of data to be manipulated, the relational model starts to present points that make their use infeasible. Given this, the emergence of a technology called NO-SQL, with the purpose of became an alternative way instead of use the Relational Model on application that requires the treatment of a significant information amount. On this article, it is presented the circumstances that led to this new technology, characteristics, main products available on the market and which kind of application this technology is recommended. This review is about a literary study, with a critical view of authors who have approached this subject previously. Key-words: Information; Database; Relational Model; NO-SQL.
LISTA DE ILUSTRAÇÕES
Figura 1 – Título de Comandos SQL ....................................................................... 17
Figura 2 – Exemplo de Estrutura de Banco de Dados de Grafos ............................ 19
LISTA DE QUADROS Quadro 1 – Exemplos de Bancos de Dados NO-SQL ..................................... 23
Quadro 2 – Comparativo entre Bancos de Dados Relacional e NO-SQL ........ 32
Quadro 3 – Uso Apropriado de Bancos de Dados NO-SQL ............................ 33
LISTA DE ABREVIATURAS E SIGLAS
SQL Structured Query Language
NO-SQL Not Only Structured Query Language
SGBD Sistema Gerenciador de Banco de Dados
API Application Programming Interface
XML eXtensible Markup Language
JSON JavaScript Object Notation
SUMÁRIO
1 INTRODUÇÃO ................................................................................... 13
1.1 JUSTIFICATIVA ............................................................................... 13
1.2 PROBLEMA DE PESQUISA ............................................................ 13
1.3 OBJETIVOS ..................................................................................... 14
2 METODOLOGIA ................................................................................. 15
3 O MODELO RELACIONAL, SURGIMENTO E CARACTERÍSTICAS DO NO-
SQL ................................................................................................................. 16
3.1 BANCO DE DADOS RELACIONAL ................................................. 16
3.1.1 A Linguagem SQL......................................................................... 17
3.1.2 As Limitações do Modelo Relacional ............................................ 18
3.2 O NO-SQL ....................................................................................... 19
3.2.1 Modelos de Dados em NO-SQL ................................................... 20
3.2.2 Modelos de Distribuição em NO-SQL ........................................... 21
3.2.3 Consistência em NO-SQL ............................................................. 22
3.2.4 Marcadores de Versões em NO-SQL ........................................... 22
4 OS DIFERENTES TIPOS DE BANCO DE DADOS NO-SQL ............ 23
4.1 BANCO DE DADOS DE CHAVE VALOR ........................................ 23
4.1.1 Propriedades de bancos de dados de chave-valor ....................... 24
4.1.2 Circunstâncias adequadas para a implementação ....................... 25
4.2 BANCO DE DADOS DE DOCUMENTOS ........................................ 26
4.2.1 Propriedades de bancos de dados de documentos no MongoDB 26
4.3 BANCO DE DADOS EM FAMÍLIAS DE COLUNAS......................... 28
4.4 BANCO DE DADOS DE GRAFOS .................................................. 28
5 A PERSISTÊNCIA POLIGLOTA E RESULTADOS ........................... 30
5.1 EXEMPLO DE APLICAÇÃO DA PERSITÊNCIA POLIGLOTA ........ 30
5.2 INQUIETUDES SOBRE A PERSISTÊNCIA POLIGLOTA ............... 31
5.3 RESULTADOS ................................................................................ 32
CONSIDERAÇÕES FINAIS .................................................................. 35
REFERÊNCIAS ..................................................................................... 36
13
1 INTRODUÇÃO
A informação é essencial para qualquer empresa, extrair e manipular essas
informações é crucial para organização nas tomadas de decisões. Todas as
informações ficam gravadas em um repositório de dados, a esse repositório é
chamado de banco de dados. Ele que armazena as informações e a partir dele que
elas são extraídas e manipuladas, utilizar banco de dados para guardar informações
é importante. Existem variados tipos de bancos de dados para os mais diversos usos,
porém, os baseados no Modelo Relacional são amplamente mais utilizados.
Os bancos de dados relacionais estão em utilização desde o final dos anos 70
e acredita-se que seu uso não terá fim em um futuro próximo, isso caso tenha fim um
dia. Uma importante questão é que a cada dia, o volume de dados com que as
aplicações têm que lidar só aumentam. Os bancos de dados relacionais em
determinadas ocasiões encontram limites em suas técnicas e ferramentas. Surgiu
então o NO-SQL (Not Only Structured Query Language), uma tecnologia que veio para
trazer soluções em questão de desempenho, disponibilidade e escalabilidade no
tratamento do armazenamento e processamento de grandes volumes de dados.
1.1 JUSTIFICATIVA
Durante o período de graduação, os alunos geralmente têm contato com
disciplinas referentes a banco de dados, que envolvem o estudo da arquitetura,
modelagem e SQL (Structured Query Language), sempre relacionado a banco de
dados relacionais. Este projeto surgiu para apresentar um tema que é relativamente
novo e academicamente pouquíssimo abordado, acreditando ser relevante discutir
como funcionam os bancos de dados não-relacionais, em quais casos seu uso pode
ser ponderado, visando expandir o campo de visão dos interessados por essa área.
1.2 PROBLEMA DE PESQUISA
O modelo mais utilizado para Banco de Dados é o relacional, formado por
tabelas e aplicando schema. Porém, ele não é muito eficiente ao trabalhar com um
volume muito grande de dados. Qual a opção para uso de um banco de dados capaz
14
de manipular uma grande quantidade de dados, podendo gerar sistemas que
possuam melhor execução, escalabilidade e fácil programação?
1.3 OBJETIVOS
O projeto possui como objetivo geral apresentar uma visão detalhada sobre a
tecnologia NO-SQL examinando a arquitetura de banco de dados não-relacionais e o
uso do modelo de banco de dados de documentos. Os objetivos específicos do projeto
são:
Analisar como decorreu o surgimento, os principais aspectos e
características de NO-SQL.
Apontar as situações em que possam ser utilizados os diferentes tipos
de banco de dados não relacionais.
Verificar o NO-SQL através do modelo orientado a documentos.
15
2 METODOLOGIA
O projeto tem por objetivo apresentar uma opção para o Modelo Relacional de
banco de dados para situações em que este já não for a opção mais viável. Para tal o
trabalho foi dividido em capítulos que propiciem uma adequada revisão de literatura
sobre o tema discorrido.
No primeiro capítulo foi realizada uma pesquisa em uma base sólida de
bibliografias que abordam a arquitetura e organização de SGBD (Sistemas
Gerenciadores de Banco de Dados) a fim de que os principais conceitos sobre o
assunto fossem apresentados, evidenciando as limitações do Modelo Relacional.
Posteriormente foi descrevida a tecnologia NO-SQL, determinando suas principais
características, identificados e diferenciados os modelos não-relacionais.
No segundo capítulo, através de comparação entre cada um dos modelos de
dados NO-SQL, determinou-se para qual situação, cada um desses modelos possa
ser usado. O terceiro capítulo contemplou a utilização o banco de dados orientado a
documentos para que fossem assemelhadas as características de NO-SQL de
maneira mais prática.
16
3 O MODELO RELACIONAL, SURGIMENTO E CARACTERÍSTICAS DO NO-SQL
Extrair e manipular as informações passou a ser essencial para que as
empresas possam melhorar suas gestões e estratégias a fim de otimizar processos e
melhorar os resultados obtidos.
São inúmeras as vantagens em se utilizar de sistemas de informação com base
em computadores, como a recuperação e atualização das informações;
armazenamento das informações em menor espaço; vários usuários compartilhando
o mesmo dado e o utilizando para tarefas distintas; possibilidade de controlar a
redundância de informações prevendo incompatibilidade; mudança para uma
padronização e maior segurança de acesso.
De acordo com Ramakrishnan e Gehrke (2011), com a grande quantidade de
informações disponíveis, é necessário o uso de ferramentas para simplificar o
gerenciamento de dados e extração das informações que serão utilizadas.
O software usado para manipular dados é o SGBD (Sistema de Gerenciamento
de Banco de Dados). Há diferentes tipos de banco de dados, podendo citar entre eles
o tabular, em rede e o hierárquico. Entretanto o mais comum e utilizado é o banco de
dados relacional.
3.1 BANCO DE DADOS RELACIONAL
Por serem simples e terem uma boa performance, o modelo relacional veio a
se tornar um padrão em aplicações comerciais. Trata-se de um modelo formal que
tem sua base na teoria matemática das relações.
O princípio do modelo relacional surgiu em julho de 1970 e segundo definido
por Codd (1970, p. 377-387), os elementos básicos de banco de dados relacionais
são as relações, chamadas de tabelas, que são compostas por um domínio, linhas,
ou tuplas e colunas, ou atributos. Um dos primeiros SGBD a implementar esse modelo
foi o System R da IBM.
Uma das principais características de banco de dados relacionais são as
restrições. Elas garantem a integridade dos dados manipulados pelos usuários. Os
valores das colunas devem ser atômicos e monovalorados mas não devem ser nulos,
de valores desconhecidos ou inexistentes.
17
Dois conceitos ajudam a representar as associações entre as relações, que
aqui passam a ser chamadas de tabelas, são as chaves primária e estrangeira. As
chaves correspondem a um conjunto de um ou mais atributos, sendo classificadas
como primárias ou estrangeiras. Chave primária identifica de maneira única uma linha
da tabela, não pode ter valor nulo e recomenda-se ter o mínimo de colunas possível
com o menor tamanho possível, também chamada de PK (Primary Key). Chave
estrangeira é a chave copiada de uma chave primária de outra tabela a fim permitir o
relacionamento entre tabelas, também chamada de FK (Foreign Key).
Uma função importante de SGBD relacional é gerência de transações. Elmasri
e Navathe (2005, p. 316) definem uma transação como uma sequência de medidas
com uma função exclusivamente na aplicação do banco de dados. As transações
devem obedecer a quatro fundamentos que formadas pelas iniciais ACID que
correspondem a Atomicidade, Consistência, Isolamento e Durabilidade.
Atomicidade – Todas as operações são executadas. A transação é executada
completamente ou nada vai ser executado.
Consistência - O banco de dados tem que garantir que as restrições de
integridade que foram assumidas previamente satisfaçam as condições de
consistência.
Isolamento – Caso duas transações sejam executadas ao mesmo tempo, os
efeitos têm o dever de serem isolados uma da outra.
Durabilidade - Após uma transação tenha ocorrido com sucesso, seu resultado
não poderá ser desfeito.
Um SBGD relacional necessita de uma linguagem de consulta para permitir que
o usuário acesse os dados. O SQL é a linguagem adotada pela maioria dos bancos
de dados relacionais.
3.1.1 A Linguagem SQL
O SQL foi desenvolvido em um protótipo de sistema de banco de dados
relacionais da IBM nos anos 70. Em 1979, a Oracle lançou o primeiro banco de dados
relacional comercial que utilizava SQL. É uma linguagem English-like que utiliza
palavras como select, update, delete como parte de seu conjunto de comandos. Não
é procedural, é possível identificar quais informações o usuário precisa e não como
18
buscá-las. Todos os comandos SQL usam um otimizador para determinar a maneira
mais rápida de recuperar dados.
Pode ser usado por vários usuários como DBA's (Data Base Administrator),
programadores, gerentes, entre outros. Efetua diversas tarefas como consulta aos
dados; inserção, atualização e remoção de linhas de uma tabela; criação, modificação
e exclusão de objetos do banco de dados; além de controlar o acesso e garantir a
consistência do banco.
Os comandos SQL, demonstrados na figura 1, são divididos em: DML - Data
Manipulation Language – Linguagem de Manipulação de Dados: Insert, Update,
Delete, Select; DDL – Data Definition Language – Linguagem de Definição de Dados:
Create, Alter e Drop; DCL – Data Control Language – Linguagem de Controle de
Dados: Grant e Revoke; DTL – Data Transaction Language – Linguagem de
Transação de Dados: Commit, Rollback, Savepoint; DQL – Data Query Language –
Linguagem de Consulta de Dados: Select.
Figura 1 - Tipos de Comandos SQL
Fonte: Quora (2016).
O comando Select pertence a uma categoria própria, a DQL, porém em
definições mais antigas também era considerado um comando de manipulação de
dados (DML).
3.1.2 As limitações do Modelo Relacional
Com o crescimento rápido do número de aplicações, o volume de dados
também cresceu em ritmo acelerado. Os problemas inerentes ao uso do Modelo
19
Relacional estão na dificuldade de conciliação do modelo com a demanda por
escalabilidade frequente.
As possíveis soluções para esse problema são um upgrade no servidor ou
aumentar o número de máquinas que processem os dados. Porém, mesmo assim,
elas não seriam por si só suficientes em caso de aumento constante do número de
usuários. Foi seguindo essa linha de pensamento em solucionar os problemas do
modelo relacional que surgiu o NO-SQL.
3.2 O NO-SQL
A origem do termo NO-SQL veio em meados dos anos 90, como consequência
da solução de banco de dados que não possuía uma interface SQL, mesmo este
sistema sendo relacional. Só anos mais tarde o termo seria usado para representar
uma alternativa ao modelo relacional.
Basicamente os bancos de dados NO-SQL casam muito bem quando usados
em clusters, já que estes exigem melhor manipulação da grande quantidade de dados
e recursos computacionais devido a seu tráfego intenso desses mesmos dados.
Outros pontos importantes são bancos de dados open source (de código aberto), que
surgiram pelas necessidades da web do século 21 e não tem schema.
Para Sadalage e Fowler (2013, p.36-37) a principal diferença entre o modelo
relacional e o NO-SQL é um termo chamado persistência poliglota, que consiste em
usar em diferentes circunstâncias diferentes formas de armazenar dados, resultando
em uma tecnologia heterogênea de armazenamento, sempre entendendo a natureza
dos dados armazenados e de que maneira eles são manipulados.
A modelagem dos dados é a forma de demonstrar como os dados ficam
dispostos e organizados dentro da estrutura da aplicação. Dentro do modelo relacional
o diagrama de entidade-relacionamento é o tipo de modelagem dominante, onde
temos as representações de tabelas de linhas e colunas. O NO-SQL se afasta desse
tipo de modelagem sendo os tipos de modelos utilizados os seguintes: orientado a
agregados, de grafos e sem esquema.
20
3.2.1 Modelos de dados em NO-SQL
O modelo orientado a agregados reconhece o desejo de manipular os dados
na forma de objetos estruturalmente complexos que um conjunto de linhas. O termo
agregado foi descrito por Evans (2004) como aglomerado de dados com o qual
comunica-se como uma unidade, os agregados constroem os marcos de execução de
atomicidade, consistência, isolamento e durabilidade com o banco de dados.
Os agregados têm uma função importante de facilitar o gerenciamento do
armazenamento em clusters. Tem um funcionamento melhor a medida que a
interação com os dados é feita no mesmo agregado; quando as interações precisam
de dados em muitos agregados diferentes não funcionam tão bem assim. São tipos
de banco de dados que utilizam o modelo orientado a agregados: O de chave-valor,
de documentos e de famílias de colunas.
Outro tipo de modelagem de dados, os bancos de dados de grafos têm um
modelo com pequenos registros em interconexões um tanto quanto complexas assim
como demonstrado na figura 2.
Figura 2 - Exemplo de Estrutura de Banco de Dados de Grafos
Fonte: Hogg (2013).
21
Assim como exemplificado na figura 2 o modelo de banco de dados de grafos
acomodam os dados em grafos formados por nós e arestas, atuando mais
satisfatoriamente com dados que possuam unidades de relacionamento múltiplo.
Bancos de dados NO-SQL não usam schema, que no modelo relacional define
uma estrutura para o banco de dados, dizendo as tabelas e colunas que existem e os
tipos de dados das colunas. Essa característica do NO-SQL permite que esse tipo de
banco trabalhe com menos restrições e mais flexibilidade nas estruturas de
armazenamento de dados.
Campos podem ser adicionados aos registros mesmo que possuam um
esquema implícito que segundo Sadalage e Fowler (2013, p.63) é um agrupado de
postulações sobre disposição dos dados dentro do código que os manipula. Tal
característica pode implicar em problemas no caso de múltiplas aplicações acessando
o mesmo banco de dados. Porém, este problema pode ser contornado com o
encapsulamento de toda a interação do banco em uma única aplicação e depois fazer
a integração com diferentes aplicações empregando webservices.
Conforme o volume de dados aumenta fica mais difícil realizar uma expansão,
podendo ser cara a opção de comprar um servidor maior. Seria atraente utilizar a
escalabilidade, distribuindo a execução do banco de dados em clusters. Assim, há
duas rotas a serem adotadas na distribuição: replicação ou fragmentação.
3.2.2 Modelos de Distribuição em NO-SQL
A precedente e mais acessível preferência de distribuição é não usar nenhuma
distribuição. Executar o banco de dados em uma só máquina, optando por esse
caminho facilita o gerenciamento dos dados afastando a complexidade de leitura e
gravação no armazenamento de dados. Somente em situações em que a
escalabilidade é realmente necessária que outros caminhos devem ser tomados.
Um caminho a seguir é a fragmentação que nada mais é do que partilhar dados
distintos em variados servidores, de maneira que cada servidor trabalhe como uma só
procedência de um subconjunto de dados.
O outro caminho é a replicação que como o termo sugere, transcreve os dados
em variados servidores, de maneira que cada porção dos dados seja encontrada em
uma pluralidade de lugares. A replicação tem dois modos: a ponto a ponto e a mestre-
22
escravo. A primeira concede gravações em qualquer nó que é estruturado para
harmonizar suas cópias dos dados. A mestre-escravo converte um nó a reprodução
oficial, que se ocupa com gravações, ao mesmo tempo que os escravos se
harmonizam com o mestre e se ocupam com as leituras.
Das grandes diferenças entre o modelo relacional e o NO-SQL está na
consistência dos dados. Existem variadas formas de abordar esse assunto dentro dos
bancos de dados não-relacionais.
3.2.3 Consistência em NO-SQL
Os conflitos de gravação acontecem quando dois usuários buscam gravar
dados ao mesmo tempo no banco. Conflitos de leitura-gravação acontecem quando
um usuário lê os dados inconsistentes da gravação de outro usuário. Sistemas
distribuídos enxergam os conflitos graças a alguns nós obterem incrementos e outros
não. A consistência quer dizer que em determinado instante o sistema reproduz as
gravações para todos os nós.
A fim de alcançar boa consistência, vários nós precisam ser cercados em
procedimentos de dados, que consequentemente aumenta a latência. Por isso é
necessário haver balanceamento da consistência com a latência. Da mesma forma
acontece na relação de durabilidade e latência, particularmente se for preciso
prosseguir operando em situações de erros na replicação dos dados.
3.2.4 Marcadores de versões em NO-SQL
Os marcadores de versões auxiliam a encontrar divergências de concorrência.
No momento em que os dados são lidos e depois atualizados, é capaz de averiguar o
marcador de versão a fim de certificar que nenhuma pessoa atualizou os dados entre
a leitura e a gravação.
Podem ser implantados utilizando um contador, que vai sendo incrementado a
cada atualização dos recursos. Também por meio de um identificador único global que
é um número formado por combinações de fontes aleatórias que não permitem que
haja um identificador igual. Outros meios de implantar um marcador de versão são a
criação de hashes de conteúdo ou a utilização de timestamp.
23
4 OS DIFERENTES TIPOS DE BANCOS DE DADOS NO-SQL
Dentro do NO-SQL, existem quatro modelos de dados principais: Banco de
dados de chave-valor, Banco de dados de documentos, Banco de dados de famílias
de colunas e Banco de dados de grafos. O Quadro 1 apresenta alguns exemplos de
bancos de dados de acordo com a sua modelagem. São apenas alguns, já que
existem inúmeras aplicações para cada modelo de dados baseado em NO-SQL.
Quadro 1: Exemplos de Bancos de Dados NO-SQL
Modelo de Dados Banco de Dados
Chave-valor Riak
LevelDB
Project Voldemort
Documentos MongoDB
CouchDB
OrientDB
Famílias de colunas Cassandra
HBase
Amazon SimpleDB
Grafos Neo4J
HyperGraphDB
FlockDB
Fonte: Do autor (2017).
A classificação apresentada no Quadro 1 é interessante porém não totalmente
perfeita. A diferenciação acerca dos tipos de modelos de dados, frequentemente é
imprecisa. Alguns bancos de dados não se inserem rigorosamente em determinada
categoria. Toma-se por exemplo o OrientDB que pode ser encaixado tanto como uma
banco de dados de grafos como um banco de dados de documentos.
4.1 BANCO DE DADOS DE CHAVE VALOR
Os bancos de dados de chave valor são compostos por tabelas hash simples.
Vale lembrar, que hash são algoritmos que mapeiam os dados de um comprimento
mutável em dados de comprimento cravado. São utilizados especialmente quando o
24
acesso ao banco é executado totalmente por intermédio da chave primária.
Considerados também como os bancos de dados NO-SQL mais fáceis de operar com
base em um ponto de vista de uma API (Application Programming Interface). Pode-se
alcançar o valor para uma estabelecida chave, introduzir um valor para uma
estabelecida chave ou deletar uma chave do banco de dados. O valor é um blob – um
conjunto de dados binários acomodados como uma só entidade – que o banco de
dados somente deposita sem se perturbar ou mesmo saber o que tem dentro desse
blob, essa responsabilidade fica a cargo da aplicação que utiliza essa informação.
Como os bancos de dados de chave-valor geralmente faz o acesso através da chave
primária, são bancos que tem um excelente desempenho, sendo escalável.
Entre os mais populares bancos de dados de chave-valor, apresenta-se o Riak
e o Redis, possivelmente os dois mais famosos e utilizados, o BerkeleyDB, o
MemcachedDB, o HamsterDB, o Amazon DynamoDB, que não é de código aberto, e
o Project Voldemort, uma espécie de Dynamo DB de código aberto. Existem muitos
outros bancos de dados de chave-valor e novos surgem a cada dia.
4.1.1 Propriedades de bancos de dados de chave-valor
É importante salientar a importância de comparar os recursos do banco de
dados NO-SQL com os SGBD que utilizam do modelo relacional. O propósito básico
é compreender quais os recursos faltantes e em que a arquitetura dos aplicativos
precisam de mudanças para melhor usar os recursos de um banco de dados de chave-
valor. Os principais recursos a serem analisados em uma comparação são as
transações, consistência, as estruturas de dados, escalabilidade e recursos de
consultas.
Distintos bancos de dados de chave-valor possuem distintos parâmetros de
transações. Entretanto, de forma comum, não há garantias nas gravações. O banco
de dados Riak usa o conceito de quórum no decorrer da chamada à API de gravação.
Quórum é um conceito que Sadalage e Fowler (2013, p.98) expressam por meio de
uma fórmula, 𝑊 > 𝑁/2, onde 𝑊 é o número de nós que participam da gravação e 𝑁
é o número de nós envolvidos na replicação. O valor de 𝑊 deve ser maior que o valor
de 𝑁. Esse conceito é chamado então de quórum de gravação.
25
A questão de consistência é admissível somente aos procedimentos em uma
única chave, já que esses procedimentos são a aquisição, gravação ou exclusão em
uma só chave. Gravações positivas conseguem ser executadas porém exigem muitos
custos para a implementação, já que uma alteração no valor não pode ser definida
pelo banco de dados. Utilizando novamente o Riak como exemplo, esse banco de
dados usa de consistência eventual na implementação. Segundo Sadalage e Fowler
(2013, p.88) em determinado instante todos os nós tem a possibilidade de ter
inconsistências de replicação de dados, porém, caso não aconteça mais atualizações,
todos os nós acabarão atualizados com o mesmo valor. Ou a gravação mais nova se
sobressai sobre as mais velhas ou todos os valores são revertidos.
As consultas nesse tipo de banco de dados é feita exclusivamente pela chave.
Caso seja necessário realizar alguma consulta usando de algum atributo da coluna de
valores, então não é viável usar o banco de dados. No que tange a estrutura de dados,
não importa qual o tipo de dado armazenado nesse banco, podendo ser um blob, um
XML, números inteiros e por assim em diante. Na questão de escalabilidade a opção
mais comumente utilizada é a fragmentação.
4.1.2 Circunstâncias adequadas para a implementação
Bancos de dados de chave-valor podem ser muito bem implementados em
aplicações que armazenam as informações da sessão web, pois deixa o processo de
solicitação da id da sessão muito mais rápido, porque tudo referente à sessão está
acondicionado em um único objeto.
Em aplicações de preferências de perfis de usuários ou de produtos, os
usuários tem uma única ID de usuário e um só nome de usuário ou ouros atributos
únicos que podem ser alocados em um objeto de forma que as preferências
encontrem-se por intermédio de uma só operação.
Também são apropriados para o uso em sites de comércio eletrônico, pois eles
possuem carrinhos de compras que estão associadas a um determinado usuário.
Todas as informações de compras devem estar disponíveis durante todo o tempo e
podem ser armazenadas em um valor de chave única, uma ID de usuário.
Contudo, há casos em que os bancos de dados de chave-valor não são os mais
indicados para serem implementados, geralmente em aplicações que necessitam de
26
relacionamentos entre dados, ou com transações em variadas operações e em
aplicações que exigem consulta por dados ou operações por conjuntos de dados.
4.2 BANCO DE DADOS DE DOCUMENTOS
Em banco de dados de documentos, o documento é o conceito primordial. Esse
tipo de banco de dados armazena e extrai informações em documentos XML
(eXtensible Markup Language), JSON (JavaScript Object Notation), entre outros. São
essencialmente “estruturas de dados na forma de árvores hierárquicas e auto
descritivas” (Sadalage e Fowler, 2013, p.133). Em documentos, não existem atributos
nulos, caso um atributo não seja encontrado, é porque possivelmente ele não era
necessário no documento analisado. Além disso, em documentos é permitido que
atributos sejam criados sem que seja necessária alterar os documentos já existentes.
Entre os bancos de dados de documentos, os mais conhecidos atualmente são
o MongoDB, que foi abordado de maneira mais profunda nesse trabalho, o Terrastore,
o OrientDB, também enquadrado como banco de dados de grafos, o RavenDB, o
CouchDB e o popular Lotus Note. Para abordar as características de bancos de dados
de documentos, foi usado para exemplificação o MongoDB.
4.2.1 Propriedades de bancos de dados de documentos no MongoDB
O MongoDB é um banco de dados de código aberto, licenciado pela GNU AGPL
versão 3, armazenando os dados em documentos JSON. Várias empresas
multinacionais o utilizam em suas aplicações, entre elas, a Globo (site da Rede Globo,
a globo.com), LinkedIn (rede social voltada para o mercado de negócios), a SAP
(empresa de desenvolvimento de softwares e gestão empresarial), MTV (canal de tv
por assinatura), entre muitas outras grandes empresas ao redor do mundo.
No funcionamento do MongoDB, cada instância tem variados bancos de dados
e cada um desses bancos de dados tem várias coleções. Se comparado com os
SGBD relacionais, encontra-se uma semelhança nesse conceito de instância, o banco
de dado do MongoDB é o equivalente ao schema do modelo relacional e as coleções
se equivalem as tabelas dos SGBD.
27
A característica de consistência é modelada usando as séries de duplicatas e
escolhendo por aguardar que as gravações sejam copiadas em todos os nós escravos
ou em certo número de nós escravos. Qualquer gravação é capaz de identificar a
quantidade de nós escravos em que devem ser reproduzidas antes de ser julgada
exitosa.
O MongoDB, assim como outros bancos de dados de documentos se esforçam
em aperfeiçoar a disponibilidade, copiando os dados, usando de replicação mestre-
escravo; esses mesmos dados continuam acessíveis em vários nós, de modo que os
cliente podem acessar os dados mesmo que o primeiro nó esteja inacessível. Assim
sendo, o MongoDB efetua a replicação, oferecendo alta acessibilidade usando um
conjunto de réplicas ou cópias.
Nesse conjunto de cópias, existem dois ou mais nós envolvidos em uma
replicação não simultânea mestre-escravo. Os nós do aglomerado escolhem entre
eles o nó mestre, conhecido como primário. Admitindo que todos os nós dispõem de
mesmas garantias de voto, certos nós podem ser beneficiados por localizar-se mais
perto de diferentes servidores, pois tem mais memória RAM; isso pode ser alterado
pelo usuário outorgando uma prioridade para cada nó.
Todos os pedidos são encaminhados ao nó mestre e os dados são copiados
para os nós escravos. Se por algum motivo o nó mestre falhar, os nós escravos vão
escolher um outro nó mestre e qualquer novo pedido de réplica já é encaminhado ao
novo nó mestre. No momento que o antigo nó mestre que falhou ficar disponível
novamente ele entra como um nó escravo e se iguala aos demais nós, trazendo as
informações de que necessita para se requalificar.
Os conjuntos de cópias normalmente são usados para repetição de dados,
restauração espontânea de falhas, extensão da capacidade de leitura de dados,
aperfeiçoamento do servidor sem a necessidade de tirar a aplicação do ar para
manutenção e restauração depois de uma catástrofe.
A questão de escalabilidade no MongoDB representa incluir ou modificar o
armazenamento de dados sem apenas mudar o banco de dados para uma máquina
mais poderosa. O que é importante em escalar nesse banco de dados é quais
características ele tem, afim de que possa lidar com maior volume de dados.
O MongoDB assim como os demais bancos de dados de documentos podem
ser utilizados em aplicações que exigem os logs de registros de diferentes eventos.
28
Como é um banco de dados sem schema, e usam de documentos JSON, é muito
aplicável em sistemas de gerenciamento de conteúdo, como blogs (no gerenciamento
de postagens, de comentários de visitantes, entre outros). Também pode ser
implantado em aplicações que fazem análises em tempo real, já que os partes do
documento tem a opção de atualização, sendo muito simples guardar informações de
visualizações da páginas ou visitantes do web site. Onde o MongoDB não é
recomendado, em aplicativos de usam recursos de consultas em estruturas
agregadas variáveis ou façam transações complexas que utilizem diferentes
operações.
4.3 BANCO DE DADOS EM FAMÍLIAS DE COLUNAS
Esse tipo de banco de dados possibilitam ao programador armazenar os dados
com chaves estruturadas para os valores e estes são associados em várias famílias
de colunas e todas elas atuam como um catálogo de dados. Eles “armazenam dados
em famílias de colunas como linhas que tenham muitas colunas associadas, fazendo
o uso de uma chave de linha” (Sadalage e Fowler, 2013, p.147). Em uma analogia
com o modelo relacional, as tabelas são famílias de colunas, as linhas são linhas, com
a relação as colunas, no modelo relacional a coluna é a mesma para todas a linhas,
no modelo NO-SQL, as colunas não tem a necessidade se serem são as mesmas.
De todos os produtos disponíveis no mercado, o Cassandra possivelmente é o
mais popular entre eles, sendo retratado como ágil e de crescimento escalar
descomplicado, com atividades de gravação divididas pelo cluster, não tem um nó
mestre, assim tanto a gravação como a leitura de dados tem a possibilidade de ser
realizadas por cada um de seus nós. Também tem o HyperTable, o Amazon
DinamoDB e o HBase.
4.4 BANCO DE DADOS DE GRAFOS
Os bancos de dados de grafos é um dos que mais se diferem do modelo
relacional e também dos modelos NO-SQL já abordados no trabalho. Eles trabalham
com os nós, também conhecidos como entidades ou vértices (eles representam uma
pessoa, um lugar, uma coisa, entre outros). Esses nós são interligados entre si por
29
relacionamentos, também conhecidos como arestas, que podem ter várias
propriedades. Essa proposta de estrutura permite modelar todos os tipos de cenários,
desde um sistema de estradas até mesmo a um histórico médico de uma cidade.
Diferentes de outros bancos de dados, nos relacionados a grafos, os
relacionamentos ocupam o primeiro lugar em termos de prioridade. Isso tem um
significado, que a aplicação não é obrigado a inferir conexões de dados utilizando FKs
ou processamento MapReduce. São um tipo de banco de dados criados para o uso
em sistemas transacionais, sendo projetados com a integridade transicional e a
disponibilidade operacional.
Empresas gigantes do ramo da tecnologia da informação como o Google e o
Facebook e PayPal usam o poder de banco de dados de grafos para criar empresas
em expansão, cada uma delas usou essa tecnologia aproveitando o poder das
conexões de dados. Pois esse modelo NO-SQL é projetado para lidar com dados
altamente conectados e o aumento no volume e conexão dos dados atuais apresenta
uma imensa oportunidade para vantagem competitiva.
Os exemplos de bancos de dados de grafos são o Neo4j, o Infinite Graph, o
OrientDB e o FlockDB. Falando particularmente do Neo4j, ele é um banco de dados
otimizados para armazenar e atravessar os grafos conectados. Ao mapear
intuitivamente os pontos e as conexões entre eles, habilitando aplicações inteligentes
e em tempo real, tais como, de inteligência artificial e Internet das Coisas.
30
5 A PERSISTÊNCIA POLIGLOTA E RESULTADOS
Os distintos modelos de bancos de dado são idealizados para solucionar
distintos problemas. Usar somente um só dispositivo de banco de dados em todas as
insuficiências acabam em uma saída de baixo desempenho; guardar informações
transacionais, armazenar em cache os dados de sessão, percorrer os caminhos de
grafos de usuários são problemas totalmente distintos. Pensando somente em união
de dados as soluções de SGBD de modelo relacional são efetivos em corroborar que
os relacionamentos subsistam. Agora, ao se pensar em encontrar dados de distintas
tabelas de um mesmo objeto, trabalhar com esse modelo de dados fica mais difícil.
As empresas inclinam-se a usar um mesmo instrumento de banco de dados
para guardar diferentes tipos de dados, além de demais utilidades como por exemplos,
relatórios, ferramentas de inteligência empresarial e controle de armazém. Ou seja,
informações de um carrinho de compras não necessitam das mesmas especificidades
de consistência, disponibilidade de backup de segurança.
Pensando em tais necessidades, no ano de 2006, Neal Ford, arquiteto e
consultor de software, criou um termo denominado persistência poliglota, a fim de
expor o conceito de que as aplicações precisam ser programados em várias
linguagens de programação, de forma a usufruir a situação de que diversas
linguagens de programação são convenientes para encarar diversidades. Aplicativos
complexos ajustam diversos tipos de adversidades, a fim de selecionar a linguagem
de programação correta para que cada tarefa seja capaz de ser mais vantajosa do
que o ensaio de regular todos as questões em uma só linguagem de programação.
5.1 EXEMPLO DE APLICAÇÃO DA PERSITÊNCIA POLIGLOTA
De maneira a ser entendido o conceito de persistência poliglota, foi abordado
um exemplo utilizado por Sadalage e Fowler, autores de um dos únicos livros sobre
NO-SQL traduzido para o português do Brasil. São autores que frisaram muito a
importância da persistência poliglota durante a emersão de um novo mundo repleto
de diferentes tecnologias disponíveis.
Em uma plataforma de comércio eletrônico, é significativo usar um volume de
dados para o carrinho de compras, porém, este precisa ter alta disponibilidade além
31
de ser escalado. Entretanto este volume de dados não pode ajudar a localizar itens
comprados pelos familiares do comprador, que é um assunto absolutamente distinto,
sendo para esse caso o conceito de persistência poliglota a ser abordado.
Para esse caso, um modelo de dados de chave-valor pode ser aplicado para
guardar as informações do carrinho antes do fechamento do pedido, além dos dados
de sessão. Bancos de dados de chave-valor cabem muito bem ser aplicados nessa
situação já que o carrinho de compras do cliente é acessado através de uma chave
ID e assim que fechado e a compra concluída, são gravadas as informações no banco.
Caso queira ser desenvolvido na aplicação um esquema de recomendação de
produtos para o usuário com base em produtos que ele visitou anteriormente ou com
base em produtos que pessoas próximas ao cliente compraram, nesse caso, é viável
utilizar banco de dados de grafos. Informações de estoque e preço de itens podem
ser armazenados em um banco de dados relacional e as informações sobre os
pedidos finalizados em banco de dados de documentos, ou seja, para uma única
plataforma de desenvolvimento, vários tipos diferentes de banco de dados podem ser
aplicados, o que define bem o que é a tal da persistência poliglota.
Ao ponto em que as diferentes tecnologias de banco de dados são
implementadas nessa plataforma de comércio eletrônico, outras aplicações da
empresa podem ser beneficiadas por esse uso múltiplo. Em vez dessa aplicação
acessar diretamente o banco de dados, ela estará acessando um serviço.
Exemplificando, o banco de dados chave-valor pode ser encapsulado em um serviço
de armazenamento de sessão; o banco de dados de documentos, em um serviço de
persistência de pedidos; o relacional em um serviço de estoque e preços e o banco
de dados de grafos em um serviço de nós e relacionamentos.
5.2 INQUIETUDES SOBRE A PERSISTÊNCIA POLIGLOTA
A inclusão dos bancos de dados NO-SQL forçarão os administradores de banco
de dados das empresas a refletirem em como usar um novo tipo de armazenamento.
Uma empresa que está habituada a trabalhar em um ambiente relacional,
independente do banco de dados que usar de início, no futuro todas as suas
aplicações serão desenvolvidas ao redor desse banco de dados. Nos novos tempos
da persistência poliglota, os administradores de banco de dados vão ter de possuir
32
variadas competências, estudar como os produtos NO-SQL operam, fiscalizar essas
tecnologias implantadas e como trabalhar com elas.
No momento em que as empresas decidirem usar algum tipo de banco de
dados NO-SQL, surgirão as indagações sobre licenças de softwares, assistência
técnica, ferramentas disponíveis, vistorias e segurança. Muitos desses bancos são de
código aberto, possuem uma comunidade ativa de adeptos e existem empresas que
prestam consultorias e suporte a essas tecnologias. A própria comunidade está a criar
ferramentas de auxílio, como as que existem para o Riak e o MongoDB.
Um ponto que é motivo de muita preocupação nas empresas é a parte de
segurança dos dados. Grande parte de bancos de dados NO-SQL não tem ainda uma
gama robusta de recursos de segurança, não por desleixo, mas porque eles possuem
um funcionamento diferente de SGDB relacionais, pois pela abordagem que utilizam
a parte de segurança fica muito mais a cargo da aplicação do que do banco.
Incluir novas tecnologias tem uma consequência no aumento da dificuldade de
programação e nos procedimentos de forma que os benefícios de um volume de
dados correto tem de ser confrontados com essa dificuldade.
O NO-SQL em si é somente um agrupamento de tecnologias de banco de
dados. Já que ampliam a disposição com a ideia de persistência poliglota, é
necessário averiguar outras ferramentas de banco de dados, tais como bancos de
dados de XML e bancos de dados de objetos, não ficando preso somente ao NO-SQL.
5.3 RESULTADOS
Os bancos de dados NO-SQL surgiram como uma alternativa a modelo
relacional, que em atuais épocas de um volume gigantesco de dados começou a
apresentar algumas limitações ao ser aplicada em determinadas situações onde se
exigia um escalonamento pra fora, BigData, entre outros. Durante o capítulo 4 foram
apresentados diferentes bancos de dados NO-SQL, no Quadro 2 é possível comparar
algumas dessas tecnologias com o NO-SQL.
Quadro 2 – Comparativo entre Bancos de Dados Relacional e NO-SQL
Oracle Riak MongoDB Cassandra
Instância de Dados Cluster Riak Instância
MongoDB
Cluster
33
Banco de dados Keyspace
Tabela Bucket Coleção Família de Colunas
Linha Chave-valor Documento Linha
Rowid Chave _id
Schema Banco de dados
Fonte: Do autor (2017).
Como possível ver no Quadro 2, há itens que variam dependendo do modelo
de dados NO-SQL utilizado em comparação com o relacional. São apenas
terminologias diferentes para características análogas de um modelo para outro,
porém o que se deve levar realmente em consideração são as características
apresentadas, tais como, consistência, disponibilidade, consulta de dados,
escalabilidade e gerenciamento de transações.
Também é importante analisar para quais situações cada banco de dados NO-
SQL pode ser implementada e para quais tal modelo não é recomendado, e essa
questão foi abordada no capítulo 4 e no Quadro 3, essas informações ficam mais
fáceis de se analisar
Quadro 3 – Uso Apropriado de Bancos de Dados NO-SQL
Tecnologia NO-SQL Quando Usar Quando Não Usar
Banco de Dados de
Chave-valor
Armazenamento de
informações de sessão;
Perfis de usuários e
preferências;
Carrinhos de Compras
Relacionamentos entre
dados;
Consulta por dados;
Operações por conjuntos
Banco de Dados de
Documentos
Registros de logs;
Plataformas de blog;
Análises em tempo real;
Comércio Eletrônico
Transações complexas
que abrangem diferentes
operações;
Consulta em estruturas
agregadas variáveis
Banco de Dados de
Famílias de Colunas
Registros de logs;
Contadores;
Time To Live
Sistemas que solicitam
transações ACID
Banco de Dados de Redes sociais; Aplicações de análise em
34
Grafos Aplicativos de rotas de
delivery;
Técnicas de
recomendação (seus
amigos compraram
produto X)
que os todos os nós
tenham de ser atualizados
após uma propriedade ser
alterada
Fonte: Do autor (2017).
Se fosse necessário responder a questão proposta, é totalmente possível
utilizar de bancos de dados NO-SQL para as mais diversas situações em SGBD
relacionais já não são mais a alternativa mais viável, seja ela por custos por compras
de equipamentos melhores, seja também por desempenho, entre outros.
35
CONSIDERAÇÕES FINAIS
Este trabalho teve como principal objetivo mostrar alternativas ao uso de
bancos de dados relacionais em sistemas de informações. Bancos de dados são
essenciais para o armazenamento e manipulação de informações de sistemas de
informações. O modelo de bancos de dados mais utilizados a anos é o relacional
formado por coleções de dados chamadas de tabelas que são compostas por linhas
e colunas. Por muito tempo e até hoje esse modelo é dominante no mercado. Contudo
com o surgimento de aplicações que exigissem mais poder no controle de volumes
gigantescos de dados, esse modelo não trabalha com a eficiência necessária. Como
alternativa a esse modelo surgiram aplicações denominadas NO-SQL que trouxeram
inovações e melhorias de performance em pontos aonde o modelo relacional não é
viável.
Foram apontadas durante o desenvolvimento do trabalho as características que
permeiam os bancos de dados não-relacionais. Os diferentes modelos de dados que
existem dentro do NO-SQL e quais as principais produtos e como as propriedades do
modelo não-relacional são abordadas nos diferentes tipos de bancos de dados, sendo
os modelos conhecidos, o armazenamento de chave-valor, de documentos, de
famílias de colunas e o de grafos.
Outro aspecto levantado durante este trabalho é um conceito que muitos
autores levantam quando se fala em tecnologias NO-SQL, a chamada persistência
poliglota, que consiste no uso de não apenas uma mas de várias aplicações não-
relacionais dentro de um mesmo sistema, pois cada modelo é melhor aproveitado em
determinada situação em detrimento de outro e assim deve ser, a ideia central é não
haver só um modelo em uso mas o uso de vários modelos em um ambiente.
Como trabalhos futuros, planeja-se abordar um modelo em específico e se
aprofundar totalmente nele, de modo a complementar os estudos que foram
estabelecidos nesse trabalho. O conhecimento sobre algum dos modelos não-
relacionais podem ser estendidos a fim de melhor compreensão sobre o NO-SQL.
36
REFERÊNCIAS
CODD, Edgar F. A Relational Model of Data for Large Shared Data Banks.
Communications of the ACM, Nova Iorque, v. 13, n. 6, p. 377-387, jun. 1970.
Disponível em: <http://db.dobo.sk/wp-
content/uploads/2015/11/Codd_1970_A_relational_model.pdf>. Acesso em: 17 set.
2017.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de Banco de Dados. São
Paulo: Pearson Education Brasil, 2005.
EVANS, Eric. Domain-Driven Design: Tackling Complexity in the Heart of
Software. Boston, MA, Estados Unidos: Addison-Wesley Professional, 2003.
HOGG, Andy. Whiteboard it – the power of graph databases. Disponível em
<http://www.computerweekly.com/feature/Whiteboard-it-the-power-of-graph-
databases>. Acesso em 17 set. 2017.
NEO4J. Why Graph Databases? Disponível em: < https://neo4j.com/why-graph-
databases/?ref=product> Acesso em: 18 de outubro de 2017.
QUORA. What are different sun languages in SQL? Disponível em: <
https://www.quora.com/What-are-different-sub-languages-in-SQL> Acesso em: 18 de
outubro de 2017.
RAMAKRISHNAN, Radgu; GEHRKE, Johannes. Sistemas de Gerenciamento de
Banco de Dados. 3 ed. Porto Alegre: AMGH, 2011.
SADALAGE, Pramod J; FOWLER, Martin. NoSQL Essencial: Um Guia Conciso
para o Mundo Emergente da Persistência Poliglota. São Paulo: Novatec, 2013.
