Comparação entre os tipos de Bases de Dados NoSql

Nesta secção as bases de dados NoSql são comparadas em diversos aspetos, para perceber o que cada uma fornece.

2.3.5.1Comparação Geral

De modo a entender melhor os vários tipos de bases de dados, estes irão ser comparados nos seguintes pontos:

 Modelo de Dados: O modelo suportado pelos vários tipos de bases de dados;  Modelo de Transação: Prioridade da base de dados na seleção das trocas baseadas

no teorema CAP;

 Licença: O tipo de licença do software;  Índices: Que bases dados suportam índices;

 Sharding: Indica que bases de dados possuem sharding automático. Isto é, a capacidade de automaticamente redistribuir os dados e replicações através dos servidores quando há mudanças de recursos, como adicionar ou remover servidores (Indrawan- Santiago, 2012).

Fundamentos Teóricos _______________________________________________________________________________ Base de dados Modelo de Dados Modelo de Transação

Licença Índice? Sharding?

Cassandra Column-

family

PA Open source Não Sim

CouchDB Document PA Open source Sim Não

DynamoDB Key-value PA Comercial Sim Sim

HBase Column-

family

PC Open source Não Sim

MongoDB Document PA Open source Sim Sim

Neo4j Graph CA Open source Não Não

Riak Key-value PA Open source Sim Sim

Voldemort Key-value PA Open source Sim Sim

Tabela 2 - Comparação entre os tipos de bases de dados NoSql (Adaptado de Indrawan-Santiago, 2012,pag.47)

2.3.5.2 Particionamento, Replicação e Consistência

Particionamento

Como já foi referido anteriormente, a maioria das bases de dados NoSql implementam algum tipo de particionamento horizontal ou sharding, em que se armazenam conjuntos de registos em diferentes segmentos que podem estar alocados em diferentes servidores. Segundo Grolinger et al. (2013), “o modelo de dados é um fator significativo para definir estratégias para particionamento em bases de dados.”

Existem várias estratégias de particionamento horizontal, mas as mais utilizadas são Range

Partitioning e Consistent Hashing.

Em relação à Range Partitioning, o objetivo é atribuir os dados a partições, localizadas em diferentes servidores baseados em conjuntos de uma chave de partição. Um servidor tem como função armazenar e lidar com a leitura/escrita de um específico conjunto de chaves. Esta estratégia tem como vantagem o processamento efetivo de range queries, isto porque chaves adjacentes residem no mesmo nodo. No entanto, pode ter desvantagens como hot

spots e load- balancing issues. Por exemplo, se os dados são processados de acordo com as

suas chaves valores, a carga de processamento será bastante concentrada num único servidor ou em poucos servidores.

Em relação ao Consistent Hashing, o conjunto de dados é representado como um círculo. O círculo é dividido em conjuntos, igual ao número de nodos disponíveis e cada nodo é mapeado para um ponto do círculo. Na figura seguinte é possível visualizar o Consistent

Hashing num exemplo com 4 nodos, N1 para N4. Para se determinar o nodo onde um objeto

deve ser alocado o sistema faz hash à chave do objeto e descobre a sua localização no círculo. Na imagem seguinte pode-se verificar que o objeto “a” está localizado entre o nodo N4 e N1. De seguida o círculo é percorrido no sentido horário, até que o primeiro nodo seja

Fundamentos Teóricos

_______________________________________________________________________________

40

encontrado e, assim, atribui-se o objeto a esse nodo. O objeto “a” presente na seguinte figura é atribuído ao nodo N1. De acordo com Grolinger et al. (2013), “cada nodo é responsável pela região do anel entre ele e o seu predecessor, e referem um exemplo onde o nodo N1 é responsável pelo data range 1, N2 pelo data range 2 e assim sucessivamente.” A localização de um objeto no Consistent Hashing pode ser calculada rapidamente, não sendo necessário um serviço de mapeamento como é necessário no Range Partitioning.

Figura 16 - Consistent hashing (Retirado de Grolinger et al., 2013, pag.13)

O Redis e o Memcache não possuem nenhuma estratégia de particionamento, sendo o cliente que escolhe uma.

Replicação

Além da escalabilidade de leitura/escrita ser aumentada, a replicação também aumenta a confiança no sistema, na tolerância a falhas e na durabilidade. Existem duas estratégias de replicação que ressaltam à vista, sendo elas a replicação master–slave e multi-master. Como já foi referido anteriormente, na replicação master-slave, um único nodo é designado como master e é o único nodo que pode processar pedidos de escrita. As alterações realizadas são propagadas do master para os nodos slaves. Bases de dados que utilizam este tipo de replicação são o Redis, BerkeleyDB, e o HBase.

Já na replicação multi-master, existe a possibilidade de vários nodos processarem pedidos de escrita, que depois são propagados para os nodos seguintes. Neste tipo de replicação a direção de propagação pode ocorrer em diferentes direções, ao contrário da replicação

mater/slave. Bases de dados que utilizam este tipo de replicação são o CouchDB e o Couchbase Server.

Fundamentos Teóricos

_______________________________________________________________________________

similar à replicação multi-master, pois tal como nesta vários nodos aceitam pedidos de escrita. No sistema de replicação todos os nodos possuem o mesmo papel.

Outro fator importante na replicação e que causa grande impacto nas bases de dados é o modo como as operações de escrita são propagadas entre os nodos. A sincronização de réplicas pode ser síncrona ou assíncrona. De acordo com Grolinger et al. (2013), na síncrona “as alterações são propagadas antes que o sucesso da operação de escrita seja reconhecido pelo cliente. Isto significa que a replicação síncrona introduz atrasos porque a operação de escrita é completada apenas depois da alteração da propagação.” Este tipo de replicação é raramente usada pelas bases de dados NoSql, isto porque pode levar a grandes atrasos no caso de perda temporária ou degradação da conexão. Já em relação à assíncrona referem que “o sucesso de uma operação de escrita é reconhecida antes das alterações serem propagadas para a réplica do nodo”. É uma vantagem porque permite a replicação para longas distâncias mas pode ser uma desvantagem, pois pode resultar em nodos com cópias de dados inconsistentes.

A escolha do modelo de replicação é de extrema importância porque tem impacto na capacidade da base de dados escalar pedidos de leitura e escrita (Grolinger et al., 2013).

Consistência

Esta consistência diz respeito à utilizada no teorema CAP, que está relacionada com a maneira como os dados são vistos nos nodos do servidor, isto depois das operações de atualização.

Existem dois modelos de consistência, sendo eles a Strong Consistency e a Eventual

Consistency. Na Strong Consistency é assegurado que quando se confirma pedidos de

escrita, os dados atualizados são visíveis nos pedidos seguintes de leitura.

Já no modelo de Eventual Consistency, que já foi referido anteriormente, as alterações são eventualmente propagadas através do sistema levando o tempo necessário. Sendo assim, alguns nodos servidor podem conter dados inconsistentes durante um certo período de tempo.

A maioria das bases de dados NoSql fornecem Eventual Consistency.

De salientar que o MongoDB pode alcançar Strong Consistency usando duas técnicas diferentes. Primeiro uma conexão é estabelecida pelo master, mas apenas de leitura. A segunda opção é estabelecer um parâmetro denominado “Replica Acknowledged”, o qual tem foco na escrita, este assegura que uma escrita é bem-sucedida em todas as réplicas antes de ser confirmado. No entanto, a base de dados torna-se num sistema de replicação síncrona

Fundamentos Teóricos

_______________________________________________________________________________

42

e o seu desempenho é afetado negativamente.

Tabela 3 - Comparação dos tipos de bases de dados NoSql em termos de particionamento, replicação e consistência (Retirado de Grolinger et al., 2013,pag.11)

Fundamentos Teóricos

_______________________________________________________________________________