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.
# Migración a Amazon Keyspaces (para Apache Cassandra)
La migración a Amazon Keyspaces (para Apache Cassandra) presenta una serie de ventajas muy interesantes para las empresas y las organizaciones. Estas son algunas de las principales ventajas que convierten a Amazon Keyspaces en una opción atractiva para la migración.
+ **Escalabilidad**: Amazon Keyspaces se ha diseñado para administrar cargas de trabajo masivas y escalar sin complicaciones para adaptarse al crecimiento de los volúmenes de datos y del tráfico. Con la versión de Cassandra tradicional, el escalado no se realiza bajo demanda y requiere una planificación para futuros picos. Amazon Keyspaces le permite ampliar o reducir fácilmente sus tablas en función de la demanda, lo que garantiza que sus aplicaciones puedan administrar picos repentinos de tráfico sin que afecte al rendimiento.
+ **Rendimiento**: Amazon Keyspaces ofrece acceso a datos de baja latencia, lo que permite a las aplicaciones recuperar y procesar datos con una velocidad excepcional. Su arquitectura distribuida garantiza que las operaciones de lectura y escritura se distribuyan en varios nodos, lo que ofrece tiempos de respuesta uniformes en milisegundos de un solo dígito, incluso con altas tasas de solicitudes.
+ **Totalmente administrado**: Amazon Keyspaces es un servicio totalmente administrado que ofrece AWS. Esto significa que AWS gestiona los aspectos operativos de la administración de bases de datos, incluidos el aprovisionamiento, la configuración, los parches, las copias de seguridad y el escalado. Esto le permite centrarse más en el desarrollo de sus aplicaciones y menos en las tareas de administración de bases de datos.
+ **Arquitectura sin servidor**: Amazon Keyspaces es un servicio sin servidor. Solo paga por la capacidad consumida, sin necesidad de aprovisionar la capacidad por adelantado. No tendrá que administrar servidores ni seleccionar instancias. Este pay-per-request modelo ofrece rentabilidad y una sobrecarga operativa mínima, ya que solo paga por los recursos que consume sin necesidad de aprovisionar ni supervisar la capacidad.
+ **Flexibilidad NoSQL con esquemas**: Amazon Keyspaces sigue un modelo de datos NoSQL, lo que proporciona flexibilidad en el diseño de esquemas. Amazon Keyspaces permite almacenar datos estructurados, semiestructurados y sin estructurar, lo que los hace adecuados para administrar tipos de datos diversos y en constante evolución. Además, Amazon Keyspaces realiza la validación del esquema durante la escritura, lo que permite una evolución centralizada del modelo de datos. Esta flexibilidad permite ciclos de desarrollo más rápidos y una adaptación más sencilla a los requisitos empresariales en constante cambio.
+ **Alta disponibilidad y durabilidad**: Amazon Keyspaces replica los datos en varias [zonas de disponibilidad](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) dentro de una Región de AWS, lo que garantiza una alta disponibilidad y durabilidad de los datos. Además, gestiona automáticamente la replicación, la conmutación por error y la recuperación, lo que minimiza el riesgo de pérdida de datos o interrupciones en el servicio. Amazon Keyspaces ofrece un SLA de disponibilidad de hasta el 99,999 %. Para obtener aún más resiliencia y lecturas locales de baja latencia, Amazon Keyspaces ofrece [replicación multirregional](multiRegion-replication.md).
+ **Seguridad y conformidad**: Amazon Keyspaces se integra con AWS Identity and Access Management para controlar el acceso de forma precisa. Proporciona cifrado en reposo y en tránsito, lo que ayuda a garantizar la seguridad de sus datos. Auditores externos han evaluado Amazon Keyspaces en términos de seguridad y conformidad con programas específicos, como HIPAA, PCI DSS y SOC, lo que le permite cumplir los requisitos normativos. Para obtener más información, consulte [Validación de conformidad para Amazon Keyspaces (para Apache Cassandra)](Keyspaces-compliance.md).
+ **Integración con el AWS ecosistema**: como parte del AWS ecosistema, Amazon Keyspaces se integra perfectamente con otros Servicios de AWS, por ejemplo CloudWatch, AWS CloudFormation Amazon y. AWS CloudTrail Esta integración le permite crear arquitecturas sin servidor, aprovechar la infraestructura como código y crear aplicaciones basadas en datos en tiempo real. Para obtener más información, consulte [Monitoreo de Amazon Keyspaces (para Apache Cassandra)](monitoring-overview.md).
**Topics**
+ [Creación de un plan de migración para migrar de Apache Cassandra a Amazon Keyspaces](migrating-cassandra.md)
+ [Selección de la herramienta adecuada para cargar o migrar datos por lotes a Amazon Keyspaces](migrating-tools.md)
# Creación de un plan de migración para migrar de Apache Cassandra a Amazon Keyspaces
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.
**Topics**
+ [Compatibilidad funcional](#migrating-cassandra-compatibility)
+ [Estimación de precios de Amazon Keyspaces](#migrating-cassandra-sizing)
+ [Elección de una estrategia de migración](#migrating-cassandra-strategy)
+ [Migración online a Amazon Keyspaces: estrategias y prácticas recomendadas](migrating-online.md)
+ [Proceso de migración sin conexión: de Apache Cassandra a Amazon Keyspaces](migrating-offline.md)
+ [Uso de una solución de migración híbrida: de Apache Cassandra a Amazon Keyspaces](migrating-hybrid.md)
## 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 compatible APIs, consulte. [Cassandra APIs, operaciones, funciones y tipos de datos compatibles](cassandra-apis.md) Para obtener información general sobre todas las diferencias funcionales entre Amazon Keyspaces y Apache Cassandra, consulte [Diferencias funcionales: Amazon Keyspaces vs. Apache Cassandra](functional-differences.md).
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](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/toolkit-compat-tool.py)
**Uso del script de compatibilidad**
1. Descargue el script de Python de compatibilidad [GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/toolkit-compat-tool.py)y muévalo a una ubicación que tenga acceso a su clúster de Apache Cassandra existente.
1. 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 diferentes consultas de CQL y mantiene un tráfico distintivo read/write .
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](ReadWriteCapacityMode.md) de Amazon Keyspaces. Con Amazon Keyspaces, puede definir la capacidad de lectura/escritura y las [políticas de escalado automático](autoscaling.md) 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 | Description (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 read/write las solicitudes 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.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/migration/migration-data-distribution.png)
Puede usar un script de muestreo de tamaño de fila disponible [GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/row-size-sampler.sh)para recopilar métricas de tamaño de fila para 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](calculating-row-size.md).
1. 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 Consola de administración de AWS.
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
```
1. 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 read/write rendimiento en Amazon Keyspaces depende del número y el tamaño de las solicitudes.
Existen dos modos de capacidad en Amazon Keyspaces:
+ [Bajo demanda](ReadWriteCapacityMode.OnDemand.md): 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 pague por lo que utilice.
+ [Aprovisionado](ReadWriteCapacityMode.Provisioned.md): 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](autoscaling.md) 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)](serverless_resource_management.md).
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 del clúster de Cassandra actual, registre el promedio de solicitudes por segundo (RPS) para las operaciones de lectura y escritura en el coordinador durante un período prolongado para obtener una tabla en la que aparezcan combinados todos los nodos de un solo centro de datos.
Al registrar el promedio de RPS durante un período de al menos varias semanas, quedan registrados 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.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/migration/migration-rps.png)
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.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/migrating-cassandra.html)
+ 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
```
1. 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 lectura `LOCAL_QUORUM` o dos solicitudes de lectura `LOCAL_ONE` para una fila de hasta 4 KB de tamaño. Si necesita leer una fila con un tamaño superior a 4 KB, la operación de lectura utiliza más. RCUs 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 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 utilizan `LOCAL_QUORUM` la coherencia 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ás WCUs. 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 requerido WCUs.
+ **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 realizas 1 653 solicitudes de escritura por segundo con un tamaño de fila de 2,5 KB en tu tabla de Cassandra, necesitas 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
```
1. 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 read/write capacidad, 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](migrating-online.md).
+ **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](migrating-offline.md).
+ **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](migrating-hybrid.md).
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.
# Migración online a Amazon Keyspaces: estrategias y prácticas recomendadas
Si necesita mantener la disponibilidad de las aplicaciones durante una migración de Apache Cassandra a Amazon Keyspaces, puede preparar una estrategia de migración en línea personalizada mediante la implementación de los componentes clave que se describen en este tema. Si sigue estas prácticas recomendadas para las migraciones en línea, puede garantizar que la disponibilidad y la read-after-write coherencia de las aplicaciones se mantengan durante todo el proceso de migración, lo que minimiza el impacto en los usuarios.
Al diseñar una estrategia de migración en línea de Apache Cassandra a Amazon Keyspaces, debe tener en cuenta los siguientes pasos clave.
1. **Escritura de nuevos datos**
+ Proxy de **escritura doble de ZDM para la migración de Amazon Keyspaces: utilice el proxy** de escritura doble de ZDM disponible [en](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) Github para realizar una migración sin tiempo de inactividad de Apache Cassandra a Amazon Keyspaces. El proxy ZDM realiza escrituras duales sin necesidad de refactorizar las aplicaciones existentes y realiza lecturas duales para validar las consultas.
+ Escrituras duales de aplicación: puede implementar escrituras duales en su aplicación utilizando las bibliotecas de clientes y los controladores existentes de Cassandra. Designe una base de datos como líder y la otra como seguidora. Los errores de escritura en la base de datos seguidora se registran en una [cola de mensajes fallidos (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) para su análisis.
+ Escrituras duales en el nivel de mensajería: también puede configurar su plataforma de mensajería existente para enviar escrituras tanto a Cassandra como a Amazon Keyspaces con un consumidor adicional. Con el tiempo, esto crea vistas coherentes en ambas bases de datos.
1. **Migración de datos históricos**
+ Copia de datos históricos: puede migrar datos históricos de Cassandra a Amazon Keyspaces con AWS Glue o mediante scripts de extracción, transformación y carga (ETL) personalizados. Administre la resolución de conflictos entre escrituras duales y cargas en lotes mediante técnicas como las transacciones simplificadas o las marcas de tiempo.
+ Uso Time-To-Live (TTL): para períodos de retención de datos más cortos, puede usar TTL tanto en Cassandra como en Amazon Keyspaces para evitar cargar datos históricos innecesarios. A medida que los datos antiguos caducan en Cassandra y se escriben datos nuevos mediante escrituras duales, Amazon Keyspaces acaba poniéndose al día.
1. **Validación de los datos**
+ Lecturas duales: implemente lecturas duales tanto desde las bases de datos de Cassandra (principal) como desde las de Amazon Keyspaces (secundaria) y compare los resultados de forma asíncrona. Las diferencias se registran o se envían a una DLQ.
+ Lecturas de ejemplo: utilice funciones λ para muestrear y comparar periódicamente los datos entre ambos sistemas y registrar cualquier discrepancia en una DLQ.
1. **Migración de la aplicación**
+ Estrategia azul-verde: modifique su aplicación para que trate Amazon Keyspaces como el almacén de datos principal y Cassandra como el almacén de datos secundario en un solo paso. Supervise el rendimiento y deshaga esas modificaciones en caso de que surjan problemas.
+ Implementación canario: primero implemente gradualmente la migración a un subconjunto de usuarios, aumentando gradualmente el tráfico a Amazon Keyspaces como principal hasta que se migre por completo.
1. **Retirada de Cassandra**
Una vez que su aplicación se haya migrado por completo a Amazon Keyspaces y se haya validado la coherencia de datos, puede planificar la retirada del clúster de Cassandra en función de las políticas de retención de datos.
Si planifica una estrategia de migración en línea con estos componentes, podrá realizar una transición fluida al servicio de Amazon Keyspaces totalmente administrado con un tiempo de inactividad o interrupción mínimos. En las siguientes secciones se aborda cada componente de manera detallada.
**Topics**
+ [Escritura de nuevos datos durante una migración en línea](migration-online-dw.md)
+ [Carga de datos históricos durante una migración en línea](migration-online-historical.md)
+ [Validación de la coherencia de datos durante una migración en línea](migration-online-validation.md)
+ [Migración de la aplicación durante una migración en línea](migration-online-app-migration.md)
+ [Retirada de Cassandra tras una migración en línea](migration-online-decommission.md)
# Escritura de nuevos datos durante una migración en línea
El primer paso de un plan de migración en línea consiste en garantizar que cualquier dato nuevo que escriba la aplicación se almacene en ambas bases de datos, en el clúster de Cassandra existente y en Amazon Keyspaces. El objetivo es proporcionar una visión coherente de los dos almacenes de datos. Para ello, aplique todas las escrituras nuevas a ambas bases de datos. Para implementar escrituras duales, considere una de las tres opciones siguientes.
+ Migración de **proxy de escritura doble de ZDM para Amazon Keyspaces**: con el proxy de ZDM para Amazon Keyspaces disponible [en](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) Github, puede migrar sus cargas de trabajo de Apache Cassandra a Amazon Keyspaces sin tiempo de inactividad de la aplicación. Esta solución mejorada implementa las AWS mejores prácticas y amplía las capacidades oficiales del proxy de ZDM.
+ Realice migraciones en línea entre Apache Cassandra y Amazon Keyspaces.
+ Escriba datos en las tablas de origen y destino simultáneamente sin refactorizar las aplicaciones.
+ Valide las consultas mediante operaciones de doble lectura.
La solución ofrece las siguientes mejoras para trabajar con AWS Amazon Keyspaces.
+ **Despliegue de contenedores**: utilice una imagen de Docker preconfigurada de Amazon Elastic Container Registry (Amazon ECR) para las implementaciones accesibles mediante VPC.
+ **Infraestructura como código**: impleméntela mediante AWS CloudFormation plantillas para una configuración automática. AWS Fargate
+ **Compatibilidad con Amazon Keyspaces**: acceda a las tablas del sistema con adaptaciones personalizadas para Amazon Keyspaces.
La solución se ejecuta en Amazon ECS con Fargate, lo que proporciona escalabilidad sin servidor en función de sus demandas de carga de trabajo. Un balanceador de carga de red distribuye el tráfico entrante de las aplicaciones entre varias tareas de Amazon ECS para lograr una alta disponibilidad.
![\[Implementación del proxy de escritura dual ZDM para migrar datos de Apache Cassandra a Amazon Keyspaces.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/migration/online-migration-zdm.png)
+ **Escrituras duales de aplicación**: puede implementar escrituras duales con cambios mínimos en el código de su aplicación aprovechando las bibliotecas de clientes y los controladores existentes de Cassandra. Puede implementar escrituras duales en su aplicación existente o crear una nueva capa en la arquitectura para administrar las escrituras duales. Para obtener más información y un caso práctico de un cliente que demuestra cómo se implementaron las escrituras duales en una aplicación existente, consulte este [caso práctico de migración de Cassandra](https://aws.amazon.com/solutions/case-studies/intuit-apache-migration-case-study/).
Al implementar escrituras duales, puede designar una base de datos como líder y la otra base de datos como seguidora. Esto le permite seguir escribiendo en la base de datos original (o líder) evitando que los errores de escritura en la base de datos de destino (o seguidora) interrumpan la ruta crítica de la aplicación.
En lugar de volver a intentar las escrituras fallidas en la seguidora, puede utilizar Amazon Simple Queue Service para registrar las escrituras fallidas en una [cola de mensajes fallidos (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html). La DLQ le permite analizar las escrituras fallidas en la seguidora y determinar por qué no se ha realizado correctamente el procesamiento en la base de datos de destino.
[Para una implementación de escritura doble más sofisticada, puede seguir las AWS mejores prácticas para diseñar una secuencia de transacciones locales utilizando el patrón saga.](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/saga.html) Un patrón saga asegura que, si se produce un error en una transacción, la saga ejecuta transacciones de compensación para revertir los cambios en la base de datos realizados por las transacciones anteriores.
Si utiliza escrituras duales para una migración en línea, puede configurar las escrituras duales para que sigan el patrón saga, de modo que cada escritura sea una transacción local que garantice las operaciones atómicas en bases de datos heterogéneas. Para obtener más información sobre cómo diseñar aplicaciones distribuidas utilizando los patrones de diseño recomendados para ellasNube de AWS, consulte [Patrones de diseño, arquitecturas e implementaciones en la nube](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/introduction).
![\[Implementación de escrituras duales en la capa de aplicación al migrar de Apache Cassandra a Amazon Keyspaces.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/migration/online-migration-dual-writes.png)
+ **Escrituras duales en el nivel de mensajería**: en lugar de implementar escrituras duales en la capa de aplicación, puede usar el nivel de mensajería existente para realizar escrituras duales en Cassandra y Amazon Keyspaces.
Para ello, puede configurar un consumidor adicional para su plataforma de mensajería de modo que envíe las escrituras a ambos almacenes de datos. Este enfoque proporciona una estrategia sencilla y con poco código que utiliza el nivel de mensajería para crear dos vistas en ambas bases de datos que, en última instancia, sean coherentes.
# Carga de datos históricos durante una migración en línea
Tras implementar la escritura dual para garantizar que los nuevos datos se escriban en ambos almacenes de datos en tiempo real, el siguiente paso del plan de migración consiste en evaluar la cantidad de datos históricos que necesita copiar o cargar por lotes de Cassandra a Amazon Keyspaces. Esto garantiza que tanto los datos nuevos como los históricos estén disponibles en la nueva base de datos de Amazon Keyspaces antes de migrar la aplicación.
En función de sus requisitos de retención de datos, por ejemplo, de la cantidad de datos históricos que necesite conservar en función de las políticas de su organización, puede considerar una de las dos opciones siguientes.
+ **Carga masiva de datos históricos**: la migración de los datos históricos de su implementación actual de Cassandra a Amazon Keyspaces se puede realizar mediante diversas técnicas, por ejemplo, el AWS Glue uso de scripts personalizados para extraer, transformar y cargar (ETL) los datos. Para obtener más información acerca del uso de AWS Glue para cargar datos históricos, consulte [Proceso de migración sin conexión: de Apache Cassandra a Amazon Keyspaces](migrating-offline.md).
Al planificar la carga masiva de datos históricos, hay que tener en cuenta cómo resolver los conflictos que pueden producirse cuando se intenta actualizar con nuevas escrituras los mismos datos que se están cargando. Cabe esperar que la carga por lotes acabe siendo coherente, lo que significa que los datos llegarán a todos los nodos al final.
Si se produce una actualización de los mismos datos al mismo tiempo debido a una nueva escritura, debe asegurarse de que la carga de los datos históricos no los sobrescriba. Para asegurarse de conservar las últimas actualizaciones de sus datos incluso durante la importación por lotes, debe incorporar la solución de conflictos a los scripts de carga por lotes o a la lógica de la aplicación para las escrituras duales.
Por ejemplo, puede usar [Transacciones ligeras](functional-differences.md#functional-differences.light-transactions) (LWT) para comparar y configurar las operaciones. Para ello, puede agregar un campo adicional a su modelo de datos que represente el momento de la modificación o el estado.
Además, Amazon Keyspaces admite la función de marca de tiempo `WRITETIME` de Cassandra. Puede utilizar las marcas de tiempo del lado del cliente de Amazon Keyspaces para conservar las marcas de tiempo de la base de datos de origen e implementar la resolución de conflictos. last-writer-wins Para obtener más información, consulte [Marcas de tiempo del cliente en Amazon Keyspaces](client-side-timestamps.md).
+ **Uso de Time-to-Live (TTL)**: para períodos de retención de datos inferiores a 30, 60 o 90 días, puede usar TTL en Cassandra y Amazon Keyspaces durante la migración para evitar cargar datos históricos innecesarios en Amazon Keyspaces. El TTL le permite establecer un período de tiempo tras el cual se quitan automáticamente los datos de la base de datos.
Durante la fase de migración, en lugar de copiar los datos históricos a Amazon Keyspaces, puede configurar los ajustes del TTL para permitir que los datos históricos caduquen automáticamente en el sistema anterior (Cassandra) y aplicar únicamente las nuevas escrituras a Amazon Keyspaces mediante el método de escritura dual. Con el paso del tiempo, y dado que los datos antiguos caducan continuamente en el clúster de Cassandra y los nuevos se escriben con el método de escritura dual, Amazon Keyspaces se pone al día automáticamente para contener los mismos datos que Cassandra.
Este enfoque puede reducir considerablemente la cantidad de datos que se van a migrar, lo que se traduce en un proceso de migración más eficiente y optimizado. Puede plantearse este enfoque cuando se enfrente a conjuntos de datos grandes con requisitos de retención de datos variables. Para obtener más información sobre e TTL, consulte [Caducidad de datos con período de vida (TTL) para Amazon Keyspaces (para Apache Cassandra)](TTL.md).
Plantéese el siguiente ejemplo de una migración de Cassandra a Amazon Keyspaces mediante la caducidad de datos con TTL. En este ejemplo, establecemos el TTL de ambas bases de datos en 60 días y mostramos cómo progresa el proceso de migración durante un período de 90 días. Ambas bases de datos reciben los mismos datos recién escritos durante este período mediante el método de escritura dual. Vamos a analizar tres fases diferentes de la migración, cada una de las cuales dura 30 días.
En las siguientes imágenes se muestra cómo funciona el proceso de migración para cada fase.
![\[Uso del TTL para hacer caducar los datos históricos al migrar de Apache Cassandra a Amazon Keyspaces.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/migration/online-migration-TTL.png)
1. Tras los primeros 30 días, el clúster de Cassandra y Amazon Keyspaces han estado recibiendo nuevas escrituras. El clúster de Cassandra también contiene datos históricos que aún no han alcanzado los 60 días de retención, lo que representa el 50 % de los datos del clúster.
Los datos que tienen más de 60 días se eliminan automáticamente en el clúster de Cassandra mediante TTL. En este punto, Amazon Keyspaces contiene el 50 % de los datos almacenados en el clúster de Cassandra, que se compone de las nuevas escrituras menos los datos históricos.
1. Transcurridos 60 días, tanto el clúster de Cassandra como Amazon Keyspaces contienen los mismos datos escritos en los últimos 60 días.
1. En un plazo de 90 días, tanto Cassandra como Amazon Keyspaces contienen los mismos datos y los datos caducan al mismo ritmo.
Este ejemplo ilustra cómo evitar el paso de cargar datos históricos mediante el uso del TTL con una fecha de caducidad establecida en 60 días.
# Validación de la coherencia de datos durante una migración en línea
El siguiente paso del proceso de migración en línea es la validación de los datos. Las escrituras duales añaden nuevos datos a su base de datos de Amazon Keyspaces y ha completado la migración de los datos históricos mediante la carga por lotes o la caducidad de los datos con TTL.
Ahora puede utilizar la fase de validación para confirmar que ambos almacenes de datos contienen realmente los mismos datos y devuelven los mismos resultados de lectura. Puede elegir una de las dos opciones siguientes para validar que ambas bases de datos contengan datos idénticos.
+ **Lecturas duales**: para validar que tanto la base de datos de origen como la de destino contengan el mismo conjunto de datos históricos y recién escritos, puede implementar lecturas duales. Para ello, debe leer tanto la base de datos principal de Cassandra como la base de datos secundaria de Amazon Keyspaces, de forma similar al método de escritura dual, y comparar los resultados de forma asíncrona.
Los resultados de la base de datos principal se devuelven al cliente y los resultados de la base de datos secundaria se utilizan para validarlos con el conjunto de resultados principal. Las diferencias detectadas se pueden registrar o enviar a una [cola de mensajes fallidos (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) para su posterior conciliación.
En el siguiente diagrama, la aplicación realiza una lectura sincrónica desde Cassandra (que es el almacén de datos principal) y una lectura asincrónica desde Amazon Keyspaces, que es el almacén de datos secundario.
![\[Uso de lecturas duales para validar la coherencia de datos durante una migración en línea de Apache Cassandra a Amazon Keyspaces.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/migration/online-migration-dual-reads.png)
+ **Lecturas de muestra**: una solución alternativa que no requiere cambios en el código de la aplicación consiste en utilizar AWS Lambda funciones para muestrear de forma periódica y aleatoria los datos del clúster Cassandra de origen y de la base de datos Amazon Keyspaces de destino.
Estas funciones de Lambda se pueden configurar para que se ejecuten a intervalos regulares. La función de Lambda recupera un subconjunto aleatorio de datos de los sistemas de origen y destino y, a continuación, realiza una comparación de los datos muestreados. Cualquier discrepancia o discordancia entre los dos conjuntos de datos se puede registrar y enviar a una [cola de mensajes fallidos (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) específica para su posterior conciliación.
Este proceso se ilustra en el siguiente diagrama.
![\[Uso de lecturas de muestra para validar la coherencia de datos durante una migración en línea de Apache Cassandra a Amazon Keyspaces.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/migration/online-migration-sample-reads.png)
# Migración de la aplicación durante una migración en línea
En la cuarta fase de una migración en línea, migrará su aplicación y realizará la transición a Amazon Keyspaces como almacén de datos principal. Esto significa que puede cambiar la aplicación para que lea y escriba directamente desde y hacia Amazon Keyspaces. Para garantizar una interrupción mínima para sus usuarios, debe ser un proceso bien planificado y coordinado.
Hay disponibles dos soluciones recomendadas diferentes para la migración de aplicaciones: la estrategia de transición azul-verde y la estrategia de transición canario. En las siguientes secciones se describen estas estrategias con más detalle.
+ **Estrategia azul-verde**: mediante el uso de este enfoque, modifica su aplicación para que trate Amazon Keyspaces como el almacén de datos principal y Cassandra como el almacén de datos secundario en un solo paso. Para ello, utilice un indicador de AWS AppConfig función para controlar la elección de los almacenes de datos principales y secundarios en la instancia de la aplicación. Para obtener más información sobre marcas de características, consulte [Creación de un perfil de configuración de marcas de características en AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-creating-configuration-and-profile-feature-flags.html).
Tras convertir Amazon Keyspaces en el almacén de datos principal, debe supervisar el comportamiento y el rendimiento de la aplicación para garantizar que Amazon Keyspaces cumpla sus requisitos y que la migración se realice correctamente.
Por ejemplo, si ha implementado lecturas duales para su aplicación, durante la fase de migración de la aplicación, pasará las lecturas principales de Cassandra a Amazon Keyspaces y las lecturas secundarias de Amazon Keyspaces a Cassandra. Tras la transición, debe seguir supervisando y comparando los resultados tal y como se describe en la sección de [validación de datos](migration-online-validation.md) para garantizar la coherencia en ambas bases de datos antes de retirar Cassandra del servicio.
Si detecta algún problema, puede volver rápidamente al estado anterior recuperando Cassandra como almacén de datos principal. Solo pasará a la fase de retirada de la migración si Amazon Keyspaces satisface todas sus necesidades como almacén de datos principal.
![\[Uso de la estrategia azul-verde para migrar una aplicación de Apache Cassandra a Amazon Keyspaces.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/migration/online-migration-switch.png)
+ **Estrategia canario**: con este enfoque, se lleva a cabo gradualmente la migración para un subconjunto de los usuarios o del tráfico. Inicialmente, un pequeño porcentaje del tráfico de la aplicación (por ejemplo, el 5 % de todo el tráfico) se redirige a la versión que utiliza Amazon Keyspaces como almacén de datos principal, mientras que el resto del tráfico sigue utilizando Cassandra como almacén de datos principal.
Esto le permite probar exhaustivamente la versión migrada con tráfico real, supervisar su rendimiento y estabilidad e investigar los posibles problemas. Si no detecta ningún problema, puede aumentar gradualmente el porcentaje de tráfico que se dirige a Amazon Keyspaces hasta que se convierta en el almacén de datos principal para todos los usuarios y todo el tráfico.
Esta implementación por etapas minimiza el riesgo de interrupciones generalizadas del servicio y permite un proceso de migración más controlado. Si surge algún problema grave durante la implementación canario, puede volver rápidamente a la versión anterior utilizando Cassandra como almacén de datos principal para el segmento de tráfico afectado. Solo pasará a la fase de retirada de la migración después de haber validado que Amazon Keyspaces procesa el 100 % de los usuarios y el tráfico según lo previsto.
El siguiente diagrama ilustra los pasos individuales de la estrategia canario.
![\[Uso de la estrategia canario para migrar una aplicación de Apache Cassandra a Amazon Keyspaces.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/migration/online-migration-canary.png)
# Retirada de Cassandra tras una migración en línea
Una vez finalizada la migración de la aplicación, cuando la aplicación se esté ejecutando completamente en Amazon Keyspaces y se haya validado la coherencia de datos durante un período de tiempo, puede planificar la retirada del clúster de Cassandra. Durante esta fase, puede evaluar si los datos que quedan en su clúster de Cassandra deben archivarse o si se pueden eliminar. Esto depende de las políticas de su organización en materia de tratamiento y retención de datos.
Si sigue esta estrategia y tiene en cuenta las mejores prácticas recomendadas que se describen en este tema al planificar la migración en línea de Cassandra a Amazon Keyspaces, puede garantizar una transición fluida a Amazon Keyspaces y, al mismo tiempo, read-after-write mantener la coherencia y la disponibilidad de su aplicación.
La migración de Apache Cassandra a Amazon Keyspaces puede ofrecer numerosas ventajas, como la reducción de los gastos operativos, el escalado automático, la mejora de la seguridad y un marco que le ayude a alcanzar sus objetivos de conformidad normativa. Al planificar una estrategia de migración en línea con escrituras duales, carga de datos históricos, validación de datos e implementación gradual, puede garantizar una transición fluida con una interrupción mínima para su aplicación y sus usuarios.
La implementación de la estrategia de migración en línea que se analiza en este tema le permite validar los resultados de la migración, identificar y abordar cualquier problema y, en última instancia, retirar su implementación actual de Cassandra en favor del servicio de Amazon Keyspaces totalmente administrado.
# Proceso de migración sin conexión: de Apache Cassandra a Amazon Keyspaces
Las migraciones sin conexión son adecuadas cuando se pueda permitir un tiempo de inactividad para llevarlas a cabo. Es habitual que las empresas tengan períodos de mantenimiento para la aplicación de parches o lanzamientos de gran tamaño, o tiempos de inactividad para llevar a cabo actualizaciones de hardware o cambios principales. La migración sin conexión puede aprovechar estos periodos para copiar datos y transferir el tráfico de aplicaciones de Apache Cassandra a Amazon Keyspaces.
La migración sin conexión reduce las modificaciones en la aplicación porque no requiere la comunicación simultánea con Cassandra y Amazon Keyspaces. Además, dado que el flujo de datos está pausado, se puede copiar el estado exacto sin mantener las mutaciones.
En este ejemplo, utilizamos Amazon Simple Storage Service (Amazon S3) como espacio provisional para los datos durante la migración sin conexión con el objetivo de minimizar el tiempo de inactividad. Puede importar automáticamente los datos que ha almacenado en formato Parquet en Amazon S3 a una tabla de Amazon Keyspaces mediante Spark Cassandra Connector y AWS Glue. En la siguiente sección se mostrará información general de alto nivel del proceso. Puede encontrar ejemplos de código para este proceso en [Github](https://github.com/aws-samples/amazon-keyspaces-examples/tree/main/scala/datastax-v4/aws-glue).
El proceso de migración sin conexión de Apache Cassandra a Amazon Keyspaces mediante Amazon S3 requiere AWS Glue los AWS Glue siguientes trabajos.
1. Un trabajo ETL que extraiga y transforme los datos de CQL y los almacena en un bucket de Amazon S3.
1. Un segundo trabajo que importe los datos del bucket a Amazon Keyspaces.
1. Un tercer trabajo que importe datos incrementales.
**Cómo realizar una migración offline a Amazon Keyspaces desde Cassandra que se ejecuta en Amazon EC2 en una Amazon Virtual Private Cloud**
1. Primero se exportan AWS Glue los datos de las tablas de Cassandra en formato Parquet y se guardan en un bucket de Amazon S3. Debe ejecutar un AWS Glue trabajo mediante un AWS Glue conector a una VPC en la que resida la EC2 instancia de Amazon que ejecuta Cassandra. A continuación, con el punto de conexión privado de Amazon S3, puede guardar los datos en el bucket de Amazon S3.
En el siguiente diagrama se muestran estos pasos.
![\[Migración de datos de Apache Cassandra desde Amazon EC2 que se ejecuta en una VPC a un bucket de Amazon S3 mediante. AWS Glue\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/migration/migration-export.png)
1. Mezcla de los datos en el bucket de Amazon S3 para mejorar la asignación al azar de los datos. Los datos importados de manera uniforme permiten distribuir más el tráfico en la tabla de destino.
Este paso es obligatorio cuando se exportan datos de Cassandra con particiones grandes (particiones con más de 1000 filas) para evitar patrones de claves sobrecargadas al insertar los datos en Amazon Keyspaces. Los problemas por claves sobrecargadas provocan `WriteThrottleEvents` en Amazon Keyspaces y causan un aumento del tiempo de carga.
![\[Un AWS Glue trabajo mezcla los datos de un bucket de Amazon S3 y los devuelve a otro bucket de Amazon S3.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/migration/migration-shuffle.png)
1. Utilice otro AWS Glue trabajo para importar datos del bucket de Amazon S3 a Amazon Keyspaces. Los datos mezclados en el bucket de Amazon S3 se almacenan en formato Parquet.
![\[El trabajo de AWS Glue importación toma los datos mezclados del bucket de Amazon S3 y los mueve a una tabla de Amazon Keyspaces.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/migration/migration-import.png)
Para obtener más información sobre el proceso de migración fuera de línea, consulte el taller [Amazon Keyspaces with AWS Glue](https://catalog.workshops.aws/unlocking-amazonkeyspaces/en-US/keyspaces-with-glue)
# Uso de una solución de migración híbrida: de Apache Cassandra a Amazon Keyspaces
La siguiente solución de migración puede considerarse un híbrido entre la migración en línea y la migración sin conexión. Con este enfoque híbrido, se escriben los datos en la base de datos de destino casi en tiempo real sin proporcionar coherencia de lectura tras la escritura. Esto significa que los datos recién escritos no estarán disponibles de forma inmediata y que es previsible que se produzcan retrasos. Si necesita coherencia de lectura tras la escritura, consulte [Migración online a Amazon Keyspaces: estrategias y prácticas recomendadas](migrating-online.md).
Para realizar una migración casi en tiempo real de Apache Cassandra a Amazon Keyspaces, puede elegir entre dos métodos disponibles.
+ **CQLReplicator**— (Recomendado) CQLReplicator es una utilidad de código abierto disponible en [Github](https://github.com/aws-samples/cql-replicator) que le ayuda a migrar datos de Apache Cassandra a Amazon Keyspaces casi en tiempo real.
Para determinar las escrituras y actualizaciones que se van a propagar a la base de datos de destino, CQLReplicator escanea el rango de tokens de Apache Cassandra y utiliza un AWS Glue trabajo para eliminar los eventos duplicados y aplicar las escrituras y actualizaciones directamente a Amazon Keyspaces.
+ **Captura de datos de cambios (CDC)**: si conoce la CDC de Cassandra, otra opción para implementar una migración híbrida es utilizar la característica de CDC integrada en Apache Cassandra, que permite capturar los cambios copiando el registro de confirmaciones en un directorio de CDC independiente.
Para ello, puede replicar los cambios en los datos en Amazon Keyspaces, lo que convierte a la CDC en una opción alternativa para los escenarios de migración de datos.
Si no necesita coherencia de lectura tras escritura, puede utilizar la canalización CQLReplicator o una canalización de CDC para migrar los datos de Apache Cassandra a Amazon Keyspaces en función de sus preferencias y de su familiaridad con las herramientas utilizadas en cada Servicios de AWS solución. El uso de estos métodos para migrar datos prácticamente en tiempo real puede considerarse un enfoque de migración híbrido que ofrece una alternativa a la migración en línea.
Esta estrategia se considera un enfoque híbrido porque, además de las opciones descritas en este tema, deben implementarse algunos pasos del proceso de migración en línea, por ejemplo, la copia de los datos históricos y las estrategias de migración de aplicaciones que se analizan en el tema [migración en línea](migrating-online.md).
En las siguientes secciones, se explican las opciones de migración híbrida con más detalle.
**Topics**
+ [Migre los datos mediante CQLReplicator](migration-hybrid-cql-rep.md)
+ [Migración de datos mediante la captura de datos de cambios (CDC)](migration-hybrid-cdc.md)
# Migre los datos mediante CQLReplicator
Con él [CQLReplicator](https://github.com/aws-samples/cql-replicator), puede leer los datos de Apache Cassandra prácticamente en tiempo real escaneando de forma inteligente el anillo de fichas de Cassandra mediante consultas CQL. CQLReplicator no usa Cassandra CDC y, en su lugar, implementa una estrategia de almacenamiento en caché para reducir las penalizaciones de rendimiento de los escaneos completos.
Para reducir el número de escrituras en el destino, elimina CQLReplicator automáticamente los eventos de replicación duplicados. Con CQLReplicator, puede ajustar la replicación de los cambios de la base de datos de origen a la base de datos de destino, lo que permite una migración de datos casi en tiempo real de Apache Cassandra a Amazon Keyspaces.
El siguiente diagrama muestra la arquitectura típica de un CQLReplicator trabajo que utiliza. AWS Glue
1. **Para permitir el acceso a Apache Cassandra que se ejecuta en una VPC privada, configure AWS Glue una conexión con el tipo de conexión Red.**
1. Para eliminar los duplicados y habilitar el almacenamiento en caché de claves con la CQLReplicator tarea, configure Amazon Simple Storage Service (Amazon S3).
1. La base de datos fuente verificada de CQLReplicator Job Streams cambia directamente a Amazon Keyspaces.
![\[Se utiliza CQLReplicator para migrar datos de Apache Cassandra a Amazon Keyspaces.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/migration/hybrid-migration-CQLRep.png)
Para obtener más información sobre el proceso de migración mediante CQLReplicator, consulte la siguiente publicación en el blog de AWS bases de datos [Migre las cargas de trabajo de Cassandra a Amazon Keyspaces utilizando CQLReplicator](https://aws.amazon.com/blogs/database/migrate-cassandra-workloads-to-amazon-keyspaces-using-cqlreplicator/) y la guía AWS prescriptiva [Migre las cargas de trabajo de Apache Cassandra a](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-apache-cassandra-workloads-to-amazon-keyspaces-using-aws-glue.html) Amazon Keyspaces mediante el uso. AWS Glue
# Migración de datos mediante la captura de datos de cambios (CDC)
Si ya está familiarizado con la configuración de un proceso de captura de datos de cambios (CDC) con [Debezium](https://debezium.io/), puede usar esta opción para migrar datos a Amazon Keyspaces como alternativa a la de usarla. CQLReplicator Debezium es una plataforma distribuida de código abierto para la CDC, diseñada para supervisar una base de datos y capturar los cambios en las filas de manera fiable.
El [conector de Debezium para Apache Cassandra](https://debezium.io/documentation/reference/stable/connectors/cassandra.html) carga los cambios en Amazon Managed Streaming para Apache Kafka (Amazon MSK) de modo que los consumidores intermedios puedan consumirlos, procesarlos y escribir a su vez los datos en Amazon Keyspaces. Para obtener más información, consulte [Guidance for continuous data migration from Apache Cassandra to Amazon Keyspaces](https://aws.amazon.com/solutions/guidance/continuous-data-migration-from-apache-cassandra-to-amazon-keyspaces/).
Si quiere solucionar cualquier posible problema de coherencia de datos, puede implementar un proceso con Amazon MSK en el que un consumidor compare las claves o particiones de Cassandra con las de Amazon Keyspaces.
Para implementar esta solución correctamente, le recomendamos que tenga en cuenta lo siguiente.
+ Cómo analizar el registro de confirmaciones de la CDC; por ejemplo, cómo eliminar los eventos duplicados.
+ Cómo mantener el directorio de la CDC; por ejemplo, cómo eliminar los registros antiguos.
+ Cómo administrar los errores parciales en Apache Cassandra; por ejemplo, si una escritura solo se realiza correctamente en una de cada tres réplicas.
+ Cómo administrar la asignación de recursos, por ejemplo, aumentar el tamaño de la instancia para que admita los requisitos adicionales de CPU, memoria, disco y E/S para el proceso de CDC que se produce en un nodo.
Este patrón trata los cambios de Cassandra como “indicios” de que una clave puede haber cambiado con respecto a su estado anterior. Para determinar si hay cambios que propagar a la base de datos de destino, primero debe leer el clúster de Cassandra de origen mediante una operación `LOCAL_QUORUM` para recibir los registros más recientes y, a continuación, escribirlos en Amazon Keyspaces.
En el caso de eliminaciones o actualizaciones de rangos, es posible que deba realizar una comparación con la totalidad de la partición para determinar qué eventos de escritura o actualización deben escribirse en la base de datos de destino.
En los casos en que las escrituras no tengan idempotencia, también debe compararlas con lo que ya está en la base de datos de destino antes de que se efectúen en Amazon Keyspaces.
En el siguiente diagrama, se muestra la arquitectura típica de una canalización de CDC con Debezium y Amazon MSK.
![\[Uso de una canalización de captura de datos de cambios para migrar datos de Apache Cassandra a Amazon Keyspaces.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/migration/hybrid-migration-CDC.png)
# Selección de la herramienta adecuada para cargar o migrar datos por lotes a Amazon Keyspaces
En esta sección, revisará las diferentes herramientas que puede utilizar para cargar o migrar datos por lotes a Amazon Keyspaces y aprenderá a seleccionar la herramienta correcta en función de sus necesidades. Además, en esta sección se proporciona información general y casos de uso de los step-by-step tutoriales disponibles que muestran cómo importar datos a Amazon Keyspaces.
Para revisar las estrategias disponibles para migrar cargas de trabajo de Apache Cassandra a Amazon Keyspaces, consulte [Creación de un plan de migración para migrar de Apache Cassandra a Amazon Keyspaces](migrating-cassandra.md).
+ **Herramientas de migración**
+ Con la [calculadora de precios de Amazon Keyspaces (para Apache Cassandra)](https://aws-samples.github.io/sample-pricing-calculator-for-keyspaces/#cassandra) disponible en Github, puede estimar los costes mensuales de Amazon Keyspaces en función de su carga de trabajo actual de Apache Cassandra. Introduzca las métricas del resultado de estado de Cassandra nodetool y de la configuración sin servidor prevista para Amazon Keyspaces a fin de comparar los costes directos entre las dos soluciones. Tenga en cuenta que esta calculadora se centra únicamente en los costes operativos de Amazon Keyspaces en comparación con su implementación actual de Cassandra. No incluye los factores del costo total de propiedad (TCO), como el mantenimiento de la infraestructura, los gastos operativos o los costos de soporte de Cassandra.
+ Proxy de **escritura doble de ZDM para la migración de Amazon Keyspaces: el proxy** de escritura doble de ZDM, disponible [en](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) Github, permite la migración sin tiempo de inactividad de Apache Cassandra a Amazon Keyspaces.
+ **CQLReplicator**— CQLReplicator es una utilidad de código abierto disponible en [Github](https://github.com/aws-samples/cql-replicator) que le ayuda a migrar datos de Apache Cassandra a Amazon Keyspaces casi en tiempo real.
Para obtener más información, consulte [Migre los datos mediante CQLReplicator](migration-hybrid-cql-rep.md).
+ Para obtener más información sobre cómo usar Amazon Managed Streaming para Apache Kafka para implementar un proceso de [migración en línea](migrating-online.md) con escrituras duales, consulte [Guidance for continuous data migration from Apache Cassandra to Amazon Keyspaces](https://aws.amazon.com/solutions/guidance/continuous-data-migration-from-apache-cassandra-to-amazon-keyspaces/).
+ Para migraciones grandes, considere la posibilidad de utilizar una herramienta de extracción, transformación y carga (ETL). Puede utilizar AWS Glue para realizar migraciones de transformación de datos de forma rápida y eficaz. Para obtener más información, consulte [Proceso de migración sin conexión: de Apache Cassandra a Amazon Keyspaces](migrating-offline.md).
+ Para obtener información sobre cómo utilizar el conector Apache Cassandra Spark para escribir datos en Amazon Keyspaces, consulte [Tutorial: Intégrelo con Apache Spark para importar o exportar datos](spark-integrating.md).
+ Comience sin demora a cargar datos en Amazon Keyspaces con el comando `COPY FROM` de cqlsh. cqlsh se incluye con Apache Cassandra y es el más adecuado para cargar pequeños conjuntos de datos o datos de prueba. Para obtener step-by-step instrucciones, consulte. [Tutorial: Carga de datos en Amazon Keyspaces utilizando cqlsh](bulk-upload.md)
+ También puede usar DataStax Bulk Loader for Apache Cassandra para cargar datos en Amazon Keyspaces mediante `dsbulk` el comando. DSBulk[proporciona capacidades de importación más sólidas que cqlsh y está disponible en el repositorio. GitHub ](https://github.com/datastax/dsbulk) Para obtener step-by-step instrucciones, consulte. [Tutorial: Carga de datos en Amazon Keyspaces mediante DSBulk](dsbulk-upload.md)
Consideraciones generales para la carga de datos a Amazon Keyspaces
+ **Divida la carga de datos en componentes más pequeños.**
Considere las siguientes unidades de migración y su huella potencial en términos de tamaño de datos en bruto. Cargar cantidades más pequeñas de datos en una o varias fases puede ayudar a simplificar su migración.
+ **Por clúster**: migre todos sus datos de Cassandra a la vez. Este enfoque podría ser adecuado para clústeres pequeños.
+ **Por espacio de claves o tabla**: divida su migración en grupos de espacios de claves o tablas. Este enfoque puede ayudarle a migrar los datos por fases en función de sus necesidades para cada carga de trabajo.
+ **Por datos**: considere la posibilidad de migrar los datos de un grupo específico de usuarios o productos, para reducir aún más el tamaño de los datos.
+ **Priorice qué datos cargar primero en función de la simplicidad.**
Considere si tiene datos que podrían migrarse primero con más facilidad; por ejemplo, datos que no cambien durante horas específicas, datos de trabajos por lotes nocturnos, datos que no se utilicen durante horas sin conexión o datos de aplicaciones internas.
**Topics**
+ [Tutorial: Carga de datos en Amazon Keyspaces utilizando cqlsh](bulk-upload.md)
+ [Tutorial: Carga de datos en Amazon Keyspaces mediante DSBulk](dsbulk-upload.md)
# Tutorial: Carga de datos en Amazon Keyspaces utilizando cqlsh
En este tutorial le guiaremos en el proceso de migración de datos de Apache Cassandra a Amazon Keyspaces utilizando el comando `cqlsh COPY FROM`. El comando `cqlsh COPY FROM` resulta útil para cargar rápida y fácilmente pequeños conjuntos de datos a Amazon Keyspaces con fines académicos o de prueba. Para obtener más información acerca de cómo migrar cargas de trabajo de producción, consulte [Proceso de migración sin conexión: de Apache Cassandra a Amazon Keyspaces](migrating-offline.md). En este tutorial, completará los siguientes pasos:
Requisitos previos: configure una AWS cuenta con credenciales, cree un archivo de almacén de confianza JKS para el certificado y configúrelo para conectarse `cqlsh` a Amazon Keyspaces.
1. **Creación del CSV de origen y la tabla de destino**: prepare un archivo CSV como datos de origen y cree el espacio de claves y la tabla de destino en Amazon Keyspaces.
1. **Preparación de los datos**: asigne al azar los datos del archivo CSV y analícelos para determinar el tamaño medio y máximo de las filas.
1. **Defina la capacidad de rendimiento**: calcule las unidades de capacidad de escritura necesarias (WCUs) en función del tamaño de los datos y el tiempo de carga deseado, y configure la capacidad aprovisionada de la tabla.
1. **Configuración de los parámetros cqlsh**: determine los valores óptimos para los parámetros `cqlsh COPY FROM` como `INGESTRATE`, `NUMPROCESSES`, `MAXBATCHSIZE` y `CHUNKSIZE` para distribuir la carga de trabajo de manera uniforme.
1. **Ejecución del comando `cqlsh COPY FROM`**: ejecute el comando `cqlsh COPY FROM` para cargar los datos del archivo CSV a la tabla de Amazon Keyspaces y supervise el progreso.
Solución de problemas: resuelva problemas comunes, como solicitudes no válidas, errores del analizador, errores de capacidad y errores de cqlsh durante el proceso de carga de datos.
**Topics**
+ [Requisitos previos: pasos que debe completar antes de poder cargar datos mediante `cqlsh COPY FROM`](bulk-upload-prequs.md)
+ [Paso 1: creación del archivo CSV de origen y de una tabla de destino para la carga de datos](bulk-upload-source.md)
+ [Paso 2: preparación de los datos de origen para una carga de datos correcta](bulk-upload-prepare-data.md)
+ [Paso 3: Establecer la capacidad de rendimiento de la tabla](bulk-upload-capacity.md)
+ [Paso 4: Configurar los ajustes de `cqlsh COPY FROM`](bulk-upload-config.md)
+ [Paso 5: ejecución del comando `cqlsh COPY FROM` para cargar los datos del archivo CSV a la tabla de destino](bulk-upload-run.md)
+ [Resolución de problemas](bulk-upload-troubleshooting.md)
# Requisitos previos: pasos que debe completar antes de poder cargar datos mediante `cqlsh COPY FROM`
Para poder comenzar el tutorial, antes debe completar las siguientes tareas.
1. Si aún no lo ha hecho, inscríbase en una Cuenta de AWS siguiendo los pasos que se indican en. [Con AWS Identity and Access Management figuración](accessing.md#SettingUp.IAM)
1. Cree las credenciales específicas del servicio; para ello, siga los pasos indicados en [Creación de credenciales específicas del servicio para el acceso programático a Amazon Keyspaces](programmatic.credentials.ssc.md).
1. Configure la conexión del intérprete de comandos de Cassandra Query Language (cqlsh) y confirme que puede conectarse a Amazon Keyspaces siguiendo los pasos indicados en [Uso de `cqlsh` para conectarse a Amazon Keyspaces](programmatic.cqlsh.md).
# Paso 1: creación del archivo CSV de origen y de una tabla de destino para la carga de datos
En este tutorial, utilizamos un archivo de valores separados por comas (CSV) llamado `keyspaces_sample_table.csv` como archivo de origen para la migración de datos. El archivo de ejemplo proporcionado contiene algunas filas de datos de una tabla llamada `book_awards`.
1. Cree el archivo de origen. Puede elegir una de las siguientes opciones:
+ Descargue el archivo CSV de ejemplo (`keyspaces_sample_table.csv`), contenido en el siguiente archivo comprimido: [samplemigration.zip](samples/samplemigration.zip). Descomprima el archivo y tome nota de la ruta a `keyspaces_sample_table.csv`.
+ Para rellenar un archivo CSV de origen con sus propios datos almacenados en una base de datos de Apache Cassandra, utilice la instrucción `cqlsh` `COPY TO`, como se muestra en el siguiente ejemplo.
```
cqlsh localhost 9042 -u "username" -p "password" --execute "COPY mykeyspace.mytable TO 'keyspaces_sample_table.csv' WITH HEADER=true";
```
Asegúrese de que el archivo CSV que cree satisfaga los siguientes requisitos:
+ La primera fila contiene los nombres de las columnas.
+ Los nombres de las columnas del archivo CSV de origen coinciden con los nombres de las columnas de la tabla de destino.
+ Los datos están delimitados con una coma.
+ Todos los valores de los datos son tipos de datos válidos de Amazon Keyspaces. Consulte [Tipos de datos](cql.elements.md#cql.data-types).
1. Cree el espacio de claves y la tabla de destino en Amazon Keyspaces.
1. Conéctese a Amazon Keyspaces con `cqlsh` y sustituya el punto de conexión del servicio, el nombre de usuario y la contraseña del siguiente ejemplo por sus propios valores.
```
cqlsh cassandra.us-east-1.amazonaws.com 9142 -u "111122223333" -p "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" --ssl
```
1. Cree un nuevo espacio de claves con el nombre `catalog` como se muestra en el siguiente ejemplo.
```
CREATE KEYSPACE catalog WITH REPLICATION = {'class': 'SingleRegionStrategy'};
```
1. Una vez que el nuevo espacio de claves, utilice el siguiente código para crear la tabla de destino `book_awards`.
```
CREATE TABLE "catalog.book_awards" (
year int,
award text,
rank int,
category text,
book_title text,
author text,
publisher text,
PRIMARY KEY ((year, award), category, rank)
);
```
Si Apache Cassandra es su origen de datos, una forma sencilla de crear la tabla de destino de Amazon Keyspaces con encabezados que coincidan es generar la instrucción `CREATE TABLE` a partir de la tabla de origen, como se muestra en la siguiente instrucción.
```
cqlsh localhost 9042 -u "username" -p "password" --execute "DESCRIBE TABLE mykeyspace.mytable;"
```
A continuación, cree la tabla de destino en Amazon Keyspaces con los nombres de las columnas y los tipos de datos que coincidan con la descripción de la tabla de origen de Cassandra.
# Paso 2: preparación de los datos de origen para una carga de datos correcta
La preparación de los datos de origen para una transferencia eficaz es un proceso de dos pasos. En primer lugar, asigna al azar los datos. En segundo lugar, analiza los datos para determinar los valores apropiados del parámetro `cqlsh` y los ajustes necesarios de la tabla para garantizar que la carga de datos se realice correctamente.
**Asignación al azar de los datos**
El comando `cqlsh COPY FROM` lee y escribe los datos en el mismo orden en que aparecen en el archivo CSV. Si utiliza el comando `cqlsh COPY TO` para crear el archivo de origen, los datos se escriben en el orden en que aparecen ordenados por claves en el CSV. Internamente, Amazon Keyspaces divide los datos utilizando claves de partición. Si bien Amazon Keyspaces tiene una lógica integrada para ayudar a equilibrar la carga de las solicitudes de la misma clave de partición, la carga de datos es más rápida y eficiente si aleatoriza el orden. Esto se debe a que puede aprovechar el equilibrio de carga integrado que se produce cuando Amazon Keyspaces escribe en diferentes particiones.
Para repartir las escrituras entre las particiones de manera uniforme, debe aleatorizar los datos en el archivo de origen. Puede escribir una aplicación para hacerlo o utilizar una herramienta de código abierto, como [Shuf](https://en.wikipedia.org/wiki/Shuf). Shuf está disponible de forma gratuita en distribuciones Linux, en macOS (instalando coreutils en [homebrew](https://brew.sh)) y en Windows (utilizando Windows Subsystem for Linux [WSL]). Se requiere un paso adicional para evitar que la fila del encabezado con los nombres de las columnas se baraje en este paso.
Para aleatorizar el archivo de origen conservando el encabezado, introduzca el siguiente código.
```
tail -n +2 keyspaces_sample_table.csv | shuf -o keyspace.table.csv && (head -1 keyspaces_sample_table.csv && cat keyspace.table.csv ) > keyspace.table.csv1 && mv keyspace.table.csv1 keyspace.table.csv
```
Shuf reescribe los datos en un nuevo archivo CSV llamado `keyspace.table.csv`. Ahora puede eliminar el archivo `keyspaces_sample_table.csv`, dado que ya no lo necesita.
**Análisis de los datos**
Determine el tamaño medio y máximo de las filas analizando los datos.
Debe hacerlo por las siguientes razones:
+ El tamaño medio de fila ayuda a estimar la cantidad total de datos que se van a transferir.
+ Necesita el tamaño medio de fila para aprovisionar la capacidad de escritura necesaria para la carga de datos.
+ Puede asegurarse de que cada fila tenga un tamaño inferior a 1 MB, que es el tamaño máximo de fila en Amazon Keyspaces.
**nota**
Esta cuota se refiere al tamaño de fila, no al de la partición. A diferencia de las particiones de Apache Cassandra, las particiones de Amazon Keyspaces pueden tener un tamaño prácticamente ilimitado. Las claves de partición y las columnas de agrupación requieren almacenamiento adicional para los metadatos, que debe añadir al tamaño bruto de las filas. Para obtener más información, consulte [Estimación del tamaño de las filas en Amazon Keyspaces](calculating-row-size.md).
El siguiente código utiliza [AWK](https://en.wikipedia.org/wiki/AWK) para analizar un archivo CSV e imprimir el tamaño medio y máximo de las filas.
```
awk -F, 'BEGIN {samp=10000;max=-1;}{if(NR>1){len=length($0);t+=len;avg=t/NR;max=(len>max ? len : max)}}NR==samp{exit}END{printf("{lines: %d, average: %d bytes, max: %d bytes}\n",NR,avg,max);}' keyspace.table.csv
```
La ejecución de este código da como resultado la siguiente salida.
```
using 10,000 samples:
{lines: 10000, avg: 123 bytes, max: 225 bytes}
```
El tamaño medio de fila se utiliza en el siguiente paso de este tutorial para aprovisionar la capacidad de escritura de la tabla.
# Paso 3: Establecer la capacidad de rendimiento de la tabla
En este tutorial se muestra cómo ajustar cqlsh para que cargue los datos dentro de un intervalo de tiempo establecido. Dado que sabe de antemano cuántas lecturas y escrituras realiza, utilice el modo de capacidad aprovisionada. Una vez finalizada la transferencia de datos, debe ajustar el modo de capacidad de la tabla para que se adapte a los patrones de tráfico de su aplicación. Para obtener más información sobre administración de capacidad, consulte [Administración de recursos sin servidor en Amazon Keyspaces (para Apache Cassandra)](serverless_resource_management.md).
Con el modo de capacidad aprovisionada, usted especifica con antelación cuánta capacidad de lectura y escritura desea aprovisionar a su tabla. La capacidad de escritura se factura por hora y se mide en unidades de capacidad de escritura ()WCUs. Cada WCU es capacidad de escritura suficiente para admitir la escritura de 1 KB de datos por segundo. Al cargar los datos, la velocidad de escritura debe estar por debajo del máximo WCUs (parámetro:`write_capacity_units`) establecido en la tabla de destino.
De forma predeterminada, puedes aprovisionar WCUs hasta 40 000 en una tabla y 80 000 WCUs en todas las tablas de tu cuenta. Si necesita capacidad adicional, puede solicitar un aumento de cuota en la consola de [Service Quotas](https://console.aws.amazon.com/servicequotas/home#!/services/cassandra/quotas). Para obtener más información sobre las cuotas, consulte [Cuotas para Amazon Keyspaces (para Apache Cassandra)](quotas.md).
**Calcula la cantidad media WCUs necesaria para un encarte**
Insertar 1 KB de datos por segundo requiere 1 WCU. Si su archivo CSV tiene 360 000 filas y quiere cargar todos los datos en 1 hora, debe escribir 100 filas por segundo (360 000 filas / 60 minutos / 60 segundos = 100 filas por segundo). Si cada fila tiene hasta 1 KB de datos, para insertar 100 filas por segundo, debe asignar 100 WCUs a la tabla. Si cada fila tiene 1,5 KB de datos, necesitará dos WCUs para insertar una fila por segundo. Por lo tanto, para insertar 100 filas por segundo, debe aprovisionar 200 WCUs.
Para determinar cuántas filas WCUs necesita insertar una fila por segundo, divida el tamaño medio de las filas en bytes entre 1024 y redondee al número entero más cercano.
Por ejemplo, si el tamaño medio de una fila es de 3000 bytes, necesitará tres WCUs para insertar una fila por segundo.
```
ROUNDUP(3000 / 1024) = ROUNDUP(2.93) = 3 WCUs
```
**Cálculo de capacidad y tiempo de carga de datos**
Ahora que conoce el tamaño y el número promedio de filas del archivo CSV, puede calcular cuántas WCUs necesita para cargar los datos en un período de tiempo determinado y el tiempo aproximado que se tarda en cargar todos los datos del archivo CSV con diferentes configuraciones de WCU.
Por ejemplo, si cada fila del archivo ocupa 1 KB y tiene 1 000 000 de filas en el archivo CSV, para cargar los datos en 1 hora, debe aprovisionar al menos 278 WCUs a la tabla para esa hora.
```
1,000,000 rows * 1 KBs = 1,000,000 KBs
1,000,000 KBs / 3600 seconds =277.8 KBs / second = 278 WCUs
```
**Configuración de los ajustes de capacidad aprovisionada**
Puede configurar los ajustes de capacidad de escritura de una tabla al crearla o mediante el comando CQL `ALTER TABLE`. A continuación se muestra la sintaxis para modificar los ajustes de capacidad aprovisionada de una tabla con la instrucción CQL `ALTER TABLE`.
```
ALTER TABLE mykeyspace.mytable WITH custom_properties={'capacity_mode':{'throughput_mode': 'PROVISIONED', 'read_capacity_units': 100, 'write_capacity_units': 278}} ;
```
Para ver la referencia completa del lenguaje, consulte [ALTER TABLE](cql.ddl.table.md#cql.ddl.table.alter).
# Paso 4: Configurar los ajustes de `cqlsh COPY FROM`
En esta sección se describe cómo determinar los valores de los parámetros para `cqlsh COPY FROM`. El comando `cqlsh COPY FROM` lee el archivo CSV que preparó anteriormente e inserta los datos en Amazon Keyspaces mediante CQL. El comando divide las filas y distribuye las operaciones `INSERT` entre un conjunto de trabajadores. Cada trabajador establece una conexión con Amazon Keyspaces y envía solicitudes `INSERT` por este canal.
El comando `cqlsh COPY` no dispone de lógica interna para distribuir el trabajo de manera uniforme entre sus trabajadores. Sin embargo, puede configurarlo manualmente para asegurarse de que el trabajo se distribuya uniformemente. Para comenzar, revise estos parámetros clave de cqlsh:
+ **DELIMITER**: si ha utilizado un delimitador distinto de la coma, puede configurar este parámetro, que por defecto es la coma.
+ **INGESTRATE**: el número objetivo de filas que `cqlsh COPY FROM` intenta procesar por segundo. Si no se establece, su valor predeterminado es 100 000.
+ **NUMPROCESSES**: el número de procesos de trabajadores subordinados que cqlsh crea para las tareas `COPY FROM`. El valor máximo para este ajuste es 16, el valor predeterminado es `num_cores - 1`, donde `num_cores` es el número de núcleos de procesamiento en el host que ejecuta cqlsh.
+ **MAXBATCHSIZE**: el tamaño del lote determina el número máximo de filas insertadas en la tabla de destino en un único lote. Si no se establece, cqlsh utiliza lotes de 20 filas insertadas.
+ **CHUNKSIZE**: el tamaño de la unidad de trabajo que pasa al trabajador subordinado. De forma predeterminada, se establece en 5000.
+ **MAXATTEMPTS** el número máximo de veces que se debe reintentar un bloque de trabajador fallido. Una vez alcanzado el máximo de intentos, los registros fallidos se escriben en un nuevo archivo CSV que puede volver a ejecutar más tarde tras investigar el fallo.
`INGESTRATE`Establézcalo en función de la cantidad WCUs que hayas aprovisionado en la tabla de destino de destino. El valor `INGESTRATE` del comando `cqlsh COPY FROM` no es un límite, es una media objetivo. Esto significa que puede (y a menudo lo hace) dispararse por encima del número que usted fije. Para tener en cuenta los picos y asegurarse de que exista capacidad suficiente para gestionar las solicitudes de carga de datos, establezca `INGESTRATE` en el 90 % de la capacidad de escritura de la tabla.
```
INGESTRATE = WCUs * .90
```
A continuación, fije el parámetro `NUMPROCESSES` en uno menos que el número de núcleos de su sistema. Para averiguar el número de núcleos de su sistema, puede ejecutar el siguiente código.
```
python -c "import multiprocessing; print(multiprocessing.cpu_count())"
```
En este tutorial, utilizamos el siguiente valor.
```
NUMPROCESSES = 4
```
Cada proceso crea un trabajador, y cada trabajador establece una conexión con Amazon Keyspaces. Amazon Keyspaces puede admitir hasta 3000 solicitudes CQL por segundo en cada conexión. Esto significa que debe asegurarse de que cada trabajador procese menos de 3000 solicitudes por segundo.
Al igual que con `INGESTRATE`, los trabajadores suelen dispararse por encima del número que usted establezca y no están limitados por segundos de reloj. Por tanto, para tener en cuenta los picos, establezca sus parámetros de cqlsh para que cada trabajador procese 2500 solicitudes por segundo. Para calcular la cantidad de trabajo distribuida a un trabajador, utilice la siguiente pauta.
+ Divida `INGESTRATE` por `NUMPROCESSES`.
+ Si `INGESTRATE` / `NUMPROCESSES` > 2500, disminuya el valor `INGESTRATE` para que esta fórmula se cumpla.
```
INGESTRATE / NUMPROCESSES <= 2,500
```
Antes de configurar los ajustes para optimizar la carga de nuestros datos de ejemplo, revisemos los ajustes predeterminados de `cqlsh` y veamos cómo afecta su uso al proceso de carga de datos. Dado que `cqlsh COPY FROM` utiliza el valor `CHUNKSIZE` a fin de crear bloques de trabajo (instrucciones `INSERT`) para distribuir a los trabajadores, el trabajo no se distribuye automáticamente de manera uniforme. Algunos trabajadores podrían permanecer inactivos, en función del ajuste de `INGESTRATE`.
Para distribuir el trabajo de manera uniforme entre los trabajadores y mantener a cada trabajador en la tasa óptima de 2500 solicitudes por segundo, debe establecer `CHUNKSIZE`, `MAXBATCHSIZE` y `INGESTRATE` cambiando los parámetros de entrada. Para optimizar la utilización del tráfico de red durante la carga de datos, elija un valor para `MAXBATCHSIZE` que se acerque al valor máximo de 30. Al cambiar `CHUNKSIZE` a 100 y `MAXBATCHSIZE` a 25, las 10 000 filas se reparten uniformemente entre los cuatro trabajadores (10 000 / 2500 = 4).
El siguiente ejemplo de código lo ilustra.
```
INGESTRATE = 10,000
NUMPROCESSES = 4
CHUNKSIZE = 100
MAXBATCHSIZE. = 25
Work Distribution:
Connection 1 / Worker 1 : 2,500 Requests per second
Connection 2 / Worker 2 : 2,500 Requests per second
Connection 3 / Worker 3 : 2,500 Requests per second
Connection 4 / Worker 4 : 2,500 Requests per second
```
En resumen, utilice las siguientes fórmulas al establecer los parámetros de `cqlsh COPY FROM`:
+ **INGESTRATE** = write\$1capacity\$1units \$1 .90
+ **NUMPROCESSES** = num\$1cores -1 (predeterminado)
+ **INGESTRATE / NUMPROCESSES** = 2500 (Esta debe ser una instrucción true)
+ **MAXBATCHSIZE** = 30 (De forma predeterminada, 20. Amazon Keyspaces acepta lotes de hasta 30)
+ **CHUNKSIZE** = (INGESTRATE / NUMPROCESSES) / MAXBATCHSIZE
Ahora que ha calculado `NUMPROCESSES`, `INGESTRATE` y `CHUNKSIZE`, está listo para cargar sus datos.
# Paso 5: ejecución del comando `cqlsh COPY FROM` para cargar los datos del archivo CSV a la tabla de destino
Para ejecutar el comando `cqlsh COPY FROM`, complete los siguientes pasos.
1. Conéctese a Amazon Keyspaces con cqlsh.
1. Elija su espacio de claves con el siguiente código.
```
USE catalog;
```
1. Establezca la coherencia de escritura en `LOCAL_QUORUM`. Para garantizar la durabilidad de los datos, Amazon Keyspaces no permite otras configuraciones de coherencia de escritura. Consulte el código siguiente.
```
CONSISTENCY LOCAL_QUORUM;
```
1. Prepare su sintaxis de `cqlsh COPY FROM` utilizando el siguiente ejemplo de código.
```
COPY book_awards FROM './keyspace.table.csv' WITH HEADER=true
AND INGESTRATE=calculated ingestrate
AND NUMPROCESSES=calculated numprocess
AND MAXBATCHSIZE=20
AND CHUNKSIZE=calculated chunksize;
```
1. Ejecute la instrucción preparada en el paso anterior. cqlsh le devuelve un eco con todos los ajustes que haya configurado.
1. Asegúrese de que los ajustes coincidan con los que ha introducido. Consulte el siguiente ejemplo.
```
Reading options from the command line: {'chunksize': '120', 'header': 'true', 'ingestrate': '36000', 'numprocesses': '15', 'maxbatchsize': '20'}
Using 15 child processes
```
1. Revise el número de filas transferidas y la tasa media actual, como se muestra en el siguiente ejemplo.
```
Processed: 57834 rows; Rate: 6561 rows/s; Avg. rate: 31751 rows/s
```
1. Cuando cqlsh haya terminado de cargar los datos, revise el resumen de las estadísticas de carga de datos (el número de archivos leídos, el tiempo de ejecución y las filas omitidas), como se muestra en el siguiente ejemplo.
```
15556824 rows imported from 1 files in 8 minutes and 8.321 seconds (0 skipped).
```
En este último paso del tutorial, ha cargado los datos en Amazon Keyspaces.
**importante**
Ahora que ha transferido los datos, ajuste la configuración de modo de capacidad de su tabla de destino para que coincida con los patrones de tráfico habituales de su aplicación. Incurrirá en cargos según la tarifa horaria de su capacidad aprovisionada hasta que la modifique.
# Resolución de problemas
Una vez finalizada la carga de datos, compruebe si se han omitido filas. Para ello, navegue hasta el directorio de origen del archivo CSV de origen y busque un archivo con el siguiente nombre.
```
import_yourcsvfilename.err.timestamp.csv
```
cqlsh escribe las filas de datos omitidas en un archivo con ese nombre. Si el archivo existe en su directorio de origen y contiene datos, estas filas no se cargaron en Amazon Keyspaces. Para reintentar estas filas, compruebe primero si se ha producido algún error durante la carga y ajuste los datos en consecuencia. Para reintentar estas filas, puede volver a ejecutar el proceso.
**Errores comunes**
Los motivos más comunes por los que no se cargan las filas son errores de capacidad y errores de análisis sintáctico.
**Errores de solicitud no válida al cargar datos en Amazon Keyspaces**
En el siguiente ejemplo, la tabla de origen contiene una columna de contador, lo que da lugar a llamadas por lotes registradas con el comando `COPY` de cqlsh. Amazon Keyspaces no admite llamadas por lotes registradas.
```
Failed to import 10 rows: InvalidRequest - Error from server: code=2200 [Invalid query] message=“Only UNLOGGED Batches are supported at this time.“, will retry later, attempt 22 of 25
```
Para resolver este error, usa DSBulk para migrar los datos. Para obtener más información, consulte [Tutorial: Carga de datos en Amazon Keyspaces mediante DSBulk](dsbulk-upload.md).
**Errores del analizador de sintaxis al cargar datos en Amazon Keyspaces**
El siguiente ejemplo muestra una fila omitida debido a un `ParseError`.
```
Failed to import 1 rows: ParseError - Invalid ... –
```
Para resolver este error, debe asegurarse de que los datos que se vayan a importar coincidan con el esquema de la tabla en Amazon Keyspaces. Revise el archivo de importación en busca de errores de análisis sintáctico. Puede intentar utilizar una única fila de datos mediante una instrucción `INSERT` para aislar el error.
**Errores de capacidad al cargar datos en Amazon Keyspaces**
```
Failed to import 1 rows: WriteTimeout - Error from server: code=1100 [Coordinator node timed out waiting for replica nodes' responses]
message="Operation timed out - received only 0 responses." info={'received_responses': 0, 'required_responses': 2, 'write_type': 'SIMPLE', 'consistency':
'LOCAL_QUORUM'}, will retry later, attempt 1 of 100
```
Amazon Keyspaces utiliza las excepciones `ReadTimeout` y `WriteTimeout` para indicar cuándo falla una solicitud de escritura debido a una capacidad de rendimiento insuficiente. Para ayudar a diagnosticar las excepciones de capacidad insuficiente, Amazon Keyspaces publica `WriteThrottleEvents` y elabora `ReadThrottledEvents` métricas en Amazon. CloudWatch Para obtener más información, consulte [Supervisión de Amazon Keyspaces con Amazon CloudWatch](monitoring-cloudwatch.md).
**Errores de cqlsh al cargar datos en Amazon Keyspaces**
Como ayuda para solucionar los errores de cqlsh, vuelva a ejecutar el comando que falla con la bandera `--debug`.
En caso de utilizar una versión incompatible de cqlsh, verá el siguiente error.
```
AttributeError: 'NoneType' object has no attribute 'is_up'
Failed to import 3 rows: AttributeError - 'NoneType' object has no attribute 'is_up', given up after 1 attempts
```
Confirme que la versión de cqlsh instalada sea correcta; para ello, ejecute el siguiente comando.
```
cqlsh --version
```
Debería ver algo similar a lo siguiente como salida.
```
cqlsh 5.0.1
```
Si utiliza Windows, sustituya todas las instancias de `cqlsh` con `cqlsh.bat`. Por ejemplo, para comprobar la versión de cqlsh en Windows, ejecute el siguiente comando.
```
cqlsh.bat --version
```
La conexión a Amazon Keyspaces falla una vez que el cliente cqlsh recibe tres errores consecutivos de cualquier tipo procedentes del servidor. El cliente cqlsh falla con el siguiente mensaje.
```
Failed to import 1 rows: NoHostAvailable - , will retry later, attempt 3 of 100
```
Para resolver este error, debe asegurarse de que los datos que se vayan a importar coincidan con el esquema de la tabla en Amazon Keyspaces. Revise el archivo de importación en busca de errores de análisis sintáctico. Puede intentar utilizar una única fila de datos mediante una instrucción INSERT para aislar el error.
El cliente intentará restablecer la conexión de forma automática.
# Tutorial: Carga de datos en Amazon Keyspaces mediante DSBulk
Este step-by-step tutorial le guía a través de la migración de datos de Apache Cassandra a Amazon Keyspaces mediante DataStax Bulk Loader () DSBulk disponible en. [GitHub](https://github.com/datastax/dsbulk.git) Su uso DSBulk es útil para cargar conjuntos de datos a Amazon Keyspaces con fines académicos o de prueba. Para obtener más información acerca de cómo migrar cargas de trabajo de producción, consulte [Proceso de migración sin conexión: de Apache Cassandra a Amazon Keyspaces](migrating-offline.md). En este tutorial, completará los siguientes pasos:
Requisitos previos: configurar una AWS cuenta con credenciales, crear un archivo de almacenamiento de confianza de JKS para el certificado, configurar`cqlsh`, descargar e instalar DSBulk y configurar un archivo. `application.conf`
1. **Creación del CSV de origen y la tabla de destino**: prepare un archivo CSV como datos de origen y cree el espacio de claves y la tabla de destino en Amazon Keyspaces.
1. **Preparación de los datos**: asigne al azar los datos del archivo CSV y analícelos para determinar el tamaño medio y máximo de las filas.
1. **Defina la capacidad de rendimiento**: calcule las unidades de capacidad de escritura necesarias (WCUs) en función del tamaño de los datos y el tiempo de carga deseado, y configure la capacidad aprovisionada de la tabla.
1. **Configure los DSBulk ajustes**: cree un archivo de DSBulk configuración con parámetros como la autenticación, el SSL/TLS, el nivel de coherencia y el tamaño del grupo de conexiones.
1. **Ejecute el comando DSBulk load**: ejecute el comando DSBulk load para cargar los datos del archivo CSV a la tabla Amazon Keyspaces y monitorizar el progreso.
**Topics**
+ [Requisitos previos: los pasos que debes completar antes de poder cargar datos con DSBulk](dsbulk-upload-prequs.md)
+ [Paso 1: Cree el archivo CSV de origen y una tabla de destino para la carga de datos mediante DSBulk](dsbulk-upload-source.md)
+ [Paso 2: Prepare los datos para cargarlos mediante DSBulk](dsbulk-upload-prepare-data.md)
+ [Paso 3: establecimiento de la capacidad de rendimiento de la tabla de destino](dsbulk-upload-capacity.md)
+ [Paso 4: configuración de los ajustes de `DSBulk` para cargar los datos del archivo CSV a la tabla de destino](dsbulk-upload-config.md)
+ [Paso 5: ejecución del comando DSBulk `load` para cargar los datos del archivo CSV a la tabla de destino](dsbulk-upload-run.md)
# Requisitos previos: los pasos que debes completar antes de poder cargar datos con DSBulk
Para poder comenzar el tutorial, antes debe completar las siguientes tareas.
1. Si aún no lo ha hecho, registre una AWS cuenta siguiendo los pasos que se indican en[Con AWS Identity and Access Management figuración](accessing.md#SettingUp.IAM).
1. Cree las credenciales; para ello, siga los pasos indicados en [Creación y configuración de AWS credenciales para Amazon Keyspaces](access.credentials.md).
1. Cree un archivo de almacén de confianza de JKS.
1. Descargue los siguientes certificados digitales y guarde los archivos localmente o en su directorio personal.
1. AmazonRootCA1
1. AmazonRootCA2
1. AmazonRootCA3
1. AmazonRootCA4
1. Starfield Class 2 Root (opcional, para compatibilidad con versiones anteriores)
Para descargar los certificados, puede usar los siguientes comandos.
```
curl -O https://www.amazontrust.com/repository/AmazonRootCA1.pem
curl -O https://www.amazontrust.com/repository/AmazonRootCA2.pem
curl -O https://www.amazontrust.com/repository/AmazonRootCA3.pem
curl -O https://www.amazontrust.com/repository/AmazonRootCA4.pem
curl -O https://certs.secureserver.net/repository/sf-class2-root.crt
```
**nota**
Anteriormente, Amazon Keyspaces utilizaba certificados TLS anclados a la CA de clase 2 de Starfield. AWS está migrando todo Regiones de AWS a certificados emitidos bajo Amazon Trust Services (Amazon Root CAs 1—4). Durante esta transición, configure los clientes para que confíen tanto en la raíz CAs 1—4 de Amazon como en la raíz de Starfield para garantizar la compatibilidad en todas las regiones.
1. Convierta los certificados digitales en archivos TrustStore y agréguelos al almacén de claves.
```
openssl x509 -outform der -in AmazonRootCA1.pem -out temp_file.der
keytool -import -alias amazon-root-ca-1 -keystore cassandra_truststore.jks -file temp_file.der
openssl x509 -outform der -in AmazonRootCA2.pem -out temp_file.der
keytool -import -alias amazon-root-ca-2 -keystore cassandra_truststore.jks -file temp_file.der
openssl x509 -outform der -in AmazonRootCA3.pem -out temp_file.der
keytool -import -alias amazon-root-ca-3 -keystore cassandra_truststore.jks -file temp_file.der
openssl x509 -outform der -in AmazonRootCA4.pem -out temp_file.der
keytool -import -alias amazon-root-ca-4 -keystore cassandra_truststore.jks -file temp_file.der
openssl x509 -outform der -in sf-class2-root.crt -out temp_file.der
keytool -import -alias cassandra -keystore cassandra_truststore.jks -file temp_file.der
```
En el último paso, debe crear una contraseña para el almacén de claves y confiar en cada certificado. El comando interactivo tiene el siguiente aspecto.
```
Enter keystore password:
Re-enter new password:
Owner: CN=Amazon Root CA 1, O=Amazon, C=US
Issuer: CN=Amazon Root CA 1, O=Amazon, C=US
Serial number: 66c9fcf99bf8c0a39e2f0788a43e696365bca
Valid from: Tue May 26 00:00:00 UTC 2015 until: Sun Jan 17 00:00:00 UTC 2038
Certificate fingerprints:
SHA1: 8D:A7:F9:65:EC:5E:FC:37:91:0F:1C:6E:59:FD:C1:CC:6A:6E:DE:16
SHA256: 8E:CD:E6:88:4F:3D:87:B1:12:5B:A3:1A:C3:FC:B1:3D:70:16:DE:7F:57:CC:90:4F:E1:CB:97:C6:AE:98:19:6E
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]
#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Key_CertSign
Crl_Sign
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 84 18 CC 85 34 EC BC 0C 94 94 2E 08 59 9C C7 B2 ....4.......Y...
0010: 10 4E 0A 08 .N..
]
]
Trust this certificate? [no]: yes
Certificate was added to keystore
Enter keystore password:
Owner: CN=Amazon Root CA 2, O=Amazon, C=US
Issuer: CN=Amazon Root CA 2, O=Amazon, C=US
Serial number: 66c9fd29635869f0a0fe58678f85b26bb8a37
Valid from: Tue May 26 00:00:00 UTC 2015 until: Sat May 26 00:00:00 UTC 2040
Certificate fingerprints:
SHA1: 5A:8C:EF:45:D7:A6:98:59:76:7A:8C:8B:44:96:B5:78:CF:47:4B:1A
SHA256: 1B:A5:B2:AA:8C:65:40:1A:82:96:01:18:F8:0B:EC:4F:62:30:4D:83:CE:C4:71:3A:19:C3:9C:01:1E:A4:6D:B4
Signature algorithm name: SHA384withRSA
Subject Public Key Algorithm: 4096-bit RSA key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]
#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Key_CertSign
Crl_Sign
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: B0 0C F0 4C 30 F4 05 58 02 48 FD 33 E5 52 AF 4B ...L0..X.H.3.R.K
0010: 84 E3 66 52 ..fR
]
]
Trust this certificate? [no]: yes
Certificate was added to keystore
Enter keystore password:
Owner: CN=Amazon Root CA 3, O=Amazon, C=US
Issuer: CN=Amazon Root CA 3, O=Amazon, C=US
Serial number: 66c9fd5749736663f3b0b9ad9e89e7603f24a
Valid from: Tue May 26 00:00:00 UTC 2015 until: Sat May 26 00:00:00 UTC 2040
Certificate fingerprints:
SHA1: 0D:44:DD:8C:3C:8C:1A:1A:58:75:64:81:E9:0F:2E:2A:FF:B3:D2:6E
SHA256: 18:CE:6C:FE:7B:F1:4E:60:B2:E3:47:B8:DF:E8:68:CB:31:D0:2E:BB:3A:DA:27:15:69:F5:03:43:B4:6D:B3:A4
Signature algorithm name: SHA256withECDSA
Subject Public Key Algorithm: 256-bit EC (secp256r1) key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]
#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Key_CertSign
Crl_Sign
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: AB B6 DB D7 06 9E 37 AC 30 86 07 91 70 C7 9C C4 ......7.0...p...
0010: 19 B1 78 C0 ..x.
]
]
Trust this certificate? [no]: yes
Certificate was added to keystore
Enter keystore password:
Owner: CN=Amazon Root CA 4, O=Amazon, C=US
Issuer: CN=Amazon Root CA 4, O=Amazon, C=US
Serial number: 66c9fd7c1bb104c2943e5717b7b2cc81ac10e
Valid from: Tue May 26 00:00:00 UTC 2015 until: Sat May 26 00:00:00 UTC 2040
Certificate fingerprints:
SHA1: F6:10:84:07:D6:F8:BB:67:98:0C:C2:E2:44:C2:EB:AE:1C:EF:63:BE
SHA256: E3:5D:28:41:9E:D0:20:25:CF:A6:90:38:CD:62:39:62:45:8D:A5:C6:95:FB:DE:A3:C2:2B:0B:FB:25:89:70:92
Signature algorithm name: SHA384withECDSA
Subject Public Key Algorithm: 384-bit EC (secp384r1) key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]
#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Key_CertSign
Crl_Sign
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: D3 EC C7 3A 65 6E CC E1 DA 76 9A 56 FB 9C F3 86 ...:en...v.V....
0010: 6D 57 E5 81 mW..
]
]
Trust this certificate? [no]: yes
Certificate was added to keystore
Enter keystore password:
Owner: OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US
Issuer: OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US
Serial number: 0
Valid from: Tue Jun 29 17:39:16 UTC 2004 until: Thu Jun 29 17:39:16 UTC 2034
Certificate fingerprints:
SHA1: AD:7E:1C:28:B0:64:EF:8F:60:03:40:20:14:C3:D0:E3:37:0E:B5:8A
SHA256: 14:65:FA:20:53:97:B8:76:FA:A6:F0:A9:95:8E:55:90:E4:0F:CC:7F:AA:4F:B7:C2:C8:67:75:21:FB:5F:B6:58
Signature algorithm name: SHA1withRSA (weak)
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: BF 5F B7 D1 CE DD 1F 86 F4 5B 55 AC DC D7 10 C2 ._.......[U.....
0010: 0E A9 88 E7 ....
]
[OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US]
SerialNumber: [ 00]
]
#2: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:true
PathLen:2147483647
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: BF 5F B7 D1 CE DD 1F 86 F4 5B 55 AC DC D7 10 C2 ._.......[U.....
0010: 0E A9 88 E7 ....
]
]
Warning:
The input uses the SHA1withRSA signature algorithm which is considered a security risk. This algorithm will be disabled in a future update.
Trust this certificate? [no]: yes
Certificate was added to keystore
```
1. Configure la conexión del intérprete de comandos de Cassandra Query Language (cqlsh) y confirme que puede conectarse a Amazon Keyspaces siguiendo los pasos indicados en [Uso de `cqlsh` para conectarse a Amazon Keyspaces](programmatic.cqlsh.md).
1. Descarga e instala DSBulk.
**nota**
Es posible que la versión que se muestra en este tutorial no sea la última disponible. Antes de realizar la descarga DSBulk, consulte la [página de descarga de DataStax Bulk Loader](https://downloads.datastax.com/#bulk-loader) para ver la versión más reciente y actualice el número de versión en los siguientes comandos según corresponda.
1. Para descargar DSBulk, puede usar el siguiente código.
```
curl -OL https://downloads.datastax.com/dsbulk/dsbulk-1.8.0.tar.gz
```
1. A continuación, descomprima el archivo tar y DSBulk agréguelo al suyo `PATH` como se muestra en el siguiente ejemplo.
```
tar -zxvf dsbulk-1.8.0.tar.gz
# add the DSBulk directory to the path
export PATH=$PATH:./dsbulk-1.8.0/bin
```
1. Cree un `application.conf` archivo para almacenar la configuración que utilizará. DSBulk Puede guardar el siguiente ejemplo como `./dsbulk_keyspaces.conf`. Sustituya `localhost` por el punto de contacto de su clúster local de Cassandra si no se encuentra en el nodo local, por ejemplo, el nombre DNS o la dirección IP. Tome nota del nombre del archivo y de la ruta, dado que deberá especificarlos más adelante en el comando `dsbulk load`.
```
datastax-java-driver {
basic.contact-points = [ "localhost"]
advanced.auth-provider {
class = software.aws.mcs.auth.SigV4AuthProvider
aws-region = us-east-1
}
}
```
1. Para habilitar la compatibilidad con SiGv4, descargue el `jar` archivo sombreado [GitHub](https://github.com/aws/aws-sigv4-auth-cassandra-java-driver-plugin/releases/)y colóquelo en la DSBulk `lib` carpeta, como se muestra en el siguiente ejemplo.
```
curl -O -L https://github.com/aws/aws-sigv4-auth-cassandra-java-driver-plugin/releases/download/4.0.6-shaded-v2/aws-sigv4-auth-cassandra-java-driver-plugin-4.0.6-shaded.jar
```
# Paso 1: Cree el archivo CSV de origen y una tabla de destino para la carga de datos mediante DSBulk
En este tutorial, utilizamos un archivo de valores separados por comas (CSV) llamado `keyspaces_sample_table.csv` como archivo de origen para la migración de datos. El archivo de ejemplo proporcionado contiene algunas filas de datos de una tabla llamada `book_awards`.
1. Cree el archivo de origen. Puede elegir una de las siguientes opciones:
+ Descargue el archivo CSV de ejemplo (`keyspaces_sample_table.csv`), contenido en el siguiente archivo comprimido: [samplemigration.zip](samples/samplemigration.zip). Descomprima el archivo y tome nota de la ruta a `keyspaces_sample_table.csv`.
+ Para rellenar un archivo CSV de origen con sus propios datos almacenados en una base de datos de Apache Cassandra, utilice `dsbulk unload`, como se muestra en el siguiente ejemplo.
```
dsbulk unload -k mykeyspace -t mytable -f ./my_application.conf > keyspaces_sample_table.csv
```
Asegúrese de que el archivo CSV que cree satisfaga los siguientes requisitos:
+ La primera fila contiene los nombres de las columnas.
+ Los nombres de las columnas del archivo CSV de origen coinciden con los nombres de las columnas de la tabla de destino.
+ Los datos están delimitados con una coma.
+ Todos los valores de los datos son tipos de datos válidos de Amazon Keyspaces. Consulte [Tipos de datos](cql.elements.md#cql.data-types).
1. Cree el espacio de claves y la tabla de destino en Amazon Keyspaces.
1. Conéctese a Amazon Keyspaces con `cqlsh` y sustituya el punto de conexión del servicio, el nombre de usuario y la contraseña del siguiente ejemplo por sus propios valores.
```
cqlsh cassandra.us-east-1.amazonaws.com 9142 -u "111122223333" -p "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" --ssl
```
1. Cree un nuevo espacio de claves con el nombre `catalog` como se muestra en el siguiente ejemplo.
```
CREATE KEYSPACE catalog WITH REPLICATION = {'class': 'SingleRegionStrategy'};
```
1. Una vez que el nuevo espacio de claves tenga el estado de disponible, utilice el siguiente código para crear la tabla de destino `book_awards`. Para obtener más información sobre la creación asíncrona de recursos y cómo comprobar si un recurso está disponible, consulte [Comprobación del estado de creación de los espacios de claves en Amazon Keyspaces](keyspaces-create.md).
```
CREATE TABLE catalog.book_awards (
year int,
award text,
rank int,
category text,
book_title text,
author text,
publisher text,
PRIMARY KEY ((year, award), category, rank)
);
```
Si Apache Cassandra es su origen de datos, una forma sencilla de crear la tabla de destino de Amazon Keyspaces con encabezados que coincidan es generar la instrucción `CREATE TABLE` a partir de la tabla de origen, como se muestra en la siguiente instrucción.
```
cqlsh localhost 9042 -u "username" -p "password" --execute "DESCRIBE TABLE mykeyspace.mytable;"
```
A continuación, cree la tabla de destino en Amazon Keyspaces con los nombres de las columnas y los tipos de datos que coincidan con la descripción de la tabla de origen de Cassandra.
# Paso 2: Prepare los datos para cargarlos mediante DSBulk
La preparación de los datos de origen para una transferencia eficaz es un proceso de dos pasos. En primer lugar, usted aleatoriza los datos. En segundo lugar, usted analiza los datos para determinar los valores apropiados de los parámetros de `dsbulk` y los ajustes necesarios de la tabla.
**Aleatorización de los datos**
El comando `dsbulk` lee y escribe los datos en el mismo orden en que aparecen en el archivo CSV. Si utiliza el comando `dsbulk` para crear el archivo de origen, los datos se escriben en el orden en que aparecen ordenados por claves en el CSV. Internamente, Amazon Keyspaces divide los datos utilizando claves de partición. Si bien Amazon Keyspaces tiene una lógica integrada para ayudar a equilibrar la carga de las solicitudes de la misma clave de partición, la carga de datos es más rápida y eficiente si aleatoriza el orden. Esto se debe a que puede aprovechar el equilibrio de carga integrado que se produce cuando Amazon Keyspaces escribe en diferentes particiones.
Para repartir las escrituras entre las particiones de manera uniforme, debe aleatorizar los datos en el archivo de origen. Puede escribir una aplicación para hacerlo o utilizar una herramienta de código abierto, como [Shuf](https://en.wikipedia.org/wiki/Shuf). Shuf está disponible de forma gratuita en distribuciones Linux, en macOS (instalando coreutils en [homebrew](https://brew.sh)) y en Windows (utilizando Windows Subsystem for Linux [WSL]). Se requiere un paso adicional para evitar que la fila del encabezado con los nombres de las columnas se baraje en este paso.
Para aleatorizar el archivo de origen conservando el encabezado, introduzca el siguiente código.
```
tail -n +2 keyspaces_sample_table.csv | shuf -o keyspace.table.csv && (head -1 keyspaces_sample_table.csv && cat keyspace.table.csv ) > keyspace.table.csv1 && mv keyspace.table.csv1 keyspace.table.csv
```
Shuf reescribe los datos en un nuevo archivo CSV llamado `keyspace.table.csv`. Ahora puede eliminar el archivo `keyspaces_sample_table.csv`, dado que ya no lo necesita.
**Análisis de los datos**
Determine el tamaño medio y máximo de las filas analizando los datos.
Debe hacerlo por las siguientes razones:
+ El tamaño medio de fila ayuda a estimar la cantidad total de datos que se van a transferir.
+ Necesita el tamaño medio de fila para aprovisionar la capacidad de escritura necesaria para la carga de datos.
+ Puede asegurarse de que cada fila tenga un tamaño inferior a 1 MB, que es el tamaño máximo de fila en Amazon Keyspaces.
**nota**
Esta cuota se refiere al tamaño de fila, no al de la partición. A diferencia de las particiones de Apache Cassandra, las particiones de Amazon Keyspaces pueden tener un tamaño prácticamente ilimitado. Las claves de partición y las columnas de agrupación requieren almacenamiento adicional para los metadatos, que debe añadir al tamaño bruto de las filas. Para obtener más información, consulte [Estimación del tamaño de las filas en Amazon Keyspaces](calculating-row-size.md).
El siguiente código utiliza [AWK](https://en.wikipedia.org/wiki/AWK) para analizar un archivo CSV e imprimir el tamaño medio y máximo de las filas.
```
awk -F, 'BEGIN {samp=10000;max=-1;}{if(NR>1){len=length($0);t+=len;avg=t/NR;max=(len>max ? len : max)}}NR==samp{exit}END{printf("{lines: %d, average: %d bytes, max: %d bytes}\n",NR,avg,max);}' keyspace.table.csv
```
La ejecución de este código da como resultado la siguiente salida.
```
using 10,000 samples:
{lines: 10000, avg: 123 bytes, max: 225 bytes}
```
Asegúrese de que el tamaño máximo de su fila no supere 1 MB. De ser así, debe dividir la fila o comprimir los datos para que el tamaño de la fila sea inferior a 1 MB. En el siguiente paso de este tutorial, usted utiliza el tamaño medio de fila para aprovisionar la capacidad de escritura de la tabla.
# Paso 3: establecimiento de la capacidad de rendimiento de la tabla de destino
Este tutorial le muestra cómo ajustar la carga DSBulk de datos dentro de un rango de tiempo establecido. Dado que sabe de antemano cuántas lecturas y escrituras realiza, utilice el modo de capacidad aprovisionada. Una vez finalizada la transferencia de datos, debe ajustar el modo de capacidad de la tabla para que se adapte a los patrones de tráfico de su aplicación. Para obtener más información sobre administración de capacidad, consulte [Administración de recursos sin servidor en Amazon Keyspaces (para Apache Cassandra)](serverless_resource_management.md).
Con el modo de capacidad aprovisionada, usted especifica con antelación cuánta capacidad de lectura y escritura desea aprovisionar a su tabla. La capacidad de escritura se factura por hora y se mide en unidades de capacidad de escritura ()WCUs. Cada WCU es capacidad de escritura suficiente para admitir la escritura de 1 KB de datos por segundo. Al cargar los datos, la velocidad de escritura debe estar por debajo del máximo WCUs (parámetro:`write_capacity_units`) establecido en la tabla de destino.
De forma predeterminada, puedes aprovisionar WCUs hasta 40 000 en una tabla y 80 000 WCUs en todas las tablas de tu cuenta. Si necesita capacidad adicional, puede solicitar un aumento de cuota en la consola de [Service Quotas](https://console.aws.amazon.com/servicequotas/home#!/services/cassandra/quotas). Para obtener más información sobre las cuotas, consulte [Cuotas para Amazon Keyspaces (para Apache Cassandra)](quotas.md).
**Calcula la cantidad media WCUs necesaria para un encarte**
Insertar 1 KB de datos por segundo requiere 1 WCU. Si su archivo CSV tiene 360 000 filas y quiere cargar todos los datos en 1 hora, debe escribir 100 filas por segundo (360 000 filas / 60 minutos / 60 segundos = 100 filas por segundo). Si cada fila tiene hasta 1 KB de datos, para insertar 100 filas por segundo, debe aprovisionar 100 WCUs a la tabla. Si cada fila tiene 1,5 KB de datos, necesitará dos WCUs para insertar una fila por segundo. Por lo tanto, para insertar 100 filas por segundo, debe aprovisionar 200 WCUs.
Para determinar cuántas filas WCUs necesita insertar una fila por segundo, divida el tamaño medio de las filas en bytes entre 1024 y redondee al número entero más cercano.
Por ejemplo, si el tamaño medio de una fila es de 3000 bytes, necesitará tres WCUs para insertar una fila por segundo.
```
ROUNDUP(3000 / 1024) = ROUNDUP(2.93) = 3 WCUs
```
**Cálculo de capacidad y tiempo de carga de datos**
Ahora que conoce el tamaño y el número promedio de filas del archivo CSV, puede calcular cuántas WCUs necesita para cargar los datos en un período de tiempo determinado y el tiempo aproximado que se tarda en cargar todos los datos del archivo CSV con diferentes configuraciones de WCU.
Por ejemplo, si cada fila del archivo ocupa 1 KB y tiene 1 000 000 de filas en el archivo CSV, para cargar los datos en 1 hora, debe aprovisionar al menos 278 WCUs a la tabla para esa hora.
```
1,000,000 rows * 1 KBs = 1,000,000 KBs
1,000,000 KBs / 3600 seconds =277.8 KBs / second = 278 WCUs
```
**Configuración de los ajustes de capacidad aprovisionada**
Puede configurar los ajustes de capacidad de escritura de una tabla al crearla o mediante el comando `ALTER TABLE`. A continuación se muestra la sintaxis para modificar los ajustes de capacidad aprovisionada de una tabla con el comando `ALTER TABLE`.
```
ALTER TABLE catalog.book_awards WITH custom_properties={'capacity_mode':{'throughput_mode': 'PROVISIONED', 'read_capacity_units': 100, 'write_capacity_units': 278}} ;
```
Para ver la referencia completa del lenguaje, consulte [CREATE TABLE](cql.ddl.table.md#cql.ddl.table.create) y [ALTER TABLE](cql.ddl.table.md#cql.ddl.table.alter).
# Paso 4: configuración de los ajustes de `DSBulk` para cargar los datos del archivo CSV a la tabla de destino
En esta sección se describen los pasos necesarios DSBulk para configurar la carga de datos en Amazon Keyspaces. La configuración se DSBulk realiza mediante un archivo de configuración. Puede especificar el archivo de configuración directamente desde la línea de comandos.
1. Cree un archivo de DSBulk configuración para la migración a Amazon Keyspaces; en este ejemplo, utilizamos el nombre del archivo. `dsbulk_keyspaces.conf` Especifique los siguientes ajustes en el archivo de DSBulk configuración.
1. *`PlainTextAuthProvider`*: cree el proveedor de autenticación con la clase `PlainTextAuthProvider`. `ServiceUserName` y `ServicePassword` deben coincidir con el nombre de usuario y la contraseña que obtuvo al generar las credenciales específicas del servicio siguiendo los pasos en [Creación de credenciales para el acceso programático a Amazon Keyspaces](programmatic.credentials.md).
1. *`local-datacenter`*— Defina el valor `local-datacenter` al valor al Región de AWS que se está conectando. Por ejemplo, si la aplicación se conecta a `cassandra.us-east-1.amazonaws.com`, entonces establezca el centro de datos local en `us-east-1`. Para ver todas las opciones disponibles Regiones de AWS, consulte[Puntos de conexión de servicio para Amazon Keyspaces](programmatic.endpoints.md). Para evitar réplicas, establezca `slow-replica-avoidance` en `false`.
1. *`SSLEngineFactory`*: para configurar SSL/TLS, inicialice la `SSLEngineFactory` añadiendo una sección en el archivo de configuración con una sola línea que especifique la clase con `class = DefaultSslEngineFactory`. Proporcione la ruta a `cassandra_truststore.jks` y la contraseña que creó anteriormente.
1. *`consistency`*: establezca el nivel de coherencia en `LOCAL QUORUM`. No se admiten otros niveles de coherencia de escritura. Para obtener más información consulte [Niveles de coherencia de lectura y escritura de Apache Cassandra admitidos y costos asociados](consistency.md).
1. El número de conexiones por grupo es configurable en el controlador Java. Para este ejemplo, establezca `advanced.connection.pool.local.size` en 3.
A continuación se muestra el archivo de configuración de ejemplo completo.
```
datastax-java-driver {
basic.contact-points = [ "cassandra.us-east-1.amazonaws.com:9142"]
advanced.auth-provider {
class = PlainTextAuthProvider
username = "ServiceUserName"
password = "ServicePassword"
}
basic.load-balancing-policy {
local-datacenter = "us-east-1"
slow-replica-avoidance = false
}
basic.request {
consistency = LOCAL_QUORUM
default-idempotence = true
}
advanced.ssl-engine-factory {
class = DefaultSslEngineFactory
truststore-path = "./cassandra_truststore.jks"
truststore-password = "my_password"
hostname-validation = false
}
advanced.connection.pool.local.size = 3
}
```
1. Revise los parámetros del DSBulk `load` comando.
1. *`executor.maxPerSecond`*: el número máximo de filas que el comando de carga intenta procesar concurrentemente por segundo. Si no se establece, este parámetro se deshabilita con -1.
`executor.maxPerSecond`Configúrelo en función del número de los WCUs que haya aprovisionado en la tabla de destino de destino. El valor `executor.maxPerSecond` del comando `load` no es un límite, es una media objetivo. Esto significa que puede (y a menudo lo hace) dispararse por encima del número que usted fije. Para tener en cuenta los picos y asegurarse de que exista capacidad suficiente para gestionar las solicitudes de carga de datos, establezca `executor.maxPerSecond` en el 90 % de la capacidad de escritura de la tabla.
```
executor.maxPerSecond = WCUs * .90
```
En este tutorial, establecemos `executor.maxPerSecond` en 5.
**nota**
Si utiliza la DSBulk versión 1.6.0 o una versión superior, puede `dsbulk.engine.maxConcurrentQueries` utilizarla en su lugar.
1. Configure estos parámetros adicionales para el DSBulk `load` comando.
+ *`batch-mode`*: este parámetro indica al sistema que agrupe las operaciones por clave de partición. Recomendamos deshabilitar el modo por lotes, ya que puede provocar situaciones de sobrecarga de claves y provocar `WriteThrottleEvents`.
+ *`driver.advanced.retry-policy-max-retries`*: determina cuántas veces se debe reintentar una consulta fallida. Si no se establece, el valor predeterminado es 10. Puede ajustar este valor según sea necesario.
+ *`driver.basic.request.timeout`*: el tiempo en minutos que el sistema espera el regreso de una consulta. Si no se establece, el valor predeterminado es “5 minutos”. Puede ajustar este valor según sea necesario.
# Paso 5: ejecución del comando DSBulk `load` para cargar los datos del archivo CSV a la tabla de destino
En el último paso de este tutorial, cargará los datos en Amazon Keyspaces.
Para ejecutar el comando DSBulk `load`, complete los siguientes pasos.
1. Ejecute el siguiente código para cargar los datos de su archivo csv en su tabla de Amazon Keyspaces. Asegúrese de actualizar la ruta al archivo de configuración de la aplicación que creó anteriormente.
```
dsbulk load -f ./dsbulk_keyspaces.conf --connector.csv.url keyspace.table.csv -header true --batch.mode DISABLED --executor.maxPerSecond 5 --driver.basic.request.timeout "5 minutes" --driver.advanced.retry-policy.max-retries 10 -k catalog -t book_awards
```
1. La salida incluye la ubicación de un archivo de registro que detalla las operaciones exitosas y fallidas. El archivo se almacena en el siguiente directorio.
```
Operation directory: /home/user_name/logs/UNLOAD_20210308-202317-801911
```
1. Las entradas del archivo de registro incluirán métricas, como se muestra en el siguiente ejemplo. Compruebe que el número de filas sea coherente con el número de filas de su archivo csv.
```
total | failed | rows/s | p50ms | p99ms | p999ms
200 | 0 | 200 | 21.63 | 21.89 | 21.89
```
**importante**
Ahora que ha transferido los datos, ajuste la configuración de modo de capacidad de su tabla de destino para que coincida con los patrones de tráfico habituales de su aplicación. Incurrirá en cargos según la tarifa horaria de su capacidad aprovisionada hasta que la modifique. Para obtener más información, consulte [Configurar los modos de read/write capacidad en Amazon Keyspaces](ReadWriteCapacityMode.md).