Seleccione sus preferencias de cookies

Usamos cookies esenciales y herramientas similares que son necesarias para proporcionar nuestro sitio y nuestros servicios. Usamos cookies de rendimiento para recopilar estadísticas anónimas para que podamos entender cómo los clientes usan nuestro sitio y hacer mejoras. Las cookies esenciales no se pueden desactivar, pero puede hacer clic en “Personalizar” o “Rechazar” para rechazar las cookies de rendimiento.

Si está de acuerdo, AWS y los terceros aprobados también utilizarán cookies para proporcionar características útiles del sitio, recordar sus preferencias y mostrar contenido relevante, incluida publicidad relevante. Para aceptar o rechazar todas las cookies no esenciales, haga clic en “Aceptar” o “Rechazar”. Para elegir opciones más detalladas, haga clic en “Personalizar”.

Creación de un plan de migración para migrar de Apache Cassandra a Amazon Keyspaces

Modo de enfoque

En esta página

Creación de un plan de migración para migrar de Apache Cassandra a Amazon Keyspaces - Amazon Keyspaces (para Apache Cassandra)

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Para que la migración de Apache Cassandra a Amazon Keyspaces se realice correctamente, recomendamos revisar los conceptos y las prácticas recomendadas de migración aplicables, así como comparar las opciones disponibles.

En este tema se describe cómo funciona el proceso de migración y se presentan varios conceptos clave y las herramientas y técnicas que tiene a su disposición. Puede evaluar las diferentes estrategias de migración para seleccionar la que mejor se adapte a sus necesidades.

Compatibilidad funcional

Analice detenidamente las diferencias funcionales entre Apache Cassandra y Amazon Keyspaces antes de la migración. Amazon Keyspaces admite todas las operaciones del plano de datos de Cassandra de uso habitual, como la creación de espacios de claves y tablas, y la lectura y escritura de datos.

Sin embargo, hay algunas Cassandra APIs que Amazon Keyspaces no admite. Para obtener más información acerca de lo compatibleAPIs, consulte. CassandraAPIs, operaciones, funciones y tipos de datos compatibles Para obtener información general sobre todas las diferencias funcionales entre Amazon Keyspaces y Apache Cassandra, consulte Diferencias funcionales: Amazon Keyspaces vs. Apache Cassandra.

Para comparar el Cassandra APIs y el esquema que está utilizando con las funciones compatibles en Amazon Keyspaces, puede ejecutar un script de compatibilidad disponible en el kit de herramientas de Amazon Keyspaces. GitHub

Uso del script de compatibilidad
  1. Descargue el script de Python de compatibilidad GitHuby muévalo a una ubicación que tenga acceso a su clúster de Apache Cassandra existente.

  2. El script de compatibilidad usa parámetros similares a CQLSH. Para --host y --port, introduzca la dirección IP y el puerto que utilice para conectarse y ejecutar consultas a uno de los nodos de Cassandra del clúster.

    Si su clúster de Cassandra usa autenticación, también debe proporcionar -username y -password. Para utilizar el script de compatibilidad, puede ejecutar el siguiente comando.

    python toolkit-compat-tool.py --host hostname or IP -u "username" -p "password" --port native transport port

Estimación de precios de Amazon Keyspaces

En esta sección se proporciona información general de la información que debe recopilar de las tablas de Apache Cassandra para calcular el costo estimado de Amazon Keyspaces. Cada una de sus tablas requiere diferentes tipos de datos, debe admitir CQL consultas diferentes y mantiene un tráfico de lectura/escritura distintivo.

Plantearse sus requisitos en función de las tablas se ajusta a los modos de aislamiento de recursos de nivel de tabla y de capacidad de rendimiento de lectura/escritura de Amazon Keyspaces. Con Amazon Keyspaces, puede definir la capacidad de lectura/escritura y las políticas de escalado automático para las tablas de forma independiente.

Comprender los requisitos de las tablas le ayuda a priorizarlas para la migración según la funcionalidad, el costo y el esfuerzo de migración.

Recopile las siguientes métricas de la tabla de Cassandra antes de una migración. Esta información ayuda a estimar el costo de la carga de trabajo en Amazon Keyspaces.

  • Nombre de la tabla: el nombre completo del espacio de claves y de la tabla.

  • Descripción: descripción de la tabla, por ejemplo, cómo se usa o qué tipo de datos se almacenan en ella.

  • Promedio de lecturas por segundo: el número medio de lecturas en las coordenadas para la tabla durante un intervalo de tiempo amplio.

  • Promedio de escrituras por segundo: el número medio de escrituras en las coordenadas para la tabla durante un intervalo de tiempo amplio.

  • Promedio de tamaño de fila en bytes: tamaño medio de fila en bytes.

  • Tamaño de almacenamiento en GBs: el tamaño de almacenamiento sin procesar de una tabla.

  • Desglose de coherencia de lectura: el porcentaje de lecturas que utilizan coherencia posterior (LOCAL_ONE o ONE) frente a las que utilizan coherencia sólida (LOCAL_QUORUM).

En esta tabla se muestra un ejemplo de la información relativa a las tablas que debe reunir al planificar una migración.

Nombre de la tabla Descripción Promedio de lecturas por segundo Promedio de escrituras por segundo Promedio de tamaño de fila en bytes Tamaño de almacenamiento en GBs Desglose de coherencia de lectura

mykeyspace.mytable

Se usa para almacenar el historial del carrito de la compra

10 000

5 000

2.200

2,000

100% LOCAL_ONE

mykeyspace.mytable 2

Se utiliza para almacenar la información de perfil más reciente

20 000

1 000

850

1 000

25 % LOCAL_QUORUM 75 % LOCAL_ONE

Recopilación de las métricas de las tablas

En esta sección, se proporcionan instrucciones paso a paso sobre cómo recopilar las métricas de tabla necesarias del clúster de Cassandra existente. Estas métricas incluyen el tamaño de la fila, el tamaño de la tabla y las solicitudes de lectura/escritura por segundo ()RPS. Le permiten evaluar los requisitos de capacidad de rendimiento para una tabla de Amazon Keyspaces y estimar los precios.

Recopilación de las métricas de la tabla de origen de Cassandra
  1. Determinación del tamaño de fila

    El tamaño de fila es importante para determinar el uso de la capacidad de lectura y escritura en Amazon Keyspaces. En el siguiente diagrama se muestra la distribución de datos típica en un rango de tokens de Cassandra.

    Un diagrama en el que se muestra la distribución de datos típica en un rango de tokens de Cassandra con el particionador murmur3.

    Puede utilizar un script de muestreo del tamaño de fila disponible GitHubpara recopilar las métricas del tamaño de las filas de cada tabla de su clúster de Cassandra.

    El script exporta los datos de la tabla desde Apache Cassandra utilizando cqlsh y awk para calcular la desviación mínima, máxima, media y estándar del tamaño de la fila sobre un conjunto configurable de datos de tabla de muestra. El muestreador de tamaño de fila pasa los argumentos a cqlsh, por lo que se pueden usar los mismos parámetros para conectarse y leer desde el clúster de Cassandra.

    La siguiente instrucción es un ejemplo de ello.

    ./row-size-sampler.sh 10.22.33.44 9142 \\ -u "username" -p "password" --ssl

    Para obtener más información sobre cómo se calcula el tamaño de las filas en Amazon Keyspaces, consulte Estimación del tamaño de las filas en Amazon Keyspaces.

  2. Determinación del tamaño de las tablas

    Con Amazon Keyspaces, no es necesario aprovisionar el almacenamiento por adelantado. Amazon Keyspaces supervisa continuamente el tamaño facturable de sus tablas para determinar sus cargos por almacenamiento. El almacenamiento se factura por GB al mes. El tamaño de tabla de Amazon Keyspaces se basa en el tamaño sin procesar (sin comprimir) de una sola réplica.

    Para supervisar el tamaño de tabla en Amazon Keyspaces, puede utilizar la métrica BillableTableSizeInBytes, que se muestra para cada tabla en la AWS Management Console.

    Para calcular el tamaño facturable de la tabla de Amazon Keyspaces, puede usar uno de estos dos métodos:

    • Utilizar el tamaño de fila promedio y multiplicar por el número de filas.

      Puede estimar el tamaño de la tabla de Amazon Keyspaces multiplicando el tamaño medio de las filas por el número de filas de la tabla de origen de Cassandra. Utilizar el script de muestra de tamaño de fila de la sección anterior para registrar el tamaño medio de las filas. Para registrar el recuento de filas, puede utilizar herramientas como dsbulk count para determinar el número total de filas de la tabla de origen.

    • Utilizar nodetool para recopilar los metadatos de la tabla.

      Nodetool es una herramienta administrativa incluida en la distribución de Apache Cassandra que proporciona información sobre el estado del proceso de Cassandra y devuelve los metadatos de la tabla. Puede utilizar nodetool para muestrear metadatos sobre el tamaño de la tabla y, con ello, extrapolar el tamaño de la tabla en Amazon Keyspaces.

      El comando que se debe utilizar es nodetool tablestats. Tablestats devuelve el tamaño y la relación de compresión de la tabla. El tamaño de la tabla se guarda como el tablelivespace de la tabla y se puede dividir por la compression ratio. A continuación, multiplique este valor de tamaño por la cantidad de nodos. Por último, divida por el factor de replicación (normalmente es tres).

      Esta es la fórmula completa del cálculo que puede utilizar para evaluar el tamaño de la tabla.

      ((tablelivespace / compression ratio) * (total number of nodes))/ (replication factor)

      Supongamos que su clúster de Cassandra tiene 12 nodos. Al ejecutar el comando nodetool tablestats, se obtiene un tablelivespace de 200 GB y una compression ratio de 0,5. El espacio de claves tiene un factor de replicación de tres.

      Este es el aspecto que tiene el cálculo para este ejemplo.

      (200 GB / 0.5) * (12 nodes)/ (replication factor of 3) = 4,800 GB / 3 = 1,600 GB is the table size estimate for Amazon Keyspaces
  3. Registro del número de lecturas y escrituras

    Para determinar los requisitos de capacidad y escalado de las tablas de Amazon Keyspaces, registre la tasa de solicitudes de lectura y escritura de las tablas de Cassandra antes de la migración.

    Amazon Keyspaces se ejecuta sin servidor y solo se paga por lo que se usa. En general, el precio del rendimiento de lectura/escritura en Amazon Keyspaces depende del número y el tamaño de las solicitudes.

    Existen dos modos de capacidad en Amazon Keyspaces:

    • Bajo demanda: se trata de una opción de facturación flexible que permite atender miles de solicitudes por segundo sin tener que planificar la capacidad. Ofrece pay-per-request precios para las solicitudes de lectura y escritura, de modo que solo pagues por lo que utilices.

    • Aprovisionado: si elige el modo de capacidad de rendimiento aprovisionado, especifica el número de lecturas y escrituras por segundo que se requieren para su aplicación. Esto le ayuda a gestionar el uso de Amazon Keyspaces para que se mantenga igual o inferior a una tasa de solicitudes definida a fin de mantener la previsibilidad.

      El modo aprovisionado ofrece escalado automático para ajustar automáticamente la tasa aprovisionada para escalarla automática o verticalmente con el fin de mejorar la eficiencia operativa. Para obtener más información sobre la administración de recursos sin servidor, consulte Administración de recursos sin servidor en Amazon Keyspaces (para Apache Cassandra).

    Como la capacidad de rendimiento de lectura y escritura se aprovisiona por separado en Amazon Keyspaces, debe medir la tasa de solicitudes de lectura y escritura en sus tablas existentes de forma independiente.

    Para recopilar las métricas de uso más precisas de su clúster de Cassandra actual, registre el promedio de solicitudes por segundo (RPS) de las operaciones de lectura y escritura a nivel de coordinador durante un período prolongado para obtener una tabla que se agregue a todos los nodos de un solo centro de datos.

    Al capturar el promedio RPS durante un período de al menos varias semanas, se capturan los picos y valles de los patrones de tráfico, como se muestra en el siguiente diagrama.

    Un diagrama que muestra la tasa media de solicitudes por segundo y día durante un período de dos semanas.

    Tienes dos opciones para determinar la tasa de solicitudes de lectura y escritura de una tabla de Cassandra.

    • Utilizar la supervisión de Cassandra existente

      Puede usar las métricas que se muestran en la siguiente tabla para observar las solicitudes de lectura y escritura. Tenga en cuenta que los nombres de las métricas pueden cambiar en función de la herramienta de supervisión que utilice.

      Dimensión Métrica de Cassandra JMX

      Escrituras

      org.apache.cassandra.metrics:type=ClientRequest, scope=Write,name=Latency#Count

      Lecturas

      org.apache.cassandra.metrics:type=ClientRequest, scope=Read,name=Latency#Count

    • Utilizar nodetool

      Utilice nodetool tablestats y nodetool info para registrar el promedio de operaciones de lectura y escritura de la tabla. tablestats devuelve el recuento total de lecturas y escrituras desde el momento en que se inició el nodo. nodetool info proporciona el tiempo de actividad de un nodo en segundos.

      Para obtener el promedio de lecturas y escrituras por segundo, divida el recuento de lectura y escritura por el tiempo de actividad del nodo en segundos. A continuación, para las lecturas, se divide por el nivel de consistencia, y para las escrituras, se divide por el factor de replicación. Estos cálculos se expresan en las siguientes fórmulas.

      Fórmula para el promedio de lecturas por segundo:

      ((number of reads * number of nodes in cluster) / read consistency quorum (2)) / uptime

      Fórmula para el promedio de escrituras por segundo:

      ((number of writes * number of nodes in cluster) / replication factor of 3) / uptime

      Supongamos que tenemos un clúster de 12 nodos que ha estado activo durante 4 semanas. nodetool info devuelve 2 419 200 segundos de tiempo de actividad y nodetool tablestats devuelve 1000 millones de escrituras y 2000 millones de lecturas. Este ejemplo daría como resultado el siguiente cálculo.

      ((2 billion reads * 12 in cluster) / read consistency quorum (2)) / 2,419,200 seconds = 12 billion reads / 2,419,200 seconds = 4,960 read request per second ((1 billion writes * 12 in cluster) / replication factor of 3) / 2,419,200 seconds = 4 billion writes / 2,419,200 seconds = 1,653 write request per second
  4. Determinación del uso de la capacidad de la tabla

    Para estimar el uso promedio de la capacidad, comience con el promedio de las tasas de solicitud y el promedio del tamaño de fila de la tabla de origen de Cassandra.

    Amazon Keyspaces utiliza unidades de capacidad de lectura (RCUs) y unidades de capacidad de escritura (WCUs) para medir la capacidad de rendimiento aprovisionada para lecturas y escrituras en tablas. Para esta estimación, utilizamos estas unidades para calcular las necesidades de capacidad de lectura y escritura de la nueva tabla de Amazon Keyspaces tras la migración.

    Más adelante en este tema analizaremos cómo afecta a la facturación la elección entre el modo de capacidad aprovisionada y el modo de capacidad bajo demanda. Sin embargo, para estimar el uso de la capacidad en este ejemplo, suponemos que la tabla está en modo aprovisionado.

    • Lecturas: una RCU representa una solicitud de LOCAL_QUORUM lectura o dos solicitudes de LOCAL_ONE lectura para una fila de hasta 4 KB de tamaño. Si necesita leer una fila de más de 4 KB, la operación de lectura utiliza másRCUs. El número total de elementos RCUs necesarios depende del tamaño de la fila y de si desea mantener la coherencia LOCAL_QUORUM o la coherencia de LOCAL_ONE lectura.

      Por ejemplo, para leer una fila de 8 KB se necesitan 2 RCUs unidades con coherencia de LOCAL_QUORUM lectura y 1 RCU si se elige la coherencia de LOCAL_ONE lectura.

    • Escrituras: una WCU representa una escritura para una fila de hasta 1 KB de tamaño. Todas las escrituras se escriben de forma LOCAL_QUORUM coherente y no se aplica ningún cargo adicional por el uso de transacciones ligeras (LWTs).

      La cantidad total WCUs requerida depende del tamaño de la fila. Si necesita escribir una fila de más de 1 KB, la operación de escritura utiliza másWCUs. Por ejemplo, si el tamaño de la fila es de 2 KB, necesitará 2 WCUs para realizar una solicitud de escritura.

    Se puede usar la siguiente fórmula para estimar el RCUs y requeridoWCUs.

    • La capacidad de lectura se RCUs puede determinar multiplicando las lecturas por segundo por el número de filas leídas por lectura, multiplicado por el tamaño medio de fila dividido entre 4 KB y redondeado al número entero más cercano.

    • La capacidad de escritura se WCUs puede determinar multiplicando el número de solicitudes por el tamaño medio de fila dividido por 1 KB y redondeado al número entero más cercano.

    Esto se expresa en las siguientes fórmulas.

    Read requests per second * ROUNDUP((Average Row Size)/4096 per unit) = RCUs per second Write requests per second * ROUNDUP(Average Row Size/1024 per unit) = WCUs per second

    Por ejemplo, si realiza 4.960 solicitudes de lectura con un tamaño de fila de 2,5 KB en su tabla de Cassandra, necesitará 4.960 en RCUs Amazon Keyspaces. Si actualmente realiza 1 653 solicitudes de escritura por segundo con un tamaño de fila de 2,5 KB en su tabla de Cassandra, necesitará 4 959 por WCUs segundo en Amazon Keyspaces.

    Este ejemplo se expresa en las siguientes fórmulas.

    4,960 read requests per second * ROUNDUP( 2.5KB /4KB bytes per unit) = 4,960 read requests per second * 1 RCU = 4,960 RCUs 1,653 write requests per second * ROUNDUP(2.5KB/1KB per unit) = 1,653 requests per second * 3 WCUs = 4,959 WCUs

    El uso de eventual consistency permite ahorrar hasta la mitad de la capacidad de rendimiento en cada solicitud de lectura. Cada lectura coherente posterior puede consumir hasta 8 KB. Puede calcular las lecturas coherentes posteriores multiplicando el cálculo anterior por 0,5, tal y como se muestra en la siguiente fórmula.

    4,960 read requests per second * ROUNDUP( 2.5KB /4KB per unit) * .5 = 2,480 read request per second * 1 RCU = 2,480 RCUs
  5. Cálculo del precio mensual estimado para Amazon Keyspaces

    Para calcular la facturación mensual de la tabla en función del rendimiento de la capacidad de lectura/escritura, puede calcular los precios del modo bajo demanda y del modo aprovisionado mediante distintas fórmulas y comparar las opciones de la tabla.

    Modo aprovisionado: el consumo de la capacidad de lectura y escritura se factura según una tarifa por hora basada en las unidades de capacidad por segundo. En primer lugar, divida esa tasa entre 0,7 para representar el objetivo de utilización predeterminado del escalado automático, que es del 70 %. Luego se debe multiplicar por 30 días naturales, 24 horas por día y los precios de las tarifas regionales.

    Este cálculo se resume en las siguientes fórmulas.

    (read capacity per second / .7) * 24 hours * 30 days * regional rate (write capacity per second / .7) * 24 hours * 30 days * regional rate

    Modo bajo demanda: la capacidad de lectura y escritura se factura según una tarifa por solicitud. En primer lugar, multiplique la tasa de solicitudes por 30 días naturales y 24 horas por día. A continuación, divida el resultado por un millón de unidades de solicitud. Por último, multiplique el resultado por la tarifa regional.

    Este cálculo se resume en las siguientes fórmulas.

    ((read capacity per second * 30 * 24 * 60 * 60) / 1 Million read request units) * regional rate ((write capacity per second * 30 * 24 * 60 * 60) / 1 Million write request units) * regional rate

Elección de una estrategia de migración

Puede elegir entre las siguientes estrategias de migración al migrar de Apache Cassandra a Amazon Keyspaces:

  • En línea: se trata de una migración en directo que utiliza escrituras duales para empezar a escribir nuevos datos en Amazon Keyspaces y en el clúster de Cassandra de forma simultánea. Este tipo de migración se recomienda para las aplicaciones que requieren cero tiempo de inactividad durante la migración y que requieren coherencia de lectura tras la escritura.

    Para obtener más información sobre cómo planificar e implementar una estrategia de migración en línea, consulte Migración online a Amazon Keyspaces: estrategias y prácticas recomendadas.

  • Sin conexión: esta técnica de migración implica copiar un conjunto de datos de Cassandra a Amazon Keyspaces durante un tiempo de inactividad. La migración sin conexión puede simplificar el proceso de migración, ya que no requiere cambios en la aplicación ni la resolución de conflictos entre los datos históricos y las nuevas escrituras.

    Para obtener más información sobre cómo planificar una migración sin conexión, consulte Proceso de migración sin conexión: de Apache Cassandra a Amazon Keyspaces.

  • Híbrida: esta técnica de migración permite replicar los cambios en Amazon Keyspaces prácticamente en tiempo real, pero sin coherencia de lectura tras la escritura.

    Para obtener más información sobre cómo planificar una migración híbrida, consulte Uso de una solución de migración híbrida: de Apache Cassandra a Amazon Keyspaces.

Tras revisar las técnicas de migración y las prácticas recomendadas que se describen en este tema, puede colocar las opciones disponibles en un árbol de decisiones para diseñar una estrategia de migración en función de sus requisitos y de los recursos disponibles.

PrivacidadTérminos del sitioPreferencias de cookies
© 2025, Amazon Web Services, Inc o sus afiliados. Todos los derechos reservados.