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, índices secundarios, TTL (Time to Live), columnas estáticas, contadores, tipos definidos por usuario (UDT) y transacciones ligeras (LWT). Las funcionalidades no soportadas incluyen vistas materializadas, índices SASI, funciones definidas por usuario (UDF), agregaciones definidas por usuario (UDA), batch log y API Thrift. Es obligatorio verificar la compatibilidad ejecutando el esquema y consultas existentes contra Keyspaces con cqlsh antes de la migración. Para la migración desde Cassandra se puede utilizar AWS DMS, que soporta carga completa y replicación continua mediante CDC (Change Data Capture). Durante la migración, se puede minimizar el tiempo de inactividad mediante escritura dual en el clúster Cassandra origen y Keyspaces simultáneamente. Al cumplir con la especificación CQL de Cassandra 3.11, las nuevas funcionalidades de Cassandra 4.x y posteriores no están disponibles.
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 es de tipo clave-valor/columna ancha, 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. La expresividad de CQL es superior a PartiQL de DynamoDB, pudiendo describir naturalmente operaciones como consultas de rango, cláusula IN, ORDER BY y ALLOW FILTERING. 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 tiene una integración abrumadoramente rica con el ecosistema AWS (Streams, DAX, Global Tables, PartiQL), facilitando la integración con Lambda triggers y EventBridge Pipes. La fortaleza de Keyspaces es la compatibilidad con el ecosistema Cassandra (drivers, ORM, herramientas), siendo ventajoso 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, siendo aproximadamente un 20-30% más económico que el modo bajo demanda. Al habilitar Auto Scaling, la capacidad se ajusta automáticamente según las variaciones de tráfico. Como punto de optimización de costos, la eliminación automática de datos mediante TTL es efectiva. 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. Point-in-Time Recovery (PITR) agrega aproximadamente un 20% al costo de almacenamiento al habilitarse, pero es indispensable para la recuperación ante pérdida de datos por errores operativos, por lo que debe habilitarse obligatoriamente en entornos de producción. La encriptación ofrece tres opciones: clave propiedad de AWS (gratuita), clave administrada por AWS y clave administrada por el cliente (KMS), seleccionándose según los requisitos de cumplimiento.