Hana 3, ¿qué más?

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.