Esta entrada de blog se publicó en Hortonworks.com antes de la fusión con Cloudera. Es posible que algunos enlaces, recursos o referencias ya no sean precisos.
Resumen
A medida que se incorporan más y más cargas de trabajo al hardware moderno en la nube, es importante que comprendamos cómo elegir las mejores bases de datos que puedan aprovechar el mejor hardware. Amazon ha introducido instancias con SSD (unidad de estado sólido) conectada directamente. Tanto Apache HBase como Apache Cassandra son bases de datos clave-valor populares. En este punto de referencia, esperamos obtener más información sobre cómo aprovechan el SSD conectado directamente en un entorno de nube.
Diseño del benchmark
El punto de referencia está diseñado para ejecutar Apache HBase y Apache Cassandra en un entorno de producción óptimo. Esto significa usar una máquina diseñada para operaciones de alto io con SSD conectado directamente. Hemos colocado registros de escritura anticipada/registro de confirmación, así como almacenamiento de datos en SSD. Anteriormente, numerosos puntos de referencia ya han confirmado que ambas soluciones pueden escalar linealmente, por lo que la prueba de escalado está fuera del alcance de este punto de referencia.
Resultados
Análisis
A lo largo de nuestro punto de referencia, hemos visto que HBase superó constantemente a Cassandra en cargas de trabajo de lectura intensiva. Esto se alinea bien con los casos de uso clave de HBase, como motores de búsqueda, aplicaciones de transacciones de alta frecuencia, análisis de datos de registro y aplicaciones de mensajería. HBase destaca en las cargas de trabajo en las que escanear tablas bidimensionales enormes es un requisito. Por otro lado, Cassandra funcionó bien en el intercambio de cargas de trabajo de escritura pesada con consistencia. Por lo tanto, es más adecuado para la recopilación de datos analíticos o la recopilación de datos de sensores cuando la coherencia a lo largo del tiempo es aceptable.
Otro factor a considerar al elegir soluciones es también si existen conjuntos de herramientas correspondientes para analizar los datos. En el caso de HBase, que se construyó sobre la plataforma Apache Hadoop, admite Map Reduce y una variedad de conectores a otras soluciones como Apache Hive y Apache Spark para permitir consultas de agregación más grandes y análisis complejos.
Configuración de prueba
Máquina:
El grupo de prueba consta de 5 máquinas. Detalles de la máquina:
AWS I3.xgrande
GP2 de 60 GB para ejecutar SO
Almacenamiento NVMe conectado directamente, 0,95 TB
4 vCPU, cada vCPU (CPU virtual) es un hiperproceso de hardware en un procesador Intel E5-2686 v4 (Broadwell) que se ejecuta a 2,3 GHz.
30,5 GB de RAM
Para minimizar los problemas de vecinos ruidosos, realizamos las pruebas en instancias dedicadas de AWS.
Software de referencia:
Conjunto de datos de prueba:1 TB generado a través de YCSB
Conjunto de pruebas:https://github.com/brianfrankcooper/YCSB
Guión de prueba: https://github.com/2bethere/hbase-cassandra-bench
Software y entorno:
HDP 2.6.1
DSE 5.0.8
CentOS 7
Java 8
Para utilizar completamente el hardware, hemos cambiado el número de controladores por servidor regional en HBase a 120. Todas las demás configuraciones se dejan como predeterminadas. El conjunto completo de listas de configuración está disponible al final de esta publicación.
Durante la implementación, también seguimos la guía de optimización de Cassandra publicada aquí:http://docs.datastax.com/en/dse/5.1/dse-admin/datastax_enterprise/config/configRecommendedSettings.html
Los clientes de YCSB están ubicados en cada uno de los 5 nodos y se ejecutan simultáneamente para generar la carga. Durante la generación del conjunto de datos, redujimos el número de subprocesos a 40.
Metodología de prueba
Estamos cargando el conjunto de datos con 40 subprocesos para cada carga de trabajo dado que la distribución del conjunto de datos es diferente para cada punto de referencia. Después de la carga, esperamos que terminen todas las operaciones de compactación antes de comenzar la prueba de carga de trabajo. Cada carga de trabajo se ejecutó 3 veces con 5 000 000 de operaciones. El número promedio se toma de 3 pruebas para producir el número final.
Acerca de YCSB
YCSB o Yahoo! Cloud Serving Benchmark es una herramienta comparativa de uso común. Proporciona resultados comparativos entre diferentes soluciones. Ejecutamos la carga de trabajo predeterminada proporcionada por YCSB.
Carga de trabajo A:actualización intensa
Ejemplo de aplicación:almacén de sesiones, registro de acciones recientes
Carga de trabajo B:leer principalmente
Ejemplo de aplicación:Etiquetado de fotos; agregar una etiqueta es una actualización, pero la mayoría de las operaciones son para leer etiquetas
Carga de trabajo C:solo lectura
Ejemplo de aplicación:caché de perfil de usuario, donde los perfiles se construyen en otro lugar (por ejemplo, Hadoop)
Carga de trabajo D:leer la última carga de trabajo
Ejemplo de aplicación:actualizaciones de estado de usuario; la gente quiere leer la información más reciente
Carga de trabajo E:distancias cortas
Ejemplo de aplicación:conversaciones encadenadas, donde cada escaneo es para las publicaciones en un hilo determinado (se supone que está agrupado por ID de hilo)
Carga de trabajo F:carga de trabajo de lectura, modificación y escritura
Ejemplo de aplicación:base de datos de usuarios, donde el usuario lee y modifica los registros de usuario o para registrar la actividad del usuario.
