En esta página, se proporcionan lineamientos para cargar grandes cantidades de datos de forma masiva y eficiente a Spanner.
Tienes varias opciones para cargar datos de forma masiva en Spanner:
- Insertar filas con el lenguaje de manipulación de datos (DML)
- Inserta filas con 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 recomendamos que uses gcloud CLI 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 los datos de manera uniforme. y carga a través de 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 las tablas de forma dinámica en rangos más pequeños. El principal de una fila determina su partición.
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 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 equilibrar cargar 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 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 de Spanner. Como mencionada anteriormente, la capacidad de procesamiento de escritura se reduce cuando se realizan 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 de forma aleatoria filas. 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 porque cada fila aleatoria podría pertenecer a una partición diferente. En el peor de los casos, cada escritura involucra cada partición en tu instancia de Spanner. Como se mencionó anteriormente, escribe la capacidad de procesamiento disminuye cuando se involucran más particiones.
Evita la sobrecarga
Es posible enviar más solicitudes de escritura de las que puede manejar Spanner. Spanner controla la sobrecarga anulando las transacciones, lo que se denomina y el rechazo de las comunicaciones. Para las transacciones de solo escritura, Spanner reintenta automáticamente el transacción. 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. Como 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, ya sea que la escritura 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 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 un límite 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 cientos de filas proporcionan un beneficio adicional y corren el riesgo de exceder los límites de Spanner según el tamaño de confirmación 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. Para crear una tabla y sus al mismo tiempo, envía las instrucciones DDL para la tabla nueva y í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 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 un ritmo más lento.
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 y cómo se migran 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.