🎯 ATIVIDADE 09 — ESCALA PLANETÁRIA

Bem-vindo à nona semana (4 aulas) do curso de Banco de Dados. Após explorarmos o MongoDB, vamos subir o nível de escala. Hoje vamos conhecer o Apache Cassandra, o banco de dados utilizado por gigantes como Netflix e Uber para lidar com bilhões de transações por segundo. 🛡️🧩

🎯 Objetivos de Aprendizagem do Laboratório

Ao final deste laboratório prático (estimativa: 4 horas presenciais / autoguiadas), você será capaz de:

• Entender a arquitetura de Colunas de Larga Escala (Wide Column Store).
• Criar e gerenciar Keyspaces e Tabelas no Cassandra.
• Utilizar a linguagem CQL (Cassandra Query Language).
• Compreender a importância da Chave de Partição para a escalabilidade.

🏢 O Cenário Prático (Seu Desafio)

A TecProExpress instalou sensores IoT em toda a sua frota de caminhões. Cada caminhão envia sua posição GPS, velocidade e temperatura da carga a cada 5 segundos. Com milhares de veículos, o volume de dados é gigantesco.

Seu desafio é configurar um ambiente no Cassandra para receber esse fluxo de dados, garantindo que as informações sejam gravadas de forma ultra-rápida e nunca sejam perdidas.

🧠 Fundamentos: A Teoria Traduzida

O Cassandra não organiza dados em uma única máquina; ele os espalha por um Anel (Cluster) de servidores.

1. O Keyspace (O Condomínio)

No SQL temos "Databases". No Cassandra, temos Keyspaces. É aqui que definimos como os dados serão replicados entre as máquinas.

2. A Chave de Partição (O Endereço)

Imagine um grande armazém. Para achar uma caixa rápido, você precisa saber o número da prateleira. No Cassandra, a Partition Key decide em qual servidor do mundo o dado será guardado.

graph TD
    subgraph Cluster ["Anel Cassandra"]
    N1[Nó 1] --- N2[Nó 2]
    N2 --- N3[Nó 3]
    N3 --- N1
    end
    
    Data[Dado de GPS] -->|Hash da Chave| N2
    
    style Cluster fill:#f3e5f5,stroke:#7b1fa2

📖 Exemplo Guiado: Criando sua Infraestrutura

Veja como o CQL é amigável e parecido com o SQL tradicional.

💡 Os blocos abaixo usam CQL (Cassandra Query Language), sintaticamente parecido com SQL mas com diferenças importantes de modelagem — usamos o realce de sintaxe SQL por não haver um fence dedicado para CQL neste portal.

1. Preparando o Terreno (Keyspace)

-- Criando o Keyspace de Logística
CREATE KEYSPACE tecpro_logistica 
WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 1};

USE tecpro_logistica;

2. Criando a Tabela de Sensores (DDL)

CREATE TABLE telemetria (
    veiculo_id INT,
    data_hora TIMESTAMP,
    latitude DECIMAL,
    longitude DECIMAL,
    velocidade FLOAT,
    PRIMARY KEY (veiculo_id, data_hora)
);

🔍 Detalhamento do Código:

• SimpleStrategy: Estratégia de replicação para ambientes de teste (um único datacenter).
• PRIMARY KEY (veiculo_id, data_hora):
  • veiculo_id: Chave de Partição (espalha os caminhões pelo cluster).
  • data_hora: Chave de Agrupamento (ordena os logs de cada caminhão por tempo).

🛠️ Prática Obrigatória 1: Setup e Carga

Cenário: Monitoramento de Frota na TecProExpress.

1. Acesse seu ambiente Cassandra (via Docker ou local).
2. Crie o Keyspace tecpro_iot.
3. Crie a tabela status_caminhao para armazenar id, placa, temperatura e data_leitura.

🚀 Script de Seed (CQL)

INSERT INTO status_caminhao (id, placa, temperatura, data_leitura) 
VALUES (101, 'ABC-1234', 5.5, toTimestamp(now()));

INSERT INTO status_caminhao (id, placa, temperatura, data_leitura) 
VALUES (101, 'ABC-1234', 5.2, toTimestamp(now()));

💻 Execução de Queries no Terminal CQL (cqlsh) & Logs

Para testar consultas sequenciais particionadas via terminal cqlsh:

-- Consultando séries temporais ordenadas fisicamente no disco
SELECT id, placa, temperatura, data_leitura 
FROM tecpro_iot.status_caminhao 
WHERE id = 101 
LIMIT 2;

🖥️ Saída Esperada no Terminal do cqlsh:

 id  | data_leitura                    | placa    | temperatura
-----+---------------------------------+----------+-------------
 101 | 2026-03-01 14:22:05.120000+0000 | ABC-1234 |         5.2
 101 | 2026-03-01 14:22:00.080000+0000 | ABC-1234 |         5.5

(2 rows)

🌐 Requisição cURL para Ingestão de Telemetria Time-Series (Swagger /docs)

curl -X POST "http://127.0.0.1:8000/api/v1/telemetria/iot" \
     -H "Content-Type: application/json" \
     -d '{
       "veiculo_id": 101,
       "placa": "ABC-1234",
       "temperatura_celsius": 5.2,
       "velocidade_kmh": 78
     }'

🔹 Resposta JSON:

{
  "status": "REGISTRADO_NO_CLUSTER",
  "partition_key": "101",
  "replication_factor": 3
}

📤 Instruções de Entrega (Microsoft Teams)

Após testar suas tabelas e consultas no Cassandra (via cqlsh):

1. Salve o script contendo a criação do Keyspace, da tabela com a Primary Key adequada (Chave de Partição + Chave de Agrupamento) e as consultas de teste em um arquivo com a extensão .cql ou .sql contendo comandos CQL.
2. Adicione comentários no código explicando por que a escolha da Partition Key (veiculo_id/id) é vital para a distribuição horizontal de dados do cluster.
3. Envie o arquivo (Atividade_09_SeuNome.cql) na tarefa correspondente no Microsoft Teams.

💡 Checkpoint de Lógica

🔥 Desafio de Fixação (Opcional)

Nível: Arquiteto de Sistemas 🏆

O que é o Replication Factor (RF)? Se você configurar RF: 3 em um cluster de 5 máquinas, o que acontece se duas máquinas pegarem fogo ao mesmo tempo?

🔑 Gabarito de Código/Fórmulas Completo

Prática 1 (Criação):

CREATE TABLE status_caminhao (
    id INT,
    placa TEXT,
    temperatura FLOAT,
    data_leitura TIMESTAMP,
    PRIMARY KEY (id, data_leitura)
) WITH CLUSTERING ORDER BY (data_leitura DESC);

Prática 2 (Consulta):

SELECT * FROM status_caminhao WHERE id = 101;

🔍 Explicação do Gabarito:

• WITH CLUSTERING ORDER BY: Faz com que os logs mais recentes apareçam no topo da lista automaticamente, sem precisar de um ORDER BY lento na hora da consulta.
• TEXT: No Cassandra, usamos TEXT em vez de VARCHAR para a maioria das strings.

📊 Rubrica Formativa de Avaliação