Etiqueta: Vertica

Notas técnicas variadas sobre Vertica: cómo consultar la configuración de balanceo de carga entre nodos, cómo listar los nodos del clúster, y recomendaciones actualizadas de hardware para dimensionar un clúster nuevo.

1. Ver el tipo de balanceo de carga configurado

SELECT currentclientbalancingpolicy FROM vs_global_settings;

SELECT currentclientbalancingpolicy FROM vs_global_settings;

Vertica, al ser un motor distribuido (MPP), puede repartir las conexiones de clientes entre los distintos nodos del clúster de varias formas. Las políticas típicas que puede devolver esta consulta son:

• NONE — sin balanceo; el cliente siempre se conecta al nodo especificado explícitamente en la cadena de conexión.
• ROUNDROBIN — reparte las conexiones entrantes de forma secuencial entre todos los nodos disponibles, en turnos.
• RANDOM — asigna cada conexión nueva a un nodo elegido al azar entre los disponibles.

El balanceo de carga a nivel de conexión evita que todos los clientes se concentren en un solo nodo (normalmente el nodo inicial/coordinador), distribuyendo la carga de sesiones activas de forma más pareja entre todo el clúster.

2. Ver los nodos del clúster

SELECT node_name, node_address FROM nodes;

SELECT node_name, node_address FROM nodes;

La tabla de catálogo nodes es la referencia base para saber qué nodos componen el clúster y su dirección de red asociada. Para un diagnóstico más completo del estado de cada nodo (no solo su existencia), conviene ampliar la consulta:

SELECT node_name, node_address, node_state, node_type
FROM nodes;

SELECT node_name, node_address, node_state, node_type
FROM nodes;

node_state revela si el nodo está UP, DOWN, o en otro estado de transición — información crítica antes de asumir que el clúster completo está sano solo porque la consulta a nodes devolvió resultados (un nodo puede seguir apareciendo en el catálogo aunque esté caído).

Recomendaciones de hardware para Vertica

Memoria RAM

Referencia oficial: Vertica Generic Hardware Guide.

Alta disponibilidad: mínimo de nodos

Para tolerar la falla de un solo nodo sin que la base de datos completa quede inaccesible, la recomendación oficial es un mínimo de 3 nodos en el clúster — con menos de eso, la pérdida de un nodo puede dejar el clúster sin quórum suficiente para seguir operando.

Ejemplo en AWS EC2

Para una instancia c3.4xlarge (8 vCPUs), se recomiendan al menos 64–96 GB de RAM, siguiendo la misma proporción de GB por núcleo. Referencia: AWS EC2 Virtual Cores.

Consideraciones adicionales de CPU

Vertica es un motor particularmente sensible a la velocidad de reloj del procesador (CPU-bound), más que a la cantidad bruta de núcleos. Cuando se debe elegir entre un procesador más rápido con menos núcleos, o uno más lento con más núcleos, generalmente conviene priorizar la velocidad de reloj — más núcleos ayudan principalmente a que el clúster procese varias consultas y cargas de datos en paralelo, pero no aceleran una consulta individual tanto como un reloj más rápido.

Homogeneidad del hardware entre nodos

Se recomienda que todos los nodos del clúster tengan una configuración de hardware similar (CPU, velocidad de reloj, núcleos, memoria, versión de sistema operativo). Vertica no está probado oficialmente sobre clústeres con hardware heterogéneo — funcionalmente puede operar así, pero el rendimiento general del clúster queda limitado al del nodo más lento.

Resumen práctico

• Antes de dar por sano un clúster, verificar tanto la existencia de los nodos (SELECT * FROM nodes) como su estado real (node_state = 'UP').
• Al dimensionar hardware nuevo, partir de la regla de 8–12 GB de RAM por núcleo físico como mínimo razonable, ajustando hacia arriba según la intensidad de la carga analítica esperada.
• Mantener el hardware homogéneo entre todos los nodos del mismo clúster para evitar cuellos de botella causados por el nodo más débil.
• Nunca desplegar un clúster productivo con menos de 3 nodos si la alta disponibilidad es un requisito.

Versión probada: Vertica 11.x — sintaxis y vistas de catálogo vigentes también en 12.x, 23.x, 24.x y la línea actual 26.x, sin cambios.

Un caso común al revisar un DDL heredado en Vertica: encontrar una columna definida con DEFAULT nextval('esquema.secuencia') y necesitar confirmar que esa secuencia realmente existe, antes de asumir que el DDL es válido.

id int NOT NULL DEFAULT nextval('public.seq_ejemplo')

id int NOT NULL DEFAULT nextval('public.seq_ejemplo')

nextval() en Vertica vs. PostgreSQL

Vertica sí soporta DEFAULT nextval('esquema.secuencia') en la definición de una columna, igual que PostgreSQL — pero con una diferencia importante que suele generar confusión a quienes vienen de ese motor: Vertica no crea secuencias automáticamente. En PostgreSQL, una columna SERIAL crea su secuencia asociada de forma implícita; en Vertica, la secuencia debe existir previamente, creada de forma explícita con CREATE SEQUENCE, antes de poder referenciarla en cualquier DEFAULT nextval(...).

Verificar si una secuencia existe

La vista correcta del catálogo del sistema para esto es v_catalog.sequences:

SELECT *
FROM v_catalog.sequences
WHERE sequence_schema = 'public'
  AND sequence_name = 'seq_ejemplo';

SELECT *
FROM v_catalog.sequences
WHERE sequence_schema = 'public'
  AND sequence_name = 'seq_ejemplo';

Para listar todas las secuencias existentes en la base de datos, con su valor actual:

SELECT sequence_schema, sequence_name, current_value
FROM v_catalog.sequences;

SELECT sequence_schema, sequence_name, current_value
FROM v_catalog.sequences;

Si la consulta devuelve una fila con un current_value numérico, la secuencia existe y está activa — el DDL que la referencia es válido y funcionará correctamente al insertar nuevas filas.

Ver dependencias entre tabla y secuencia

Para confirmar específicamente qué tabla(s) están usando una secuencia determinada (útil antes de eliminar o modificar una secuencia, para no romper nada):

SELECT *
FROM v_catalog.sequence_dependencies
WHERE sequence_name = 'seq_ejemplo';

SELECT *
FROM v_catalog.sequence_dependencies
WHERE sequence_name = 'seq_ejemplo';

Columnas IDENTITY vs. secuencias nombradas

Vale la pena distinguir dos mecanismos distintos que Vertica ofrece para autoincrementar valores:

• Columnas IDENTITY — se definen directamente en el DDL de la tabla (id IDENTITY(1,1)) y Vertica crea automáticamente una secuencia interna asociada, visible también en v_catalog.sequences, pero gestionada implícitamente junto con la tabla.
• Secuencias nombradas — creadas explícitamente con CREATE SEQUENCE, y luego referenciadas manualmente con nextval('esquema.nombre') en el DEFAULT de una o más columnas. Este es el caso descrito en este artículo.

La diferencia práctica más importante: una secuencia nombrada puede ser compartida entre varias tablas o columnas distintas si así se diseña, mientras que una columna IDENTITY está atada exclusivamente a la tabla donde se definió.

Comportamiento distribuido de las secuencias

Al ser Vertica un motor distribuido (MPP), las secuencias no funcionan exactamente igual que en un motor de un solo nodo: cada nodo del clúster mantiene su propia caché local de valores de secuencia durante una sesión, y las solicita de forma independiente conforme las va necesitando. Esto garantiza que todos los valores generados sean únicos, pero como consecuencia, los valores de nextval() pueden aparecer no consecutivos si distintos nodos están insertando datos en paralelo — es un comportamiento esperado y normal en Vertica, no un error.

Detalle adicional: simplificar expresiones de timestamp

Un ajuste menor mencionado durante la revisión del DDL — la expresión con cast explícito:

(statement_timestamp())::timestamp

(statement_timestamp())::timestamp

Puede simplificarse, ya que statement_timestamp() ya retorna un tipo timestamp nativo, haciendo el cast redundante:

DEFAULT statement_timestamp()

DEFAULT statement_timestamp()

Resumen del flujo de verificación

1. Confirmar que la secuencia existe con SELECT * FROM v_catalog.sequences WHERE sequence_name = '...'.
2. Si no existe, crearla explícitamente con CREATE SEQUENCE antes de referenciarla en cualquier DEFAULT nextval(...).
3. Revisar v_catalog.sequence_dependencies antes de modificar o eliminar una secuencia en uso, para identificar todas las tablas que dependen de ella.
4. Recordar que los valores pueden no ser consecutivos en un clúster con varios nodos activos — no es un bug, es el comportamiento distribuido esperado.