Capitulo 2- Fundamentos Teóricos
2.3 NoSql
2.3.4 Tipos de Bases de Dados NoSql
Segundo Toth (2011), Bonnet et al. (2011) e Guimarães et al. (2013), os principais tipos de bases de dados NoSql são:
Document Databases, que têm como finalidade armazenar documentos em coleções, coleções estas que contêm objetos idênticos. Não possuem esquema e campos podem ser dinamicamente adicionados a um documento. (ex. CouchDB e
MongoDB);
Key Values Databases, que têm como finalidade armazenar os dados como chaves e valores (ex. Riak, Redis e DynamoDB);
Graph Databases, que têm como finalidade armazenar relacionamentos entre os dados (ex. Neo4J e OrientDB);
Column-based Databases, que têm como finalidade armazenar os dados como triplas contendo linha, coluna e rótulo de tempo (ex. Cassandra, HBase).
2.3.4.1 Key Value Databases
Fundamentos Teóricos
_______________________________________________________________________________
26
isto porque não possuem esquemas nem coleções (Atzeni et al., 2013).
Almeida & Brito (2012) citam Lóscio et al. (2011) que referem que é uma “base de dados composta por um conjunto de chaves, às quais estão associadas um único valor, que pode ser uma string ou um binário”.
Toda a base de dados assemelha-se com um mapa ou dicionário que contém objetos chamados valores, cada um identificado por uma chave única (Atzeni et al., 2013; Hecht & Jablonski, 2011). Estes valores são isolados e independentes uns dos outros e, por isso, as relações devem ser tratadas pela lógica da aplicação. Em relação às chaves, estas são a única maneira para recuperar dados guardados. Possuem uma simples estrutura de dados, sendo assim são livres de esquemas. Também permitem que novos valores de qualquer tipo possam ser acrescentados em tempo real, sem que qualquer tipo de conflito com outros dados armazenados aconteça e sem influenciar a disponibilidade do sistema.
Para ser possível adicionar algum tipo de estrutura no modelo de dados é necessário utilizar o grupo de pares de chave-valor (Hecht & Jablonski, 2011).
O modelo de dados das Key Value Databases significa que um valor corresponde a uma chave. Embora a estrutura seja simples, a velocidade de consulta é maior que nas bases de dados relacionais, suporta grande armazenamento e alta concorrência. Fornece suporte para consultas e operações de modificação através da chave primária (Han et al., 2011).
Estas bases de dados representam um “balde de dados”. Por exemplo, num caso de um carrinho de compras mencionado na figura seguinte, onde se pode visualizar uma chave ligado a um valor que contém dados de encomendas (Tauro et al., 2012).
Fundamentos Teóricos
_______________________________________________________________________________
Estas bases de dados são úteis quando se lida com operações simples, que são baseadas apenas em atributos chave. (Hecht & Jablonski, 2011) É inviável neste modelo de dados efetuar consultas ad-hoc, isto porque todas as consultas são efetuadas sobre as chaves e não sobre os valores. (Carniel et al., 2012)
2.3.4.2 Column-Based Databases
São também conhecidas como column oriented databases. Este tipo de base de dados possui um formato tabela e por isso tem uma representação gráfica semelhante às bases de dados relacionais. Semelhante mas não igual, pois lida com valores nulos de maneira distinta e não suporta associações entre tabelas (Han et al., 2011; Hecht & Jablonski, 2011).
Tomando como exemplo “um caso em que se use muitos tipos de atributos, as bases de dados relacionais iriam guardar um valor nulo em cada coluna no qual o dataset não tem valor. Já as column-based databases apenas armazenam um par chave-valor num único registo, se o dataset precisar. É por isto que a Google as refere como “sparse” e torna as
column-based databases bastante eficientes em dominar grandes quantidades de dados.”
Este modelo opõe-se ao das bases de dados relacionais, isto porque as relacionais armazenam os dados em linhas e nas column-based databases “os dados são indexados por uma tripla (linha, coluna e timestamp), onde linhas e colunas são identificadas por chaves e o timestamp permite diferenciar múltiplas versões de um mesmo dado” (Lóscio et al., 2011). Já para Cattell (2011), o seu modelo de dados básico são registos e colunas, e o seu modelo básico de escalabilidade está separado entre registos e colunas através de múltiplos nodos:
Registos estão separados ao longo dos nodos através de sharding na chave primária. Normalmente, separam-se por range em vez de uma função hash. Isto significa que consultas em intervalos de valores não têm de ir para todos os nodos;
Colunas de uma tabela são distribuídas através de múltiplos nodos utilizando
“column groups”. Estes podem parecer muito complexos, mas grupos de colunas
são uma simples maneira para o utilizador indicar quais colunas são melhor armazenadas juntas.
Existem duas maneiras de estruturar os dados, sendo elas:
Orientado à linha: cada registo é uma agregação, por exemplo, um cliente com o
Id 1234 e com a família de colunas representando pedaços de dados como perfil,
histórico de encomendas dentro da agregação;
Orientado a colunas: Cada família de colunas define um tipo de registos, por exemplo perfis de clientes com linhas associadas a registos. Podemos pensar na linha como um conjunto de registos em todas as famílias de colunas (Sadalage & Fowler,
Fundamentos Teóricos
_______________________________________________________________________________
28
2012).
Na imagem seguinte podemos visualizar a estrutura típica destas bases de dados.
Figura 8 - Estrutura típica das column-based databases (Retirado de Sadalage & Fowler, 2012,pag.46)
De acordo com Abadi & Madden (2008), quando se pretende aceder aos dados sobre a granularidade de uma entidade, o modelo baseado em linhas é o mais indicado, isto tendo em conta que todos os dados estão armazenados em conjunto. Mas caso se pretenda ter acesso apenas a alguns atributos de diversos registos, então o modelo baseado em colunas é o mais indicado. Sendo assim, quando se pretende pesquisar um cargo, adicionar um cargo ou eliminá- lo usamos o modelo baseado em linhas, caso usemos uma consulta para verificar o género mais comum no curso de MIEGSI, é preferível utilizar o modelo baseado em colunas.
Os dados são armazenados de acordo com as suas colunas de forma independente (Liu et al., 2011). Cada coluna é exclusivamente armazenada em cada tabela, não existindo relacionamentos (Carniel et al., 2012).
Concluindo, o modelo de dados das column-based databases é mais indicado para aplicações que trabalhem com grandes quantidades de dados que estejam armazenados em grandes clusters, como, por exemplo, data warehouses, pois o modelo de dados permite particionamento eficiente (Han et al., 2011; Hecht & Jablonski, 2011).
2.3.4.3 Graph Databases
Fundamentos Teóricos
_______________________________________________________________________________ databases têm uma excelente gestão de dados fortemente ligados. Deste modo, as aplicações
que têm dados com muitos relacionamentos são ótimas para este tipo de base de dados. Segundo Hecht & Jablonski (2011), são mais indicadas para “serviços baseados em localização, representação de conhecimento e problemas de encontrar caminhos nos sistemas de navegação, sistemas recomendados e todo o tipo de casos que envolva relações complexas.”
O modelo deste tipo de base de dados baseia-se no conceito de grafo. Tem a sua estrutura composta por: “nós (são os vértices do grafo), relacionamentos (são as arestas) e propriedades (ou atributos) dos nós e relacionamentos” (Lóscio et al., 2011).
Toth (2011) ainda destaca que “pode-se armazenar qualquer tipo de dados dentro do conteúdo”. As principais vantagens deste tipo de base de dados são:
O facto de “não existir tanta replicação de dados como nos outros modelos, facto que acontece por se aproveitar do relacionamento entre os registros” (Toth, 2011); “A vantagem de utilização do modelo baseado em grafos fica bastante clara quando
consultas complexas são exigidas pelo utilizador. Comparado ao modelo relacional, que para estas situações pode ser muito custoso” (Lóscio et al., 2011). Isto porque quando se percorre um grafo, algoritmos heurísticos são aplicados para otimizar a busca por valores, identificando qual o melhor caminho entre dois nós, isto sem haver necessidade de verificar outros nós. Já no modelo relacional estas consultas obrigavam a construir joins, que caso fossem muito complexos afetavam o desempenho da consulta;
“Esse modelo também dá suporte ao uso de restrições sobre os dados, como restrições de identidade e de integridade referencial (Diana & Gerosa, 2010), ao contrário da maioria dos modelos NoSql que são mais flexíveis;”
“Esse modelo pode tornar consultas rápidas, devido à possibilidade da utilização de propriedades de grafos, medidas de centralidade (pagerank) e algoritmos de menor caminho” (Toth, 2011).
Na seguinte figura é possível visualizar um exemplo destas bases de dados, onde várias pessoas têm relacionamentos entre si, quer de amizade, quer de empregado/patrão.
Fundamentos Teóricos
_______________________________________________________________________________
30
Figura 9 - Exemplo das relações numa graph database (Retirado de Sadalage & Fowler, 2012,pag.52)
Sendo assim, as graph databases são indicadas para situações de contexto complexo em que se conhece a semântica entre os objetos armazenados (Almeida & Brito, 2012).
2.3.4.4 Document-based Databases
Estas bases de dados são organizadas em coleções de documentos, ao contrário das bases de dados relacionais em que se usam tabelas estruturadas com campos para cada registo. Também é permitido ao utilizador adicionar vários campos de diferentes tamanhos a um documento (Leavitt, 2010).
Nestas bases de dados o objetivo é gerir e armazenar documentos. Estes documentos podem assumir os formatos XML, JSON (Javascript Object Notation) ou BSON (Binary JSON) que são formatos padrão na troca de dados (Moniruzzaman & Hossain, 2013).
Uma vez que estas bases de dados não possuem um esquema definido para lidar com os dados faz com que sejam uma boa solução para as típicas aplicações da web 2.0, assim como para gerir conteúdos associados às redes sociais (Queiroz et al., 2013).
Este tipo de base de dados armazena coleções de documentos, em que um documento representa “um objeto com um identificador único e um conjunto de campos, que podem ser strings, listas ou documentos embutidos” (Lóscio et al., 2011).
Diana & Gerosa (2010) referem que este tipo de base de dados “não possui esquema, ou seja, os documentos armazenados não precisam possuir estrutura em comum”, assim novos campos podem ser acrescentados a um documento, sem que traga problemas à base de dados.
Fundamentos Teóricos
_______________________________________________________________________________
um documento, por exemplo, documentos JSON (Carniel et al., 2012).
As Document Databases agrupam pares de chave-valor em documentos. A cada documento é atribuída uma chave especial “ID”, sendo que esta é atribuída a cada um destes separadamente. Desta forma, é possível tratar dados estruturados complexos como Nested
objects mais convenientemente (Hecht & Jablonski, 2011).
Diversos atributos podem estar contidos dentro de uma única coluna, e, por sua vez, o número e tipo de atributos armazenados podem variar de registo para registo. Contrariamente às key-value databases, este tipo de base de dados permite a pesquisa por chave ou valor, sendo ideais para armazenar e gerir Big data-Size collections de documentos como:
Documentos de texto;
Mensagens de correio eletrónico; Documentos XML;
Representações de entidades da base de dados como produto ou consumidor; Sparse Data (Moniruzzaman & Hossain, 2013).
Como as key value databases, estas não possuem restrições ao nível de esquema, o que permite guardar novos documentos, com qualquer tipo de atributos, tão facilmente como adicionar novos atributos aos documentos existentes em tempo real.
É possível efetuar pesquisas por multi atributo em registos que podem ter diferentes tipos de pares chave-valor, o que as leva a serem uma ótima escolha para a integração de dados, assim como para tarefas de migração de esquemas (Hecht & Jablonski, 2011).
Dentro de uma coleção, os documentos podem ser vistos de forma sequencial, podem ser recuperados individualmente utilizando o seu identificador ou efetuar uma consulta respeitando a sua estrutura de campos. É igualmente possível introduzir um novo documento a qualquer altura numa coleção (Atzeni et al., 2013).
Cada coleção possui um nome, e as operações individuais referem-se a esta usando o seu nome. Desta forma inserem objetos para uma coleção específica. De certo modo, as coleções possuem uma forma ligeira de esquema, isto porque são visíveis tal como as tabelas nas bases de dados relacionais. Uma forma pode dizer-se ligeira pois por um lado as coleções não necessitam de ser explícitas, ao contrário do que acontece nas bases de dados relacionais, onde uma create table é precisa antes de um select. Por outro lado, nas NoSql, uma nova coleção é iniciada quando um comando refere uma coleção inexistente. E é igualmente ligeira, pois a sua estrutura interna não é pré-definida (Atzeni et al., 2013). Cada objeto possui uma chave que é única, os atributos são elementos básicos do modelo,
Fundamentos Teóricos
_______________________________________________________________________________
32
correspondendo a valores simples como strings ou inteiros (Han et al., 2011).
O facto de as relações estarem integradas dentro do próprio documento pode originar dados duplicados, mas isto possibilita uma consulta direta. Desta forma, tendo como base uma estrutura que tenha uma relação Cliente com Encomendas (um cliente pode ter várias encomendas), se uma consulta fosse criada para retornar as encomendas do Cliente “X”, neste tipo de base de dados bastaria obter o documento correspondente ao Cliente “X”, que este por sua vez já traria os documentos correspondentes às suas encomendas. Já nas bases de dados relacionais seria necessário fazer uma junção das tabelas Clientes e Encomendas, o que levaria a uma diminuição de desempenho na sua execução, mais sentida caso as tabelas tenham alguma dimensão (Almeida & Brito, 2012). Uma outra vantagem de possuir dados duplicados é que “facilita a distribuição do sistema, já que a quantidade de nós a serem consultados numa busca envolvendo várias entidades relacionadas é menor caso elas estejam próximas” (Diana & Gerosa, 2010). Sendo assim, dependendo do contexto, Diana & Gerosa (2010), referem que “pode criar problemas de consistência no banco de dados, causados por anomalias de atualização e remoção”, isto pode ser sentido quando um documento duplicado é atualizado num só documento.
A principal diferença entre as Key value databases e as Document é o facto de nas Key value as agregações serem opacas para os sistemas e nas Document a estrutura das agregações é transparente, ou seja, pode ser vista.
Nas key value databases apenas podemos aceder a uma agregação por via de uma chave. Nas Document Databases podemos submeter consultas à base de dados baseadas nos campos da agregação, podemos retirar parte de uma agregação em vez de tudo, e a base de dados pode criar índices baseadas no conteúdo da agregação (Sadalage & Fowler, 2012). De acordo com Strauch (2010), as bases de dados CouchDB e MongoDB são os principais representantes desta classe de banco de dados baseada em documentos. (Almeida & Brito, 2012)
Fundamentos Teóricos
_______________________________________________________________________________
Figura 10 - Exemplo de dois Documentos de uma Document database
Relativamente aos documentos acima apresentados pode-se verificar que são similares mas têm diferenças no conteúdo. Isto é permitido nas Document Databases. Ainda que a estrutura de dados possa diferir entre os documentos, estes podem na mesma pertencer à mesma coleção, ao contrário das bases de dados relacionais em que cada linha na tabela tem de seguir a mesma estrutura (Sadalage & Fowler, 2012).
2.3.4.4.1 CouchDB
Apache CouchDB é uma Document database open-source (CouchDB, 2011), criada pela
Fundação Apache e está desenvolvida em Erlang, que é uma linguagem de programação utilizada para aplicações concorrentes e distribuídas. As propriedades ACID são cumpridas nesta base de dados, fornecendo atualizações serializadas (CouchDB, 2011). É já da sua natureza distribuído e suporta vários tipos de esquemas de replicação e resolução de conflitos.
Data Model
CouchDB utiliza uma base de dados formada por uma coleção independente de documentos
em JSON. Estes documentos são compostos por pares de chave/valor. Valores podem ser do tipo: números, string, boleanos e listas. Estes documentos não possuem qualquer tipo de esquema e, sendo assim, não têm de seguir nenhuma estrutura, exceto claro, a estrutura inerente a JSON. Na seguinte imagem pode-se visualizar um exemplo que modela a informação necessária para descrever um livro.
Fundamentos Teóricos
_______________________________________________________________________________
34
Figura 11 - Documento contendo um exemplo de descrição de um livro (Retirado de Silva, 2011,pag.14)
Segundo Queiroz et al. (2013), são atribuídos a cada documento pelo menos dois atributos: um número de revisão para resolução de conflitos durante atualizações e um identificador único.
Silva (2011) cita Anderson et al. (2010).que referem que esta base de dados “é um simples contentor de uma coleção de documentos e não estabelece nenhuma relação obrigatória entre eles”
Embora o CouchDB não imponha nenhum tipo de relação entre os documentos, é importante possuir algum tipo de estrutura que retrate como os documentos são organizados. Sendo assim, o CouchDB fornece um view model.
Segundo Silva (2011), views são métodos de agregar documentos existentes na base de dados. Já para Queiroz et al. (2013) permitem a filtragem de partes específicas ou criar índices para acelerar a procura de um documento. Estas não afetam os dados de uma base de dados, simplesmente mudam a maneira de como os dados são representados, definindo assim o design da aplicação.
Silva (2011) também refere que “para definir uma view o utilizador deve fornecer uma função javascript que atua como uma função map da operação mapreduce. Esta função leva um documento como um argumento e é permitido manipular os dados do documento da maneira que se desejar. A view resultante é um documento que pode ter múltiplas linhas.” Na figura anterior foi apresentado um caso de uma coleção de documentos de livros. Partindo do princípio que é pretendido obter o título de todos os livros que estão armazenados na base de dados, criamos uma função map correspondente para ser usada na
Fundamentos Teóricos
_______________________________________________________________________________
Figura 12 - Exemplo de uma função utilizada para obter o título de todos os livros armazenados na base de dados (Retirado de Silva, 2011,pag.14)
Query Model
O CouchDB utiliza uma RESTful HTTP API para efetuar operações CRUD básicas em todos os dados armazenados e utiliza métodos como, http POST, GET, PUT e DELETE as realizar. Consultas mais complexas podem ser como views, como se viu anteriormente e o resultado pode ser lido utilizando esta REST API (Anderson et al., 2010; Silva, 2011).
Replication Model
O CouchDB é um sistema de base de dados distribuído peer-based (CouchDB, 2011), permite peers para atualização e alteração de dados, sincronizando bidireccionalmente as mudanças. Portanto, utilizando o master-slave setup, em que as sincronizações são feitas unilateralmente, ou o master-master setup, em que as mudanças podem acontecer em qualquer um dos nodos, estes devem ser sincronizados bidireccionalmente.
Para isto acontecer, o CouchDB utiliza uma replicação otimista e tem a capacidade de lidar com conflitos, que podem acontecer derivado a replicações de alterações. Como já foi referido anteriormente, um id de revisão é atribuído, isto porque sempre que um documento é atualizado, a versão antiga é mantida e atribuído à versão atualizada um id de revisão diferente. Portanto, quando um conflito é detetado, a versão que prevalecer é gravada como a mais recente e a versão que não prevalecer é também gravada na história do documento. Isto é realizado de forma consistente em todos os nós. Existe a possibilidade da aplicação poder escolher lidar com o conflito por ela própria, ignorando uma versão (Anderson et al., 2010).
Consistency Model
Relativamente à consistência, o CouchDB fornece Eventual Consistency. Como vários
masters são permitidos, as alterações têm a necessidade de serem propagadas aos nodos
restantes, sendo assim não existem bloqueios de escrita. Portanto, até estas alterações se propagarem de nodo para nodo, a base de dados permanece num estado de inconsistência. Como são suportados master setups únicos com múltiplos slaves, Strong Consistency pode
Fundamentos Teóricos
_______________________________________________________________________________
36
ser alcançada (Anderson et al., 2010).
2.3.4.4.2 MongoDB
O MongoDB é uma Document database open-source escrita na linguagem C++ (10gen, 2011). A companhia 10gen também fornece suporte a esta base de dados. Não possui qualquer tipo de esquema e gere documentos JSON como o CouchDB. Foca-se no alto desempenho e desenvolvimento ágil, fornecendo ao programador um conjunto de caraterísticas para facilmente consultar dados, ao mesmo tempo que escala o sistema.
Data Model
O MongoDB utiliza uma base de dados composta por coleções de documentos no formato
BSON, que é uma versão dos documentos JSON mas binária. Segundo Queiroz et al. (2013),
estas coleções e documentos relembram os conceitos de tabelas e linhas da tecnologia relacional, mas com a particularidade dos documentos não necessitarem de ter o mesmo esquema. Sendo assim, os documentos podem conter campos que são diferentes uns dos outros. Na figura seguinte podemos então visualizar a diferença existente entre os campos.
Figura 13 - Exemplo de um Documento com campos distintos (Retirado de Queiroz et al., 2013,pag.485)
Os documentos contemplados pela base de dados MongoDB estão num “formato chamado
BSON que é muito semelhante ao JSON mas numa representação binária, por razões de
eficiência e por causa de tipos de dados adicionais em comparação com JSON” (Strauch, 2010).