Compartir a través de

Adaptación a Azure Cosmos DB for Apache Cassandra desde Apache Cassandra

  • Artículo

SE APLICA A: Cassandra

Azure Cosmos DB for Apache Cassandra proporciona compatibilidad de protocolo de conexión con los SDK y herramientas existentes de Cassandra. Puede ejecutar aplicaciones diseñadas para conectarse a Apache Cassandra mediante la API para Cassandra con cambios mínimos.

Cuando use la API para Cassandra, es importante tener en cuenta las diferencias entre Apache Cassandra y Azure Cosmos DB. Si está familiarizado con Apache Cassandra nativo, este artículo puede ayudarle a empezar a usar Azure Cosmos DB for Apache Cassandra.

Compatibilidad de características

La API para Cassandra admite una gran variedad de características de Apache Cassandra. Algunas características no son compatibles o tienen limitaciones. Antes de migrar, asegúrese de que las características de Azure Cosmos DB for Apache Cassandra que necesita son compatibles.

Replicación

A la hora de planear la replicación, es importante tener en cuenta la migración y la coherencia.

Aunque puede comunicarse con la API para Cassandra mediante el protocolo de conexión Cassandra Query Language (CQL) Binary Protocol v4, Azure Cosmos DB implementa su propio protocolo de replicación interna. No puede usar el protocolo Gossip de Cassandra para la migración o replicación en directo. Para más información, consulte Migración en directo desde Apache Cassandra a la API para Cassandra mediante escrituras dobles.

Para más información sobre la migración sin conexión, consulte Migración de datos de Cassandra a una cuenta de Azure Cosmos DB for Apache Cassandra mediante Azure Databricks.

Aunque los métodos de coherencia de la replicación de Apache Cassandra y Azure Cosmos DB son parecidos, es importante conocer en qué se diferencian. Un documento de asignación compara los enfoques de Apache Cassandra y Azure Cosmos DB con respecto a la coherencia de la replicación. No obstante, le recomendamos que revise específicamente la configuración de la coherencia de Azure Cosmos DB o vea una breve guía en vídeo para comprender la configuración de la coherencia en la plataforma de Azure Cosmos DB.

Si usa la API para Cassandra, no es necesario realizar cambios sustanciales de código en las aplicaciones existentes que ejecuten Apache Cassandra. Se recomiendan algunos enfoques y opciones de configuración de la API para Cassandra en Azure Cosmos DB. Vea la entrada de blog Recomendaciones de la API para Cassandra para Java.

Ejemplos de código

La API para Cassandra está diseñada para funcionar con el código de la aplicación existente. Pero si detecta algún error relacionado con la conectividad, use los ejemplos de inicio rápido como punto de partida para descubrir los cambios de configuración menores que puede que tenga que realizar en el código existente.

Además, también tenemos ejemplos más detallados para los controladores Java v3 y Java v4. Estos ejemplos de código implementan extensiones personalizadas, que a su vez implementan las configuraciones de cliente recomendadas.

También puede usar ejemplos de Spring Boot (controlador v3) y Spring Boot (controlador v4) de Java.

Storage

La API para Cassandra cuenta con el respaldo de Azure Cosmos DB, que es un motor de base de datos NoSQL orientado a documentos. Azure Cosmos DB mantiene metadatos, lo que puede provocar un cambio en la cantidad de almacenamiento físico necesario para una carga de trabajo específica.

La diferencia en los requisitos de almacenamiento entre Apache Cassandra nativo y Azure Cosmos DB es más notable en tamaños de fila pequeños. En algunos casos, la diferencia puede estar compensada ya que Azure Cosmos DB no implementa la compactación ni los marcadores de exclusión. Este factor depende considerablemente de la carga de trabajo. Si no está seguro de los requisitos de almacenamiento, le recomendamos que cree primero una prueba de concepto.

Implementaciones en varias regiones

De forma predeterminada, Apache Cassandra nativo es un sistema de arquitectura multimaestro. Apache Cassandra no dispone de una opción para un solo maestro con replicación en varias regiones solo para lecturas. El concepto de conmutación por error en el nivel de aplicación en otra región para escrituras es redundante en Apache Cassandra. Todos los nodos son independientes y no hay un único punto de error. Sin embargo, Azure Cosmos DB proporciona la capacidad integrada para configurar regiones de arquitectura multimaestro o de un único maestro para las escrituras.

Una ventaja de tener una región con un único maestro para las escrituras es evitar escenarios de conflicto entre regiones. Le ofrece la opción de mantener una coherencia sólida en varias regiones mientras mantiene un nivel de alta disponibilidad.

Nota:

Una coherencia sólida entre regiones y un objetivo de punto de recuperación (RPO) de cero no es posible para Apache Cassandra nativo ya que todos los nodos pueden atender operaciones de escritura. Puede configurar Cosmos DB para lograr una coherencia sólida entre regiones mediante una configuración de región de escritura única. Sin embargo, al igual que con Apache Cassandra nativo, no puede establecer una cuenta de Azure Cosmos DB configurada con varias regiones de escritura si desea lograr una coherencia sólida. Un sistema distribuido no puede proporcionar un RPO de cero ni un objetivo de tiempo de recuperación (RTO) de cero.

Para más información, consulte Directiva de equilibrio de carga en el blog de recomendaciones de la API para Cassandra para Java. Vea también Escenarios de conmutación por error en el ejemplo de código oficial del controlador de Java v4 de Cassandra.

Unidades de solicitud

Una de las principales diferencias entre ejecutar un clúster de Apache Cassandra nativo y aprovisionar una cuenta de Azure Cosmos DB estriba en cómo se aprovisiona la capacidad de la base de datos. En las bases de datos tradicionales, la capacidad se expresa en términos de núcleos de CPU, RAM e IOPS. Azure Cosmos DB es una base de datos multiinquilino de plataforma como servicio. La capacidad se expresa mediante una única métrica normalizada denominada unidades de solicitud. Cada solicitud enviada a la base de datos tiene un costo de unidad de solicitud (costo de RU). Es posible generar perfiles de cada solicitud para determinar su costo.

La ventaja de usar unidades de solicitud como métrica está en que la capacidad de la base de datos se puede aprovisionar de forma determinista para conseguir un rendimiento y una eficiencia altamente predecibles. Después de generar un perfil del costo de cada solicitud, puede usar unidades de solicitud para asociar directamente el número de solicitudes enviadas a la base de datos con la capacidad que necesita aprovisionar. La dificultad de esta forma de aprovisionamiento de capacidad es que debe entender bien las características de rendimiento de la carga de trabajo.

Se recomienda encarecidamente generar perfiles de las solicitudes. Use esa información para ayudar a estimar el número de unidades de solicitud que va a ser necesario aprovisionar. Estos son algunos artículos que pueden ayudarle a hacer la estimación:

Modelos de aprovisionamiento de capacidad

En el aprovisionamiento tradicional de bases de datos, se aprovisiona una capacidad fija de antemano para administrar el rendimiento previsto. Azure Cosmos DB ofrece un modelo basado en capacidad llamado rendimiento aprovisionado. Como servicio multiinquilino, Azure Cosmos DB también ofrece modelos basados en el consumo en el modo de escalado automático y el modo sin servidor. La medida en que una carga de trabajo puede beneficiarse de cualquiera de estos modelos de aprovisionamiento basados en el consumo depende de la previsibilidad del rendimiento de la carga de trabajo.

Por lo general, las cargas de trabajo de estado estable con un rendimiento predecible se benefician más del rendimiento aprovisionado. Las cargas de trabajo que tienen períodos grandes de latencia se benefician más del modo sin servidor. Las cargas de trabajo que tienen un nivel continuo de rendimiento mínimo, pero con picos impredecibles, se benefician más del escalado automático. Le recomendamos que consulte los siguientes artículos para conocer el mejor modelo de capacidad para sus necesidades de rendimiento:

Creación de particiones

La creación de particiones en Azure Cosmos DB es similar a la creación de particiones en Apache Cassandra. Una de las principales diferencias es que Azure Cosmos DB está más optimizado para el escalado horizontal. En Azure Cosmos DB, se ponen límites en la cantidad de capacidad de rendimiento vertical que está disponible en cualquier partición física. El efecto de esta optimización es más notable cuando hay un sesgo de rendimiento significativo en un modelo de datos existente.

Tome medidas para asegurarse de que el diseño de la clave de partición dé lugar a una distribución relativamente uniforme de las solicitudes. Para más información sobre el funcionamiento de las particiones lógicas y físicas, y los límites de capacidad de rendimiento por partición, consulte Creación de particiones en Azure Cosmos DB for Apache Cassandra.

Escalado

En Apache Cassandra nativo, aumentar la capacidad y el escalado implica agregar nuevos nodos a un clúster y asegurarse de que estos se agreguen correctamente al anillo de Cassandra. En Azure Cosmos DB, agregar nodos es un proceso transparente y automático. El escalado es una función de cuántas unidades de solicitud se aprovisionan para su espacio de claves o tabla. El escalado en máquinas físicas se produce cuando el almacenamiento físico o el rendimiento requerido alcanzan los límites permitidos para una partición lógica o física. Para más información, consulte Creación de particiones en Azure Cosmos DB for Apache Cassandra.

Limitación de frecuencia

Una dificultad de las unidades de solicitud de aprovisionamiento, especialmente si usa el rendimiento aprovisionado, es la limitación de frecuencia. Azure Cosmos DB devuelve errores de frecuencia limitada si los clientes consumen más recursos que la cantidad que se ha aprovisionado. La API de Cassandra de Azure Cosmos DB traslada estas excepciones como errores sobrecargados en el protocolo nativo de Cassandra. Para más información sobre cómo evitar la limitación de frecuencia en la aplicación, consulte Prevención de errores de limitación de velocidad de operaciones de Azure Cosmos DB for Apache Cassandra.

Conector de Apache Spark

Muchos usuarios de Apache Cassandra usan el conector Apache Spark Cassandra para consultar sus datos para las necesidades analíticas y de movimiento de datos. Puede conectarse a la API para Cassandra del mismo modo y con el mismo conector. Antes de conectarse a la API para Cassandra, consulte Conexión con Azure Cosmos DB for Apache Cassandra desde Spark. En particular, consulte la sección Optimización de la configuración de rendimiento del conector de Spark.

Solución de problemas comunes

Para obtener soluciones a problemas comunes, consulte Solución de problemas habituales de Azure Cosmos DB for Apache Cassandra.

Pasos siguientes