Manipulando Partições no NoSQL - dummies

A palavra partição é usada para dois conceitos diferentes no campo NoSQL. Uma partição de dados é um mecanismo para garantir que os dados sejam distribuídos uniformemente em um cluster. Por outro lado, uma partição de rede ocorre quando duas partes do mesmo cluster de banco de dados não podem se comunicar.

Em sistemas de cluster muito grandes, é cada vez mais provável que uma falha de uma peça de equipamento aconteça. Se uma alternância de rede entre servidores em um cluster falhar, ocorre um fenômeno referido como (no jargão do computador) split brain . Nesse caso, os servidores individuais ainda estão recebendo solicitações, mas não podem se comunicar entre si.

Este cenário pode levar à inconsistência de dados ou simplesmente a capacidade reduzida no armazenamento de dados, uma vez que a partição de rede com o mínimo de servidores é removida do cluster (ou "votou off" na verdadeira moda Big Brother).

Tolerando partições

Você tem duas opções quando ocorre uma partição de rede:

• Continuar, em algum nível, para atender operações de leitura e gravação.

• "Vote off" uma parte da partição e decide corrigir os dados mais tarde, quando ambas as partes se comunicarem. Isso geralmente envolve o cluster de votação de uma réplica de leitura como o novo mestre para cada nó de partição mestre faltando.

O Riak permite que você determine a quantidade de vezes que os dados são replicados (três cópias, por padrão - ou seja, n = 3) e quantos servidores devem ser consultados para que uma leitura seja bem-sucedida. Isso significa que, se o mestre primário de uma chave estiver no lado errado de uma partição de rede, as operações de leitura ainda podem ser bem sucedidas se os outros dois servidores estiverem disponíveis (ou seja, r = 2 disponibilidade de leitura).

O Riak identifica quando o servidor de partição primário desce usando um sistema chamado hinted handoff . Quando os dados são originalmente replicados, o primeiro nó para uma partição de chave específica é gravado, juntamente com (por padrão) dois dos seguintes nós vizinhos.

Se o primário não puder ser gravado, o próximo nó do anel está escrito. Essas escritas são efetivamente entregues ao próximo nó. Quando o servidor primário volta, as gravações são reproduzidas nesse nó antes de assumir novamente as operações de gravação primária.

Em ambas as operações, as inconsistências de versão podem acontecer porque réplicas diferentes podem estar em estados de versão diferentes, mesmo que apenas por alguns milissegundos.

Riak emprega ainda outro sistema chamado ativo anti - entropia para aliviar esse problema. Este sistema arrasta valores atualizados e garante que as réplicas sejam atualizadas em algum ponto, de preferência, antes e depois.Isso ajuda a evitar conflitos ao ler enquanto mantém uma alta velocidade de ingestão, o que evita um commit de duas fases usado por outros bancos de dados do NoSQL com suporte de cluster master-slave, compartilhado-nada.

Se um conflito na leitura acontecer, Riak usa ler reparação para tentar retornar apenas os dados mais recentes. Eventualmente, porém, e dependendo das configurações de consistência e disponibilidade que você usa, o aplicativo cliente pode ser apresentado com várias versões e pediu para decidir por si mesmo.

Em algumas situações, essa compensação é desejável, e muitas aplicações podem intuitivamente saber, com base nos dados apresentados, qual versão usar e qual versão descartar.

Indicação secundária

Os índices secundários são índices sobre dados específicos dentro de um valor. A maioria das lojas de valores-chave deixa essa indexação até o aplicativo. No entanto, Riak é diferente, empregando um esquema chamado documento - baseado em particionamento que permite a indexação secundária.

O particionamento baseado em documento assume que você está escrevendo estruturas JSON no banco de dados Riak. Em seguida, você pode configurar índices em propriedades específicas do nome nesta estrutura JSON, conforme mostrado:

{"order-id": 5001, "id do cliente": 1429857, "data da ordem": "2014-09-24 "," Total ": 134. 24}

Se você tiver um aplicativo que esteja mostrando as ordens de um cliente para o mês anterior, então você deseja consultar todos os registros, como mostrado, onde o ID do cliente é um valor fixo (1429857) e a data do pedido está dentro de um intervalo específico (o início e o final do mês).

Na maioria das lojas de valor-chave, você cria outro balde cuja chave é o número e o mês combinados do cliente e o valor é uma lista de ids de pedidos. No entanto, na Riak, você simplesmente adiciona um índice secundário tanto no ID do cliente (número inteiro) como na data da ordem (data), que ocupa espaço de armazenamento extra, mas tem a vantagem de ser transparente para o desenvolvedor do aplicativo.

Esses índices também são atualizados ao vivo - significando que não há intervalo entre a atualização de um valor de documento no Riak e os índices atualizados. Este acesso ao dado em tempo real é mais difícil de retirar do que parece. Afinal, se os índices forem inconsistentes, você nunca encontrará os dados consistentemente mantidos!

Avaliando Riak

Basho, a entidade comercial por trás da Riak, diz que a próxima versão 2. 0 O banco de dados NoSQL sempre tem consistência forte, uma reivindicação que outros fornecedores do NoSQL produzem. A reivindicação dos fornecedores do NoSQL para sempre ter uma consistência forte é como reivindicar ser um vegetariano forte … exceto aos domingos quando você está com carne assada.

O Riak não é um banco de dados compatível com ACID. Sua configuração não pode ser alterada de modo que ela seja executada no modo de conformidade ACID. Os clientes podem obter dados inconsistentes durante operações normais ou durante partições de rede. A Riak comercializa consistência absoluta para maior disponibilidade e tolerância de partição.

A execução do Riak no modo de consistência forte significa que suas réplicas de leitura são atualizadas ao mesmo tempo que o mestre primário. Isso envolve um commit de duas fases - basicamente, o nó mestre escrevendo para os outros nós antes de confirmar que a gravação está completa.

No momento desta escrita, o modo de consistência forte da Riak não suporta índices secundários ou tipos de dados complexos (por exemplo, JSON). Espero que Basho conserte esse problema nos próximos lançamentos do banco de dados.

Riak Search (um mecanismo de pesquisa Apache Solr rebranded e integrado usa um modelo de atualização eventualmente consistente) pode produzir falsos positivos ao usar consistência forte. Esta situação ocorre porque os dados podem ser escritos e, em seguida, a transação abandonada, mas os dados ainda são usados ​​para indexação - deixando um resultado de busca "falso positivo" - o resultado não é mais válido para a consulta de pesquisa.

O Riak também usa um processo sentinela separado para determinar qual nó se torna um mestre em condições de failover. Este processo, no entanto, não está altamente disponível, o que significa que, por alguns segundos, é possível que, enquanto uma nova cópia do processo sentinela for colocada on-line, um novo nó não pode ser adicionado ou um novo mestre eleito. Você precisa estar ciente dessa possibilidade em condições de failover de alto estresse.

A Riak possui alguns recursos agradáveis ​​para desenvolvedores de aplicativos, como indexação secundária e suporte de valor JSON incorporado. A replicação de banco de dados para recuperação de desastres para outros datacenters está disponível apenas na versão paga, cujo preço pode ser encontrado em seu site (preços de aluguel mostrados, preços de licenças perpétuas fornecidos apenas no pedido).

A ferramenta de monitoramento do cluster Riak Control também não é altamente considerada por causa de seu tempo de atraso ao monitorar clusters. A Riak tem muitas promessas e, se a Basho adicionar mais empresa - nível instalações de gerenciamento de cluster em versões futuras, ela se tornará um produto de primeira classe.