Etiqueta: bases-de-datos

  • ROW_NUMBER, SUM y MAX con PARTITION BY

    Las funciones de ventana (window functions) en SQL permiten hacer cálculos sobre un conjunto de filas relacionadas sin colapsar el resultado, a diferencia de GROUP BY. La cláusula OVER define esa «ventana» de filas, y PARTITION BY la divide en grupos — como un GROUP BY que no oculta el detalle de cada fila.

    Datos de ejemplo

    Partimos de esta tabla base para todos los ejemplos:

    deptocodnombre
    1100Fran
    1101Chris
    2102Alberto
    2103Hernan
    3104Julia

    ROW_NUMBER con PARTITION BY

    Este ejemplo numera las filas dentro de cada departamento, ordenadas por código. El contador se reinicia en 1 cada vez que cambia el valor de depto:

    SELECT depto, cod, nombre,
        ROW_NUMBER() OVER (PARTITION BY depto ORDER BY cod) AS rw
    FROM departamentos

    Resultado

    deptocodnombrerw
    1100Fran1
    1101Chris2
    2102Alberto1
    2103Hernan2
    3104Julia1

    RANK y DENSE_RANK: variantes de numeración

    ROW_NUMBER siempre da números consecutivos únicos, incluso si hay empates. Si necesitas que los empates compartan posición, existen dos alternativas:

    • RANK() — da la misma posición a los empates, pero deja «huecos» en la numeración siguiente (1, 1, 3).
    • DENSE_RANK() — da la misma posición a los empates, sin dejar huecos (1, 1, 2).
    SELECT depto, cod, nombre,
        RANK() OVER (PARTITION BY depto ORDER BY cod) AS posicion_rank,
        DENSE_RANK() OVER (PARTITION BY depto ORDER BY cod) AS posicion_dense
    FROM departamentos

    Suma de ventas por día

    Calcula el total acumulado de ventas partiendo los datos por fecha. Al usar ORDER BY dentro de OVER, la suma se vuelve un running total: cada fila acumula el valor de las anteriores dentro de su misma partición:

    SELECT fecha, venta_dia,
        SUM(venta_dia) OVER (PARTITION BY fecha ORDER BY fecha DESC) AS suma_acumulada
    FROM ventas

    Sueldos máximos por departamento

    Obtiene el sueldo más alto dentro de cada departamento, sin agrupar ni perder las filas individuales — cada empleado sigue apareciendo en su propia fila, junto al máximo de su equipo:

    SELECT depto, nombre, sueldo,
        MAX(sueldo) OVER (PARTITION BY depto) AS sueldo_max_depto
    FROM empleados

    LAG y LEAD: comparar con la fila anterior o siguiente

    Otro uso común de OVER es comparar el valor de una fila con el de la fila anterior o siguiente dentro de la misma partición — útil para calcular variaciones día a día o mes a mes:

    SELECT depto, cod, nombre,
        LAG(cod) OVER (PARTITION BY depto ORDER BY cod) AS cod_anterior,
        LEAD(cod) OVER (PARTITION BY depto ORDER BY cod) AS cod_siguiente
    FROM departamentos

    Por qué usar OVER en vez de GROUP BY

    La diferencia clave es que GROUP BY reduce el número de filas del resultado (una por grupo), mientras que OVER/PARTITION BY mantiene todas las filas originales y solo agrega una columna calculada junto a cada una. Esto es especialmente útil cuando necesitas comparar el valor de una fila contra un agregado de su grupo (como el sueldo máximo del departamento) sin perder el detalle individual.

  • Gestión de licencia Community Edition en Vertica

    El sistema arrojó una advertencia crítica de cumplimiento debido al desbordamiento de la capacidad de datos permitida por la Community Edition (CE) de Vertica.

    Resumen del problema

    Estos son los datos clave de la alerta:

    • Límite de la licencia gratuita: 1.00 TB de datos crudos (raw data) y un máximo de 3 nodos.
    • Estado actual del servidor: 1.94 TB de datos crudos utilizados (194% de utilización).
    • Impacto: aunque la base de datos sigue operando, se requiere una acción correctiva (limpieza o actualización) para evitar restricciones estrictas o bloqueos en futuras inserciones de datos.

    1. Auditoría y control de la licencia

    Para verificar oficialmente el espacio que el motor de Vertica calcula de cara al cumplimiento del contrato (basado en el tamaño del dato crudo antes de ser comprimido).

    Ver el último resultado de auditoría — monitorea las columnas license_size_bytes (permitido) y database_size_bytes (consumo real):

    SELECT * FROM V_CATALOG.LICENSE_AUDITS ORDER BY audit_start_timestamp DESC LIMIT 1;

    Forzar un recálculo manual de la licencia — Vertica realiza esta auditoría de forma automática en ciertos intervalos. Si haces una limpieza masiva de datos, debes forzar al motor a reevaluar el espacio:

    SELECT SELECT_LICENSE_AUDIT();

    2. Diagnóstico de espacio (tablas y disco físico)

    Comandos para identificar qué elementos específicos están saturando el almacenamiento.

    Identificar el tamaño comprimido por esquema y tabla — muestra cuánto pesan los datos optimizados dentro del disco:

    SELECT 
        schema_name, 
        anchor_table_name AS table_name, 
        SUM(used_bytes) / 1024 / 1024 / 1024 AS compressed_size_gb
    FROM 
        V_MONITOR.PROJECTION_STORAGE
    GROUP BY 
        schema_name, 
        anchor_table_name
    ORDER BY 
        compressed_size_gb DESC;

    Estimar el tamaño crudo de un objeto específico — para saber cuánto aporta una sola tabla al contador de la licencia:

    SELECT AUDIT('nombre_esquema.nombre_tabla');

    Ver el espacio libre en el sistema operativo (por nodo) — para prevenir el llenado absoluto de los discos duros físicos asignados a Vertica:

    SELECT 
        node_name, 
        storage_path, 
        storage_usage, 
        disk_space_used_mb, 
        disk_space_free_mb 
    FROM 
        V_MONITOR.DISK_STORAGE;

    3. Liberación de espacio permanente: el proceso PURGE

    Por diseño, cuando ejecutas un DELETE o un UPDATE en Vertica, los registros no se borran del disco, sino que se marcan como ocultos en un Delete Vector. Siguen consumiendo espacio y sumando a la licencia hasta que se limpian físicamente.

    El comando PURGE reorganiza el almacenamiento columnar y elimina definitivamente esos bytes de desecho.

    Paso 1: mover la marca de historia al presente (AHM) — Vertica protege los borrados recientes para permitir consultas al pasado (AT EPOCH). Si necesitas espacio inmediato, debes obligar al sistema a consolidar el tiempo histórico:

    SELECT MAKE_AHM_NOW();

    Paso 2: ejecutar la limpieza física de los datos eliminados

    Para una tabla específica (recomendado):

    SELECT PURGE_TABLE('nombre_esquema.nombre_tabla_pesada');

    Para toda la base de datos (alto consumo de recursos):

    SELECT PURGE();

    Paso 3: actualizar el estado de la licencia

    SELECT SELECT_LICENSE_AUDIT();

    Estado actual de Vertica y actualizaciones (versión 26)

    • Evolución del versionado: Vertica abandonó la numeración tradicional (10, 11, 12). Ahora utiliza una nomenclatura basada en el año de lanzamiento. La versión más reciente del mercado es Vertica 26.1 (2026).
    • Disponibilidad gratuita: la versión Community Edition (CE) sigue existiendo y se puede descargar desde el portal unificado de OpenText (o mediante contenedores Docker). Conserva exactamente las mismas reglas: gratis hasta 1.00 TB y 3 nodos.
    • Estrategia de migración: no se recomienda actualizar a la versión 26 con la base de datos saturada en 1.94 TB, ya que el nuevo motor mantendrá el bloqueo por exceso de almacenamiento. El plan de acción ideal es purgar los datos en la versión 10.1 actual hasta estar por debajo de 1.00 TB, y posteriormente realizar el salto de versión.