Consejos para solucionar problemas de rendimiento de Actian Vector en Hadoop
Actian Vector y Vector en Hadoop son potentes herramientas para ejecutar consultas de forma eficiente. Sin embargo, la mayoría de los usuarios de plataformas de análisis de datos buscan formas de optimizar el rendimiento para obtener mejoras incrementales en las consultas.
El equipo de Servicio y Soporte de Actian trabaja con nuestros clientes para identificar las áreas comunes que deben ser investigadas cuando se trata de mejorar el rendimiento de las consultas. La mayoría de nuestras recomendaciones se aplican tanto a Actian Vector (nodo único) como a Actian Vector en Hadoop (VectorH, un clúster multinodo en Hadoop).
Actian ha publicado recientemente una visión general en profundidad de los conocimientos técnicos y las mejores prácticas para ayudar a todos los usuarios de Vector y VectorH a optimizar el rendimiento, con especial atención a VectorH.
A diferencia de los motores de consulta SQL en Hadoop (Hive, Impala, Spark SQL, etc.) VectorH es un verdadero RDBMS columnar, MPP, con capacidades completas de SQL, transactions acid (es decir, soporte para actualizaciones y eliminaciones en el lugar), opciones de seguridad robustas incorporadas, etc. Esta flexibilidad permite optimizar VectorH para cargas de trabajo y entornos complejos.
Ten en cuenta que Vector y VectorH son muy capaces de ejecutar consultas de forma eficiente sin utilizar ninguna de las técnicas examinadas. No obstante, estas técnicas resultarán muy útiles para cargas de trabajo exigentes y entornos Hadoop muy concurridos, y te permitirán obtener los mejores resultados de tu plataforma.
A través de nuestro trabajo con los clientes, hemos descubierto que deben investigarse las siguientes áreas para lograr el máximo rendimiento.
Partición de tablas
Una consideración muy importante en el diseño de esquemas para cualquier sistema de Procesamiento Paralelo Masivo (MPP) como VectorH es cómo distribuir los datos en un cluster para equilibrar la ejecución de consultas de manera uniforme en todos los recursos disponibles. Si no particionas explícitamente tus tablas cuando son creadas, VectorH creará por defecto tablas no particionadas - pero para un mejor rendimiento, siempre debes particionar las tablas más grandes de tu base de datos.
Evitar la desviación de los datos
Los datos desequilibrados, en los que un pequeño número de máquinas tiene muchos más datos que la mayoría de las demás, se conoce como desviación de datos. El desequilibrio de datos puede causar graves problemas de rendimiento en las consultas, ya que la máquina con la cantidad desproporcionada de datos gobierna la velocidad general de la consulta y puede convertirse en un cuello de botella.
Estadísticas pendientes
Las estadísticas de distribution des données son esenciales para la correcta creación de un buen plan de consulta. En ausencia de estadísticas, el optimizador de consultas VectorH hace ciertas suposiciones por defecto sobre cosas como cuántas filas coincidirán cuando se unan dos tablas. Cuando se trabaja con grandes conjuntos de datos, es mucho mejor disponer de datos reales sobre la distribución real de los datos, en lugar de confiar en estas estimaciones.
Clasificación de datos
El modelo relacional de procesamiento no requiere que los datos estén ordenados en el disco, sino que se utiliza una cláusula ORDER BY en una consulta que necesita los datos en una secuencia determinada.
Sin embargo, mediante el uso de lo que se conoce como índices MinMax (mantenidos automáticamente dentro de la estructura de una tabla sin intervención del usuario), VectorH es capaz de utilizar datos ordenados para eliminar de forma más eficiente bloques innecesarios de datos del procesamiento y, por tanto, acelerar la ejecución de consultas, cuando éstas tienen una cláusula WHERE o una restricción join sobre una columna en la que la tabla está ordenada.
Utilizar los tipos de datos más adecuados
Como en cualquier base de datos, elegir el tipo de datos adecuado para tu esquema y tus consultas puede marcar una gran diferencia en el rendimiento de VectorH, así que no acostumbres a utilizar el tamaño máximo de columna por comodidad. En su lugar, considere los valores más grandes que es probable que almacene en una columna VARCHAR, por ejemplo, y dimensione sus columnas en consecuencia.
Dado que VectorH comprime los datos de las columnas de forma muy eficaz, la creación de columnas mucho más grandes de lo necesario tiene un impacto mínimo en el tamaño de las tablas de datos. Dado que las columnas VARCHAR se almacenan internamente como cadenas terminadas en cero, el tamaño de VARCHAR no tiene ningún efecto sobre los tiempos de procesamiento de las consultas. Sin embargo, sí influye en los tiempos de comunicación del frontend, ya que los datos se almacenan como la longitud máxima definida después de salir del motor. Nótese sin embargo que almacenar datos que son inherentemente numéricos (IDs, timestamps, etc) como datos VARCHAR es muy perjudicial para el sistema, ya que VectorH puede procesar datos numéricos mucho más eficientemente que datos de caracteres.
Gestión de memoria para pequeños cambios
VectorH cuenta con un mecanismo pendiente de patente para gestionar de forma eficiente muchos cambios pequeños en los datos, denominado Positional Delta Trees (PDT). Estos también permiten el uso de sentencias de actualización y borrado en datos almacenados en un sistema de archivos de solo apéndice como HDFS.
Sin embargo, si se ejecutan muchas sentencias de actualización, inserción o eliminación, el uso de memoria para las estructuras PDT puede aumentar rápidamente. Si se utiliza una gran cantidad de memoria, el sistema puede ralentizarse al procesar cambios futuros y, finalmente, se agotará la memoria. La gestión de esta memoria se realiza de forma automática, pero el usuario también puede emitir directamente una instrucción «combine», que fusionará los cambios del PDT con la tabla principal en un proceso denominado propagación de actualizaciones. Existen varios desencadenantes que hacen que el sistema realice este mantenimiento automáticamente en segundo plano (como los umbrales de memoria total utilizada para los PDT o el porcentaje de filas actualizadas), por lo que suele ser transparente para el usuario.
Optimización de simultanéité
VectorH está diseñado para permitir que una sola consulta se ejecute utilizando tantos subprocesos de ejecución paralelos como sea posible para alcanzar el máximo rendimiento. Sin embargo, aunque quizá sea atípico para un sistema MPP, también está diseñado para permitir una alta concurrencia con una asignación democrática de recursos cuando hay un gran número de consultas en el sistema. VectorH gestionará ambas situaciones con la configuración predeterminada, pero se puede ajustar para adaptarse a las necesidades de la aplicación (por ejemplo, si se desea atender un mayor rendimiento de consultas pesadas reduciendo los recursos máximos que puede adquirir cualquier consulta).
El número de conexiones simultáneas (64 por defecto) que acepta una instancia de VectorH se rige por el parámetro connect_limit, almacenado en config.dat y gestionado a través de la utilidad CBF. Pero normalmente hay más conexiones que consultas ejecutándose, así que ¿cómo se distribuyen los recursos entre las consultas concurrentes?
Por defecto, VectorH intenta equilibrar las cargas de trabajo de una y varias consultas. Los parámetros clave para equilibrar esto son:
- Número de núcleos processeur en el cluster VectorH.
- Número de hilos que puede utilizar una consulta.
- Número de hilos que el sistema concede a una consulta.
- Número de consultas que se están ejecutando actualmente en el sistema.
Resumen
Vector y VectorH son muy capaces de ejecutar consultas de forma eficiente sin necesidad de utilizar ninguna de las técnicas y consejos aquí descritos. Pero cuanto más exigente sea su carga de trabajo, ya sea en términos de volúmenes de datos, complejidad de las consultas o simultanéité los usuarios, la aplicación de algunos de los consejos definidos en el informe completo le permitirá obtener los mejores resultados de su plataforma.
Manténgase conectado
Información detallada sobre los datos a su disposición.
(por ejemplo, ventas@..., asistencia@...)
