Antes de crear un clúster de ApsaraDB for HBase, seleccione las especificaciones de los nodos maestros, las especificaciones y la cantidad de nodos principales, así como el tipo de almacenamiento. Ajuste estos parámetros a las consultas por segundo (QPS), transacciones por segundo (TPS), volumen de datos, requisitos de latencia de respuesta y necesidades de estabilidad de su carga de trabajo.
También debe decidir lo siguiente:
Edición de ApsaraDB for HBase. Consulte ApsaraDB for HBase editions.
Tipo de instancia de Elastic Compute Service (ECS): utilice una instancia dedicada para asignar recursos exclusivos y evitar la contención. Para cargas de trabajo de baja latencia, combine una instancia dedicada con discos SSD.
Seleccione las especificaciones de los nodos maestros
Los nodos maestros ejecutan los procesos maestros de ApsaraDB for HBase, los NameNodes del sistema de archivos distribuidos de Hadoop (HDFS) y ZooKeeper. Estos nodos no almacenan datos. De forma predeterminada, se despliegan dos nodos maestros en modo primario-secundario para garantizar la recuperación ante desastres.
Si los nodos maestros tienen CPU o memoria insuficiente, el rendimiento de todo el clúster se degrada. Seleccione las especificaciones según la cantidad de nodos principales, tablas y regiones de HBase que gestione el clúster. Los clústeres con muchas tablas o regiones requieren nodos maestros con especificaciones más altas.
|
Cantidad de nodos principales |
Especificación del nodo maestro |
|
Menos de 4 |
CPU de 4 núcleos, 8 GB de memoria |
|
De 4 a 7 |
CPU de 8 núcleos, 16 GB de memoria (recomendado para clústeres pequeños) |
|
De 8 a 15 |
CPU de 8 núcleos, 32 GB de memoria |
|
Más de 16 |
CPU de 16 núcleos, 64 GB de memoria o superior |
Seleccione las especificaciones de los nodos principales
Los nodos principales funcionan como RegionServers en ApsaraDB for HBase. Gestionan todas las solicitudes de lectura y escritura, por lo que sus especificaciones afectan directamente el rendimiento, la latencia y la estabilidad del clúster.
Rango de especificaciones: desde CPU de 4 núcleos con 8 GB de memoria (mínimo) hasta CPU de 32 núcleos con 128 GB de memoria (máximo).
Principio clave: mantenga todos los metadatos en caché para lograr un rendimiento óptimo. Elija la memoria de los nodos principales según la cantidad de datos que deban permanecer en caché.
Para los distintos clústeres de ApsaraDB for HBase, consulte los siguientes ejemplos de selección de especificaciones de nodos principales:
Clústeres pequeños: CPU de 4 núcleos y 16 GB de memoria, o CPU de 8 núcleos y 32 GB de memoria (recomendado).
-
Clústeres medianos o grandes: seleccione los nodos principales según la cantidad de datos que deban almacenarse en memoria.
Gran volumen de datos para almacenar: CPU de 16 núcleos y 64 GB de memoria, o CPU de 32 núcleos y 128 GB de memoria.
Poco volumen de datos para almacenar: CPU de 16 núcleos y 32 GB de memoria, o CPU de 32 núcleos y 64 GB de memoria.
Si necesita ayuda para calcular el espacio de almacenamiento obligatorio, únase al grupo de DingTalk ApsaraDB for HBase Q&A (s0s3eg3) o envíe un ticket.
Especificaciones según el volumen de carga de trabajo
|
TPS + QPS |
Nodos recomendados |
Notas |
|
Menos de 1,000 |
Dos nodos: CPU de 4 núcleos, 16 GB de memoria |
Mínimo para cargas ligeras. Mantenga menos de 600 regiones por nodo. La opción de 4 núcleos/8 GB está disponible, pero evítela: 8 GB de memoria pueden provocar errores de falta de memoria cuando aumentan la carga o el almacén de pares clave-valor. |
|
De 1,000 a 20,000 |
Dos o tres nodos: CPU de 8 núcleos, 32 GB de memoria |
Más rentable que la configuración de 8 núcleos/16 GB. Los 16 GB adicionales de memoria proporcionan un margen de estabilidad para cargas de ligeras a medias. |
|
Más de 20,000 |
8 núcleos/32 GB; 16 núcleos/32 GB; 16 núcleos/64 GB; 32 núcleos/64 GB; 32 núcleos/128 GB; o superior |
Para cargas de trabajo en línea, elija nodos con mucha memoria para maximizar la tasa de aciertos de caché. Para tareas sin conexión de MapReduce o Apache Spark con alto uso de CPU, priorice una mayor cantidad de núcleos. |
Cuando el volumen de solicitudes no es suficiente
Las métricas TPS y QPS no son los únicos factores. Incluso con solo unos cientos de solicitudes por segundo, actualice las especificaciones de los nodos principales si su carga de trabajo incluye alguno de los siguientes elementos:
Filas que almacenan kilobytes o megabytes de datos
Solicitudes de escaneo con filtros complejos
Bajas tasas de aciertos de caché, donde cada solicitud accede al disco
Una gran cantidad de tablas y regiones
En estas condiciones, los nodos de 4 núcleos/8 GB pueden causar problemas de estabilidad y aumentar la latencia, a pesar del bajo volumen de solicitudes.
Escalamiento vertical u horizontal
Cuando aumentan los picos de carga, sube la latencia o el clúster se vuelve inestable, puede escalar horizontalmente agregando nodos principales. Sin embargo, agregar únicamente nodos con especificaciones bajas puede generar puntos críticos si la carga de trabajo se distribuye de manera desigual. Las especificaciones de un nodo principal determinan su capacidad para absorber picos de tráfico y prevenir puntos críticos.
Por ejemplo, si un aumento repentino de tráfico afecta a una sola región o una solicitud grande llega a un único nodo, un nodo con especificaciones bajas podría sobrecargarse o quedarse sin memoria, lo que afectaría la estabilidad del clúster.
Elija primero las especificaciones según los requisitos de la carga de trabajo y luego ajuste la cantidad de nodos según sea necesario.
Para actualizar los nodos maestros o principales, únase al grupo de DingTalk ApsaraDB for HBase Q&A (s0s3eg3) o envíe un ticket.
Seleccione el tipo de almacenamiento
El tipo de almacenamiento no se puede cambiar después de crear el clúster. Elija cuidadosamente antes de crearlo.
ApsaraDB for HBase admite tres tipos de almacenamiento:
|
Función |
Tipo de almacenamiento |
Ideal para |
|
Alto rendimiento |
Discos SSD, SSD locales o ESSD |
Cargas de trabajo en línea que requieren baja latencia: publicidad, recomendaciones, feeds y perfiles de usuarios. Ofrece una latencia de 1 a 2 ms y minimiza la variabilidad del rendimiento. Los discos SSD son la mejor opción para lograr una baja latencia P99 (percentil 99). |
|
Alta eficiencia |
Ultra disks o HDD locales |
Cargas de trabajo en línea sensibles a la latencia donde ~10 ms son aceptables. Los HDD generan mayor variabilidad de rendimiento que los SSD. |
|
Almacenamiento de datos fríos |
OSS (almacenamiento en frío) |
Almacenamiento casi en línea y archivado de datos. El rendimiento de escritura coincide con el del almacenamiento en caliente, pero las QPS de lectura son limitadas y la latencia de lectura ronda las decenas de milisegundos. |
Discos en la nube
Los discos en la nube son escalables y se replican para garantizar redundancia. Son independientes del hardware físico, lo que protege contra la pérdida de datos por fallos de hardware. Los discos en la nube incluyen SSD y ultra disks.
Para aumentar la capacidad de almacenamiento después de crear el clúster, expanda los discos en la nube existentes o agregue más nodos principales.
Discos locales
Los discos locales son discos físicos conectados a instancias de ECS. Cuestan menos que los discos en la nube, pero no se pueden escalar de forma independiente: la especificación del nodo principal determina el tamaño del disco.
Para aumentar la capacidad de almacenamiento, agregue más nodos principales. No puede ampliar la capacidad actualizando la instancia de ECS.
Si falla un solo disco, no se pierden datos. Si se dañan dos o más discos físicos, las cargas de trabajo se ven afectadas. El equipo de soporte de ApsaraDB for HBase reemplaza rápidamente los discos dañados.
Los discos locales tienen costos iniciales altos y son adecuados para cargas de trabajo con grandes volúmenes de datos.
Almacenamiento en frío
El almacenamiento en frío es un nivel basado en Object Storage Service (OSS) dedicado a ApsaraDB for HBase. Úselo junto con discos en la nube para almacenar datos a los que se accede con poca frecuencia, o habilite la separación de datos calientes y fríos para archivar automáticamente los datos fríos y reducir costos.
A diferencia de los discos en la nube y los discos locales, el almacenamiento en frío no necesita seleccionarse al crear el clúster. Habilite y expanda el almacenamiento en frío en cualquier momento después de crear el clúster.