Skip to main content
[ PIER ]

ScyllaDB

Una reescritura en C++ de Cassandra — mismo CQL, 10× menos latencia.

Database Listo para clúster #nosql#wide-column#cassandra-compatible#high-performance

ScyllaDB es una reimplementación de alto rendimiento, drop-in compatible, de Apache Cassandra escrita en C++ usando una arquitectura shared-nothing, shard-por-core. Habla CQL, corre en Kubernetes, escala linealmente y entrega latencias p99 de un dígito en milisegundos en cargas donde Cassandra sufre.

Desplegar con Pier

  1. 1 Abre el panel de Pier y haz clic en Add service.
  2. 2 Elige ScyllaDB 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 ScyllaDB?

ScyllaDB es una reescritura en C++ desde cero de Apache Cassandra que empezó en 2015 con un objetivo: mantener el modelo de datos, eliminar el “tax” de JVM de Cassandra. La arquitectura shard-por-core significa que cada core de CPU posee una porción de datos sin estado mutable compartido — sin context-switches de threads, sin pausas de GC, sin sincronización cross-core.

El resultado para el usuario: mismo CQL, mismos drivers, mismos schemas — pero 10× menos latencia p99, a menudo la mitad del hardware. Discord migró 177 nodos de Cassandra a 72 nodos de ScyllaDB y bajó p99 un orden de magnitud.

Cómo lo despliega Pier

Pier usa la imagen Docker oficial scylladb/scylla, montando /var/lib/scylla como volumen de datos. La versión por defecto es latest (Scylla 6.x al momento de escribir esto); 5-stable, 6-stable son variantes fijadas.

El modo clúster soporta 2–5 nodos; los despliegues de producción suelen querer 3+ por datacenter. Pier expone 9042 (CQL) y 9180 (shard-aware).

Los backups usan tarballs de snapshot y pueden enviarse a cualquier almacenamiento compatible con S3.

Cuándo NO usar ScyllaDB

Para OLTP con consistencia fuerte y joins ricos — Postgres. Para analítica ad-hoc — ClickHouse. Para documentos con schemas flexibles — MongoDB. Para caché/queue en memoria — Redis/Valkey. Scylla brilla cuando acceso partition-keyed + throughput de escritura + tail latency predecible son los requisitos duros.

Características clave

Compatibilidad CQL drop-in

Mismo protocolo CQL, mismos drivers, mismo modelo de datos que Cassandra. Migra vía dumps cqlsh o streaming en vivo con sstableloader.

Arquitectura shard-por-core

Cada core de CPU posee un shard. Sin locks cross-core, sin context-switching de threads — latencia predecible bajo carga pesada.

10× menor latencia p99

Un dígito de milisegundos en el percentil 99 donde Cassandra está en decenas o cientos. Mejor tail latency = mejor experiencia de usuario.

Menor huella de hardware

A menudo corre la misma carga sobre 1/3 del hardware de Cassandra. Los ahorros se acumulan en clústers multi-nodo.

Mismo diseño sin master

Sin primary, sin failover. Cada nodo es igual. Consistencia ajustable desde ONE hasta ALL.

Tooling operativo moderno

Observabilidad integrada vía Prometheus, scheduling dinámico de cores, gestión automática de memoria, hinted handoff.

Casos de uso

Perfiles de usuario y almacenes de sesión

Registros por usuario servidos por partition key a p99 de un dígito de ms — encaja perfectamente con AdTech, social, gaming.

Time-series e IoT a escala

Ingesta alta de datos sensor / telemetría; mismo modelo que los patrones de time-series de Cassandra pero con mejor latencia.

Sistemas de recomendación como backing store

Recomendaciones pre-computadas usuario/item servidas con alta concurrencia y tail latency predecible.

Serving AdTech y bidding

Respuestas de bid en tiempo real necesitan p99 sub-10ms — la arquitectura por core de Scylla gana donde DBs generalistas caen.

Migración de reducción de coste desde Cassandra

Clústers Cassandra existentes a menudo migran a Scylla y reducen el conteo de nodos en 60–70% con mejores SLOs.

Ejemplos de código

Crear keyspace y tabla (idéntico a Cassandra) sql 
CREATE KEYSPACE app
  WITH replication = {
    'class': 'NetworkTopologyStrategy',
    'datacenter1': 3
  };

USE app;

CREATE TABLE sessions (
  user_id   UUID,
  token     TEXT,
  created   TIMESTAMP,
  last_seen TIMESTAMP,
  PRIMARY KEY ((user_id), token)
);
Escritura con TTL sql 
INSERT INTO sessions (user_id, token, created, last_seen)
VALUES (?, ?, toTimestamp(now()), toTimestamp(now()))
USING TTL 86400;  -- expira en 24h
Consistencia ajustable sql 
CONSISTENCY LOCAL_QUORUM;
SELECT * FROM sessions WHERE user_id = ?;
Conectar desde Java / Spring (el driver Cassandra funciona sin cambios) java 
CqlSession session = CqlSession.builder()
  .addContactPoint(new InetSocketAddress("scylla-host", 9042))
  .withAuthCredentials("user", "pass")
  .withKeyspace("app")
  .build();

Comparativa

vs Apache Cassandra ScyllaDB es compatible a nivel de cable y CQL. Mismo modelo de datos, mismos drivers. Scylla gana en latencia y densidad; Cassandra tiene mayor ecosistema y trayectoria más larga.
vs DynamoDB Ambos son wide-column con APIs similares (DynamoDB tiene su propio SDK). Scylla tiene una API compatible con DynamoDB llamada Alternator. Autohospedado vs gestionado por AWS; Scylla gana en predictibilidad de costes.
vs Redis / Valkey Redis es en memoria con persistencia opcional; Scylla es durable disk-first. Usa Redis para caché + datos efímeros, Scylla para wide-column durable a escala.
vs MongoDB Mongo es orientado a documentos con lenguaje de query rico. Scylla es wide-column partition-keyed. Mongo gana en queries ad-hoc; Scylla gana en latencia predecible y throughput de escritura.

Preguntas frecuentes

¿ScyllaDB es realmente un reemplazo drop-in para Cassandra?
A nivel de protocolo CQL, sí. Los schemas migran vía `cqlsh -e "DESCRIBE KEYSPACE..."`. La migración de datos vía sstableloader o cqlsh copy. Algunas herramientas específicas de Cassandra (subcomandos de nodetool) tienen equivalentes en ScyllaDB.
¿Open source o propietario?
ScyllaDB se distribuye en dos ediciones — ScyllaDB Open Source (AGPL) y ScyllaDB Enterprise (comercial). Pier despliega la edición Open Source.
¿Puertos por defecto?
9042/tcp para CQL (igual que Cassandra). 9180/tcp para el protocolo shard-aware específico de Scylla (los clientes aware del driver lo usan para mejor routing).
¿Tamaño de clúster?
La plantilla de clúster de Pier soporta 2–5 nodos. Producción suele querer 3+ nodos por datacenter para lecturas/escrituras QUORUM.
¿Migrar de Cassandra a ScyllaDB?
Sí — ScyllaDB incluye un toolkit de migración. Streaming en vivo vía SCYLLA migrator + sstableloader. La mayoría de apps no cambian una línea de código; solo cambian los endpoints de conexión.
¿Backups?
ScyllaDB tiene soporte de snapshots integrado vía `nodetool snapshot` (igual que Cassandra). Pier envía tarballs de snapshot a S3 en horario.
¿Ganancia de rendimiento vs Cassandra?
Depende de la carga. Reportes típicos — 50–80% menor latencia p99, 30–60% menos nodos para el mismo throughput. Corre tus propios benchmarks antes de comprometerte a migrar.

Servicios relacionados

Desplegar en tu VPS

ScyllaDB es una reimplementación de alto rendimiento, drop-in compatible, de Apache Cassandra escrita en C++ usando una arquitectura shared-nothing, shard-por-core. Habla CQL, corre en Kubernetes, escala linealmente y entrega latencias p99 de un dígito en milisegundos en cargas donde Cassandra sufre.

Desplegar este servicio →