Comprende el rendimiento de Cloud Bigtable

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

Rendimiento en cargas de trabajo típicas

Cloud 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 Cloud 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 10,000 filas por segundo o hasta 10,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 100,000 filas por segundo para una carga de trabajo típica de solo lectura o de solo escritura.

Planifica tu capacidad de Cloud Bigtable

Compensación entre la alta capacidad de procesamiento y la latencia baja

Cuando planificas tus clústeres de Cloud Bigtable, es importante tener en cuenta la compensación entre la capacidad de procesamiento y la latencia. Cloud Bigtable se usa en una gran variedad de aplicaciones, y los distintos casos de uso pueden tener diferentes objetivos de optimización. 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 otro lado, un servicio en línea que entrega solicitudes de usuarios puede priorizar una latencia más baja por sobre la capacidad de procesamiento. Por lo tanto, es importante planificar la capacidad según corresponda.

Los números en la sección Rendimiento en cargas de trabajo típicas se logran cuando priorizas la capacidad de procesamiento, pero la latencia final de Cloud Bigtable de esa carga puede ser demasiado alta para aplicaciones sensibles a la latencia. En general, Cloud Bigtable ofrece una latencia óptima cuando la carga de CPU de un clúster es inferior al 70%. Sin embargo, en el caso de aplicaciones sensibles a la latencia, recomendamos que planifiques al menos el doble de capacidad para la cantidad máxima de QPS de Cloud Bigtable. Esta capacidad garantiza que el clúster de Cloud Bigtable se ejecute con menos del 50% de carga de CPU, por lo que puede ofrecer una latencia baja a los servicios de frontend. Esta capacidad también proporciona un búfer para los aumentos de tráfico o los hotspots de acceso a las claves, lo que puede provocar un tráfico desequilibrado entre los nodos del clúster.

Ejecuta las cargas de trabajo típicas en Cloud Bigtable

Siempre debes ejecutar tus propias cargas de trabajo típicas en un clúster de Cloud 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 Cloud 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 Cloud Bigtable.

Causas del rendimiento más bajo

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

  • El esquema de la tabla no está diseñado correctamente. Para obtener un buen rendimiento en Cloud Bigtable, es fundamental diseñar un esquema que permita distribuir las lecturas y escrituras de manera uniforme entre cada tabla. Si deseas obtener más información, consulta Diseña el esquema.
  • Las filas de la tabla de Cloud 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 Cloud Bigtable contienen una gran cantidad de celdas. Cloud Bigtable tarda un poco 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 de Cloud Bigtable no tiene suficientes nodos. Si tu clúster de Cloud Bigtable está sobrecargado, agregar más nodos puede mejorar el rendimiento. Usa las herramientas de supervisión para verificar si el clúster está sobrecargado.
  • La escala del clúster de Cloud Bigtable aumentó o disminuyó recientemente. Después de aumentar la cantidad de nodos en un clúster para escalar verticalmente, pueden pasar hasta 20 minutos bajo carga antes de que veas una mejora significativa en el rendimiento del clúster. Cuando disminuyas la cantidad de nodos en un clúster a fin de 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 Cloud 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 Cloud Bigtable o si tus clientes se ejecutan fuera 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.

Replicación y rendimiento

La habilitación de la replicación afectará el rendimiento de una instancia de Cloud Bigtable. El efecto es positivo para algunas métricas y negativo en otras. Debes comprender los impactos posibles en el rendimiento antes de decidir habilitar la replicación.

Rendimiento de lectura

La replicación puede mejorar la capacidad de procesamiento de lectura, especialmente cuando usas un enrutamiento de varios clústeres. Además, la replicación puede reducir la latencia de lectura mediante colocando de los datos de Cloud Bigtable geográficamente más cerca de los usuarios de tu aplicación.

Rendimiento de escritura

Aunque la replicación puede mejorar la disponibilidad y el rendimiento de lectura, no aumenta la capacidad de procesamiento de escritura. Una escritura en un clúster debe replicarse en todos los otros clústeres de la instancia. Como resultado, cada clúster gasta recursos de CPU para extraer cambios de los otros clústeres. En realidad, la capacidad de procesamiento de escritura podría disminuir porque la replicación requiere que cada clúster realice un trabajo adicional.

Por ejemplo, imagina que tienes una instancia de clúster único y el clúster tiene 3 nodos:

Instancia de clúster único que tiene 3 nodos

Si agregas nodos al clúster, el efecto en la capacidad de procesamiento de escritura es diferente a si habilitas la replicación mediante la adición de un segundo clúster de 3 nodos a la instancia.

Agregar nodos al clúster original: puedes agregar 3 nodos al clúster, para un total de 6 nodos. La capacidad de procesamiento de escritura para la instancia se duplica, pero los datos de la instancia están disponibles solo en una zona:

Instancia de clúster único que tiene 6 nodos

Con replicación: como alternativa, puedes agregar un segundo clúster con 3 nodos, para un total de 6 nodos. La instancia ahora escribe cada dato dos veces: cuando se recibe la escritura por primera vez y, nuevamente, cuando se replica en el otro clúster. La capacidad de procesamiento de escritura no aumenta y puede disminuir, pero tienes el beneficio de tener tus datos disponibles en dos zonas diferentes:

Instancia de dos clústeres que tiene 6 nodos

En estos ejemplos, la instancia de clúster único puede controlar el doble de capacidad de procesamiento de escritura que la instancia replicada, aunque los clústeres de cada instancia tengan un total de 6 nodos.

Latencia de replicación

Cuando usas el enrutamiento de varios clústeres, la replicación para Cloud Bigtable tiene una coherencia eventual. Como regla general, lleva más tiempo replicar datos a una distancia mayor. Los clústeres replicados en regiones diferentes generalmente tendrán una latencia de replicación más alta que los clústeres replicados en la misma región.

Perfiles de aplicación y enrutamiento de tráfico

Según tu caso práctico, utilizarás uno o más perfiles de aplicación para enrutar el tráfico de Cloud Bigtable. Cada perfil de aplicación utiliza el enrutamiento de varios clústeres o de clúster único. La elección del enrutamiento puede afectar el rendimiento.

El enrutamiento de varios clústeres puede minimizar la latencia. Un perfil de aplicación con enrutamiento de varios clústeres enruta automáticamente las solicitudes al clúster más cercano en una instancia desde la perspectiva de la aplicación, y, luego, las escrituras se replican en los otros clústeres de la instancia. Esta elección automática de la distancia más corta da como resultado la latencia más baja posible.

Un perfil de aplicación que usa el enrutamiento de clúster único puede ser óptimo para ciertos casos prácticos, como separar cargas de trabajo o contar con una semántica de lectura después de escritura en un solo clúster, pero no reducirá la latencia en la forma en que lo hace el enrutamiento de varios clústeres.

Si quieres comprender cómo configurar los perfiles de tu aplicación para estos y otros casos prácticos, consulta Ejemplos de configuración de replicación.

De qué forma Cloud Bigtable optimiza tus datos con el tiempo

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

  1. Cloud Bigtable intenta almacenar la misma cantidad de datos en cada nodo.
  2. Cloud 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, Cloud 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, Cloud Bigtable también podría dividir un tablet en dos o más partes, ya sea para reducir su tamaño o para dejar las filas más activas juntas dentro de uno.

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

Distribuir la cantidad de datos entre los nodos

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

Si escribiste solo una pequeña cantidad de datos en la tabla, Cloud Bigtable almacenará todos los tablets en un solo nodo del clúster:

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

A medida que se acumulen más tablets, Cloud Bigtable transferirá algunos de ellos a otros nodos del clúster a fin de que la cantidad de datos se balancee de manera uniforme:

Los tablets adicionales se distribuyen entre varios nodos.

Distribuir 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. Cloud 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.

Cloud 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 Cloud Bigtable

Si ejecutas una prueba de rendimiento para una aplicación que depende de Cloud 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 Cloud 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 Cloud 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 Cloud 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 Cloud Bigtable proporciona análisis diarios que muestran los patrones de uso de cada tabla del 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. Obtén información para comenzar a usar Key Visualizer.
  • Comenta el código encargado de ejecutar las lecturas y escrituras de Cloud Bigtable. Si el problema de rendimiento desaparece, probablemente, estés usando Cloud Bigtable de la manera óptima. Si el problema de rendimiento persiste, probablemente, no esté relacionado con Cloud Bigtable.
  • Asegúrate de crear la menor cantidad posible de clientes. Crear un cliente de Cloud 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 Cloud Bigtable es mejor cuando las lecturas y escrituras se distribuyen de manera uniforme en la tabla, lo que ayuda a que Cloud 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 Cloud 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.

Próximos pasos