La plataforma global e independiente para la comunidad SAP.

Hana 3, ¿qué más?

Los milagros se hacen inmediatamente, lo imposible tarda un poco más. Una visión más detallada de la historia de SAP Hana Cloud.
Werner Dähn, rtdi.io
15 mayo 2020
[shutterstock.com: 80454427, Vira Mylyan-Monastyrska]
avatar
Este texto ha sido traducido automáticamente del alemán al español.

Es bien sabido que Hana no se creó para la nube. Pero, ¿cuál es el problema? El artículo de E-3 "Somos ERP" del autor "no/nombre" de E-3 de febrero de 2020 da en el clavo: los costes operativos de Hana como servicio para la propia SAP.

Una base de datos que se adapte automáticamente a la carga sería la solución ideal. De este modo, los costes de explotación se mantendrían al 100% dentro del rango óptimo y se evitaría el despilfarro de recursos.

El deseo de una escalabilidad infinita es obvio y comprensible. ¿Es factible? Ésa es la otra cara de la moneda. Una anécdota de SAP: "Necesitamos soluciones disruptivas, así que desarróllenlas".

Vamos, vamos". Así que se supone que tienes que inventar algo sin precedentes a la carta, ponerlo en práctica rápidamente y cambiar las leyes de la física por el camino. Es difícil, ¿verdad?

Hana 3 toca un límite físico exactamente de esta manera. Para el escalado infinito requerido, las tareas deben (a) poder dividirse en partes infinitamente pequeñas, (b) ejecutarse en paralelo y -para que siga siendo una base de datos- (c) conservar una secuencia/transaccionalidad global. Esto no es posible. La contradicción interna de los requisitos debe resolverse mediante un compromiso al menos en un punto.

Esfuerzo y objetivo

Pero si el escalado infinito es sólo una forma de reducir costes, ¿quizás haya una forma más barata? Esto ya se ha intentado antes, los administradores de Hana lo conocen como Multi-Database-Container (MDC).

El servidor de índices, el proceso que se encarga de todo el procesamiento y almacenamiento de datos en Hana, fue identificado como el problema.

En el centro de datos de la nube, cada Hana requiere uno de estos grandes procesos de servidor de índices. Entonces, ¿qué tal instalar solo una instancia de Hana por servidor y tener contenedores de base de datos independientes?

Entonces, ¿el desarrollo ha eliminado del servidor de índices todo lo que no forma parte de una base de datos y lo ha trasladado al servidor de nombres: almacenamiento de datos? No, eso no es posible, ese es el núcleo de la base de datos.

¿Las consultas? ¿La gestión de las sesiones? Al final, no se pudo eliminar nada. Resultado: El SystemDB más un servidor de índices por contenedor de base de datos se ejecuta en cada ordenador. ¿Ahorro? Prácticamente cero.

El servidor de índices

¿Cómo se podría reducir el tamaño del servidor de índices? En este momento tiene un tamaño de 4 GB con una base de datos vacía.

Dispone de un motor SQL, un motor de cálculo, consultas espaciales, consultas de series temporales y gráficos y un almacén de documentos. El método más barato sería eliminar parte de las funcionalidades.

Sin embargo, una de las ventajas de Hana es su universalidad. Esto está escrito con razón en todas las diapositivas de marketing. Por lo tanto, el servidor de índices tendría que ser cortado de alguna manera diferente, obviamente en una pequeña funcionalidad central y un componente dinámico, dependiente de la carga.

Una de las principales afirmaciones de Hasso Plattner hace diez años fue que un registro de datos se crea una vez y se consulta cientos de veces. A partir de ahí, Plattner llegó a la conclusión de que una base de datos debe optimizarse para la velocidad de consulta y que el rendimiento de inserción es secundario.

Toda la base de datos Hana y S/4 Hana se basan en esta premisa, y por eso tienen tanto éxito.

Para nuestro servidor de índices, esto significa tirar todo el código que se ocupa de la consulta de datos. Realmente todo. De este modo, la responsabilidad del servidor de índices se reduce a la gestión de datos y a la aplicación de los cambios de datos.

Por lo tanto, el proceso posee la memoria RAM con los datos y gestiona las sentencias de inserción, actualización y eliminación. El servidor de índices sólo sería el nivel de almacenamiento en memoria.

Las consultas son la parte compleja, con el optimizador de consultas, los distintos motores y el alto riesgo de que se produzca un error. El acceso de sólo lectura a la RAM del servidor de índices (memoria compartida) es suficiente para estas funciones y pueden trabajar de forma totalmente independiente unas de otras.

Otra ventaja de este enfoque: ¿Qué ocurre hoy en día cuando un usuario envía una consulta y el código se desboca a causa de un error? El servidor de índices se bloquea y con él toda la base de datos.

Si la consulta es un proceso separado, tal vez incluso cada consulta en ejecución se ejecutaría en un proceso separado, sólo se colapsa la sesión de un usuario.

Sin embargo, diseñar bien este proceso de consulta no es fácil.

Contenedor

¿Cómo se vería eso en la práctica? Cada cliente tiene una imagen Docker con Hana. Esta imagen se inicia en un servidor con los datos de rendimiento adquiridos. Debido a que el servidor de índices es ahora tan pequeño, se puede iniciar muy rápidamente, tan rápidamente que la mayoría de las instancias de desarrolladores pueden incluso entrar en un estado de hibernación y la imagen Docker se detiene cuando está inactiva.

Si un cliente necesita más recursos, su instancia de Hana se detiene y se reinicia en el otro hardware. O se puede ir en la dirección de scale-out, iniciar varias instancias Docker en los mismos archivos de base de datos y estos distribuyen los datos entre sí.

No importa dónde se ejecute un contenedor, en el centro de datos de la nube o en las instalaciones del cliente.

Lo que he descrito hasta ahora son conocimientos generales de la construcción de bases de datos. Será emocionante ver qué base técnica obtiene Hana Cloud.


Conclusión: lo viejo frente a lo nuevo

Si Hana Cloud fuera una versión normal de Hana, SAP ya habría ganado mucho. Los datos en memoria se encuentran en el nivel superior y, gracias a las extensiones de almacenamiento nativo de Hana (NSE), muchos datos pueden permanecer en disco. Todo ello debería empaquetarse en contenedores para facilitar el manejo de las numerosas instancias. Sin embargo, este parece ser el plan solo hasta cierto punto. La mencionada separación del desarrollo de Hana Cloud en una segunda línea de código separada tiene consecuencias.
En cualquier caso, dos líneas de código suponen el doble de costes de desarrollo, o se descuida una de ellas. Además, hay que volver a implementar todas las funciones existentes de Hana, y como esto no es posible en el poco tiempo disponible, faltarán algunas. A su vez, las características para un funcionamiento eficaz en la nube sólo se pueden encontrar en la línea de código de Hana Cloud.
No cabe esperar clientes satisfechos. Como cliente de Hana on-prem, puede ver los nuevos desarrollos relacionados con el funcionamiento de la base de datos, pero no puede utilizarlos. Los usuarios de la nube echarán de menos funciones que hace tiempo que están disponibles en Hana on-prem pero que aún no se han implementado en la línea de código de la nube.
Mientras esta situación dure poco tiempo, se le puede hacer frente. Sin embargo, aún no he oído ninguna declaración que indique una convergencia de estos dos acontecimientos, sino todo lo contrario.

avatar
Werner Dähn, rtdi.io

Werner Dähn es especialista en integración de datos y director general de rtdi.io.


Escriba un comentario

Trabajar sobre la base de SAP es crucial para el éxito de la conversión a S/4. 

Esto confiere al centro de competencia una importancia estratégica para los clientes actuales de SAP. Independientemente del modelo operativo de S/4 Hana, temas como Automatización, Supervisión, Seguridad, Gestión del ciclo de vida de las aplicaciones y Gestión de datos la base de las operaciones S/4.

Por segunda vez, E3 Magazine organiza una cumbre para la comunidad SAP en Salzburgo con el fin de ofrecer información exhaustiva sobre todos los aspectos del trabajo preliminar de S/4 Hana. Toda la información sobre el evento puede encontrarse aquí:

Cumbre de Centro de Competencia SAP 2024

Lugar de celebración

Sala de actos, FourSide Hotel Salzburg,
En el recinto ferial 2,
A-5020 Salzburgo

Fecha del acontecimiento

5 y 6 de junio de 2024

Entrada normal:

€ 590 sin IVA

Lugar de celebración

Sala de actos, Hotel Hilton Heidelberg,
Kurfürstenanlage 1,
69115 Heidelberg

Fecha del acontecimiento

28 y 29 de febrero de 2024

Entradas

Billete normal
590 EUR sin IVA
El organizador es la revista E3 de la editorial B4Bmedia.net AG. Las conferencias irán acompañadas de una exposición de socios seleccionados de SAP. El precio de la entrada incluye la asistencia a todas las conferencias de la Cumbre Steampunk y BTP 2024, la visita a la zona de exposición, la participación en el evento nocturno y el catering durante el programa oficial. El programa de conferencias y la lista de expositores y patrocinadores (socios de SAP) se publicarán en este sitio web a su debido tiempo.