Al ejecutar cualquier herramienta de evaluación comparativa de rendimiento en su clúster, una decisión crítica siempre es qué tamaño de conjunto de datos se debe usar para una prueba de rendimiento, y aquí demostramos por qué es importante seleccionar un tamaño de conjunto de datos de "adecuado" cuando se ejecuta un rendimiento de HBase prueba en tu clúster.
Las configuraciones del clúster de HBase y el tamaño del conjunto de datos pueden variar el rendimiento de su carga de trabajo y los resultados de las pruebas en el mismo clúster. Debe elegir este tamaño de conjunto de datos en función de lo que intenta comprender sobre el rendimiento de su clúster. Para mostrar la diferencia entre un conjunto de trabajo que se ajusta a la memoria caché disponible y uno que debe leerse desde el almacenamiento subyacente, realizamos 2 pruebas de carga de trabajo YCSB con tamaños de conjuntos de datos elegidos adecuadamente en el mismo clúster de base de datos de operación CDP Private Cloud Base 7.2.2. Usamos tamaños de conjuntos de datos de 40 GB frente a 1 TB y el rendimiento para las diferentes cargas de trabajo de YCSB se compara a continuación, en el gráfico, cuanto más alta sea la barra, mejor será el rendimiento.
Nota:Rendimiento =Operaciones por segundo
Cuando una aplicación intenta realizar una lectura desde un clúster HBase, el servidor de región que maneja la solicitud primero verifica si los resultados necesarios están en un bloque de datos que ya es local para su proceso a través de su caché de bloques. Si el bloque de datos está presente, la solicitud del cliente se puede atender directamente desde la memoria caché y esto cuenta como un acierto de la memoria caché. Sin embargo, si el bloque no es actualmente local para el proceso del servidor de región, se cuenta como un error de caché y debe leerse desde el archivo HFile en el almacenamiento HDFS. Dependiendo de la utilización de la memoria caché, ese bloque se guardará en la memoria caché para futuras solicitudes.
Como se esperaba y se ve en el gráfico de resumen, una carga de trabajo en la que la mayoría de los conjuntos de datos caben en la memoria caché tiene latencias más bajas y el rendimiento es mucho mayor en comparación con una ejecución de carga de trabajo en la que se accede a los datos desde HFiles en almacenamiento hdfs.
Para elegir nuestros tamaños de conjuntos de datos de carga de trabajo para cumplir bien con nuestros objetivos de prueba, es importante verificar los tamaños de los montones de RegionServer, las cachés L1 y L2, las cachés de búfer del sistema operativo y luego establecer un tamaño de conjunto de datos adecuado. Después de que la ejecución de una carga de trabajo de YCSB se haya completado, un buen parámetro para verificar que las cosas se ejecutaron como se esperaba es la cantidad de datos que se revisaron desde el caché (un golpe de caché) y la cantidad a la que se accedió desde el almacenamiento hdfs. Esta proporción de coincidencias de caché del servidor de región con respecto al total de solicitudes de lectura es la proporción de coincidencias de caché.
Puede encontrar esta información en la configuración "l1CacheHitRatio" de la proporción de aciertos de caché L1. Si tiene configurados cachés L1 y L2 en su clúster, entonces el caché L1 sirve los bloques de índice y el caché L2 sirve los bloques de datos, y puede registrar las configuraciones L1 "l1CacheHitRatio" y L2 "l2CacheHitRatio" como referencia.
El resto de esta publicación de blog repasará los detalles de nuestra configuración de prueba, elegirá el tamaño del conjunto de datos y luego ejecutará YCSB con esos tamaños de conjunto de datos.
Configuración de clúster de HBase utilizada para esta prueba:
- Cluster utilizado: Clúster de 6 nodos (1 maestro + 5 servidores de región)
- Descripción: Dell PowerEdge R430, 20c/40t Xenon e5-2630 v4 @ 2.2Ghz, 128GB Ram, 4-2TB discos
- Seguridad: Ninguno configurado (sin Kerberos)
- Versión CDP: CDP Private Cloud Base 7.2.2 Clúster HBase de 6 nodos con 1 servidor principal + 5 servidores regionales
- JDK usó jdk1.8_232
- Los servidores de la región HBase se configuraron con un almacenamiento dinámico de 32 GB
- El maestro HBase se configuró con un montón de 4 GB
- Se usó caché L1 con LruBlockCache con un tamaño de caché de 12,3 GB
- El caché L1 total en el clúster es de 61 GB (12,3 * 5 =61 GB)
- L2 off heap cache no se configuró en el clúster
Caso de dimensionamiento 1:los datos encajan completamente en la memoria caché disponible en el clúster
En nuestro clúster HBase, configuramos un total de 61 GB (12,3 GB * 5) en los servidores de 5 regiones asignados para la memoria caché de bloque L1. Para un conjunto de datos que cabe completamente en la caché, elegimos un conjunto de datos de 40 GB en tamaño.
Caso de dimensionamiento 2:conjunto de datos más grande que la memoria caché disponible en el clúster
Para el segundo escenario, queremos que los datos sean mucho más grandes que el caché disponible. Para elegir un tamaño de conjunto de datos apropiado, analizamos tanto la memoria caché de bloque HBase configurada como la memoria caché del búfer del sistema operativo en el clúster. En nuestro clúster HBase dado, el caché de bloque L1 configurado es 61G cuando se agrega a través de RegionServers. Los nodos del servidor tenían un total de 128 G de RAM cada uno y el sistema operativo puede usar cualquier memoria que no esté dedicada a un proceso del servidor para almacenar en caché de manera efectiva los bloques HDFS subyacentes y aumentar el rendimiento general. En nuestra configuración de prueba, hay alrededor de 96 G de caché de sistema operativo disponible en cada nodo de servidor de región para este propósito (ignorando la memoria utilizada por los procesos de DataNode o OS para simplificar las cosas). Agregando esto a través de los servidores de 5 regiones, teníamos un potencial de casi 500 G para los búferes (96 G * 5 servidores de regiones). Por lo tanto, elegimos un tamaño de conjunto de datos de 1 TB, superando tanto el caché de bloque configurado como el caché de búfer del sistema operativo disponible.
Conversión de tamaños de datos objetivo en parámetros YCSB
En YCSB, una fila tiene 1 KB de forma predeterminada, por lo que dependiendo de cuántas filas cargue en la "tabla de usuario" de YCSB, puede estimar fácilmente el tamaño de los datos de la tabla de "tabla de usuario" de YCSB. Entonces, si carga 1 millón de filas, ha cargado 1 000 000 * 1 KB =1 GB de datos en la "tabla de usuario" de YCSB .
Los tamaños de conjuntos de datos utilizados para nuestras dos pruebas fueron:
- 40 GB de datos con 40 millones de filas
- 1 TB de datos con mil millones de filas
Metodología de prueba
CDP Private Cloud Base 7.2.2 se instaló en el clúster de 6 nodos y se generaron datos de carga de trabajo con 40 millones de filas (tamaño total del conjunto de datos => 40 GB) y se ejecutaron cargas de trabajo YCSB. Después de la carga, esperamos a que terminaran todas las operaciones de compactación antes de comenzar la prueba de carga de trabajo.
Las cargas de trabajo de YCSB que se ejecutaron en HBase fueron
- Carga de trabajo A:50 % de lectura y 50 % de actualización
- Carga de trabajo C:100 % de lectura
- Carga de trabajo F:50 % de lectura y 50 % de relación de actualización/lectura, modificación y escritura:50/50
- Carga de trabajo de solo actualización personalizada:100 % de actualización
Cada carga de trabajo de YCSB (A, C, F y UpdateOnly) se ejecutó durante 15 minutos cada una, y la ejecución completa se repitió 5 veces sin reinicios entre ejecuciones para medir el rendimiento de YCSB*. Los resultados que se muestran son promedios tomados para las últimas 3 ejecuciones de las 5 ejecuciones. Se ignoraron las 2 primeras ejecuciones de prueba para evitar la penalización de la primera y la segunda ejecución.
Una vez que se completaron las ejecuciones de 40 GB, eliminamos la tabla de usuario y volvimos a generar mil millones de filas para crear un tamaño de conjunto de datos de 1 TB y volvimos a ejecutar las pruebas con la misma metodología en el mismo clúster.
Resultados de la prueba
Resultados YCSB con 40GB
En el caso de 40 GB, los datos pueden caber completamente en el caché L1 de 61 GB en el clúster. La proporción de aciertos de caché L1 observada en el clúster durante la prueba fue cercana al 99 %.
Consejo: Para conjuntos de datos más pequeños donde los datos pueden caber en la memoria caché, también podemos usar la opción de carga de memoria caché y precalentar la memoria caché para obtener una tasa de aciertos de memoria caché del 100 % mediante la opción de tabla PREFETCH_BLOCKS_ON_OPEN
Ejecutamos cada carga de trabajo de YCSB durante 15 minutos cada 5 veces y tomamos promedios de las últimas 3 ejecuciones para evitar la penalización de la primera ejecución.
Resultados observados con índice de aciertos de caché L1 de 40 G del 99 % en los servidores de la región se muestran a continuación en la tabla:
| Operación | Operaciones numéricas | Rendimiento | Latencia media | 95 Latencia | 99 Latencia |
| (Número de operaciones/seg) | (ms) | (ms) | (ms) | ||
| Carga de trabajo C | 148558364 | 165063 | 0,24 | 0,30 | 0,48 |
| Solo Actualizar | 56727908 | 63030 | 0,63 | 0,78 | 1,57 |
| Carga de trabajo A | 35745710 | 79439 | 0,40 | 0,54 | 0,66 |
| Carga de trabajo F | 24823285 | 55157 | 0,58 | 0,70 | 0,96 |
Resultados de YCSB con un conjunto de datos de 1 TB
En el caso de 1 TB, los datos no caben en la memoria caché L1 de 61 GB en el clúster ni en la memoria caché del búfer del sistema operativo de 500 GB. La proporción de aciertos de caché L1 en el clúster observado durante la prueba fue del 82-84 %.
Ejecutamos cada carga de trabajo durante 15 minutos cada 5 veces y tomamos promedios de las últimas 3 ejecuciones para evitar la penalización de la primera ejecución.
Resultados vistos con 1TB Proporción de aciertos de caché L1 82-84 % en los servidores de la región se muestran a continuación en la tabla:
| Operación | Operaciones numéricas | Rendimiento | Latencia media | 95 Latencia | 99 Latencia |
| (Número de operaciones/seg) | (ms) | (ms) | (ms) | ||
| Carga de trabajo C | 2727037 | 3030 | 13.19 | 55,50 | 110,85 |
| Solo Actualizar | 56345498 | 62605 | 0,64 | 0,78 | 1,58 |
| Carga de trabajo A | 3085135 | 6855 | 10,88 | 48,34 | 97,70 |
| Carga de trabajo F | 3333982 | 3704 | 10.45 | 47,78 | 98,62 |
*Rendimiento (ops/s) =Número de operaciones por segundo
Análisis:
Al comparar los resultados de las pruebas para los dos tamaños de conjuntos de datos diferentes anteriores, podemos ver cómo el mismo rendimiento de la carga de trabajo puede variar de 3 000 operaciones por segundo a 165 000 operaciones por segundo cuando se accede a los datos más rápidamente desde el conjunto de datos de 40 G con la memoria caché calentada en comparación con el almacenamiento hdfs.
El siguiente gráfico muestra el rendimiento y compara cómo cambió el rendimiento para diferentes cargas de trabajo cuando se ejecutan con los conjuntos de datos de 2 tamaños diferentes. En el gráfico, cuanto más alta sea la barra, mejor será el rendimiento.
Nota:Rendimiento =Operaciones por segundo
Como se ve en el gráfico, las cargas de trabajo de YCSB que leen datos como la Carga de trabajo A, la Carga de trabajo C y la Carga de trabajo F tuvieron un rendimiento mucho mejor en el caso de 40 G donde los datos caben fácilmente en la memoria caché frente al caso de tamaño de datos de 1 TB donde los datos de HFile tenían que ser accedido desde HDFS
En cuanto a las proporciones de aciertos de caché, el conjunto de datos de 40 G tuvo una proporción de aciertos de caché cercana al 99 %, y el conjunto de datos de 1 TB tuvo una proporción de aciertos de caché de alrededor del 85 %, por lo que se accedió al 15 % de los datos en el caso de 1 TB desde el almacenamiento hdfs .
La carga de trabajo de solo actualización personalizada de YCSB que ejecutamos tuvo el mismo rendimiento en ambos casos, ya que solo realizó actualizaciones y no lecturas.
Durante el rendimiento de HBase, observamos de cerca las latencias de los percentiles 95 y 99. La latencia promedio es solo el rendimiento total dividido por el tiempo total; sin embargo, el percentil 95 y el percentil 99 muestran los valores atípicos reales que afectan el rendimiento total de la carga de trabajo. En el caso de 1 TB, los valores atípicos de alta latencia en el percentil 95 y 99 hacen que el rendimiento se ralentice, y en el caso de 40 GB, la caché de baja latencia alcanza el percentil 99 y aumenta el rendimiento total.
El gráfico a continuación muestra la comparación de latencia para la latencia promedio, la latencia del percentil 95 y la latencia del percentil 99 y cómo difiere para diferentes cargas de trabajo cuando se ejecuta con conjuntos de datos de diferentes tamaños.
En el gráfico anterior, es difícil ver las barras que representan la latencia para el conjunto de datos de 40 GB, ya que son extremadamente bajas en comparación con la latencia observada para el conjunto de datos de 1 TB que accede a los datos de hdfs.
Trazamos el gráfico de latencia usando el registro de los valores de latencia para mostrar la diferencia en el gráfico a continuación
Como se ve arriba, las latencias son mucho más bajas en el caso de 40 GB, donde la tasa de aciertos de la memoria caché es cercana al 99 % y la mayoría de los datos de la carga de trabajo están disponibles en la memoria caché. En comparación con el conjunto de datos de 1 TB, la proporción de aciertos de caché fue de alrededor del 85 %, ya que se tuvo que acceder a los datos de HFile desde el almacenamiento HDFS.
La latencia promedio y 99 para la carga de trabajo C en el caso de 40 G donde el 99 % de los datos se devuelven desde la caché calentada fue de alrededor de 2 a 4 ms. La latencia del percentil 99 para la misma carga de trabajo C en el caso de 1 TB fue de alrededor de 100 ms para la carga de trabajo C (carga de trabajo de solo lectura).
Esto muestra que un acierto de caché del caché de bloque en montón devuelve una lectura en alrededor de 2 ms y una falla de caché y obtener un registro de HDFS podría tomar alrededor de 100 ms en este clúster.
Recomendación:
Cuando se ejecuta una prueba de evaluación comparativa YCSB, el tamaño del conjunto de datos hace una diferencia sustancial en los resultados de rendimiento y, por lo tanto, es muy importante dimensionar la prueba de manera adecuada. Al mismo tiempo, observar la proporción de aciertos de caché y las diferencias de latencia entre la latencia mínima y la latencia 99 lo ayudará a encontrar la latencia de un acierto de caché en comparación con cuando se accede a los datos desde el almacenamiento subyacente en el clúster.
Consejo:
Para verificar las proporciones de aciertos de caché de su carga de trabajo en un servidor de región, puede usar el siguiente comando
curl http://<region-server-host>:22102/jmx | grep -e l1CacheHitRatio -e l2CacheHitRatio
También puede ver la proporción de aciertos de caché desde la interfaz de usuario web de HBase siguiendo los pasos a continuación:
- Desde la interfaz de usuario web de HBase, haga clic en el servidor de la región
- En la sección Bloquear caché, seleccione L1 (y L2 si L2 está configurado) para revisar las proporciones de aciertos de caché.
A continuación, se muestra una captura de pantalla que muestra la proporción de aciertos de caché del caché de bloque L1:
Aquí hay un enlace para obtener más información sobre la captura de pantalla de HBase que se muestra arriba y bloquear el caché https://docs.cloudera.com/runtime/7.2.2/configuring-hbase/topics/hbase-blockcache.html
Acerca de YCSB
YCSB es un conjunto de programas y especificaciones de código abierto para evaluar las capacidades de recuperación y mantenimiento de los programas informáticos. Es una herramienta muy popular que se utiliza para comparar el rendimiento relativo de los sistemas de gestión de bases de datos NoSQL.
Para usar YCSB para probar el rendimiento de la base de datos operativa, consulte el blog Cómo ejecutar YCSB para HBase
