Consejos para la resolución de problemas de rendimiento de Actian Vector en Hadoop
Actian Vector pasó a llamarse Actian Analytics Engine en 2026.
Actian Vector y Vector en Hadoop son herramientas potentes 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 lograr mejoras graduales en las consultas.
El equipo de servicio y asistencia técnica de Actian colabora con nuestros clientes para identificar los aspectos comunes que deben analizarse a la hora de intentar mejorar el rendimiento de las consultas. La mayoría de nuestras recomendaciones se aplican tanto a Actian Vector (un solo nodo) como a Actian Vector en Hadoop (VectorH, un clúster de varios nodos en Hadoop).
Actian ha publicado recientemente un análisis detallado de aspectos técnicos y buenas prácticas para ayudar a todos los usuarios de Vector y VectorH a optimizar el rendimiento, prestando especial atención a VectorH.
A diferencia de los motores de consultas SQL de Hadoop (Hive, Impala, Spark SQL, etc.), VectorH es un auténtico SGBD colunar, MPP, con todas las capacidades de SQL, transacciones ACID (es decir, compatibilidad con actualizaciones y eliminaciones in situ), opciones de seguridad robustas integradas, etc. Esta flexibilidad permite que VectorH se optimice para cargas de trabajo y entornos complejos.
Ten en cuenta que Vector y VectorH son perfectamente capaces de ejecutar consultas de forma eficiente sin necesidad de recurrir a ninguna de las técnicas analizadas. No obstante, estas técnicas resultarán muy útiles para cargas de trabajo exigentes y entornos Hadoop con gran volumen de actividad, y te permitirán obtener los mejores resultados de tu plataforma.
A través de nuestro trabajo con los clientes, hemos constatado que es necesario analizar los siguientes aspectos para alcanzar el máximo rendimiento.
Divide tus tablas en particiones
Un aspecto muy importante a tener en cuenta en el diseño de esquemas para cualquier sistema de procesamiento masivamente paralelo (MPP), como VectorH, es cómo distribuir los datos por el clúster para equilibrar la ejecución de las consultas de forma uniforme entre todos los recursos disponibles. Si no se particionan explícitamente las tablas al crearlas, VectorH creará, por defecto, tablas no particionadas; sin embargo, para obtener el mejor rendimiento, siempre se deben particionar las tablas más grandes de la base de datos.
Evita el sesgo en los datos
Los datos desequilibrados, en los que un pequeño número de máquinas contiene muchos más datos que la mayoría de las demás, se conocen como «asimetría de datos». La asimetría de datos puede provocar graves problemas de rendimiento en las consultas, ya que la máquina con una cantidad desproporcionada de datos determina la velocidad global de las consultas y puede convertirse en un cuello de botella.
Datos estadísticos que faltan
Las estadísticas de distribución de datos son esenciales para elaborar correctamente un buen plan de consulta. A falta de estadísticas, el optimizador de consultas de VectorH parte de ciertas suposiciones por defecto sobre aspectos como el número de filas que coincidirán al unir dos tablas. Cuando se trabaja con conjuntos de datos de gran tamaño, es mucho mejor disponer de datos reales sobre la distribución efectiva de los datos, en lugar de basarse en estas estimaciones.
Clasificación de datos
El modelo relacional de procesamiento no requiere que los datos estén ordenados en el disco; en su lugar, se utiliza una cláusula ORDER BY en aquellas consultas que necesitan que los datos se devuelvan en una secuencia concreta.
Sin embargo, al utilizar los denominados índices MinMax (que se mantienen 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 los bloques de datos innecesarios del procesamiento y, por lo tanto, acelerar la ejecución de las consultas, cuando estas incluyen una cláusula WHERE o una restricción de unión en una columna según la cual está ordenada la tabla.
Utilización de los tipos de datos más adecuados
Al igual que con cualquier base de datos, elegir el tipo de datos adecuado para tu esquema y tus consultas puede influir considerablemente en el rendimiento de VectorH, así que no conviertas en una práctica habitual utilizar el tamaño máximo de columna por comodidad. En su lugar, ten en cuenta los valores más grandes que probablemente vayas a almacenar en una columna VARCHAR, por ejemplo, y define el tamaño de tus columnas en consecuencia.
Dado que VectorH comprime los datos de las columnas de forma muy eficaz, crear columnas mucho más grandes de lo necesario tiene un impacto mínimo en el tamaño de las tablas de datos. Como las columnas VARCHAR se almacenan internamente como cadenas terminadas en nulo, el tamaño de la columna VARCHAR no afecta en realidad a los tiempos de procesamiento de las consultas. Sin embargo, sí influye en los tiempos de comunicación con la interfaz de usuario, ya que los datos se almacenan con la longitud máxima definida una vez que salen del motor. No obstante, hay que tener en cuenta que almacenar datos que son intrínsecamente numéricos (ID, marcas de tiempo, etc.) como datos VARCHAR resulta muy perjudicial para el sistema, ya que VectorH puede procesar datos numéricos de forma mucho más eficiente que los datos de caracteres.
Gestión de la memoria para pequeños cambios
VectorH cuenta con un mecanismo, cuya patente está en trámite, que permite gestionar de forma eficiente numerosos cambios menores en los datos, denominado «Positional Delta Trees» (PDT). Estos también permiten utilizar sentencias de actualización y eliminación en datos almacenados en un sistema de archivos de solo adición, 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 a la hora de procesar cambios futuros y, con el tiempo, se agotará la memoria. La gestión de esta memoria se realiza de forma automática; no obstante, 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 esto suele ser transparente para el usuario.
Optimización para la concurrencia
VectorH está diseñado para permitir que una sola consulta se ejecute utilizando el mayor número posible de subprocesos de ejecución paralelos con el fin de alcanzar el máximo rendimiento. Sin embargo, aunque quizá resulte atípico para un sistema MPP, también está diseñado para permitir una alta concurrencia con una asignación equitativa de recursos cuando hay un gran número de consultas en el sistema. VectorH gestionará ambas situaciones con la configuración predeterminada, pero puede ajustarse para adaptarse a las necesidades de la aplicación (por ejemplo, si se desea dar cabida a un mayor rendimiento de consultas de gran carga limitando los recursos máximos que puede adquirir una sola consulta).
El número de conexiones simultáneas (64 por defecto) que aceptará una instancia determinada de VectorH viene determinado por el parámetro `connect_limit`, almacenado en el archivo `config.dat` y gestionado a través de la utilidad CBF. Sin embargo, suele haber más conexiones que consultas en ejecución, por lo que cabe preguntarse: ¿cómo se asignan los recursos entre las consultas simultáneas?
De forma predeterminada, VectorH intenta equilibrar las cargas de trabajo de una sola consulta y las de varias consultas. Los parámetros clave para lograr este equilibrio son:
- El número de núcleos de CPU del clúster VectorH.
- El número de subprocesos que puede utilizar una consulta.
- El número de subprocesos que el sistema asigna a una consulta.
- El número de consultas que se están ejecutando actualmente en el sistema.
Resumen
Vector y VectorH son perfectamente capaces de ejecutar consultas de forma eficiente sin necesidad de recurrir a ninguna de las técnicas y consejos que aquí se describen. Sin embargo, cuanto más exigente sea tu carga de trabajo —ya sea en términos de volumen de datos, complejidad de las consultas o concurrencia de usuarios—, más te permitirá obtener los mejores resultados de tu plataforma la aplicación de algunos de los consejos que se recogen en el informe completo.