??? CAPÍTULO 19: APACHE CASSANDRA — BIG DATA E CQL

Bem-vindo ao universo das tabelas imensas, de leituras e gravações em nível global. O Apache Cassandra 4.x (e sua vertente em C++, o ScyllaDB) revolucionou a forma como gigantes da tecnologia absorvem dados. ?????

Objetivo: Compreender a ruptura da arquitetura clássica Client-Server, abraçando a distribuição Descentralizada (Peer-to-Peer), o protocolo de rede Gossip e o formato estrutural do Anel Bi-Direcional (Ring).

?? PASSO 1: O Fim do Servidor Principal (Masterless)

Na engenharia clássica do SQL (mesmo particionada), é comum existir um Servidor "Mestre" (que domina a escrita) e Servidores "Escravos" (que fazem cópia para leitura). Se o mestre cai, o banco pára de gravar até que a equipe assuma ou um escravo se promova.

O Cassandra é Masterless (Sem Mestre). Ele adota a arquitetura Peer-to-Peer originada no manifesto do Amazon Dynamo. Todas as máquinas (Nós) ligadas na mesma rede são iguais. Todas podem escrever, todas podem ler. Se um nó queima, os usuários nem percebem.

?? PASSO 2: A Matemática do Anel (Ring)

Os dados não ficam num nó aleatório. Eles são distribuídos através de um cálculo criptográfico (Hashes) distribuindo as fatias da pizza igualmente em um Anel Virtuall (Ring).

?? Análise da Arquitetura Distribuída (Cassandra Ring)

flowchart TD
    APP["📱 Sua Aplicação Node.js / Python"]

    subgraph Cluster Cassandra ["Anel de Dados / Ring"]
        direction LR
        NO_A(("Nó Europa"))
        NO_B(("Nó Brasil"))
        NO_C(("Nó USA"))
        NO_D(("Nó Ásia"))

        NO_A <-->|Gossip| NO_B
        NO_B <-->|Gossip| NO_C
        NO_C <-->|Gossip| NO_D
        NO_D <-->|Gossip| NO_A
    end

    APP -.->|"Conecta em Qualquer Nó"| NO_B
    APP -.->|"O Nó vira Coordenador"| NO_C

??? O Protocolo Gossip (A Fofoca)

Como o Nó do Brasil sabe que o Nó da Ásia caiu? Através do protocolo Gossip (Fofoca). A cada segundo, os nós se comunicam trocando metadados uns dos outros. "Ei, eu estou vivo, e falei com o Nó da Ásia e ele está morto há 30 segundos". Todo o anel toma consciência instintiva do estado da infraestrutura.

?? PASSO 3: Soluções On-Premise vs Cloud Providers

Montar servidores bare-metal pelo mundo exige engenheiros Sêniores de Redes. Portanto, a indústria foca nos Cloud Providers (DBaaS). O Cassandra brilha sob as opções Serverless:

• DataStax Astra DB: O ambiente oficial criado pelos mantenedores do Cassandra. Gerenciamento zero para o programador, foco 100% no uso da linguagem (CQL).
• Amazon Keyspaces (for Apache Cassandra): A réplica compatível da AWS.
• ScyllaDB: Construído em C++, é compatível nativamente com os drivers CQL do Cassandra, oferecendo performance bruta de latência em milissegundos para casos radicais e sem o "peso" na memória exigido pelo Java.

?? Dica de Infra: Mesmo utilizando a Nuvem sob demanda (Astra, AWS Keyspaces), estudar o funcionamento local (Docker) ou a lógica do Ring é mandatório, pois o mau uso das chaves derruba sua aplicação inteira gerando custos imprevistos na AWS. ?????

?? MODELAGEM DE DADOS: O FIM DO JOIN

No RDBMS (Relacional), você modela as tabelas baseando-se no que será Guardado (Data-Driven). O aluno faz um MER focado primariamente na clareza (Normalização) (User, Pedido, Item) para evitar dados duplicados. Isso é lindo no Papel, mas mata o HDD. ?????

Objetivo: Adotar a arquitetura Query-Driven Modeling (Modelagem Focada na Pergunta), compreendendo o motivo vital pelo qual o ecossistema Distribuído aboliu as amarras do RDBMS.

?? PASSO 1: A Morte da Teoria dos Conjuntos Analíticos

?? REGRA DE OURO E DE SANGUE: NÃO EXISTE JOIN NO CASSANDRA!

Se você tiver uma tabela de USUARIOS em um Nó no Japão, e a tabela de COMPRAS no Nó do Brasil, tentar realizar um SELECT ... INNER JOIN exigiria que milhões de Gigabytes subissem no cabo de fibra ótica cruzando o Oceano toda vez que alguém clicasse em "Ver meu Histórico". O Timeout quebraria a internet.

Portanto, o Cassandra abandonou a junção de servidor (JOIN). Para que as respostas sejam servidas em menos de 10 milissegundos, você precisou abolir a normalização e forçar a "Leitura Seqüencial".

?? PASSO 2: Mudança de Paradigma (Query-Driven)

Para desenhar o seu banco a partir de agora, você precisa seguir este exato ritual:

1. Comece pelas Queries (Quais Perguntas a UI do seu App fará ao usuário?).
2. Desenhe uma Tabela Específica para Cada Pergunta.

?? Dica de Performance: No Cassandra, duplicar dados não é pecado, é estratégia primária. Se seu App tem duas abas na interface ("Buscar por Usuário" e "Buscar por E-mail"), você não vai usar subconsultas secundárias ou Joins reversos. Você terá obrigatoriamente duas tabelas gigantes: users_by_id e users_by_email.

?? PASSO 3: O Custo de Escrita vs. Custo de Leitura

No mundo anterior (SQL Clássico) aprendemos: "Evite gravar o mesmo dado duas vezes senão o HD acaba e a anomalia acontece."

No ecossistema de dados distribuído de altíssima escala (Cassandra/ScyllaDB), a verdade é matemática: Escrita é Barata, Leitura Cruzada é Extremamente Cara. O Cassandra foi projetado com otimizações nativas poderosas para escrever simultaneamente em 3, 5 ou 10 tabelas em microssegundos (utilizando o CommitLog em memória nativa), mas ele detesta ter que procurar peças que faltam usando a CPU dele (o Read dele é pior sem os metadados ideais).

Então, sempre crie e use comandos síncronos da sua Linguagem (Seu backend Node, Spring Boot, etc.) e mande ele inserir o mesmo evento de Venda nas 3 tabelas específicas ao vivo na hora da compra (Desnormalização Forte). ?????

?? CHAVES: PARTITION KEY VS CLUSTERING KEY

A essência de toda a magia distribuída, de por que o Cassandra alcança performance na casa dos milissegundos operando em Petabytes, jaz inteiramente no Design Matemático da sua Primary Key Composta (Chave Primária). ?????

Objetivo: Diferenciar o comportamento físico dos discos quando criamos Partition Keys (Localizador Global de Nó) e Clustering Keys (Localizador Magnético Interno / Ordem).

?? PASSO 1: A Dissecção da Chave Primária CQL

Na linguagem CQL, a Primary Key base não significa "Valor Único Aleatório Auto-Increment" como estamos moldados a pensar no MySQL Clássico. Aqui, uma "Chave Primária" é o controle total sobre o Motor Físico do cluster.

Se declararmos a tabela pedidos_by_cliente:

CREATE TABLE pedidos_by_cliente (
    cliente_id UUID,
    data_compra TIMESTAMP,
    produto TEXT,
    valor DECIMAL,
    PRIMARY KEY ((cliente_id), data_compra)
);

1. A primeira parte isolada em parênteses (cliente_id) é a Partition Key (K-Hash).
2. A segunda parte data_compra é a Clustering Key (K-Ordem).

?? PASSO 2: O Agrupamento de Discos Virtuais

O papel vital dessas chaves para o desenvolvedor Cloud:

• Partition Key (A Viagem Geográfica): Determina em GIGABYTES ONDE (em qual computador/Nó físico de Tóquio, NY ou SP) aquele registro viverá. Registros com o mesmo cliente_id cairão infalivelmente no mesmo servidor da rede.
• Clustering Key (A Viagem Magnética): Uma vez que fomos enviados ao Nó correto de Tóquio, ela dita a Ordem exata em que as linhas serão gravadas fisicamente juntas lado a lado. Por padrão (ASC).

?? NÃO EXISTE JOIN NO CASSANDRA! Portanto, agrupar fisicamente (Via Partition e Clustering) os dados que você deseja resgatar na sua tela inicial se torna vitalícia a regra do engenheiro da Alta Disponibilidade.

?? PASSO 3: Lógica Visual do Motor (Diagrama de Chato)

Abaixo vemos as dependências matemáticas geradas pela criação exata de chaves. O Nó que reter a Partição "X" reterá todas as ordenações magnéticas vinculadas a essa "Partição K".

?? Modelagem Híbrida de Escala

erDiagram    
    TABELA_PEDIDOS ||--o{ REGISTRO_FISICO : "Contém (Via Partition/Clustering)"
    
    TABELA_PEDIDOS {
        UUID cliente_id "PK (Partition_Key) - Hashing Token"
        TIMESTAMP data_compra "CK (Clustering_Key) - Order ASC"
        TEXT produto "Payload Data"
        DECIMAL valor "Payload Data"
    }

    REGISTRO_FISICO {
        Disco log_sequencial_node
        Ordenamento data_crescente
    }

?? Dica de Engenheiro: Um "Ponto de Atenção" fatal na carreira de um Analista de Dados Distribuído! Ao criar a Query, o WHERE no Cassandra é Obrigatório e Engessado. Você não pode buscar com um WHERE data_compra = X sem ANTES dizer WHERE cliente_id = Y. Você precisa informar primeiro ao Motor Distribuído qual país ele deve ir voar (Partition), para então ele ordenar e varrer a porta. ?????

?? CQL BÁSICO: COLLECTIONS E TIME TO LIVE (TTL)

Ao aceitar a natureza imutável do Apache Cassandra e o "Fim do JOIN", o Cassandra Query Language (CQL) compensou essa rigidez arquitetural entregando mecanismos elegantes poderosos de inserção temporária e arrays nativos via Colecionadores. ?????

Objetivo: Operacionalizar consultas e comandos de gravação distribuídos, explorando Tipos Complexos (List, Set, Map), O Fetiche mortal do Allow Filtering e as Exclusões Orgânicas (Tombstones e TTL).

?? PASSO 1: A Gravação Distribuída (Actor Model)

Sistemas Cloud escrevem metralhando milhares de Nós da forma mais brutalmente assíncrona.

?? Workflow das Operações Multi-Escrita

flowchart LR
    APP("?? Aplicação Back-end") -- "INSERT INTO (Level: QUORUM)" --> COORD("?? Coordinator Node")
    
    subgraph "Gravação Ponto-Comum (Replica = 3)"
        direction TB
        COORD --> N1[("??? Escrita Nó Principal")]
        COORD --> N2[("??? Escrita Réplica 1")]
        COORD --> N3[("??? Escrita Réplica 2")]
    end

(O Node de contato, chamado Coordinator, orquestra magicamente o disparo da replicação global em milissegundos)

?? PASSO 2: Trabalhando Collections (Sem JOINs de Fato)

Ao modelar entidades Query-Driven, às vezes queremos incluir anexos menores sem precisar gerar Duplicações Extras gigantes de tabelas inteiras.

O CQL disponibiliza SET, LIST e MAP.

/* ADICIONAR CONTEÚDO EXTRA EMBUTIDO */
CREATE TABLE user_perfis (
    email text PRIMARY KEY,
    nome text,
    telefones SET<text>,          -- Lista de valores únicos
    historico LIST<timestamp>,    -- Lista ordenada aceita duplicados
    preferencias MAP<text, text>  -- Chave : Valor (Dicionário)
);

/* INSERINDO METADADOS NOSQL (Sets utilizam chaves e Maps também) */
INSERT INTO user_perfis (email, nome, telefones, preferencias)
VALUES ('ceo@empresa.com', 'Alex', {'55999999', '55888888'}, {'tema':'dark', 'alertas':'on'});

?? PASSO 3: O Mortal ALLOW FILTERING

A engine exigirá obrigatoriamente que suas pesquisas contemplem a Partition Key exata da Tabela Desnormalizada, como visto anteriormente (O "Voo" direto ao servidor correto).

Se num momento trágico de gambiarra o DBA tentar consultar pelo Nome do Cidadão (que NÃO é chave Primária ou Índex) a tela devolverá um Erro fatal, te bloqueando.

?? A Marreta do Mal: ALLOW FILTERING

-- NUNCA FAÇA ISSO NO GLOBO (APENAS PARA POGS LOCAIS MINÚSCULOS)
SELECT * FROM user_perfis WHERE nome = 'Alex' ALLOW FILTERING;

O ALLOW FILTERING obriga o Cassandra a ignorar o roteamento da Partição (Ele avisa: Pode ler do HD da Terra inteira Node por Node de forma cega!). Você colapsará a RAM e a CPU do Cluster e ele cairá (Latency Timeouts Diários). ???

?? PASSO 4: Validade dos Dados (Time To Live - TTL)

Sistemas "Temporais", Sensores IoT (Temperatura da Fábrica) ou Cookies Lógicos no Banco ganham uma expiração da prateleira orgânica. No Big Data distribuído não ficamos executando lógicas pesadas de "Rotinas de DELETE Diárias":

/* O dado sumirá orgânicamente como fantasmas (Tombstone) em Segundos Exatos (60s) */
INSERT INTO medicoes_sensores (sensor_id, temp, timestamp) 
VALUES ('ZN01', 58, toTimestamp(now())) USING TTL 60;

A matemática da nuvem cria Marcadores Fúnebres (Tombstones) aos quais as operações diárias de varredura magnética compactam removendo efetivamente a lixeira sem sobrecarregar ninguém! ?????

?? CONSIDERAÇÕES FINAIS: UNIDADE VII (BIG DATA / CASSANDRA)

A essência da Arquitetura Distribuída separa os programadores dos Engenheiros de Dados de Alta Performance. Dominar a estratégia Masterless (Nó-a-Nó) molda profundamente o seu poder de escala em projetos que outrora sofreriam quedas drásticas no mundo corporativo. ?????

Objetivo: Ratificar os axiomas do Cluster NoSQL, avaliando mentalmente decisões rigorosas de Query-Driven Modeling e Particionamento Físico de chaves compostas (Discos e Localização).

? Exercícios de Fixação: Partitioning & Ring Nodes

1. Sob o protocolo de espalhamento matemático em um cluster Ring (Anel) do Apache Cassandra, o que efetivamente o Protocolo GOSSIP entrega como valor insuperável à rede? a) O Gossip transfere e copia a Primary Key inteira para o Banco Relacional. b) O Gossip converte o tráfego Binário do Sistema Operacional local para formato JSON e retransmite para o mongosh. c) O Gossip é o mensageiro vitalício (1 Segundo) onde os Servidores (Nós) atualizam reciprocamente o status uns dos outros, mapeando falhas ou lentidões da topologia (Cluster Health) de forma autonôma e descentralizada, sem precisar de um "Servidor Gerenciador Central". d) O Protocolo Gossip apenas funciona na Nuvem AWS.

2. No paradigma Masterless, se o Nó Brasil recebe do aplicativo a instrução INSERT com um número de réplicas setado para 3 geografias globais, qual a função sistêmica deste nó específico no momento da operação? a) Ele declina o insert exigindo que o Master do Japão aprove a Gravação. b) Ele assume provisoriamente o cargo de Coordinator, executando cópias assíncronas paralelas aos outros nós-alvo ditados pelo Driver do App. c) Ele armazena um arquivo XML de backup. d) Ele inicia um ROLLBACK preventivo.

3. Uma Equipe tentou executar um SELECT por NOME DO CLIENTE em uma enorme Tabela desenhada com id_cliente como Partition Key Exclusiva. Eles não receberam resultado, mas sim um Erro Sistêmico. O Analista Júnior propôs usar brutalmente a clausura ALLOW FILTERING. O que ocorrerá com a corporação? a) A pesquisa ocorrerá rápido e sem restrições usando Inteligência Artificial. b) O Cluster sofrerá esgotamentos mortais de Timeout e lentidão, já que você ordenou que HDs do mundo inteiro (Sem critério Geográfico Hashing) varressem exaustivamente todos os registros da Tabela, quebrando a regra fundamental do roteamento por Particionamento. c) O ALLOW FILTERING apenas ordena os resultados pelo alfabeto ASC. d) O ALLOW FILTERING criará um Log Seguro.

?? Desafio de Modelagem (O Arquiteto Data-Driven vs Query-Driven)

O Problema (Mudança Brusca na Nuvem de Telemetria): Uma montadora RDBMS coletava a velocidade e temperatura dos Seus Carros e salvava tudo em PostgreSQL de forma linear. Toda vez que os Analistas queriam a "Temperatura do Motor X nos Últimos 10 Minutos", o banco de dados desmaiava rodando um milhão de Table Scans. O CTO mandou você migrar o sistema vital para Servidores Físicos Apache Cassandra (ScyllaDB em C++).

Você sabe que a Query Principal Vital é: "Quero TODAS as temperaturas coletadas de UM ESPECÍFICO Motor (motor_serial), ordenados dos registros Mais Recentes para os Mais Antigos!"

Sua Missão Arquitetural: Crie a Tabela Primária CQL perfeita (telemetria_por_motor), isolando quem será a Partition Key (Localidade do HDD do Ring) e quem será a dependente Clustering Key (Ordenando no próprio HDD no sentido Temporal Descendente).

CREATE TABLE telemetria_por_motor (
    motor_serial text,
    data_coleta timestamp,
    temperatura decimal,
    velocidade int,
    
    -- ESTRUTURANDO AS CHAVES DO HD:
    PRIMARY KEY ( (motor_serial), data_coleta )

) WITH CLUSTERING ORDER BY (data_coleta DESC);