Gerenciando Keys no NoSQL - dummies

As capacidades de leitura rápida das lojas de valor-chave derivam do uso de chaves bem definidas. Essas chaves são tipicamente hash, o que fornece a uma loja de valores-chave uma maneira muito previsível de determinar quais dados de partição (e, portanto, servidor) reside. Um servidor específico gerencia uma ou mais partições.

Uma boa chave permite que você identifique de forma exclusiva o registro único que atenda uma consulta sem ter que observar os valores dentro desse registro. Uma tecla incorreta exigirá que seu código de aplicativo interprete seu registro para determinar se, de fato, corresponde a consulta.

Se você não projetar sua chave bem, você pode acabar com um servidor com uma carga desproporcionalmente mais pesada do que os outros, levando a um desempenho fraco. Usando o tempo atual do sistema como uma chave, por exemplo, empurra todos os novos dados para o último nó no cluster, o que leva a um cenário de pesadelo de reequilíbrio.

Particionamento

O design da partição é importante porque algumas lojas de valores-chave, como o Oracle NoSQL, não permitem que o número de partições seja modificado quando um cluster é criado. Sua distribuição entre servidores, porém, pode ser modificada. Então comece com um grande número de partições que você pode espalhar no futuro.

Um exemplo de particionamento é a abordagem de hashing consistente do Voldemort, como mostrado. Aqui você vê as mesmas partições espalhadas por três servidores inicialmente e depois em quatro servidores mais tarde. O número de partições permanece o mesmo, mas sua alocação é diferente em todos os servidores. O mesmo se aplica às suas réplicas.

Acessando dados nas partições

As lojas de valores-chave são altamente distribuídas sem um único ponto de falha. Isso significa que não há necessidade de um nó de coordenação principal para acompanhar os servidores dentro de um cluster. O gerenciamento de cluster é feito automaticamente por um protocolo de bate-papo entre nós no servidor.

Você pode usar um truque no driver do cliente para espremer o desempenho máximo de recuperar e armazenar chaves e valores - o driver do cliente controla quais servidores mantêm o intervalo de teclas. Então, o driver do cliente sempre sabe com qual servidor conversar.

A maioria dos bancos de dados, o NoSQL incluído, transmite uma solicitação a todos os membros de um cluster. Esse cluster aceita a gravação internamente ou passa uma sob o capô para o nó correto. Esta configuração significa que uma viagem de rede adicional entre nós é possível, o que pode aumentar a latência.

Para evitar a latência de descoberta, os controladores de clientes de lojas de valores principais mantêm uma lista de metadados dos nós atuais em um cluster e quais os intervalos de chaves de partição que cada nod gerencia.Desta forma, o driver do cliente pode entrar em contato com o servidor correto, o que torna as operações mais rápidas.

Se um novo nó é adicionado a um cluster e os metadados estão desatualizados, o cluster informa o driver do cliente, que então baixa os metadados do cluster mais recentes antes de reenviar a solicitação para o nó correto. Desta forma, o rendimento máximo é mantido com um mínimo de sobrecarga durante o desenvolvimento. Outro benefício secundário é que não há necessidade de um balanceador de carga passar consultas no próximo servidor disponível, ou menos ocupado, apenas um servidor (ou ler servidor de réplicas) já recebeu um pedido de cliente, portanto, não há necessidade de balanceamento de carga.