Cassandra es una base de datos relacional NoSQL de alto rendimiento que utilizan algunas de las compañías más grandes, incluidas Netflix y Reddit. Aunque originalmente se diseñó para ejecutarse localmente, esta base de datos también se puede usar en servicios en la nube.
Las instancias de AWS EC2, en particular, son una opción de host que puede otorgar ventajas de mayor escalabilidad, confiabilidad, seguridad y menor costo.
En este artículo, veremos las diferencias entre Cassandra y la oferta similar de AWS, DynamoDB y cubriremos algunos consejos para garantizar que pueda maximizar los posibles beneficios si decide hacer la transición a la nube
Cassandra vs DynamoDB
Cassandra y AWS DynamoDB tienen esencialmente la misma funcionalidad, ya que ambos se basan en la misma premisa NoSQL . Puede ver un desglose adicional de las diferencias en la tabla a continuación, pero las diferencias clave son que DynamoDB es una base de datos totalmente administrada pero patentada y menos personalizable, mientras que Cassandra es de código abierto, tiene soporte completo de región activa activa y baja latencia pero requiere manejo manual.
| Cassandra | DynamoDB | |
| Clave primaria | Admite una gran cantidad de campos | Admite solo 2 campos El uso de más atributos requiere concatenación manual en un solo campo |
| Esquema | Datos está estructurado de acuerdo con un esquema predefinido | Solo la clave principal requiere un esquema Los datos de la tabla pueden tener atributos mixtos |
| Tiempo de vida (TTL) | Admite por columna que le permite expirar campos individuales de un elemento | Compatible solo con el elemento |
| Consistencia | Ofrece consistencia fuerte y eventual Se agregó la funcionalidad de poder especificar el número de nodos consultados con consistencia eventual |
Ofrece consistencia fuerte y eventual |
| Idioma | Utiliza el lenguaje de consulta Cassandra (CQL) | Utiliza el protocolo JSON |
| Utiliza el binario y permite solicitudes continuas simultáneas | Utiliza JSON / HTTP | |
| Lote | Soportes procesamiento por lotes con un Garantía de aprobación completa / falla total | Admite operaciones por lotes sin opción de aprobación total / falla total |
| Escalabilidad | Requiere replicación manual para escalar pero permite un control preciso | Escalas automáticas pero no ofrece control sobre réplicas |
para la operación
Si ha decidido mover su base de datos Cassandra a AWS, los siguientes consejos pueden ayudarlo a asegurarse de obtener el mayor beneficio.
Cassandra: Implementación
Uno de los beneficios de desplegar Cassandra en AWS es la capacidad de automatizar tareas de implementación, como describir y aprovisionar recursos de infraestructura, a través de CloudFormation. Al hacerlo, se recomienda usar una plantilla de CloudFormation para cada anillo de Cassandra que desee organizar y si está implementando en varias regiones, debe administrar sus pilas con CloudFormation StackSet.
En AWS, su implementación debe seguir una de estas tres arquitecturas:
- Región única con múltiples zonas de disponibilidad (AZ) : consiste en un anillo en una región con nodos distribuidos uniformemente en al menos tres AZ. Esta configuración es útil cuando se requiere que use una región para cumplir con los estándares reglamentarios, pero crea un riesgo de falla regional.
- Activo-activo, multi-región : consiste en múltiples anillos en múltiples regiones. Esta configuración funciona mejor si los anillos son idénticos; elimina el riesgo de pérdida de datos durante la conmutación por error y está altamente disponible, pero tiene un costo mayor debido a la duplicación.
- Active-standby, multiregión : funciona igual que active-active excepto que un anillo sirve solo como recuperación de desastres. Esto es útil si necesita un objetivo de punto de recuperación (RPO) o un objetivo de tiempo de recuperación (RTO) bajo, pero tiene una desventaja adicional de alta latencia para escrituras de consistencia eventual.
Almacenamiento
Al ejecutar Cassandra en AWS, tiene la opción de dos opciones de almacenamiento diferentes: almacenamiento efímero, que es bueno para implementaciones de propósito general, o volúmenes EBS que son más flexibles y buenos para clústeres con mucha lectura. El tipo de instancia que use dependerá de este almacenamiento, pero independientemente de cuál elija, debe evitar el uso de instancias burstable (T2) ya que no pueden proporcionarle un rendimiento aceptable.
Efímero
Con el almacenamiento efímero, obtendrá el mejor rendimiento de las instancias optimizadas de almacenamiento (I3) con las que puede obtener hasta 3,3 millones de operaciones de E / S por segundo (IOPS). Esta opción de almacenamiento funciona mejor para clústeres más grandes, ya que a medida que un clúster se hace más pequeño, la falla del nodo afectará el rendimiento de manera más significativa. Si elige esta opción, es importante recordar que el almacenamiento efímero solo existe mientras una instancia esté activa. Si un nodo falla, los datos almacenados desaparecen, por lo que es importante hacer una copia de seguridad de sus datos con frecuencia, lo que requerirá una solución personalizada con rsync o integración de terceros.
EBS
Con el almacenamiento de volumen de EBS, obtendrá el mejor rendimiento de las instancias de cómputo optimizado (C5), que pueden proporcionar hasta 80K IOPS por instancia si una configuración RAID es usado. Esta opción de almacenamiento funciona mejor para clústeres pequeños con grandes cantidades de datos debido a su mayor resistencia en comparación con el almacenamiento efímero. Con los volúmenes EBS, los datos se respaldan fácilmente a través de instantáneas que se pueden usar para generar rápidamente nuevas instancias en caso de falla, ya que eliminan la necesidad de volver a copiar todos los cambios excepto los más recientes.
Mantenimiento
Para las implementaciones de Cassandra, sus acciones de mantenimiento deben estar programadas con AWS SDK, que puede usarse en combinación con Lambda o activarse manualmente.
Cuando llegue el momento de escalar horizontalmente su base de datos, asegúrese de mantener un factor consistente para que sus datos permanezcan distribuidos de manera uniforme, por ejemplo, al escalar el doble de sus instancias y reducirlas a la mitad al reducir la escala.
Para modificar sus instancias, como cuando se actualizan volúmenes o se aplican parches, debe hacer uso de actualizaciones sucesivas, intercambiando una instancia a la vez. Esto ayudará a eliminar el tiempo de inactividad y facilitará la reparación de su anillo si una actualización falla. Al hacer esto, puede beneficiarse del uso de una interfaz de red elástica secundaria que le permite asignar la dirección IP de su instancia reemplazada a la nueva y eliminar la necesidad de reequilibrar su anillo.
Para administrar la seguridad de su base de datos, utilice las funciones de cifrado integradas de AWS. Tanto el cifrado en reposo como el en tránsito están disponibles, pero tenga en cuenta que el cifrado en reposo dependerá de su tipo de almacenamiento. Para EBS, puede encriptar el volumen, mientras que, para efímero, tendrá que usar un sistema de archivos encriptados o una solución de terceros.
Cassandra: Conclusión
Cassandra es una herramienta poderosa que continúa viendo uso y soporte a pesar de su antigüedad, y una a la que podrías ser leal. Si ya está utilizando los servicios Cassandra y AWS, tiene sentido que considere unir los dos. Con suerte, este artículo le dio una mejor idea de cómo se ve dicha integración y le enseñó algunos consejos sobre cómo integrarse de manera eficiente y sin problemas, asegurando que obtenga los beneficios de los servicios de Cassandra y AWS con la máxima flexibilidad.