Skip to main content
[ PIER ]

Apache Cassandra

NoSQL wide-column linealmente escalable — la base de datos que no se cae.

Database Listo para clúster #nosql#wide-column#distributed

Apache Cassandra es una base de datos NoSQL wide-column distribuida diseñada para alto throughput de escritura, escalado horizontal lineal y sin single point of failure. Usado en Netflix, Apple, Discord, Instagram, eBay — donde quiera que "la base de datos no se puede caer nunca" sea un requisito duro.

Desplegar con Pier

  1. 1 Abre el panel de Pier y haz clic en Add service.
  2. 2 Elige Cassandra en la lista de plantillas.
  3. 3 Elige la versión, asigna un nombre al servicio y Pier provisionará automáticamente el contenedor, el almacenamiento y los puertos.
  4. 4 Vincula un dominio si quieres HTTPS. Traefik genera el certificado de Let's Encrypt automáticamente.

¿Qué es Apache Cassandra?

Cassandra es una base de datos NoSQL wide-column distribuida originalmente desarrollada en Facebook (2008) y open-sourceada a través de la Apache Foundation. Su diseño prioriza el throughput de escritura y la disponibilidad sobre la consistencia — cada nodo es igual, no hay ceremonia de failover y el clúster sigue aceptando escrituras durante fallos de nodos y particiones de red.

Netflix, Apple, Discord (4 mil millones de mensajes/día), Instagram, eBay, Uber y muchos operadores de telecomunicaciones corren clústers Cassandra a escala extrema. Su modelo de datos (partition key + clustering key) te fuerza a pensar en patrones de query por adelantado pero te recompensa con escalado horizontal predecible y sin dramas operativos a escala.

Cómo lo despliega Pier

Pier usa la imagen Docker oficial cassandra, montando /var/lib/cassandra como volumen de datos. La versión por defecto es latest (Cassandra 5.x); 5.0, 4.1 LTS y 4.0 LTS también están disponibles.

El modo clúster soporta 2–5 nodos. Para producción, generalmente quieres 6+ nodos en 2+ datacenters — usa la plantilla de clúster de Pier como punto de partida y expande manualmente.

Los backups capturan tarballs de nodetool snapshot y pueden subirse a cualquier almacenamiento compatible con S3.

Cuándo NO usar Cassandra

Para OLTP con consistencia fuerte — Postgres. Para queries analíticas ad-hoc — ClickHouse. Para almacenamiento documental con queries ricas — MongoDB. Para latencia sub-milisegundo por nodo — ScyllaDB. Cassandra gana cuando patrones de acceso partition-keyed + throughput de escritura

  • disponibilidad + multi-DC son los requisitos duros.

Características clave

Arquitectura sin master

Cada nodo es igual — sin primary, sin ceremonia de failover. Lee y escribe en cualquier nodo; el clúster sigue convergiendo.

Escalado horizontal lineal

Dobla el tamaño del clúster, obtén aproximadamente el doble de throughput. Pocas bases de datos escalan el throughput de escritura de forma tan predecible.

Consistencia ajustable

Consistencia por consulta desde ONE (más rápido) hasta ALL (más fuerte). Elige el trade-off CAP correcto por caso de uso.

CQL — lenguaje similar a SQL

Cassandra Query Language se lee como SQL — CREATE TABLE, SELECT, INSERT — pero impone modelado partition-aware. Accesible para equipos SQL.

Replicación multi-datacenter

Replicación asíncrona entre regiones geográficas de fábrica. Consistencia quorum-por-DC para lecturas regionales de baja latencia.

Sin SPOF — sobrevive a pérdida de nodos

El clúster sigue sirviendo escrituras a través de fallos de nodos, particiones de red y upgrades rolling. Probado en batalla a escala Netflix.

Casos de uso

Time-series e IoT a escala extrema

Miles de millones de escrituras por día en clústers multi-nodo. Datos de sensores, telemetría, audit logs.

Sistemas de mensajería y chat

Discord almacena miles de millones de mensajes en Cassandra. El schema wide-row encaja perfectamente con los patrones de acceso a hilos de chat.

Streams de actividad de usuario

Timelines por usuario, feeds de notificaciones — alto throughput de escritura, patrones de lectura simples.

Estado de sesión multi-región

Sesiones de usuario replicadas globalmente con localidad regional de lectura. Consistencia multi-DC ajustada por clase de sesión.

Sistemas de recomendación como backing store

Recomendaciones pre-computadas servidas por partition key con lecturas sub-milisegundo en alta concurrencia.

Ejemplos de código

Crear keyspace y tabla sql 
CREATE KEYSPACE app
  WITH replication = {
    'class': 'NetworkTopologyStrategy',
    'datacenter1': 3
  };

USE app;

CREATE TABLE events (
  user_id  UUID,
  ts       TIMESTAMP,
  kind     TEXT,
  payload  TEXT,
  PRIMARY KEY ((user_id), ts)
) WITH CLUSTERING ORDER BY (ts DESC);
Escribir y leer por partición sql 
INSERT INTO events (user_id, ts, kind, payload)
VALUES (uuid(), toTimestamp(now()), 'signup', '{"plan":"pro"}');

SELECT * FROM events
WHERE user_id = 550e8400-e29b-41d4-a716-446655440000
LIMIT 20;
Consistencia ajustable sql 
-- Consistencia fuerte (quorum):
CONSISTENCY QUORUM;
SELECT * FROM events WHERE user_id = ?;

-- Eventual / rápida:
CONSISTENCY ONE;
SELECT * FROM events WHERE user_id = ?;
TTL en filas sql 
INSERT INTO sessions (id, user_id, payload)
VALUES (?, ?, ?)
USING TTL 3600;  -- expira tras 1 hora

Comparativa

vs ScyllaDB ScyllaDB es una reescritura en C++ de Cassandra optimizada para latencia sub-milisegundo y menor coste de hardware. CQL-compatible. Elige ScyllaDB si la latencia y throughput por nodo importan; Cassandra si la comunidad + tooling importan.
vs MongoDB Mongo es orientado a documentos; Cassandra es wide-column. Mongo gana en queries ad-hoc; Cassandra gana en escalado lineal de escritura y replicación multi-DC.
vs PostgreSQL Postgres es single-master con réplicas de lectura — consistencia fuerte, joins, transacciones. Cassandra es multi-master, sin joins, consistencia eventual por defecto. Elige Postgres para OLTP; Cassandra para cargas write-heavy y partition-keyed.
vs DynamoDB DynamoDB es wide-column gestionado por AWS con billing on-demand. Cassandra es autohospedado con costes predecibles. Las APIs difieren; Cassandra es OSS.

Preguntas frecuentes

¿Cassandra hace joins?
No. El modelo de datos es partition-key + clustering-key; desnormalizas y pre-computas joins en tiempo de escritura. SELECT debe incluir la partition key (o pagar un full-cluster scan).
¿Tamaño de clúster para producción?
Mínimo 3 nodos para lecturas/escrituras quorum; 6+ nodos para producción. La plantilla de clúster de Pier soporta 2–5 nodos — vale para evaluación y despliegues pequeños; producción suele necesitar más.
¿Puertos por defecto?
9042/tcp para protocolo CQL nativo; 7000/tcp para gossip entre nodos. Pier expone 9042 a apps; 7000 permanece en la red interna de Pier.
¿Backups?
Pier dispara `nodetool snapshot` en horario y envía los tarballs de snapshot a S3. El restore implica parar el nodo, reemplazar archivos de datos y rearrancarlo.
¿Debo elegir Cassandra o ScyllaDB?
Para mejor rendimiento por nodo — ScyllaDB. Para el mayor ecosistema, más tooling y Q&A comunitario — Cassandra. Ambos hablan CQL; la migración entre ellos es directa.
¿Cómo modelo los datos?
Empieza por queries, deriva las tablas. El modelado "query-first" es obligatorio. Desnormaliza libremente. Las docs del "Spotify model" o "Time-series patterns" de Cassandra son lectura esencial antes de usar en producción.
¿Autenticación por defecto?
Cassandra usa PasswordAuthenticator. Pier configura las credenciales vía variables de entorno en el primer arranque.

Servicios relacionados

Desplegar en tu VPS

Apache Cassandra es una base de datos NoSQL wide-column distribuida diseñada para alto throughput de escritura, escalado horizontal lineal y sin single point of failure. Usado en Netflix, Apple, Discord, Instagram, eBay — donde quiera que "la base de datos no se puede caer nunca" sea un requisito duro.

Desplegar este servicio →