SAP HANA: USO DE MEMORIA

La forma en como HANA consume la memoria RAM de un servidor principalmente ligada a cada
servicio es mucho más intensa que una Base de Datos tradicional, esto porque el uso que le da es
completamente diferente, en su misma definición SAP HANA fue diseñado en las capacidades
actuales de hardware la cual ha cambiado mucho a por ejemplo hace 5 u 7 años, donde las
limitantes en la arquitectura de computadoras eran siempre el dilema del cuello de botella de Von
Newmann la transmisión de información de un lado a otro siempre siendo más grande los datos
que el mismo canal para transmitirlos, generando enormes retrasos entre diferentes componentes
de la misma PC, por ejemplo el disco duro y la memoria RAM, este dilema está cada vez quedando
más en el pasado debido a la necesidad de análisis de enormes volúmenes de datos, teniendo hoy
en día arquitecturas en cluster capaces de tener TB en RAM y cientos de procesadores trabajando
como uno mismo:

Aprovechando estas nuevas innovaciones HANA desenreda el hilo y transforma la necesidad de

uso de discos rígidos mecánicos y los reemplaza por el uso de memoria RAM completamente,
soportando la información importante directamente en RAM y sin la necesidad de tener que pasar
datos entre estos dos dispositivos, aunque eso no quiere decir que no utilice discos duros, por el
contrario los utiliza pero para datos persistentes poco leídos y además los utiliza con discos SSD
que pueden dar lecturas insuperables contra los típicos discos mecánicos con velocidades
mínimas de 10x más que los rígidos, sumando a esto que cualquier necesidad de lectura será aún
más rápida.

Solo por explorar un equipo disponible en la actualidad y ponerlo como ejemplo:

El x3956 x6 Server de IBM el cual es un servidor con capacidad de 8 procesadores con 192 DIMM’s
es decir 24 DIMM’s por procesador con capacidad de 120 núcleos, lo cual nos da una posibilidad
de hasta 12 TB.

Algo adicional que me pareció importante es que se ha creado una nueva tecnología llamada eXFlash
que bueno básicamente es poner en un DIMM un SSD andando y que este funcione como un disco
duro, pero directo en los canales de memoria, el detalle aquí es que estos nuevos modelos tendrán
capacidades de 200 Gb a 400 Gb:

Bueno con todo esto queda claro que el elemento hardware ya no será un problema para una empresa y
con esto las bases de datos no tendrán más inconvenientes que adaptarse a trabajar directamente en
RAM con ello mejorando la respuesta y el desempeño, por tanto podría decirse que parte de la magia
de todo esto no es solo el software ofrecido si no este brinco en tecnología hardware que se puede
obtener, con ello HANA da el primer brinco en utilizar estas propiedades y obligando a actualizar su
viejo servidor a muchas de las empresas que cuentan ya con sus ERP, BW e infinidad de herramientas
de gestión empresarial.
Con todo lo anterior debe quedar claro por qué HANA es el producto de más crecimiento para SAP y el
que más importa a corto y mediano plazo.
Ahora volviendo a HANA el consumo de memoria está basado en varios procesos que son ejecutados
en Linux Suse o redhat las versiones oficiales hasta el momento, cuando son iniciados cada uno reserva
la memoria a utilizar apoyado con el sistema operativo, por tal motivo es crítico que HANA gestione la
memoria de una forma eficiente por este motivo HANA maneja su propio pool para requerir
información al Sistema Operativo, este es utilizado para almacenar los datos y las tablas de sistema, y
todo lo requerido por una base de datos como procesos temporales y uso de procesos del sistema.

Aquí un gráfico de cómo se reparte todo esto:

También basado en la vista inicial se muestra parte del consumo de memoria: