Hana: El todo es más que la suma de las partes

Ahora se habla cada vez más de "warm storage" (almacenamiento dinámico por niveles y extensiones de almacenamiento nativo). Entonces, ¿va SAP por el camino inverso y acabará donde las bases de datos clásicas: con bases de datos en disco y la memoria como caché?

Filas para OLTP Columnas para OLAP

A menudo se oye decir que el almacenamiento en filas es mejor para leer frases enteras. Incluso Hasso Plattner lo insinuó en la última keynote de Sapphire. El argumento de siempre:

Los datos de un registro se almacenan juntos en una base de datos basada en líneas. Un argumento atractivo, pero demasiado corto de miras. No se tiene en cuenta la distancia topológica.

Este argumento procede de la época de los discos duros, cuando el cabezal de lectura más la velocidad angular del disco giratorio determinaban el tiempo de acceso y se leían sectores de 4 kB de una vez.

Con los SSD ya no hay mecánica, se envía una dirección y se devuelve un sector de 4 kB. Por lo tanto, el tiempo de acceso a un sector es significativamente más corto, pero los datos deben seguir estando cerca, en el mismo sector de 4 kB.

En cambio, la memoria sólo devuelve 16 bytes por acceso, pero por supuesto mucho más rápido, y qué dirección de memoria se solicita a continuación es irrelevante.

En otras palabras: para leer 4 kB a máxima velocidad, los datos deben estar en un sector en los discos duros y SSD. A la memoria, en cambio, no le importa en absoluto, se realizan 256 accesos de 16 bytes cada uno para leer 4 kB como sea.

Desde esta perspectiva, el almacenamiento orientado a filas o columnas es igual de rápido si todos los datos están ya en la memoria. La dirección de memoria es diferente, pero esto no influye en la velocidad.

La afirmación de que la lectura de una fila requiere un almacenamiento orientado a filas y los análisis OLAP requieren una orientación a columnas sólo se aplica a las operaciones de disco. Aunque he refutado así el razonamiento en sí, la afirmación "con memoria suficiente, una base de datos normal es también una base de datos en memoria" sigue sin respuesta.

Esto se debe a la orientación de las columnas: un registro de datos contiene una gran variedad de información, número de material, texto y muchos indicadores como color, tipo, tamaño, etc.

Sin duda, esta información divergente no puede comprimirse tan bien como cada columna por sí sola, con patrones más bien repetitivos. Un enfoque aún más inteligente consiste en examinar individualmente cada valor de una columna de este tipo.

Por ejemplo, sólo existen los valores M, S, L, XL para el campo Talla, por lo que se generan cuatro cadenas. La cadena para M podría tener este aspecto: 0100-0000-0000-1000; y significa que el valor M aparece en los registros 2 y 13.

Algo así se puede comprimir muy bien con un ordenador y además muy rápido. Para otras columnas se utilizan otros métodos, como el número de material, que es diferente para cada material.

Buscar y encontrar

En un sistema ERP se accede a los datos por clave primaria o mediante una búsqueda. "mostrar pedido de cliente 1234" o "buscar todos los artículos de venta para el pedido de cliente 1234".

El primer proceso es el mismo para ambos tipos de base de datos. Una base de datos clásica utiliza el índice, encuentra allí la dirección de la fila y lee el registro en esta dirección. En Hana, se lee el índice, se encuentra allí el número de registro y se recupera el valor en esta posición de cada columna.

De nuevo hay diferencias en la búsqueda: con una orientación por filas, es de esperar que haya un segundo índice que contenga todas las direcciones de los registros de artículos de venta que pertenecen a un pedido de cliente.

De lo contrario, la base de datos no tiene ninguna posibilidad y tiene que buscar en toda la tabla. Con Hana, la indexación ya viene dada por la forma en que se almacenan los datos. Una inmensa ventaja práctica.

Cada uno de estos puntos -orientación a columnas, compresión, indexación e in-memory- tiene sus propias ventajas y desventajas. El argumento de venta exclusivo de SAP Hana es que, aún hoy, esta base de datos sigue siendo la única que combina inteligentemente todos estos puntos, de modo que las ventajas se unen.

Puedes conservar todo en memoria si lo comprimes. Si organizas los datos en columnas, puedes comprimirlos mejor. Aparte de las claves primarias, los índices ya no son necesarios gracias a la organización en columnas y a la compresión.

Dado que todos los datos se almacenan en la memoria, las consultas de un conjunto de tablas completo son igual de rápidas que con el almacenamiento por filas, por lo que incluso se puede utilizar el almacenamiento por columnas para este tipo de consultas.

Por otro lado, se gana mucho con Hana para los casos normales. Las consultas OLAP como "ventas totales al año" son muy rápidas porque los datos ya están organizados en columnas.

Las búsquedas en cualquier atributo son mucho más rápidas porque cada columna representa por sí misma un índice. Las consultas que no leen el 100% de las columnas de la tabla son más rápidas.

Pero éste es también el quid de la cuestión: Todo mi análisis se basaba en la premisa de que todos los datos ya están en la memoria y también caben en ella.

¿No es un despilfarro de memoria y, por tanto, de dinero mantener siempre todo en la RAM (memoria de acceso aleatorio), independientemente de si se necesita o no?

SAP ofrece aquí al administrador opciones de optimización: El primer punto son los tipos de datos binarios (tipos de datos LOB, CLOB y NCLOB). Estos no se almacenan en memoria, sino que permanecen siempre en disco.

El puntero al fichero está en la memoria, pero no el contenido. Buena idea, pero no sirve de mucho porque esos tipos de datos casi nunca aparecen en un ERP.

Primer uso

Siguiente optimización: Las particiones sólo se cargan en la memoria cuando se han utilizado por primera vez y no por precaución. Así, si una tabla consta de mil millones de registros, divididos en diez particiones para diez años, sólo se cargaría en memoria la partición correspondiente al año en curso.

También es una buena idea, reduce el tiempo de arranque y el requerimiento de memoria inicial, pero con el tiempo cada partición habrá sido utilizada al menos una vez por alguien. Esto significa que en algún momento todo estará en la RAM y permanecerá allí hasta el próximo reinicio.

Existe una función para ello: el periodo de retención. Con este ajuste, tales particiones se eliminan de la RAM después de un tiempo determinado sin ningún acceso. Finalmente un ajuste que elimina cosas de la RAM. Atención, ¡este interruptor está en Off por defecto!

Esto ya está muy bien, pero hay dos lagunas. La primera persona que utiliza un solo conjunto de datos desencadena la carga completa de esta partición en la memoria.

Si dicha partición tiene un tamaño de un gigabyte, puede tardar dos segundos. Y nada de esto ayuda si toda la base de datos requiere 1,1 terabytes de RAM, pero sólo se dispone de 1 terabyte.

Aquí es donde la última función, la Extensión de Almacenamiento Nativo, viene al rescate. Esto significa que ya no se carga toda la partición, sino sólo las páginas necesarias que contienen estos datos.

Y si no hay suficiente RAM disponible, las páginas que no se necesitan se eliminan de nuevo. El procedimiento aquí es realmente el mismo que con una base de datos clásica basada en disco y sólo utiliza la RAM como caché para las tablas con esta configuración.

Datos multitemperatura

Pero no es así como se pretende. Hana también es una base de datos de computación en memoria, por lo que todos (!) los datos utilizados (!) deben estar disponibles en la memoria. Esta es la única forma de que las consultas OLTP y OLAP puedan ser gestionadas por la misma base de datos, la única forma de conseguir tiempos de respuesta cortos y predecibles.

Estas funciones adicionales sólo son adecuadas para datos multitemperatura. Para datos que se necesitan de vez en cuando. Para los que el usuario no debe ser enviado a una base de datos de archivo.

Si utilizara estas características para todas las tablas y proporcionara muy poca RAM, entonces las desventajas del almacenamiento orientado a columnas empezarían a hacerse evidentes. Ya no tendría todas las ventajas sin los inconvenientes.

En su lugar, Hana representa el punto de entrada central para los datos de diferente naturaleza y oculta las diferencias físicas: el usuario emite sus órdenes, algunos datos proceden del almacén en memoria, otros del disco, otros se visualizan a través de la función Hana Smart Data Access desde un sistema externo ("Federated"). El usuario no nota nada de esto, aparte de unos tiempos de respuesta más largos. Hana se convierte en un tejido de datos.

La física está oculta, pero sigue ahí. La lectura de estructuras de datos Hana desde la memoria es más rápida que desde el disco con la Extensión de Almacenamiento Nativo.

La diferencia con la asignación dinámica de niveles con una base de datos SAP IQ en segundo plano es aún mayor porque aquí ya no se utilizan estructuras de datos Hana. Por tanto, la interfaz se limita a SQL.

Y si el usuario accede a un sistema externo a través de Smart Data Access, la respuesta sólo puede ser tan rápida como lo permita el sistema externo.