Comprende el rendimiento

En esta página, se describe el rendimiento aproximado que Bigtable puede proporcionar en condiciones óptimas, los factores que pueden afectar el rendimiento y sugerencias para probar y solucionar problemas de rendimiento de Bigtable.

Rendimiento en cargas de trabajo típicas

Bigtable ofrece un rendimiento muy predecible que es escalable y lineal. Cuando evitas las causas del rendimiento más bajo que se describen a continuación, cada nodo de Bigtable puede proporcionar la siguiente capacidad de procesamiento aproximada, según el tipo de almacenamiento que el clúster use:

Tipo de almacenamiento Lecturas   Escrituras   Análisis
SSD hasta 17,000 filas por segundo o hasta 14,000 filas por segundo o hasta 220 MB/s
HDD hasta 500 filas por segundo o hasta 10,000 filas por segundo o hasta 180 MB/s

En estas estimaciones, se supone que cada fila contiene 1 KB de datos.

En general, el rendimiento de un clúster se escala de forma lineal a medida que le agregas nodos. Por ejemplo, si creas un clúster SSD con 10 nodos, este puede admitir hasta 140,000 filas por segundo para una carga de trabajo típica de solo lectura o de solo escritura.

Planifica tu capacidad de Bigtable

Cuando planifiques tus clústeres de Bigtable, decide si deseas realizar la optimización para la latencia o la capacidad de procesamiento. Por ejemplo, para un trabajo de procesamiento de datos por lotes, es posible que debas preocuparte más por la capacidad de procesamiento que por la latencia. Por el contrario, para un servicio en línea que entrega solicitudes de usuarios, es posible que debas priorizar una latencia más baja por sobre la capacidad de procesamiento. Puedes alcanzar las cifras de la sección Rendimiento en cargas de trabajo típicas cuando optimizas la capacidad de procesamiento.

Uso de CPU

En casi todos los casos, te recomendamos que uses el ajuste de escala automático, que permite que Bigtable agregue o quite nodos según tu uso. Para obtener más información, consulta Ajuste de escala automático.

Usa los siguientes lineamientos cuando configures tus objetivos de escalamiento automático o si eliges la asignación manual de nodos. Estos lineamientos se aplican independientemente de la cantidad de clústeres que tenga tu instancia. En el caso de un clúster con asignación manual de nodos, debes supervisar el uso de CPU del clúster con el objetivo de mantener el uso de CPU por debajo de estos valores para obtener un rendimiento óptimo.

Objetivo de optimización Uso máximo de CPU
Capacidad de procesamiento 90%
Latencia 60%

Para obtener más información sobre la supervisión, consulta Supervisión.

Uso de almacenamiento

Otro elemento que debes considerar en la planificación de la capacidad es el almacenamiento. La capacidad de almacenamiento de un clúster se determina por el tipo de almacenamiento y la cantidad de nodos del clúster. Cuando aumenta la cantidad de datos almacenados en un clúster, Bigtable optimiza el almacenamiento mediante la distribución de la cantidad de datos en todos los nodos del clúster.

Para determinar el uso de almacenamiento por nodo, divide el uso del almacenamiento (bytes) del clúster por la cantidad de nodos del clúster. Por ejemplo, imagina un clúster que tiene tres nodos HDD y 9 TB de datos. Cada nodo almacena alrededor de 3 TB, que es el 18.75% del límite de 16 TB de almacenamiento HDD por nodo.

Cuando el uso del almacenamiento aumenta, las cargas de trabajo pueden experimentar un aumento en la latencia del procesamiento de consultas, incluso si el clúster tiene suficientes nodos para satisfacer las necesidades generales de CPU. Esto se debe a que cuanto más alto sea el almacenamiento por nodo, se necesita más trabajo en segundo plano, como la indexación. El aumento del trabajo en segundo plano para manejar más almacenamiento puede generar una mayor latencia y una menor capacidad de procesamiento.

Comienza con lo siguiente cuando configures el ajuste de escala automático. Si eliges la asignación manual de nodos, supervisa el uso de almacenamiento del clúster y agrega o quita nodos para mantener lo siguiente.

Objetivo de optimización Uso máximo de almacenamiento
Capacidad de procesamiento 70%
Latencia 60%

Para obtener más información, consulta Almacenamiento por nodo.

Ejecuta las cargas de trabajo típicas en Bigtable

Siempre debes ejecutar tus propias cargas de trabajo típicas en un clúster de Bigtable cuando planifiques la capacidad, de modo que puedas determinar la mejor asignación de recursos para tus aplicaciones.

PerfKit Benchmarker de Google usa YCSB para comparar servicios en la nube. Si deseas crear pruebas en tus propias cargas de trabajo, puedes seguir el instructivo de PerfKit Benchmarker para Bigtable. Cuando lo hagas, debes ajustar los parámetros en los archivos de configuración yaml de las comparativas para asegurarte de que la comparativa que se genera refleje las siguientes características en tu producción:

Si deseas obtener más prácticas recomendadas, consulta Prueba el rendimiento con Bigtable.

Causas del rendimiento más bajo

Existen varios factores que pueden provocar que Bigtable funcione más lento que las estimaciones que se muestran aquí:

  • Lees una gran cantidad de claves de fila o rangos de filas no contiguos en una sola solicitud de lectura. Bigtable analiza la tabla y lee las filas solicitadas de forma secuencial. Esta falta de paralelismo afecta la latencia general, y cualquier operación de lectura que alcance un nodo activo puede aumentar la latencia de tail. Consulta Lecturas y rendimiento para obtener más detalles.
  • El esquema de tu tabla no está diseñado correctamente. Para obtener un buen rendimiento en Bigtable, es fundamental diseñar un esquema que permita distribuir las lecturas y escrituras de manera uniforme entre cada tabla. Además, los hotspots en una tabla pueden afectar el rendimiento de otras tablas en la misma instancia. Consulta Prácticas recomendadas para el diseño de esquemas para obtener más información.
  • Las filas de la tabla de Bigtable contienen grandes cantidades de datos. En las estimaciones de rendimiento que se muestran arriba, se supone que cada fila contiene 1 KB de datos. Puedes leer y escribir grandes cantidades de datos por fila, pero aumentar la cantidad de datos por fila también reduce la cantidad de filas por segundo.
  • Las filas de tu tabla de Bigtable contienen una gran cantidad de celdas. Bigtable demora en procesar cada celda de una fila. Además, cada celda agrega algo de sobrecarga a la cantidad de datos que se almacenan en tu tabla y que se envían por la red. Por ejemplo, si almacenas 1 KB (1,024 bytes) de datos, sería mucho más eficiente almacenarlos en una sola celda que dividirlos entre 1,024 celdas con 1 byte cada una. Si divides los datos en más celdas de las necesarias, es posible que no obtengas el mejor rendimiento posible. Si las filas contienen una gran cantidad de celdas porque las columnas contienen varias versiones de datos con marca de tiempo, considera conservar solo el valor más reciente. Otra opción para una tabla que ya existe es enviar una eliminación a todas las versiones anteriores con cada reescritura.

  • El clúster no tiene nodos suficientes. Los nodos de un clúster proporcionan procesamiento para que el clúster controle las lecturas y escrituras entrantes, hace un seguimiento del almacenamiento y realiza tareas de mantenimiento, como la compactación. Debes asegurarte de que tu clúster tenga suficientes nodos a fin de cumplir con los límites recomendados para el procesamiento y el almacenamiento. Usa las herramientas de supervisión para verificar si el clúster está sobrecargado.

    • Procesamiento: Si la CPU de tu clúster de Bigtable está sobrecargada, agregar más nodos puede mejorar el rendimiento mediante la distribución de la carga de trabajo en más nodos.
    • Almacenamiento: Si el uso del almacenamiento por nodo superó lo recomendado, debes agregar más nodos para mantener una latencia y una capacidad de procesamiento óptimas, incluso si el clúster tiene suficiente CPU para procesar las solicitudes. Esto se debe a que aumentar el almacenamiento por nodo aumenta la cantidad de trabajo de mantenimiento en segundo plano por nodo. Para ver más detalles, consulta Compensaciones entre el uso del almacenamiento y el rendimiento.

  • La escala del clúster de Bigtable aumentó o disminuyó recientemente. Después de aumentar la cantidad de nodos en un clúster, pueden pasar hasta 20 minutos con carga para que veas una mejora significativa en el rendimiento del clúster. Bigtable escala los nodos de un clúster según la carga que experimenta.

    Cuando disminuyas la cantidad de nodos en un clúster para reducir la escala, intenta no reducir el tamaño del clúster más de un 10% en un período de 10 minutos para minimizar los picos de latencia.

  • El clúster de Bigtable usa discos HDD. En la mayoría de los casos, el clúster debería usar discos SSD, que tienen un rendimiento muy superior a los HDD. Para obtener más detalles, consulta Elige entre el almacenamiento SSD y HDD.

  • Hay problemas con la conexión de red. Los problemas de red pueden reducir la capacidad de procesamiento, y esto puede provocar que las lecturas y escrituras tarden más de lo habitual. En particular, es posible que detectes problemas si tus clientes no se ejecutan en la misma zona que tu clúster de Bigtable o si tus clientes se ejecutan fuera de Google Cloud.

  • Usas la replicación, pero tu aplicación usa una biblioteca cliente desactualizada. Si observas un aumento de la latencia después de habilitar la replicación, asegúrate de que la biblioteca cliente de Cloud Bigtable que usa tu aplicación esté actualizada. Es posible que las versiones anteriores de las bibliotecas cliente no estén optimizadas para admitir la replicación. Consulta las bibliotecas cliente de Cloud Bigtable para encontrar el repositorio de GitHub de tu biblioteca cliente, en el que puedes verificar la versión y actualizarla si es necesario.

  • Habilitaste la replicación, pero no agregaste más nodos a los clústeres. En una instancia que usa la replicación, cada clúster debe manejar el trabajo de replicación además de la carga que recibe de las aplicaciones. Los clústeres con aprovisionamiento insuficiente pueden causar una mayor latencia. Para verificarlo, revisa los gráficos del uso de CPU de la instancia en la consola de Google Cloud.

Ya que el rendimiento varía según las distintas cargas de trabajo, deberías realizar pruebas con tus propias cargas a fin de obtener las comparativas más precisas.

Inicios en frío y QPS bajas

Los inicios en frío y las QPS bajas pueden aumentar la latencia. Bigtable tiene un mejor rendimiento con tablas grandes a las que se accede con frecuencia. Por este motivo, si comienzas a enviar solicitudes después de un período sin uso (un inicio en frío), es posible que observes una latencia alta mientras Bigtable restablece las conexiones. La latencia también es mayor cuando las QPS son bajas.

Si tu QPS es baja o si sabes que, a veces, enviarás solicitudes a una tabla de Bigtable después de un período de inactividad, puedes probar las siguientes estrategias para mantener la conexión activa y evitar esta latencia alta.

Durante los períodos de QPS bajas, la cantidad de errores que muestra Bigtable es más relevante que el porcentaje de operaciones que muestran un error.

Inicio en frío en el momento de la inicialización del cliente. Si usas una versión del cliente de Cloud Bigtable para Java anterior a la versión 2.18.0, puedes habilitar la actualización de canales. En versiones posteriores, la actualización de canales está habilitada de forma predeterminada. La actualización del canal realiza dos acciones:

  • Cuando se inicializa el cliente, prepara el canal antes de enviar las primeras solicitudes.
  • El servidor desconecta las conexiones de larga duración cada hora. La activación de canales reemplaza de forma preventiva los canales que vencerán.

Sin embargo, esto no mantiene el canal activo cuando hay períodos de inactividad.

Cómo optimiza Bigtable los datos con el tiempo

Para almacenar los datos subyacentes de cada una de tus tablas, Bigtable fragmenta los datos en varios tablets que se pueden mover entre los nodos de tu clúster de Bigtable. Este método de almacenamiento permite a Bigtable usar dos estrategias diferentes para optimizar los datos con el tiempo:

  1. Bigtable intenta almacenar aproximadamente la misma cantidad de datos en cada nodo de Bigtable.
  2. Bigtable intenta distribuir las operaciones de lectura y escritura de forma equitativa entre sus nodos.

A veces, estas estrategias tienen conflictos entre sí. Por ejemplo, si las filas de un tablet se leen con demasiada frecuencia, Bigtable podría almacenarlo en su propio nodo, incluso si esto provoca que algunos nodos almacenen más datos que otros.

Como parte de este proceso, Bigtable también puede dividir una tablet en dos o más, ya sea para reducir su tamaño o para aislar las filas más activas dentro de una tablet existente.

En las siguientes secciones, se explican estas estrategias en más detalle.

Distribuye la cantidad de datos entre los nodos

A medida que escribes datos en una tabla de Bigtable, se fragmentan en tablets. Cada tablet contiene un rango contiguo de filas de la tabla.

Si escribiste menos de varios GB de datos en la tabla, Bigtable almacenará todas las tablas en un solo nodo de tu clúster:

Un clúster con cuatro tablets en un solo nodo.

A medida que se acumulan más tablets, Bigtable transfiere algunos de ellos a otros nodos del clúster para que la cantidad de datos se balancee de manera uniforme:

Los tablets adicionales se distribuyen entre varios nodos.

Distribuye las lecturas y escrituras de manera uniforme entre los nodos

Si diseñaste tu esquema correctamente, las lecturas y escrituras se deberían distribuir de manera uniforme en tu tabla. Sin embargo, en algunos casos, no se puede evitar acceder a algunas filas con más frecuencia que a otras. Bigtable te ayuda con estos casos, ya que considera las lecturas y escrituras cuando balancea los tablets entre los nodos.

Por ejemplo, supongamos que el 25% de las lecturas van a una pequeña cantidad de tablets en un clúster y que las lecturas se dividen de manera uniforme entre los otros:

De 48 tablets, el 25% de las lecturas se divide entre 3 de ellos.

Bigtable redistribuirá los tablets existentes a fin de que las lecturas se repartan de la manera más uniforme posible en el clúster:

Los tres tablets más activos se aíslan en su propio nodo.

Prueba el rendimiento con Bigtable

Si ejecutas una prueba de rendimiento para una aplicación que depende de Bigtable, sigue estos lineamientos a medida que planifiques y ejecutes la prueba:

  • Realiza pruebas con datos suficientes.
    • Si las tablas de la instancia de producción contienen un total de 100 GB de datos o menos por nodo, realiza las pruebas en una tabla de la misma cantidad de datos.
    • Si las tablas contienen más de 100 GB de datos por nodo, realiza las pruebas con una tabla que contenga al menos 100 GB de datos por nodo. Por ejemplo, si la instancia de producción tiene un clúster de cuatro nodos, y las tablas de la instancia contienen un total de 1 TB de datos, ejecuta la prueba con una tabla de al menos 400 GB.
  • Realiza las pruebas con una sola tabla.
  • Respeta el límite recomendado de uso de almacenamiento por nodo. Para obtener más detalles, consulta Almacenamiento por nodo.
  • Antes de comenzar, realiza una prueba previa con carga durante varios minutos. Este paso permite que Bigtable tenga la oportunidad de balancear los datos entre tus nodos según los patrones de acceso que detecte.
  • Ejecuta la prueba por, al menos, 10 minutos. Este paso permite que Bigtable optimice tus datos y ayuda a garantizar que pruebes las lecturas del disco y las almacenadas en caché en la memoria.

Soluciona problemas de rendimiento

Si piensas que Bigtable crea un cuello de botella de rendimiento en tu aplicación, asegúrate de revisar los siguientes apartados:

  • Mira los análisis de Key Visualizer sobre tus tablas. La herramienta Key Visualizer para Bigtable genera datos de análisis nuevos cada 15 minutos que muestran los patrones de uso de cada tabla de un clúster. Key Visualizer permite verificar si tus patrones de uso causan resultados no deseados, como hotspots en filas específicas o el uso excesivo de CPU. Aprende cómo comenzar a usar Key Visualizer.
  • Comenta el código encargado de ejecutar las lecturas y escrituras de Bigtable. Si el problema de rendimiento desaparece, probablemente, estés usando Bigtable de la manera óptima. Si el problema de rendimiento persiste, probablemente, no esté relacionado con Bigtable.

  • Asegúrate de crear la menor cantidad posible de clientes. Crear un cliente de Bigtable es una operación relativamente costosa. Por lo tanto, debes crear la menor cantidad posible:

    • Si usas la replicación o los perfiles de app para identificar distintos tipos de tráfico en tu instancia, crea un cliente por cada perfil de app y comparte esos clientes en tu aplicación.
    • Si no usas la replicación ni los perfiles de app, crea solo un cliente de aplicación y compártelo en tu aplicación.

    Si usas el cliente de HBase para Java, creas un objeto Connection en lugar de un cliente, por lo que debes crear la menor cantidad de conexiones posible.

  • Asegúrate de leer y escribir varias filas en tu tabla. El rendimiento de Bigtable es mejor cuando las lecturas y escrituras se distribuyen de manera uniforme en la tabla, lo que ayuda a que Bigtable distribuya la carga de trabajo entre todos los nodos del clúster. Si las lecturas y escrituras no se distribuyen entre todos tus nodos de Bigtable, el rendimiento será menor.

    Si detectas que lees y escribes solo una pequeña cantidad de filas, es posible que debas rediseñar tu esquema a fin de que las lecturas y escrituras se distribuyan de una manera más uniforme.

  • Verifica que tengas, aproximadamente, el mismo rendimiento para las lecturas y las escrituras. Si detectas que las lecturas son mucho más rápidas que las escrituras, es posible que estés intentando leer claves de filas que no existen, o un gran rango de claves de fila que solo contiene una pequeña cantidad de filas.

    A fin de hacer una comparación válida entre estas operaciones, debes intentar que, al menos, el 90% de tus lecturas muestre resultados válidos. Además, si lees un rango grande de claves de fila, mide el rendimiento según la cantidad real de filas que contiene, en lugar de hacerlo según la cantidad máxima de filas que podría tener.

  • Usa el tipo correcto de solicitudes de escritura para tus datos. Elegir la forma óptima para escribir los datos ayuda a mantener un alto rendimiento.

  • Comprueba la latencia de una sola fila. Si observas una latencia inesperada cuando envías solicitudes ReadRows, puedes verificar la latencia de la primera fila de la solicitud para disminuir la causa. De forma predeterminada, la latencia general de una solicitud ReadRows incluye la latencia para cada fila de la solicitud y el tiempo de procesamiento entre filas. Si la latencia general es alta, pero la latencia de la primera fila es baja, esto sugiere que la latencia se genera debido a la cantidad de solicitudes o al tiempo de procesamiento, en lugar de un problema con Bigtable.

    Si usas la biblioteca cliente de Bigtable para Java, puedes ver la métrica read_rows_first_row_latency en el Explorador de métricas de la consola de Google Cloud después de habilitar las métricas del cliente.

  • Usa un perfil de app independiente para cada carga de trabajo. Si tienes problemas de rendimiento después de agregar una carga de trabajo nueva, crea un perfil de app nuevo para la carga de trabajo nueva. Luego, puedes supervisar las métricas de tus perfiles de app por separado para solucionar problemas. Consulta Cómo funcionan los perfiles de app para obtener detalles sobre por qué es una práctica recomendada usar varios perfiles de app.

  • Habilita las métricas del cliente. Puedes configurar métricas del cliente para optimizar y solucionar problemas de rendimiento. Por ejemplo, como Bigtable funciona mejor con QPS altas y distribuidas de manera uniforme, un aumento de la latencia de P100 (máx.) para un pequeño porcentaje de solicitudes no indica necesariamente un problema de rendimiento más grande con Bigtable. Las métricas del cliente pueden brindarte estadísticas sobre qué parte del ciclo de vida de la solicitud podría estar causando la latencia.

¿Qué sigue?