Principais diferenças e princípios de design do NoSQL

Os sistemas de bancos de dados NoSQL, como o Amazon Keyspaces, usam os modelos alternativos para o gerenciamento de dados, como pares de chave-valor ou armazenamento de documentos. Ao mudar de um sistema de gerenciamento de banco de dados relacional de dados relacionais para um sistema de banco de dados NoSQL como o Amazon Keyspaces, é importante compreender as principais diferenças e as abordagens específicas de design.

Diferenças entre design relacional de dados e NoSQL

Os sistemas de bancos de dados relacionais (RDBMS) e os bancos de dados NoSQL têm diferentes pontos fortes e fracos:

• No RDBMS, as consultas de dados são flexíveis, mas têm um custo relativamente alto e não escalam com facilidade em situações de grande volume de tráfego (consulte Melhores práticas de modelagem de dados: recomendações para projetar modelos de dados).

• Em um banco de dados NoSQL como o Amazon Keyspaces, há formas limitadas de consultar dados com eficiência. As demais formas de consulta podem apresentar alto custo e baixa performance.

Essas diferenças tornam o design de banco de dados diferente entre os dois sistemas:

• Em RDBMS, você cria o design para obter flexibilidade sem se preocupar com detalhes de implementação ou desempenho. A otimização de consultas geralmente não afeta o design do esquema, mas a normalização é importante.

• No Amazon Keyspaces, você projeta o esquema especificamente para fazer as consultas mais comuns e importantes do modo mais rápido e barato possível. Suas estruturas de dados são adaptadas aos requisitos específicos de seus casos de uso de negócios.

Dois conceitos-chave para design em NoSQL

O design do NoSQL exige uma visão diferente daquela no design do RDBMS. Para um RDBMS, você pode criar um modelo de dados normalizado sem pensar nos padrões de acesso. Você poderá estendê-lo posteriormente quando surgirem novas perguntas e requisitos de consulta. Você pode organizar cada tipo de dados em sua própria tabela.

Como o design de NoSQL é diferente

• Em comparação, você não deve começar a projetar o esquema do Amazon Keyspaces até que saiba quais as perguntas que ele precisa responder. É essencial compreender os problemas de negócios e os casos de uso de aplicativo antecipadamente.

• Você deve manter o mínimo de tabelas possível em um aplicativo do Amazon Keyspaces. Com menos tabelas, há mais escalabilidade, menos gerenciamento de permissões e menor sobrecarga para o Amazon Keyspaces. Isso também pode ajudar a manter os custos de backup mais baixos em geral.

Abordar o design em NoSQL

A primeira etapa ao projetar a aplicação do Amazon Keyspaces é identificar os padrões específicos de consulta aos quais o sistema deve atender.

Especificamente, é importante compreender três propriedades fundamentais de padrões de acesso de seu aplicativo antes de começar:

• Tamanho de dados: saber o volume de dados que serão armazenados e solicitados ao mesmo tempo ajuda a determinar a maneira mais eficiente de particionar os dados.

• Forma dos dados: em vez de remodelar dados quando uma consulta é processada (como um sistema RDBMS faz), um banco de dados NoSQL organiza os dados para que sua forma no banco de dados corresponda ao que será consultado. Esse é um fator importante no aumento da velocidade e da escalabilidade.

• Velocidade dos dados: o Amazon Keyspaces é escalado aumentando-se o número de partições físicas que estão disponíveis para processar consultas e distribuindo-se os dados com eficiência entre essas partições. Saber antecipadamente qual é o pico das cargas de consulta pode ajudar a determinar como particionar os dados para melhor utilizar a capacidade de E/S.

Após identificar os requisitos específicos da consulta, você pode organizar dados de acordo com os princípios gerais que regem o desempenho:

• Mantenha os dados relacionados juntos.   Uma pesquisa sobre a otimização de tabelas de rotas há 20 anos descobriu que a "localidade de referência" era o único fator o mais importante para agilizar o tempo de resposta: manter dados relacionados juntos em um só lugar. Isso também se aplica aos sistemas NoSQL hoje, em que manter dados relacionados juntos tem um impacto significativo no custo e no desempenho. Em vez da distribuição de itens de dados relacionados entre várias tabelas, você deve manter itens relacionados no sistema de NoSQL o mais próximo possível.

  Como regra geral, você deve manter o mínimo de tabelas possível em um aplicativo do Amazon Keyspaces.

  As exceções são os casos que envolvem dados de séries temporais de alto volume ou conjuntos de dados que têm padrões muito diferentes de acesso. Uma única tabela com índices invertidos pode normalmente habilitar consultas simples para criar e recuperar estruturas de dados hierárquicas e complexas, exigidas pelo aplicativo.

• Use a ordem de classificação.   Os itens relacionados podem ser agrupados juntos e consultados de modo eficiente se o design da chave fizer com que sejam classificados juntos. Essa é uma estratégia importante de design do NoSQL.

• Distribua as consultas.   É importante também que um alto volume de consultas não se concentre em uma parte do banco de dados, onde podem exceder a capacidade de E/S. Em vez disso, você deve projetar chaves de dados para distribuir o tráfego entre as partições do modo mais uniforme possível, evitando “pontos de atividade”.

Esses princípios gerais traduzem-se em alguns padrões comuns de design que você pode usar para modelar dados no Amazon Keyspaces com eficiência.