Padrões de Especialista NoSQL (Cassandra & DynamoDB)

Visão Geral

Esta habilidade fornece modelos mentais profissionais e padrões de design para armazenamentos distribuídos de colunas largas e chave-valor (especificamente Apache Cassandra e Amazon DynamoDB).

Diferente do SQL (onde você modela entidades de dados) ou de armazenamentos de documentos (como MongoDB), esses sistemas distribuídos exigem que você modele suas consultas primeiro.

Quando Usar

• Projetando para Escalabilidade: Indo além de bancos de dados simples de nó único para clusters distribuídos.
• Seleção de Tecnologia: Avaliando ou usando Cassandra, ScyllaDB ou DynamoDB.
• Otimização de Desempenho: Solucionando problemas de "partições quentes" ou alta latência em sistemas NoSQL existentes.
• Microsserviços: Implementando padrões de "banco de dados por serviço" onde leituras altamente otimizadas são necessárias.

A Mudança de Mentalidade: SQL vs. NoSQL Distribuído

A Regra de Ouro: Em SQL, você projeta o modelo de dados para responder a qualquer consulta. Em NoSQL, você projeta o modelo de dados para responder a consultas específicas de forma eficiente.

Padrões de Design Principais

1. Modelagem Orientada a Consultas (Padrões de Acesso)

Normalmente, você não pode "adicionar uma consulta depois" sem migração ou criação de uma nova tabela/índice.

Processo:

1. Listar todas as Entidades (Usuário, Pedido, Produto).
2. Listar todos os Padrões de Acesso ("Obter Usuário por E-mail", "Obter Pedidos por Usuário ordenados por Data").
3. Projetar Tabela(s) especificamente para atender a esses padrões com uma única consulta.

2. A Chave de Partição é o Rei

Os dados são distribuídos entre nós físicos com base na Chave de Partição (PK).

• Objetivo: Distribuição uniforme de dados e tráfego.
• Anti-Padrão: Usar uma PK de baixa cardinalidade (por exemplo, status="active" ou gender="m") cria Partições Quentes, limitando a taxa de transferência à capacidade de um único nó.
• Melhor Prática: Usar chaves de alta cardinalidade (IDs de Usuário, IDs de Dispositivo, Chaves Compostas).

3. Chaves de Clusterização / Ordenação

Dentro de uma partição, os dados são ordenados em disco pela Chave de Clusterização (Cassandra) ou Chave de Ordenação (DynamoDB).

• Isso permite Consultas de Intervalo eficientes (por exemplo, WHERE user_id=X AND date > Y).
• Ele efetivamente pré-ordena seus dados para requisitos de recuperação específicos.

4. Design de Tabela Única (Listas de Adjacência)

Uso principal: DynamoDB (mas os conceitos se aplicam em outros lugares)

Armazenar múltiplos tipos de entidade em uma única tabela para permitir leituras pré-unidas.

• Consulta: PK="USER#123"
• Resultado: Busca o Perfil do Usuário E todos os Pedidos em uma única requisição de rede.

5. Desnormalização e Duplicação

Não tenha medo de armazenar os mesmos dados em várias tabelas para atender a diferentes padrões de consulta.

• Tabela A: users_by_id (PK: uuid)
• Tabela B: users_by_email (PK: email)

Compromisso: Você deve gerenciar a consistência dos dados entre as tabelas (geralmente usando consistência eventual ou escritas em lote).

Orientação Específica

Apache Cassandra / ScyllaDB

• Estrutura da Chave Primária: ((Partition Key), Clustering Columns)
• Sem Joins, Sem Agregados: Não tente JOIN ou GROUP BY. Pré-calcule agregados em uma tabela de contadores separada.
• Evite ALLOW FILTERING: Se você vir isso em produção, seu modelo de dados está errado. Isso implica uma varredura completa do cluster.
• Escritas são Baratas: Inserções e atualizações são apenas anexações à árvore LSM. Não se preocupe tanto com o volume de escrita quanto com a eficiência da leitura.
• Tombstones: Exclusões são marcadores caros. Evite padrões de exclusão de alta velocidade (como filas) em tabelas padrão.

AWS DynamoDB

• GSI (Índice Secundário Global): Use GSIs para criar visualizações alternativas de seus dados (por exemplo, "Pesquisar Pedidos por Data" em vez de por Usuário).
  • Nota: GSIs são eventualmente consistentes.

…