Comprender 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 en esta página, cada nodo de Bigtable puede proporcionar la siguiente capacidad de procesamiento aproximada, según el tipo de almacenamiento que el clúster use:

Nivel de almacenamiento Lecturas   Escrituras   Análisis
Nivel en la memoria (vista previa) hasta 120,000 filas por segundo1 o hasta 10,000 filas por segundo2 N/A
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
Almacenamiento de acceso poco frecuente hasta 100 filas por segundo o hasta 10,000 filas por segundo o Hasta 36 MB/s

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

1 Un nodo de Enterprise Plus incluye 40,000 filas por segundo y se puede escalar verticalmente hasta 120,000 filas por segundo por nodo en incrementos de 40,000. Para obtener más información, consulta Nivel en memoria.

2 Una alta escritura de filas por segundo en los datos del nivel en la memoria puede afectar la capacidad de procesamiento de escritura.

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 sin que se habilite el nivel en memoria. Con el nivel en la memoria habilitado, el clúster puede admitir una capacidad de procesamiento de lectura de hasta 1.2 millones de filas por segundo.

Planifica tu capacidad de Bigtable

Cuando planifiques tus clústeres de Bigtable, decide si deseas optimizar 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 los números de la sección Rendimiento en cargas de trabajo típicas cuando optimizas la capacidad de procesamiento.

Nivel en la memoria

Con el nivel en memoria habilitado, cada nodo incluye 40,000 filas por segundo. Agregar nodos de forma horizontal aumenta la capacidad total del clúster. Además, cada nodo puede escalar verticalmente hasta un máximo de 120,000 filas por segundo por nodo para admitir la capacidad de procesamiento de lectura en la memoria. Cuando se alcanza el límite de escalamiento vertical, el escalamiento automático de Bigtable agrega nodos adicionales para escalar horizontalmente. Un clúster con escalamiento manual admite el escalamiento vertical en la memoria hasta que se alcanza la capacidad de procesamiento. El escalamiento vertical más allá de las 40,000 filas por segundo base se factura aplicando un multiplicador al costo por hora del nodo. Para obtener más información, consulta Precios.

Cada nodo en memoria incluye 8 GB de capacidad de almacenamiento. Si bien el procesamiento puede escalarse verticalmente, la capacidad de almacenamiento permanece fija por nodo. Sin embargo, el ajuste de escala horizontal agrega 8 GB de memoria adicionales para cada nodo nuevo. Dado que el almacenamiento no aumenta durante el escalamiento vertical, es posible que la tasa de errores de una carga de trabajo aumente cuando un nodo escale verticalmente su capacidad de procesamiento en la memoria.

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 el uso. Para obtener más información, consulta Ajuste de escala automático.

Sigue estos lineamientos cuando configures tus objetivos de ajuste de escala 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 mantenerlo 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

El almacenamiento es otro aspecto que debes considerar en la planificación de la capacidad. 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 distribuyendo los 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 los parámetros del 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 tus cargas de trabajo en Bigtable

Siempre debes ejecutar tus cargas de trabajo en un clúster de Bigtable cuando planifiques la capacidad para 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 para tus cargas de trabajo, puedes seguir el instructivo de PerfKitBenchmarker para Bigtable. Cuando lo hagas, ajusta los parámetros en los archivos YAML de configuración de las comparativas para asegurarte de que la comparativa que se genera refleje las siguientes características de producción:

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

Causas del rendimiento más bajo

Los siguientes factores pueden provocar que Bigtable funcione más lento que lo estimado:

  • 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 las lecturas que alcanzan un nodo activo pueden aumentar la latencia de cola. Consulta Lecturas y rendimiento para obtener más detalles.
  • El esquema de la 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 puntos calientes de 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, 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 existente 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 mejora el rendimiento, ya que distribuye la carga de trabajo en más nodos.
    • Almacenamiento: Si el uso del almacenamiento por nodo es superior al recomendado, agrega 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 la cantidad de almacenamiento por nodo incrementa la cantidad de trabajo de mantenimiento en segundo plano por nodo. Para obtener más información, consulta Compensaciones entre el uso del almacenamiento y el rendimiento.

  • La escala del clúster de Bigtable aumentó o disminuyó recientemente. Después de que el ajuste de escala automático aumenta la cantidad de nodos en un clúster, pueden pasar hasta 20 minutos con carga antes de que el rendimiento mejore significativamente. Bigtable ajusta los nodos del clúster según la carga que experimentan.

    Cuando disminuyas la cantidad de nodos en un clúster para reducir la escala verticalmente, intenta no reducir el tamaño del clúster en 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 .

Debido a que diferentes cargas de trabajo pueden causar que el rendimiento varíe, realiza pruebas con tus cargas de trabajo para 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, prueba las siguientes estrategias para mantener la conexión activa y evitar la 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.17.1, 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: