Amazon Keyspaces

Base de datos completamente administrada compatible con Apache Cassandra que ofrece escalabilidad y disponibilidad serverless mientras se utiliza CQL (Cassandra Query Language) directamente

Descripción general

Amazon Keyspaces (for Apache Cassandra) es un servicio de base de datos completamente administrado que proporciona una API CQL compatible con Apache Cassandra. Permite utilizar directamente los drivers y herramientas existentes de Cassandra, liberándose de la operación de clústeres Cassandra (gestión de nodos, aplicación de parches, backups, escalado). El almacenamiento se replica automáticamente en 3 AZ, proporcionando un SLA de disponibilidad del 99.999%. Ofrece dos modelos de facturación: modo de capacidad bajo demanda y modo de capacidad provisionada.

Compatibilidad con Cassandra y límites de incompatibilidad

Keyspaces soporta la mayor parte de CQL (Cassandra Query Language), pero no todas las funcionalidades de Cassandra están disponibles. Las funcionalidades soportadas incluyen operaciones CRUD de tablas, TTL (Time to Live), columnas estáticas, contadores, tipos definidos por usuario (UDT), transacciones ligeras (LWT) y lotes con y sin registro (logged y unlogged batch). Las funcionalidades no soportadas incluyen índices secundarios (CREATE INDEX), vistas materializadas, funciones definidas por usuario (UDF), agregaciones definidas por usuario (UDA), triggers y TRUNCATE. Antes de la migración, se verifica la compatibilidad ejecutando el esquema y consultas existentes contra Keyspaces con cqlsh. Para migrar datos desde Cassandra hay opciones como la carga con cqlsh o DSBulk, la migración sin conexión con AWS Glue y la replicación casi en tiempo real con CQLReplicator. Durante la migración, se puede minimizar el tiempo de inactividad mediante escritura dual en el clúster Cassandra origen y Keyspaces simultáneamente. Keyspaces es compatible con la API de CQL 3.11, con compatibilidad hacia atrás con la versión 2.x (a fecha de octubre de 2026). Si depende de funcionalidades propias de versiones más recientes, verifique el estado de compatibilidad antes de decidir su adopción.

Criterios de selección frente a DynamoDB

Tanto Keyspaces como DynamoDB son bases de datos NoSQL completamente administradas, pero difieren en el modelo de datos y la flexibilidad de consultas. DynamoDB admite los modelos de datos clave-valor y de documentos, requiriendo diseñar previamente los patrones de acceso mediante partition key y sort key. Los GSI (Global Secondary Index) permiten patrones de acceso adicionales, pero cada índice genera costos adicionales. Keyspaces es de tipo columna ancha, permitiendo un modelado de datos flexible mediante partition key y clustering columns. CQL ofrece consultas de rango, cláusula IN, ORDER BY y otras operaciones (IN solo se admite en SELECT y, al combinar IN con ORDER BY, los resultados se ordenan dentro de una página). Como criterio de selección, DynamoDB es adecuado para nuevos proyectos diseñados nativamente en AWS, mientras que Keyspaces es apropiado para migrar cargas de trabajo Cassandra existentes. DynamoDB ofrece integración con el ecosistema AWS (Streams, DAX, Global Tables, PartiQL) y se conecta con Lambda triggers y EventBridge Pipes. Keyspaces se caracteriza por la compatibilidad con el ecosistema Cassandra (drivers, ORM, herramientas), siendo una opción cuando se prioriza la portabilidad en entornos multi-cloud o híbridos.

Selección de modo de capacidad y optimización de costos

Los modos de capacidad de Keyspaces, al igual que DynamoDB, son de dos tipos: bajo demanda y provisionado. El modo bajo demanda es facturación completamente por uso según el número de solicitudes, adecuado para cargas de trabajo con patrones de tráfico impredecibles y entornos de desarrollo. El modo provisionado configura previamente las unidades de capacidad de lectura/escritura. Al habilitar Auto Scaling, la capacidad se ajusta automáticamente según las variaciones de tráfico. Como punto de optimización de costos, TTL elimina automáticamente los datos caducados. Al configurar TTL en datos que se vuelven innecesarios después de cierto período, como datos de logs o sesiones, se puede contener el aumento de costos de almacenamiento. Con Point-in-Time Recovery (PITR) habilitado, se puede restaurar una tabla a cualquier segundo desde que se habilitó PITR, dentro de los últimos 35 días. La encriptación en reposo ofrece dos opciones de clave: la clave propiedad de AWS predeterminada (sin cargo adicional) y una clave administrada por el cliente en AWS KMS, seleccionándose según los requisitos de cumplimiento.

Referencias (recursos oficiales de AWS)

Las fuentes primarias de esta página son el sitio web y la documentación oficiales de AWS. Consulta las páginas oficiales siguientes para conocer las especificaciones y los precios más recientes.

Si esta página y la documentación oficial difieren, prevalece la documentación oficial.

Compartir