Memoria, Persistencia y Almacenamiento

El paradigma in-memory

La característica definitoria de SAP HANA es que todos los datos operacionales residen en memoria RAM. Este cambio fundamental respecto a bases de datos tradicionales (donde datos viven en disco y se cachean temporalmente en memoria) proporciona la velocidad revolucionaria de HANA.

Sin embargo, in-memory no significa que HANA ignore el disco completamente. El almacenamiento persistente es esencial para durabilidad: garantizar que datos no se pierden si el servidor pierde energía, sufre crash, o requiere reinicio. La arquitectura de HANA equilibra performance in-memory con durabilidad basada en disco.

Jerarquía de memoria

La memoria en sistemas modernos tiene múltiples niveles con trade-offs entre velocidad, capacidad y coste. HANA está diseñado para operar primariamente en los niveles más rápidos.

Los CPU caches (L1, L2, L3) son extremadamente rápidos pero pequeños: decenas de KB a MB. HANA no controla estos caches directamente; son gestionados por hardware. Sin embargo, los algoritmos de HANA están optimizados para maximizar cache hits reduciendo cache misses que causan stalls de CPU.

La RAM principal es donde HANA almacena datos operacionales. Con capacidades de cientos de GB a TB, proporciona espacio suficiente para bases de datos empresariales completas. El acceso es extremadamente rápido (nanosegundos) comparado con disco (milisegundos).

El almacenamiento persistente (SSD/NVMe) es significativamente más lento que RAM pero mucho más barato por GB y no volátil. HANA usa disco para persistencia, no para operaciones normales. La velocidad de disco importa para operaciones de recovery, backup, y situaciones excepcionales donde memoria se agota.

Gestión de memoria HANA

El Global Allocation Limit es el parámetro fundamental que controla cuánta memoria HANA puede utilizar. Se configura típicamente como porcentaje de RAM física instalada (por ejemplo, 90%) dejando memoria para sistema operativo, otros procesos, y headroom para picos temporales.

Si un servidor tiene 512GB RAM, el Global Allocation Limit podría configurarse en 460GB. HANA monitoriza continuamente su uso de memoria contra este límite y toma acciones si se aproxima: liberar caches, rechazar nuevas operaciones, o en casos extremos unload datos menos usados a disco.

La arquitectura de memoria de HANA separa memoria en múltiples pools con propósitos específicos. Esta separación permite gestión más granular y previene que un tipo de operación consuma toda la memoria disponible.

El Code and Stack pool almacena código ejecutable y call stacks de threads. Es relativamente pequeño pero crítico: sin memoria para nuevos threads, el sistema no puede procesar nuevas solicitudes.

El Shared Memory pool contiene estructuras compartidas entre procesos: metadata de tablas, catálogo del sistema, configuración. Relativamente estable en tamaño; crece cuando se crean objetos nuevos pero no fluctúa dramáticamente.

El Row Store pool almacena datos de tablas row-based, tablas temporales, y estructuras transitorias. Las operaciones complejas crean tablas temporales intermedias aquí. El sizing adecuado previene out-of-memory errors durante queries complejas.

El Column Store pool es típicamente el pool más grande, almacenando todos los datos de tablas columnares. En sistema productivo típico, 70-80% de memoria total está asignada a column store porque ahí residen los datos de negocio.

Estructuras de memoria columnar

Las tablas columnares en memoria tienen estructura compleja optimizada para diferentes patrones de acceso y para permitir actualizaciones eficientes sin reescribir datos completos.

El Main Storage contiene datos históricos estables en formato altamente comprimido y optimizado para lectura. Los datos aquí rara vez cambian; se escribieron hace tiempo y están completamente optimizados. Las queries que leen datos históricos acceden principalmente main storage.

El Delta Storage mantiene cambios recientes: nuevas filas insertadas, modificaciones a datos existentes. Los datos aquí están menos comprimidos porque se esperan más cambios. Las escrituras van primero a delta storage donde pueden acumularse eficientemente.

La separación main/delta es fundamental para performance: las escrituras son rápidas (van a delta sin reorganizar estructuras masivas), las lecturas siguen siendo rápidas (main storage está altamente optimizado), y el sistema puede consolidar cambios periódicamente sin bloquear operaciones.

El Dictionary almacena valores únicos para dictionary encoding. Una columna con millones de filas pero solo miles de valores únicos tiene dictionary relativamente pequeño. El dictionary mapea cada valor único a un código numérico corto.

Los Attribute Vectors almacenan códigos del dictionary para cada fila. En lugar de almacenar "United States" millones de veces, almacena código 42 millones de veces. Como los códigos son enteros cortos, ocupan mucho menos espacio y procesan más rápido.

Delta Merge

El delta merge es proceso que consolida cambios del delta storage en main storage. Es operación crítica que mantiene balance entre performance de escritura y lectura.

Sin delta merge, el delta storage crecería indefinidamente. Las queries tendrían que escanear tanto main como delta (cada vez más grande), degradando performance de lectura. El merge periódico mantiene delta pequeño.

El proceso de merge lee datos de delta storage, los combina con main storage, reaplica compresión completa, reconstruye índices, y actualiza estructuras. Durante merge, la tabla permanece disponible; no hay downtime perceptible para usuarios.

El merge puede ser automático (HANA decide cuándo ejecutar basándose en tamaño de delta, tiempo desde último merge, y carga del sistema) o manual (administradores ejecutan merge explícitamente, útil para tablas específicas o timing controlado).

El auto merge decision considera múltiples factores: si delta alcanza cierto tamaño (por ejemplo, 10% de main), si ha pasado cierto tiempo desde último merge, si la carga del sistema es baja (merge consume recursos; HANA prefiere ejecutar cuando el sistema está idle).

Las tablas grandes pueden particionar merge: en lugar de mergear tabla completa, HANA mergea particiones individualmente. Esto distribuye carga de merge y reduce impacto en operaciones concurrentes.

El merge crítico ocurre cuando delta se llena completamente. Si delta alcanza límite y no puede aceptar más escrituras, HANA ejecuta merge inmediatamente incluso si impacta performance. Esta situación debe evitarse mediante merge proactivo regular.

Persistencia y durabilidad

Aunque HANA es in-memory, debe garantizar durabilidad transaccional: cambios committed no se pierden incluso si servidor crashea. La arquitectura de persistencia implementa garantías ACID sin sacrificar performance in-memory.

El principio write-ahead logging garantiza durabilidad: antes de que transacción se confirme, sus cambios se escriben a log en disco. Solo después de que log está seguro en disco, la transacción se considera committed. Si sistema crashea antes de persisting cambios de memoria a data volumes, el recovery reproduce el log recuperando todas las transacciones committed.

Esta estrategia permite que estructuras en memoria sean eventual consistent con disco. Los datos en memoria son siempre la versión authoritative; disco contiene snapshot ligeramente obsoleto más log de cambios recientes. El sistema puede reconstruir estado actual desde snapshot + log.

Data Volumes

Los data volumes almacenan snapshots de datos de tablas en disco. Son archivos grandes (típicamente varios GB cada uno) organizados en directorios específicos en filesystem.

Cada tabla tiene data volumes separados para main storage y delta storage. Las estructuras columnares (dictionaries, attribute vectors) persisten en formatos optimizados que permiten carga rápida durante startup.

La escritura a data volumes no ocurre con cada transacción (sería demasiado lento). En su lugar, ocurre durante savepoints periódicos cuando HANA escribe snapshot completo de estado actual. Entre savepoints, solo el log se actualiza.

El formato de data volumes está altamente optimizado. Los datos persisten en formato comprimido similar a formato en memoria. Durante startup, HANA puede mapear data volumes directamente a memoria con mínimo procesamiento, acelerando recovery.

Los data volumes antiguos no se borran inmediatamente durante savepoints. HANA mantiene versiones previas permitiendo rollback a snapshot anterior si necesario. La gestión de versiones de data volumes es automática; versiones muy antiguas se borran después de ser reemplazadas por savepoints más recientes.

Log Volumes

Los log volumes contienen redo logs que registran cada cambio de datos. Son el mecanismo crítico de durabilidad en HANA.

Cada transacción que modifica datos genera log entries describiendo los cambios. Antes de commit, estas entries se escriben (flush) a log volume en disco. Solo después de que write físico completa, la transacción puede confirmar a aplicación.

Los log volumes son archivos secuenciales append-only. Las escrituras secuenciales son mucho más rápidas que escrituras random, permitiendo que logging sea eficiente incluso con alto volumen de transacciones.

El tamaño de log segment define cuánto puede crecer un archivo de log individual antes de que HANA cree nuevo segment. Típicamente configurado en varios GB. Cuando segment actual se llena, HANA crea nuevo segment y continúa logging ahí.

Los log segments viejos pueden eliminarse después de savepoint que incluye todas las transacciones de ese segment. Si savepoint más reciente es posterior al log segment completo, ese segment ya no es necesario para recovery y puede archivarse o eliminarse.

La retención de logs debe balancear espacio en disco versus capacidad de recovery. Mantener más logs permite point-in-time recovery a momentos más antiguos, pero consume almacenamiento. Las políticas de retención definen cuánto historial mantener.

Savepoints

Un savepoint es checkpoint donde HANA escribe todo el estado de memoria a data volumes en disco y trunca el log. Es operación crítica que mantiene logs manejables y acelera recovery.

El savepoint automático ejecuta periódicamente (por ejemplo, cada 5 minutos o cuando log alcanza cierto tamaño). La frecuencia de savepoints balancea: savepoints frecuentes mantienen logs pequeños y recovery rápido, pero consumen I/O de disco. Savepoints infrecuentes reducen overhead de I/O pero alargan recovery y permiten que logs crezcan grandes.

Durante savepoint, HANA ejecuta múltiples fases: primero congela nuevas escrituras a estructuras específicas, escribe snapshot de esas estructuras a disco, actualiza metadata indicando que nuevo savepoint está completo, y finalmente permite reanudar escrituras. El proceso está altamente optimizado; el "freeze" es extremadamente breve.

El savepoint asíncrono permite que la mayoría del trabajo de savepoint ocurra en background sin bloquear transacciones. Solo una pequeña fase crítica al inicio y fin requiere sincronización. Durante la fase bulk de escritura de datos, las transacciones continúan normalmente.

Los savepoints completos escriben todo el contenido de memoria. Los savepoints incrementales (en ciertas configuraciones) escriben solo cambios desde último savepoint, reduciendo I/O pero requiriendo cadena de múltiples savepoints para recovery completo.

Startup y Recovery

Cuando HANA arranca (después de shutdown normal o crash), debe reconstruir estado completo de memoria desde disco. El proceso de recovery está altamente optimizado para minimizar tiempo de indisponibilidad.

La fase de carga lee data volumes del último savepoint completo y los mapea a memoria. Como data volumes están en formato similar a estructuras en memoria, esta carga es relativamente rápida incluso para bases de datos de múltiples TB.

La fase de log replay reproduce redo logs desde el último savepoint, aplicando todos los cambios committed que ocurrieron después del savepoint. Esto garantiza que el estado final incluye todas las transacciones committed hasta el momento del crash.

El parallel recovery distribuye trabajo de recovery entre múltiples threads y cores. Diferentes tablas pueden cargarse simultáneamente, y log replay puede paralelizarse donde transacciones son independientes. Esto reduce dramáticamente tiempo de recovery en sistemas grandes.

La fase de validación verifica integridad de datos cargados, reconstruye índices necesarios, y ejecuta consistency checks. Solo después de validación exitosa, HANA acepta conexiones de aplicaciones.

El tiempo de recovery en HANA es típicamente minutos incluso para bases de datos de múltiples TB, dramáticamente más rápido que bases de datos tradicionales donde recovery puede llevar horas. Esto mejora RTO (Recovery Time Objective) significativamente.

Gestión de situaciones Out-of-Memory

Cuando HANA se aproxima al Global Allocation Limit, debe tomar acciones para prevenir out-of-memory crash que causaría indisponibilidad del sistema.

La liberación de caches es primera línea de defensa. HANA mantiene múltiples caches (result cache, statement cache, metadata cache) que mejoran performance pero no son esenciales. Cuando memoria escasea, estos caches se liberan proporcionando memoria para operaciones críticas.

El unload de tablas a disco permite que HANA expulse temporalmente tablas poco usadas de memoria. Los datos persisten en data volumes; cuando se acceden nuevamente, se recargan. Esta capacidad previene que tablas raramente accedidas consuman memoria permanentemente.

El rechazo de nuevas operaciones ocurre cuando liberación de caches y unloading no liberan suficiente memoria. HANA rechaza queries nuevas o complejas que requerirían memoria significativa, devolviendo error a aplicación. Operaciones en curso continúan, pero nuevas solicitudes fallan hasta que memoria se libere.

El out-of-memory crash es último recurso cuando todas las estrategias de gestión fallan. El sistema se detiene abruptamente. Esto es preferible a corrupción de datos que podría ocurrir si sistema continúa operando sin memoria suficiente. Tras crash, recovery normal reconstruye estado consistente.

La prevención proactiva mediante monitorización de uso de memoria y alertas tempranas permite intervención antes de situaciones críticas: añadir más memoria, optimizar queries que consumen memoria excesiva, o archivar datos obsoletos reduciendo footprint de memoria.

Optimización de memoria

El sizing correcto de memoria es fundamental para performance óptimo. Memoria insuficiente causa out-of-memory errors y degradación de performance. Memoria excesiva es desperdicio de inversión (RAM es cara).

El análisis de consumo de memoria identifica qué tablas consumen más memoria. Las tablas grandes que se acceden raramente son candidatas para archivado o particionamiento con particiones antiguas en almacenamiento más barato.

La compresión avanzada reduce footprint de memoria. HANA soporta múltiples niveles de compresión; más agresiva reduce tamaño pero incrementa CPU para descompresión. El balance óptimo depende de workload específico.

El particionamiento de tablas muy grandes permite que particiones antiguas se unloaden de memoria mientras particiones recientes permanecen hot. Una tabla de transacciones con años de historial puede particionar por fecha: últimos 2 años en memoria, historial más antiguo unloaded.

La eliminación de índices innecesarios libera memoria. A diferencia de bases de datos tradicionales donde índices son críticos, HANA frecuentemente no necesita índices secundarios. Cada índice consume memoria; auditar y eliminar índices no utilizados recupera memoria.

Almacenamiento en disco

Aunque HANA opera in-memory, las características del almacenamiento en disco impactan significativamente operaciones específicas: savepoints, logging, backups, y recovery.

El tipo de almacenamiento debe ser enterprise-grade: SSD o NVMe con alta IOPS y baja latencia. Los discos tradicionales HDD son inadecuados; su latencia alta degradaría operaciones de persistencia y recovery intolerablemente.

El throughput de escritura secuencial importa para logging y savepoints. HANA escribe grandes volúmenes de datos durante estas operaciones; almacenamiento con bajo throughput secuencial causa cuellos de botella.

La redundancia es crítica. Los data volumes y log volumes deben estar en almacenamiento con protección contra fallos de disco: RAID, storage array con redundancia, o filesystem con replicación. Pérdida de data volumes o logs sin backup reciente causa pérdida de datos catastrófica.

El tamaño de almacenamiento debe considerar: data volumes (típicamente igual o ligeramente mayor que tamaño de datos en memoria debido a estructuras de persistencia), log volumes (depende de frecuencia de savepoints y volumen transaccional), y espacio para backups si se almacenan localmente.

Multi-temperature Data Management

No todos los datos son igualmente importantes para performance. Los datos "calientes" (hot data) accedidos frecuentemente deben estar en memoria rápida. Los datos "fríos" (cold data) raramente accedidos pueden almacenarse en medios más lentos y baratos.

El Native Storage Extension (NSE) permite que tablas específicas o particiones almacenen datos en disk-based extension en lugar de memoria. Los datos persisten en formato columnar optimizado en disco; se cargan a memoria solo cuando se acceden.

El Dynamic Tiering integra HANA con almacenamiento columnar basado en disco para datos muy fríos. Los datos históricos que rara vez se consultan pueden moverse a dynamic tiering, liberando memoria preciosa para datos activos.

El Data Aging determina automáticamente qué datos son calientes versus fríos basándose en patterns de acceso. Aplicaciones pueden definir políticas de aging que mueven datos automáticamente a tiers apropiados según edad, frecuencia de acceso, o reglas de negocio.

Mejores prácticas

Dimensiona memoria con headroom adecuado. Operar consistentemente cerca del Global Allocation Limit causa problemas. Apunta a utilización máxima del 75-80% dejando buffer para picos y operaciones complejas.

Monitoriza tendencias de consumo de memoria a largo plazo. El crecimiento gradual de uso de memoria indica que eventualmente necesitarás más memoria o debes archivar datos.

Configura alertas de memoria en múltiples umbrales: warning al 70%, crítico al 85%, emergencia al 95%. Esto permite intervención progresiva antes de situaciones desesperadas.

Ejecuta delta merge regular en tablas con alta tasa de escritura. No confíes solo en auto merge; tablas críticas pueden beneficiarse de merge manual durante ventanas de mantenimiento.

Revisa periódicamente qué tablas consumen más memoria. Identifica candidatos para archivado, particionamiento, o movimiento a cold storage.

Prueba recovery regularmente. No esperes hasta crash real para descubrir que recovery toma más tiempo del esperado o que hay problemas con configuración de persistencia.

Temas relacionados

Para profundizar en memoria y persistencia HANA, consulta:

Arquitectura de SAP HANA para contexto de cómo memoria se integra en arquitectura general.

Column Store vs Row Store para estructuras de datos específicas en memoria.

Backups y recuperación para protección de datos y recovery detallado.

Performance y tuning para optimización de uso de memoria.

Monitorización para vigilar consumo de memoria y alertas.

Problemas comunes para troubleshooting de issues de memoria.