Comparación entre CQL
y SQL Relacional
Este documento presenta una comparación entre la sintaxis
avanzada de Cassandra (CQL) y SQL relacional. Se incluyen
ejemplos que muestran sus diferencias clave.
por Cristian Alvarado
Creación de Tablas
SQL Relacional (MySQL) Cassandra (CQL)
CREATE TABLE clientes ( id SERIAL PRIMARY CREATE TABLE clientes ( id UUID PRIMARY
KEY, nombre VARCHAR(100), email KEY, nombre TEXT, email TEXT );
VARCHAR(100) UNIQUE );
En SQL, la clave primaria genera un índice automáticamente. En Cassandra, la clave primaria define la distribución
de los datos en nodos.
Particionamiento y Clustering
SQL con Índices Cassandra con Clustering
CREATE INDEX idx_nombre ON CREATE TABLE clientes ( id UUID, pais TEXT,
clientes(nombre); SELECT * FROM clientes ciudad TEXT, nombre TEXT, PRIMARY KEY
WHERE nombre = 'Juan'; ((pais), ciudad) ) WITH CLUSTERING ORDER BY
(ciudad ASC); SELECT * FROM clientes WHERE
pais = 'Colombia';
En SQL, los índices secundarios son eficientes. En Cassandra, la clave de partición (pais) define cómo se almacenan
los datos en los nodos.
Índices Secundarios vs. Materialized Views
SQL Relacional (Índice) Cassandra (Materialized View)
CREATE INDEX idx_email ON clientes(email); CREATE MATERIALIZED VIEW clientes_por_email
SELECT * FROM clientes WHERE email = AS SELECT id, nombre, email FROM clientes
'juan@[Link]'; WHERE email IS NOT NULL PRIMARY KEY (email,
id); SELECT * FROM clientes_por_email WHERE
email = 'juan@[Link]';
SQL usa índices secundarios para acelerar búsquedas. Cassandra replica los datos en una vista optimizada para
consultas.
Batches (Transacciones en Lotes)
SQL Relacional (Transacción) Cassandra (Batch Writing)
BEGIN TRANSACTION; INSERT INTO pedidos (id, BEGIN BATCH INSERT INTO pedidos (id,
cliente_id, total) VALUES (1, 5, 100); cliente_id, total) VALUES (uuid(), 5, 100);
INSERT INTO detalles_pedido (pedido_id, INSERT INTO detalles_pedido (pedido_id,
producto, cantidad) VALUES (1, 'Proteína', producto, cantidad) VALUES (uuid(),
2); COMMIT; 'Proteína', 2); APPLY BATCH;
En SQL, COMMIT asegura que todo se ejecute o nada se haga. En Cassandra, BATCH no garantiza atomicidad en
particiones diferentes.
TTL (Expiración Automática de Datos)
SQL (Eliminar manualmente) Cassandra (TTL Automático)
DELETE FROM logs WHERE fecha < NOW() - INSERT INTO logs (id, mensaje) VALUES
INTERVAL '7 days'; (uuid(), 'Registro de error') USING TTL
604800; -- Expira en 7 días
En SQL, la eliminación es manual o con DELETE. En Cassandra, los datos pueden eliminarse automáticamente tras
un tiempo definido.
Relaciones: Joins vs. Denormalización
SQL Relacional (Usando Joins) Cassandra (Denormalización)
SELECT [Link], [Link] FROM CREATE TABLE pedidos_cliente ( cliente_id
clientes JOIN pedidos ON [Link] = UUID, pedido_id UUID, total DECIMAL,
pedidos.cliente_id; PRIMARY KEY (cliente_id, pedido_id) );
SELECT * FROM pedidos_cliente WHERE
cliente_id = ;
En SQL, los JOIN son eficientes. En Cassandra, en lugar de JOIN, se duplica la información en tablas optimizadas.
User-Defined Types (UDT)
SQL Relacional (Usando JSON) Cassandra (Usando UDT)
CREATE TABLE clientes ( id SERIAL PRIMARY CREATE TYPE direccion ( calle TEXT, ciudad
KEY, nombre TEXT, direccion JSONB ); INSERT TEXT ); CREATE TABLE clientes ( id UUID
INTO clientes (id, nombre, direccion) PRIMARY KEY, nombre TEXT, dir FROZEN );
VALUES (1, 'Juan', '{"calle": "Av. INSERT INTO clientes (id, nombre,
Principal", "ciudad": "Monterrey"}'); direccion) VALUES (uuid(), 'Juan', {calle:
SELECT nombre, direccion->>'ciudad' FROM 'Av. Principal', ciudad: 'Monterrey'});
clientes WHERE id = 1;
SQL usa JSON o tablas relacionales. Cassandra usa UDT para estructuras anidadas.
Conclusión: ¿SQL vs.
Cassandra?
1 SQL
Cuando la integridad referencial y las relaciones son críticas.
2 Cassandra
Cuando se necesitan consultas rápidas a gran escala con
datos duplicados.
Si buscas lectura rápida con millones de registros, Cassandra es
mejor. Si necesitas transacciones y relaciones, usa SQL.
