Puertas abiertas para las bases de datos

Desde el punto de vista del marketing, la historia del uso de las bases de datos desde el punto de vista de SAP es un golpe maestro: durante décadas, degradaron las mejores bases de datos a almacenes de datos primitivos.

El procesamiento inteligente de datos se realizaba exclusivamente en los servidores de aplicaciones SAP. Hubo fuertes quejas sobre la incompetencia de los proveedores de bases de datos y el bajo rendimiento que ofrecían.

Inventaron Hana y, para mejorar el rendimiento del ERP, SAP permitió ahora un paso que IBM, Oracle y Microsoft se negaron durante años: las funciones de procesamiento de datos pueden y deben trasladarse desde el servidor de aplicaciones ERP más cerca de los datos en el servidor de base de datos.

¿Qué cliente facturó más en el primer trimestre? Una función sencilla y elemental para cualquier base de datos SQL: encontrar el máximo en una tabla.

Cualquier proveedor puede hacerlo en pocos milisegundos, independientemente del tamaño de la base de datos. No es así en un sistema R/3. Primero hay que cargar toda la tabla desde el servidor de la base de datos al servidor de la aplicación, luego un programa Abap empieza a buscar el máximo en la tabla local.

Este ejemplo muy simplificado ilustra el recorrido básico de los datos en un sistema R/3. El servidor de base de datos es sólo una memoria, la lógica de aplicación completa tuvo y tiene lugar en el servidor de aplicación.

Esto también explica por qué, antes de la gran oleada de virtualización en los centros de datos R/3, también había un servidor separado para cada módulo R/3. Mucha chapa metálica, para regocijo de los proveedores de hardware.

Las bases de datos SQL dan más de sí El concepto de un manejo muy reducido y estandarizado de las bases de datos en R/3 tenía mucho sentido para SAP. De esta forma se podía parecer "neutral" en el mercado y dar a IBM, Oracle y Microsoft la oportunidad de formar parte de la comunidad.

Donde hay luz, también hay sombra: Este enfoque genérico de la base de datos enviaba con demasiada frecuencia el comportamiento del tiempo de respuesta al sótano. En la escena SAP, se intentó mantener el tiempo de respuesta respectivo justo por debajo de un segundo con enormes gastos de hardware - a la larga, naturalmente, no fue un camino exitoso.

Cuando Hana salió al mercado y SAP se vio obligada a demostrar su rendimiento, relajó el concepto. En sentido estricto, fue una revolución, aunque sonara muy "simple":

En el futuro, las funciones del ERP se vincularán más estrechamente a los datos y las funciones básicas, como la búsqueda mín./máx., la conversión de divisas, etc., se externalizarán por completo del código Abap y se ejecutarán como funciones originales de la base de datos.

En teoría, es el momento de los proveedores de bases de datos IBM, Oracle y Microsoft. Si cada paso del procesamiento de datos ya no tiene que tener lugar en el servidor Abap, entonces la base de datos SQL puede demostrar su rendimiento.

Con Hana, SAP se vio obligada por primera vez a utilizar la base de datos ERP ya no como un archivo de datos, sino como un sistema inteligente para la gestión de datos. Una función clave para la interfaz entre el servidor de aplicaciones ERP y la base de datos SQL son los Core Data Services, existe un documento al respecto:

Referencia SAP Hana Core Data Services (CDS), SAP Hana Platform SPS 09, Documento Versión 1.1 (2015-02-16, PDF 120 páginas). Entre otras cosas, IBM deposita algunas esperanzas en esta interfaz para que DB2 vuelva a ser más atractivo para los usuarios de Business Suite 7 (ECC 6.0).

Pero no sólo con S/7, sino también con S/4, CDS y, posteriormente, BFL (SAP Business Function Library) podría convertirse en una oportunidad para IBM, Oracle y Microsoft. También hay un PDF con 158 páginas sobre BFL.

Por tanto, la velocidad moderada de un sistema R/3 también se debía a la arquitectura del software: La interacción de la base de datos y el servidor de aplicaciones, es decir, los dos primeros niveles del modelo cliente/servidor de tres niveles de SAP, era cualquier cosa menos óptima.

Al desarrollar su propia base de datos SQL, SAP parece haber reconocido dolorosamente este problema. Así, la "innovación" de que los datos y las funciones se acercan ahora en la plataforma de base de datos Hana se presentó también con mucho alboroto y entusiasmo.

¿Demasiado de algo bueno? Una vez rota la interfaz entre el servidor de aplicaciones y el servidor de base de datos, SAP programó inmediatamente numerosas funciones ERP como funciones de base de datos, de modo que el código de aplicación ERP Abap muta en una llamada a funciones Hana durante largos tramos.

Lo que la plataforma Hana puede hacer se lee mejor en SAP Hana Predictive Analysis Library (PAL), SAP Hana Platform SPS 09, Document Version 1.1 (2015-10-16, PDF 384 páginas). Esto, a su vez, podría convertirse en un tapón para IBM, Oracle y Microsoft.

Hana también es una base de datos SQL. A través de CDS, existe una capa transparente entre el servidor de aplicaciones y el servidor de bases de datos. S/7 y S/4 también pueden utilizar las funciones SQL "inteligentes" de una base de datos, lo que repercute positivamente en la velocidad de procesamiento.

Sin embargo, Hana es también mucho más que una base de datos SQL, véase PAL, y por tanto SoH (S/7 en Hana) y S/4 descargarán mucho más a la plataforma subyacente de lo que pueden ofrecer las bases de datos SQL de IBM, Oracle y Microsoft.

De este modo, SAP ha aprovechado bien la "apertura", por un lado para mejorar drásticamente el comportamiento del tiempo de respuesta y, por otro, para excluir inmediatamente a los competidores.

Así pues, por el momento sigue siendo incierto cómo IBM, Oracle y Microsoft utilizarán y querrán utilizar en el futuro el favor del momento sobre la base de CDS. El hecho es, sin embargo, que CDS/BFL abre una gran ventana de opciones para todas las bases de datos SQL.