Prácticas recomendadas sobre la carga masiva

Esta página proporciona lineamientos para la carga masiva de grandes volúmenes de datos en Spanner.

Tienes varias opciones para cargar datos de forma masiva en Spanner:

Si bien también puedes insertar filas con Google Cloud CLI, no te recomendamos que uses la CLI de gcloud para la carga masiva.

Lineamientos de rendimiento para la carga masiva

Para lograr un rendimiento óptimo de la carga masiva, maximiza el uso de particiones para distribuir la escritura de los datos entre las tareas del trabajador.

Spanner usa la división basada en la carga para distribuir de manera uniforme la carga de datos entre los recursos de procesamiento de la instancia. Después de unos minutos de carga alta, Spanner presenta límites de división entre filas. En general, si la carga de datos está bien distribuida y sigues las prácticas recomendadas para el diseño de esquema y la carga masiva, la capacidad de procesamiento de escritura se duplicará cada algunos minutos hasta saturar los recursos de CPU disponibles en tu instancia.

Particiona tus datos por clave primaria

Spanner particiona automáticamente las tablas en rangos más pequeños. El La clave primaria de una fila determina dónde se particiona.

A fin de obtener una capacidad de procesamiento de escritura óptima para cargas masivas, particiona tus datos por clave primaria con este patrón:

  • Cada partición contiene un rango de filas consecutivas, según lo determinan las columnas de claves.
  • Cada confirmación contiene datos para una sola partición.

Recomendamos que la cantidad de particiones sea 10 veces la cantidad de nodos en tu instancia de Spanner. Para asignar filas a las particiones, haz lo siguiente:

  • Ordena tus datos por clave primaria.
  • Divide los datos en 10 x (el número de nodos) separados, con particiones de igual tamaño.
  • Crea y asigna una tarea de trabajo independiente para cada partición. La creación de las tareas de trabajo se realiza en tu aplicación. No es una instancia de Spanner .

Si sigues este patrón, deberías ver una capacidad de procesamiento de escritura masiva general de una máxima de entre 10 y 20 MB por segundo por nodo para cargas grandes.

A medida que cargas datos, Spanner crea y actualiza divisiones para balancear la carga en los nodos de tu instancia. Durante este proceso, es posible que se produzcan disminuciones temporales en la capacidad de procesamiento.

Ejemplo

Tienes una configuración regional con 3 nodos. Tienes 90,000 filas en una tabla no intercalada. Las claves primarias de la tabla varían de 1 a 90,000.

  • Filas: 90,000 filas
  • Nodos: 3
  • Particiones: 10 x 3 = 30
  • Filas por partición: 90,000 / 30 = 3,000.

La primera partición incluye el rango de clave de 1 a 3,000. La segunda partición incluye el intervalo de clave de 3,001 a 6,000. La trigésima partición incluye el rango de clave de 87,001 a 90,000. (No debes usar teclas secuenciales en una tabla grande. Este ejemplo es solo para demostración).

En cada tarea de trabajo se envían las escrituras para una sola partición. Dentro de cada partición, debes escribir las filas de forma secuencial por clave primaria. Escribir filas al azar, con respecto a la clave primaria, también proporciona una capacidad de procesamiento bastante alto. La medición de las ejecuciones de prueba te brindará estadísticas sobre qué enfoque proporciona el mejor rendimiento para el conjunto de datos.

Si decides no usar particiones

Escribir filas aleatorias dentro de una confirmación puede ser más lento que escribir una un conjunto contiguo de filas en una confirmación, y es probable que y particiones. La latencia y la sobrecarga de confirmación son mayores cuando se realizan más divisiones se escribe en una confirmación, debido al aumento de la coordinación entre servidores. Múltiples es probable que las divisiones estén involucradas, ya que cada fila aleatoria podría pertenecer a una división diferente. En el peor de los casos cada operación de escritura involucra cada división en tu instancia. Como se mencionó anteriormente, la capacidad de procesamiento de escritura disminuye cuando se usan más divisiones.

Carga masiva sin particionar

Escribir un conjunto contiguo de filas en una confirmación puede ser más rápido que escribir filas aleatorias. Es probable que las filas aleatorias también incluyan datos de diferentes particiones.

Cuando se escriben más particiones en una confirmación, más coordinación de Cloud, lo que aumenta la latencia de confirmación y la sobrecarga.

Es probable que haya varias particiones, ya que cada fila aleatoria podría pertenecer a una partición diferente. En el peor de los casos, cada escritura involucra cada partición de tu instancia de Spanner. Como se mencionó anteriormente, la capacidad de procesamiento de escritura disminuye cuando hay más particiones.

Evita la sobrecarga

Es posible enviar más solicitudes de escritura de las que Spanner puede enviar o un controlador de políticas. Spanner maneja la sobrecarga mediante la anulación de transacciones; esto se denomina rechazo. Para transacciones de solo escritura, Spanner vuelve a intentar la transacción automáticamente. En esos casos, el rechazo se muestra como una latencia alta. Durante cargas pesadas, el rechazo puede durar hasta un minuto. Durante cargas demasiado pesadas, el rechazo puede tomar varios minutos. Para evitar el rechazo, Deberías limitar las solicitudes de escritura para mantener el uso de CPU dentro límites razonables. Como alternativa, los usuarios pueden aumentar la cantidad de nodos para que el uso de la CPU permanezca dentro de los límites.

Confirma entre 1 MB y 5 MB de mutaciones a la vez

Cada operación de escritura en Spanner contiene una sobrecarga, ya sea grande o pequeña. Para maximizar la capacidad de procesamiento, maximiza la cantidad de datos almacenados por escritura. Las escrituras más grandes reducen la proporción de sobrecarga por escritura. Una buena técnica es para cada confirmación muta cientos de filas. Cuando se escriben filas relativamente grandes, un tamaño de confirmación de 1 MB a 5 MB en general proporciona el mejor rendimiento. Cuando se escriben valores pequeños o valores que se indexan, en general, es mejor escribir como máximo unos cientos de filas en una sola confirmación. Más allá del tamaño del tamaño de la confirmación y la cantidad de filas, ten en cuenta que existe una limitación de 80,000 mutaciones por confirmación. Para determinar el rendimiento óptimo, debes probar y medir la capacidad de procesamiento.

Las confirmaciones superiores a 5 MB o más que unos cientos de filas no proporcionan beneficios adicionales y corren el riesgo de exceder los límites de Spanner sobre el tamaño de las confirmaciones y las mutaciones por confirmación.

Lineamientos para índices secundarios

Si tu base de datos tiene índices secundarios, debes elegir entre agregar los índices al esquema de la base de datos antes o después de cargar los datos de la tabla.

  • Agregar el índice antes de que se carguen los datos permite que el cambio de esquema se complete de inmediato. Sin embargo, cada escritura que afecta al índice lleva más tiempo, ya que también necesita actualizar el índice. Cuando se completa la carga de datos, la base de datos se puede usar de inmediato con todos los índices implementados. Si deseas crear una tabla y sus índices al mismo tiempo, envía a Spanner las instrucciones DDL para la tabla nueva y los nuevos índices en una sola solicitud.

  • Agregar el índice después de cargar los datos significa que cada escritura es eficiente. Sin embargo, el cambio de esquema para cada reabastecimiento de índice puede llevar mucho tiempo. La base de datos no se puede usar por completo, y las consultas no pueden usar los índices hasta que se completen todos los cambios de esquema. La base de datos aún puede entregar operaciones de escritura y consultas, pero a una velocidad más lenta.

Te recomendamos que agregues los índices que son fundamentales para tu aplicación empresarial antes de cargar los datos. Para todos los índices que no sean críticos, agrégalos después de migrar los datos.

Prueba y mide la capacidad de procesamiento

La predicción de la capacidad de procesamiento puede ser difícil. Recomendamos que pruebes la estrategia de carga masiva antes de ejecutar la carga final. Para obtener un ejemplo detallado sobre cómo usar el rendimiento de la partición y la supervisión, consulta la página sobre cómo maximizar la capacidad de carga de datos.

Prácticas recomendadas para la carga masiva periódica en una base de datos existente

Si estás actualizando una base de datos existente que contiene datos, pero no tiene cualquier índice secundario, las recomendaciones de este documento se aplicar.

Si tienes índices secundarios, las instrucciones podrían generar un rendimiento razonable. El rendimiento depende de la cantidad de divisiones, en promedio, que participen en las transacciones. Si la capacidad de procesamiento es demasiado baja, puedes intentar lo siguiente:

  • Incluye una cantidad menor de mutaciones en cada confirmación; esto podría aumentar el rendimiento.
  • Si tu carga es mayor que el tamaño total actual de la tabla que se está actualizando, borra los índices secundarios y vuelve a agregarlos después de subir los datos. Por lo general, este paso no es necesario, pero podría mejorar la capacidad de procesamiento.