O que é NoSQL? Modelos de dados, diferenças em relação ao SQL e quando usar

Bancos de dados NoSQL são uma família de bancos de dados que usam modelos como documentos, pares chave-valor, colunas largas e grafos, em vez de depender do modelo de tabela relacional. Escolha um conforme o formato dos seus dados e as operações que sua aplicação precisa; apenas o rótulo NoSQL não garante consultas mais rápidas ou design mais simples.

SQL (Structured Query Language) é uma linguagem para consulta e manipulação de dados, enquanto NoSQL é uma categoria que abrange múltiplos modelos. “Not Only SQL” é uma maneira de explicar o nome; isso não significa que todo produto proíba SQL. A visão geral do NoSQL da AWS descreve os diferentes modelos e propósitos.

Os quatro principais modelos de dados NoSQL

Essas categorias descrevem como os dados são representados. Um produto pode suportar múltiplos modelos, e produtos na mesma categoria podem diferir em capacidades de consulta e operação.

Bancos de dados chave-valor

Um modelo chave-valor busca um valor usando uma chave como session:abc123. Considere-o quando o acesso for previsível, como ao recuperar uma sessão pelo seu ID. Pesquisar condições arbitrárias dentro de valores requer verificação dos recursos de indexação e consulta do produto específico.

Os valores não precisam ser apenas strings simples. O Redis suporta hashes, listas, conjuntos e conjuntos ordenados além de strings, conforme documentado em sua referência de tipo de dados. Para um cache, também decida onde os dados de referência ficam, quando as entradas expiram e o que acontece quando uma entrada em cache está ausente.

Bancos de dados de documentos

Um documento agrupa os campos, arrays e objetos aninhados de um item. JSON (JavaScript Object Notation) é um formato de texto para expressar tais estruturas; o MongoDB armazena documentos usando BSON (Binary JSON). Considere documentos para itens com atributos diferentes ou para dados comumente lidos juntos em uma tela.

Escolha entre incorporar informações relacionadas em um documento e referenciar o identificador de outro documento de acordo com a frequência de acesso, tamanho e atualizações. Copiar um endereço em cada pedido pode simplificar as leituras, mas você deve decidir o que a cópia significa e como ela é mantida. O guia de modelagem do MongoDB recomenda projetar com base nos padrões de acesso.

Bancos de dados de colunas largas

Modelos de colunas largas organizam dados em torno de chaves de linha ou partição e colunas. O Bigtable usa um mapa ordenado pela chave da linha e agrupa colunas relacionadas em famílias de colunas. Sua documentação sobre modelo de armazenamento explica linhas, colunas e famílias.

Um armazenamento de colunas largas não deve ser tratado como a mesma coisa que um armazenamento colunar analítico que agrupa os valores de uma coluna. O Cassandra exige um design de tabelas e partições orientado a consultas e não suporta junções relacionais. Sua introdução ao modelo de dados explica por que você deve primeiro identificar perguntas como “ler os registros deste dispositivo para este período.” Verifique se o candidato suporta as consultas de faixa e agregações necessárias.

Bancos de dados de grafos

Um grafo representa entidades, como pessoas, produtos ou servidores, como nós e suas conexões como arestas. Considere-o para perguntas que seguem relacionamentos, como identificar serviços afetados por uma falha de servidor.

Grafos também podem armazenar atributos. O modelo de grafo com propriedades do Neo4j permite propriedades tanto em nós quanto em relacionamentos, conforme explicado em seu guia sobre os conceitos de grafos. Um modelo de grafo não torna toda consulta rápida; defina a profundidade da travessia, tipos de relacionamento e condições de caminho.

Como o NoSQL difere de um banco de dados relacional?

Um sistema de gerenciamento de banco de dados relacional (RDBMS) organiza dados usando tabelas, chaves e restrições. Ele fornece uma base útil para unir registros relacionados e aplicar regras compartilhadas. Um produto NoSQL oferece operações apropriadas ao seu modelo, portanto, compare como cada candidato responde às questões da sua aplicação em vez de copiar um esquema existente sem alterações.

Armazenar JSON não exige automaticamente NoSQL. PostgreSQL, por exemplo, oferece tipos JSON e indexação para jsonb; veja sua documentação de tipo JSON. Manter regras relacionais e transações enquanto se utiliza atributos flexíveis para parte dos dados também é um desenho candidato.

Um esquema flexível ainda precisa ser projetado

Um esquema define estrutura e regras, como nomes de campos, tipos e valores obrigatórios. Mesmo que documentos possam ter campos diferentes, uma aplicação precisa de dados previsíveis. Este catálogo JSON fictício ilustra dois produtos com atributos diferentes:

[
  {
    "product_id": "book-101",
    "name": "Database Basics",
    "price_krw": 24000,
    "attributes": {
      "author": "Mina Kim",
      "pages": 320
    }
  },
  {
    "product_id": "headphones-201",
    "name": "Wireless Headphones",
    "price_krw": 79000,
    "attributes": {
      "wireless": true,
      "battery_hours": 30
    }
  }
]

Ambos os produtos compartilham product_id, name e price_krw, mas seus attributes aninhados diferem. A estrutura de um documento expressa essa variação de forma natural. No entanto, misturar números e strings no mesmo campo de preço pode complicar a ordenação e o cálculo, portanto, defina os tipos permitidos e o manejo de valores ausentes.

O MongoDB suporta regras de validação para tipos e intervalos de valores; sua documentação de validação de esquema explica como aplicar regras quando necessário. A CQL (Cassandra Query Language) do Cassandra, por outro lado, define colunas e tipos quando uma tabela é criada, como mostrado em sua referência de definição de tabela. Portanto, "Todo banco de dados NoSQL é sem esquema" é impreciso.

JSON descreve uma estrutura; ele não é, por natureza, um dado não estruturado. Decida separadamente se imagens e vídeos pertencem dentro de um banco de dados ou em armazenamento de objetos, com suas localizações e metadados em um banco de dados. O tamanho do arquivo, os requisitos de entrega e as necessidades de gerenciamento afetam essa escolha.

Verifique as garantias de transação e consistência por produto

Suporte a transações e escopo

Uma transação trata as mudanças como uma unidade de trabalho. ACID significa Atomicidade, Consistência, Isolamento e Durabilidade. Para mudanças que devem ter sucesso ou falhar juntas, como criar um pedido e reduzir o estoque, estabeleça primeiro as garantias necessárias.

NoSQL não implica ausência de transações. O MongoDB suporta transações de múltiplos documentos em conjuntos de réplicas e clusters particionados (sharded clusters), com garantias afetadas pela implantação e pelas configurações de leitura/escrita; veja sua documentação de transações. O DynamoDB também fornece APIs (Interfaces de Programação de Aplicações) transacionais, mas possui restrições, incluindo os alvos suportados e o escopo de Região. Sua referência de transações explica esses limites.

O que uma leitura pode retornar logo após uma gravação?

O comportamento de replicação também importa. Com leituras eventualmente consistentes, uma gravação recentemente concluída pode ainda não aparecer no resultado de uma leitura. Defina requisitos por ação do usuário: um pedido pode estar temporariamente ausente imediatamente após o usuário salvá-lo?

Tabelas do DynamoDB e índices secundários locais podem usar leituras fortemente consistentes, enquanto leituras de índices secundários globais e streams são eventualmente consistentes. Veja sua documentação sobre consistência de leitura para diferenças por alvo de consulta. Consistência ACID dentro de uma transação e consistência de leituras entre réplicas são preocupações diferentes.

Escalabilidade horizontal não garante desempenho

A escalabilidade horizontal adiciona servidores em vez de substituir um servidor por uma máquina maior. O sharding distribui os dados entre servidores; a replicação mantém cópias. Apenas múltiplos servidores não garantem dados equilibrados ou consultas mais rápidas. A visão geral do sharding do MongoDB descreve configurações distribuídas separadamente.

Uma chave mal distribuída pode concentrar solicitações em uma partição quente. Por exemplo, agrupar todos os eventos sob uma única chave fixa pode prejudicar a distribuição de carga. Considere os padrões de acesso e a distribuição de chaves juntos, como explicado em orientações de chave de partição do DynamoDB.

O desempenho depende do tamanho dos dados, índices, intervalo de consultas, proporção de leituras e gravações, configurações de consistência e carga de trabalho. Compare a latência de solicitações lentas, falhas e comportamento de recuperação junto com o tempo médio de resposta. Inclua réplicas, backups, rede e trabalho operacional na avaliação de custos; a categoria NoSQL sozinha não estabelece um custo menor.

Quando você deve considerar NoSQL?

• Cache de chave conhecida ou acesso a sessão: considere um armazenamento de chave-valor ao definir expiração, persistência e sincronização com dados de referência.
• Itens de catálogo com atributos variados: considere documentos ao projetar validação de campos compartilhados e índices de pesquisa.
• Eventos consultados por uma chave conhecida e período: considere armazenamento de colunas largas ao verificar o tamanho da partição e consultas de intervalo.
• Travessia de relacionamento em múltiplas etapas: considere um grafo ao definir tipos de conexão e profundidade de travessia.

Quando relatórios variados unem múltiplas tabelas ou restrições entre registros exigem aplicação centralizada, um banco de dados relacional merece uma comparação antecipada. Não decida apenas pelo rótulo da indústria ou volume de dados: examine como as leituras e atualizações mais importantes funcionariam em cada candidato.

Você pode atribuir diferentes funções a diferentes sistemas de armazenamento, como usar um banco de dados relacional como a fonte principal dos dados e um armazenamento chave-valor como cache. Sistemas de armazenamento adicionais também tornam a atualização de cópias, a propagação de exclusões e a recuperação mais complexas, então adicione-as apenas para um requisito demonstrado.

Uma sequência de avaliação prática

1. Anote as consultas importantes. Especifique filtros e ordenação para tarefas como consulta de produto por ID, pedidos recentes de usuários ou registros diários de um dispositivo.
2. Defina os requisitos de correção. Registre as alterações que devem ser bem-sucedidas juntas, o manejo de solicitações duplicadas, leituras imediatas e valores obsoletos aceitáveis.
3. Projete modelos candidatos reais. Examine o tamanho do documento, incorporação ou referências, índices, chaves de partição e caminhos de consulta à medida que os dados crescem.
4. Compare pequenas implementações. Use os mesmos dados e operações para reproduzir carga normal, carga concentrada e falhas; registre versões do produto e configurações.
5. Planeje operações e migração. Verifique permissões, backup e restauração, monitoramento, migração, custo esperado e um caminho de volta para o sistema de armazenamento existente, se necessário.

Comece com as consultas e requisitos de correção, depois escolha um modelo e produto que os satisfaçam. Se o banco de dados que você já usa atende a esses requisitos, estabeleça a razão para adicionar outro tipo de armazenamento antes de introduzi-lo.