Base de datos compatible con Cassandra - Base de datos distribuida serverless con Amazon Keyspaces
Aprenda a diseñar y operar bases de datos distribuidas utilizando Amazon Keyspaces (para Apache Cassandra) y DynamoDB.
Apache Cassandra y Amazon Keyspaces
Apache Cassandra es una base de datos NoSQL conocida por su alto rendimiento de escritura, escalabilidad lineal y replicación multirregión como base de datos distribuida a gran escala. Se ha usado ampliamente como base de servicios a gran escala en usos con escrituras intensivas, como datos de series temporales, registros de eventos e historiales de mensajes, pero operarla en las instalaciones requiere experiencia profunda. Las tareas operativas son extensas, incluyendo el rebalanceo de datos durante la adición y eliminación de nodos, optimización de estrategias de compactación, gestión de tombstones y ajuste de JVM. Amazon Keyspaces es un servicio de base de datos completamente administrado compatible con Apache Cassandra que permite usar CQL (Cassandra Query Language) tal cual. Puede usar los controladores y herramientas de aplicaciones Cassandra existentes con modificaciones mínimas, reduciendo drásticamente la carga operativa mientras preserva el modelo de datos y los patrones de consulta de Cassandra. Con su arquitectura serverless, puede comenzar a leer y escribir datos inmediatamente después de crear una tabla, sin necesidad de aprovisionar capacidad previamente.
Características y arquitectura de Amazon Keyspaces
Amazon Keyspaces opera de manera serverless, escalando automáticamente el rendimiento de las tablas según el tráfico. En modo bajo demanda, paga por solicitud de lectura/escritura, minimizando costos durante períodos de bajo tráfico. El modo aprovisionado ofrece precios eficientes para cargas de trabajo predecibles. El almacenamiento se expande automáticamente y los datos se replican en tres zonas de disponibilidad dentro de la región con un factor de replicación de 3. El SLA de disponibilidad tiene dos niveles según la configuración: el Service Commitment del SLA oficial (versión actualizada el 24 de mayo de 2023) establece un tiempo de actividad mensual del 99.99% para el Standard SLA, que se aplica a configuraciones de una sola región, y del 99.999% para el Multi-Region Replication SLA, que se aplica cuando se configura la replicación multirregión. Tenga en cuenta que la replicación en tres AZ respalda la durabilidad dentro de una sola región y no es en sí misma la base del 99.999%. El cifrado está habilitado por defecto tanto para datos en reposo como en tránsito, con la opción de usar claves administradas por el cliente a través de AWS KMS. Keyspaces es compatible con la API de CQL 3.11 (compatible con versiones anteriores 2.x), y las definiciones de tablas, tipos de datos y sintaxis de consultas son compatibles con Cassandra. Las escrituras condicionales con transacciones ligeras (LWT), como IF NOT EXISTS, y el tipo counter son compatibles, y el uso de LWT no tiene cargo adicional. Sin embargo, las escrituras cuya condición resulta FALSE consumen unidades de escritura según el tamaño de la fila, por lo que se supervisa el número de fallos con la métrica ConditionalCheckFailed de CloudWatch. Según la tabla de compatibilidad oficial (a agosto de 2026), no se admiten, entre otros, los índices secundarios (CREATE INDEX / DROP INDEX), las vistas materializadas, los triggers, las funciones definidas por el usuario (UDF) y las funciones de agregación, ALTER TYPE y TRUNCATE. Las columnas estáticas, TTL, LOGGED / UNLOGGED BATCH y los tipos definidos por el usuario (UDT) están disponibles. La recuperación a un punto en el tiempo (PITR) permite restaurar una tabla a cualquier punto dentro de los últimos 35 días, facilitando la recuperación de operaciones accidentales o corrupción de datos. A continuación se muestra un ejemplo de creación de tabla en Keyspaces usando CQL: CREATE TABLE my_keyspace.orders ( customer_id text, order_id timeuuid, product_name text, quantity int, total_amount decimal, PRIMARY KEY (customer_id, order_id) ) WITH CLUSTERING ORDER BY (order_id DESC) AND CUSTOM_PROPERTIES = {'capacity_mode': {'throughput_mode': 'PAY_PER_REQUEST'}};
Estrategia de migración de Cassandra a Keyspaces
Se recomienda un enfoque por fases para migrar de un clúster Cassandra existente a Keyspaces. Primero, verifique la conectividad a Keyspaces usando cqlsh o controladores DataStax y confirme la compatibilidad del esquema. Para la migración de datos, hay dos enfoques: migración por lotes usando AWS Glue, y migración gradual usando escrituras duales (escribiendo en ambas bases de datos simultáneamente). Al usar Glue, configure un trabajo ETL que lea datos de Cassandra y los escriba en Keyspaces. Para migraciones de conjuntos de datos grandes, es eficiente asegurar suficiente capacidad de escritura en modo aprovisionado de Keyspaces y cambiar a modo bajo demanda después de completar la migración. Los cambios del lado de la aplicación son mínimos. Los principales cambios son actualizar el endpoint de conexión y configurar TLS (que es obligatorio para Keyspaces). Durante las pruebas de rendimiento de migración, es importante verificar teniendo en cuenta cómo maneja Keyspaces los niveles de consistencia. Las escrituras siempre se ejecutan con LOCAL_QUORUM por durabilidad, y para las lecturas se elige entre tres niveles: ONE, LOCAL_ONE y LOCAL_QUORUM (el valor predeterminado depende de la configuración del controlador, por lo que es más seguro especificarlo explícitamente). Cada lectura de 4 KB consume 0.5 unidades con ONE / LOCAL_ONE y 1 unidad con LOCAL_QUORUM, por lo que conviene revisar antes de migrar el equilibrio entre los requisitos de consistencia, la latencia y el costo.
Elección entre Keyspaces y DynamoDB
Al seleccionar una base de datos distribuida en AWS, tanto Keyspaces como DynamoDB son candidatos. Keyspaces es ideal como destino de migración para aplicaciones Cassandra existentes, permitiendo aprovechar directamente sus conocimientos y habilidades en CQL. Puede mantener patrones de modelado de datos específicos de Cassandra como claves de partición compuestas, columnas de agrupamiento para modelado de datos flexible, TTL (Time to Live) para expiración automática de datos y columnas estáticas para datos compartidos a nivel de partición. Keyspaces también admite la replicación multirregión: en una configuración activo-activo, cada región procesa lecturas y escrituras de forma independiente, y los conflictos se resuelven automáticamente con last writer wins. El retraso de replicación entre regiones suele ser inferior a 1 segundo, el RPO ante una falla regional es de unos pocos segundos y la conmutación por error solo requiere cambiar el enrutamiento con Route 53 (no se necesitan operaciones de promoción ni de conmutación por error). Sin embargo, entre las restricciones indicadas en la documentación oficial (a agosto de 2026) están las siguientes: TTL debe configurarse al crear la tabla multirregión y después no se puede habilitar, deshabilitar ni cambiar su valor; el cifrado en reposo solo admite claves propiedad de AWS y no claves administradas por el cliente; no se admiten la replicación síncrona ni la consistencia QUORUM; y AWS GovCloud (US) y las regiones de China quedan excluidas. Por otro lado, DynamoDB, como servicio nativo de AWS, proporciona integración perfecta con Lambda, AppSync, API Gateway y más. Sus fortalezas residen en la integración con el ecosistema AWS, incluyendo DynamoDB Streams para arquitecturas dirigidas por eventos, tablas globales y DAX (DynamoDB Accelerator) para caché a nivel de microsegundos. Para desarrollo nuevo por equipos sin experiencia en Cassandra, se recomienda DynamoDB; para migrar cargas de trabajo Cassandra existentes, Keyspaces es la mejor opción. Ambos servicios soportan autenticación IAM, endpoints VPC y cifrado, cumpliendo requisitos de seguridad de nivel empresarial.
Precios de Keyspaces
Los siguientes precios se basan en la tabla de precios oficial de AWS a agosto de 2026 e indican Norte de Virginia (us-east-1) y Tokio (ap-northeast-1). En modo bajo demanda, las lecturas cuestan $0.125 (Norte de Virginia) / $0.1425 (Tokio) por millón de unidades de solicitud de lectura, y las escrituras $0.625 (Norte de Virginia) / $0.715 (Tokio) por millón de unidades de solicitud de escritura. El modo aprovisionado se factura con tarifas por hora y no por mes: $0.00013/hora (Norte de Virginia) / $0.0001484/hora (Tokio) por unidad de capacidad de lectura (RCU) y $0.00065/hora (Norte de Virginia) / $0.000742/hora (Tokio) por unidad de capacidad de escritura (WCU). La tarifa de escritura es unas 5 veces la de lectura; en un mes de 730 horas en Norte de Virginia, una RCU equivale a unos $0.095 y una WCU a unos $0.475. El almacenamiento cuesta $0.25 (Norte de Virginia) / $0.285 (Tokio) por GB al mes, el almacenamiento de copias de seguridad para PITR $0.20 (Norte de Virginia) / $0.228 (Tokio) por GB al mes, la eliminación automática por TTL $0.275 (Norte de Virginia) / $0.315 (Tokio) por millón de elementos y la restauración desde una copia de seguridad $0.15 (Norte de Virginia) / $0.171 (Tokio) por GB. Tokio es entre un 10% y un 20% más caro que Norte de Virginia, por lo que, si los requisitos de latencia lo permiten, la elección de la región en sí supone una diferencia de costo. La estructura de precios es casi idéntica a DynamoDB, pero la ventaja son los menores costos de migración para cargas de trabajo Cassandra existentes ya que puede acceder a los datos mediante CQL.
Resumen - Elección de la base de datos compatible con Cassandra adecuada
Al elegir entre Keyspaces como destino de migración de Cassandra y DynamoDB como opción nativa de AWS según las características de su carga de trabajo y activos existentes, puede construir una estrategia óptima de base de datos distribuida. Si se requiere compatibilidad con CQL, Keyspaces es la elección correcta; si prioriza la flexibilidad serverless, DynamoDB es la mejor opción.
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.