En esta página, se proporcionan lineamientos para cargar de manera masiva y eficiente grandes cantidades de datos en Spanner.
Tienes varias opciones para cargar datos de forma masiva a Spanner:
- Inserta filas con el lenguaje de manipulación de datos (DML).
- Inserta filas mediante mutaciones.
- Importa datos con el conector de Dataflow.
- Importa una base de datos con archivos Avro.
- Importar datos en formato CSV
Si bien también puedes insertar filas con Google Cloud CLI, no te recomendamos que uses gcloud CLI para la carga masiva.
Lineamientos de rendimiento para la carga masiva
Para lograr un rendimiento óptimo de carga masiva, maximiza el uso de la partición para distribuir la escritura de los datos en las tareas del trabajador.
Spanner usa la división basada en la carga para distribuir de manera uniforme la carga de datos en los recursos de procesamiento de la instancia. Después de unos minutos de carga alta, Spanner presenta límites divididos entre las 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 las tablas de forma dinámica en rangos más pequeños. 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 mayor que la cantidad de nodos en la 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 función 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 claves 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 un conjunto de filas contiguos en una confirmación y, probablemente, tocar datos en diferentes particiones. La latencia de confirmación y la sobrecarga son mayores cuando se escriben más divisiones en una confirmación, debido a una mayor coordinación entre los servidores. Es probable que haya varias divisiones, ya que cada fila aleatoria podría pertenecer a una división diferente. En el peor de los casos, cada escritura involucra cada división en tu instancia de Spanner. Como se mencionó anteriormente, la capacidad de procesamiento de escritura disminuye cuando se utilizan más divisiones.
Carga masiva sin partición
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, se requiere más coordinación entre los servidores, lo que aumenta la latencia de confirmación y la sobrecarga.
Es probable que se involucren varias particiones, ya que cada fila aleatoria podría pertenecer a una partición diferente. En el peor de los casos, cada escritura involucra todas las particiones en la instancia de Spanner. Como se mencionó antes, la capacidad de procesamiento de escritura disminuye cuando se involucran más particiones.
Evita la sobrecarga
Es posible enviar más solicitudes de escritura de las que Spanner puede controlar. Spanner controla la sobrecarga mediante la anulación de transacciones, lo que se denomina rechazo. Para las transacciones de solo escritura, Spanner vuelve a intentar la transacción de forma automática. 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. Si quieres evitar el rechazo, debes regular las solicitudes de escritura para mantener el uso de CPU dentro de los límites razonables. De manera alternativa, los usuarios pueden aumentar la cantidad de nodos para que el uso de CPU se mantenga dentro de los límites.
Confirma entre 1 MB y 5 MB de mutaciones a la vez
Cada escritura en Spanner contiene una sobrecarga, sin importar si la escritura es 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 que cada confirmación mute 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 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 de más de 5 MB o más de unos cientos de filas no proporcionan beneficios adicionales y corren el riesgo de exceder los límites de Spanner sobre tamaño de confirmación y 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 las instrucciones DDL para la tabla nueva y los índices nuevos en una sola solicitud a Spanner.
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 en su totalidad 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 menor.
Te recomendamos agregar índices que sean fundamentales para tu aplicación empresarial antes de cargar los datos. Para todos los índices no 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 actualizas una base de datos existente que contiene datos, pero no tiene ningún índice secundario, las recomendaciones sobre este tema aún son útiles.
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.