¿Dónde tiene sentido realmente la in-memoria?

En primer lugar, SAP ha puesto mucho empeño en posicionar su propia base de datos en memoria Hana como una revolución entre las bases de datos.

Mientras tanto, existen varias soluciones de bases de datos en memoria para aplicaciones SAP, pero todas son diferentes. Por eso, como siempre, merece la pena echar un vistazo entre bastidores antes de que una empresa se decida por una de estas soluciones.

Las diferencias en la aplicación, la utilización y los beneficios reales son muy claras, además de los costes de adquisición de hardware y software.

Antes de que una empresa se involucre con la in-memory en una base de datos, la primera pregunta es: ¿qué quiero conseguir con ella?

Es una falsa expectativa que la tecnología in-memory por sí sola, independientemente del fabricante que la utilice, suponga una mejora fundamental en el rendimiento de todos los procesos a partir de consultas analíticas o transacciones de escritura en la base de datos. Esto no es así.

Muchos requisitos: la memoria por sí sola no los resuelve

Una buena base de datos no sólo se caracteriza por estar en memoria. Las soluciones con un planteamiento "o lo uno o lo otro" no resuelven los requisitos globales de un sistema de gestión de bases de datos, sino que aportan la solución a requisitos analíticos específicos individuales.

Todavía no se ha visto un coche de Fórmula 1 en el Rally Dakar. Una base de datos se caracteriza por su capacidad para responder a todas las exigencias en términos de rendimiento, alta disponibilidad, estabilidad y seguridad, aprovechando al máximo los recursos disponibles en RAM, CPU, almacenamiento y red.

Los accesos a un único registro son especialmente frecuentes en las aplicaciones SAP Business Suite. Si el sistema de base de datos está configurado correctamente, in-memory apenas puede conseguir mejoras en el rendimiento de estas transacciones.

Por el contrario, los accesos de un solo registro con enlaces complejos resueltos a través de varias tablas en un almacén en memoria orientado a columnas pueden ser significativamente más complejos que un acceso de un solo registro a un único bloque de base de datos en la memoria (caché de búfer) en un almacén orientado a filas.

Por lo general, las consultas analíticas se realizan en un sistema SAP BW, lo que significa que muy rara vez se procesan registros individuales. La tecnología in-memory puede aportar una mejora decisiva para este caso de uso, en particular a medida que los volúmenes de datos siguen creciendo.

Entonces, ¿cuál es el óptimo?

¿Todos los datos 100% en memoria o sólo objetos seleccionados? ¿Decide el fabricante de la base de datos con una base de datos en memoria pura o es el administrador de la base de datos quien decide en qué casos tiene sentido la base de datos en memoria?

¿Conseguiremos lo óptimo para todas las aplicaciones SAP, es decir, para SAP BW, SAP ERP, SAP CRM, SAP HR, si siempre tenemos que mantener todos los datos permanentemente en memoria?

Mantener todos los datos en memoria sigue estando asociado a elevados costes de inversión en hardware debidamente equipado con suficiente RAM y CPU para el entorno productivo y a prueba de fallos. Tiene más sentido disponer de una solución que permita todas las opciones de ejecución de alto rendimiento para todas las transacciones de lectura y escritura.

En el pasado, todos los fabricantes de bases de datos conocidos han optado por un enfoque orientado a la línea al desarrollar sus bases de datos porque es el enfoque óptimo para las transacciones de escritura.

Hoy en día vemos bases de datos que han crecido enormemente. Por tanto, estos datos deben crearse primero en las bases de datos mediante transacciones de escritura. In-memory apenas puede proporcionar apoyo aquí.

Las ventajas de la tecnología en memoria residen claramente en el entorno analítico a la hora de leer y agregar cantidades muy grandes de datos.

Existen, por tanto, casos de uso especiales en el entorno analítico en los que la tecnología en memoria puede realmente lograr ventajas significativas en términos de rendimiento. Partiendo de esta base, una combinación de diseño de base de datos clásico con almacenamiento convencional orientado a filas y la nueva tecnología en memoria orientada a columnas es un enfoque óptimo.

¿Quién debería estar mejor informado sobre las vías de acceso de alto rendimiento en su base de datos si no es la propia base de datos? ¿Por qué debería un sistema de base de datos almacenar todos los datos en una arquitectura en memoria orientada a columnas si la base de datos utiliza sus estadísticas para determinar la información para un mejor acceso a través de un bloque de base de datos orientado a filas?

La introducción de particiones con la división física y la reducción de tablas con el fin de mantener el rendimiento es muy limitada en el estándar SAP BW, pero sólo puede implementarse en los sistemas SAP ERP con un gran coste.

Por este motivo, las arquitecturas scale-out con SAP Hana también son difíciles de realizar para las aplicaciones SAP Business Suite. Las ventajas del procesamiento paralelo masivo de una única transacción utilizando in-memory a través de un scale-out apenas pueden aprovecharse en este caso.

El enfoque de la tecnología en memoria de Oracle Database es diferente. Combina de forma óptima ambos mundos: el enfoque clásico orientado a filas para el procesamiento de registros individuales y, en paralelo, la arquitectura en memoria orientada a columnas para consultas analíticas extremadamente aceleradas.

Esto ofrece a la base de datos otra opción para que el optimizador de bases de datos ejecute las consultas desde la caché de memoria intermedia orientada a filas o el almacén en memoria orientado a columnas con el máximo rendimiento para tablas idénticas.

Esto convierte a Oracle en el único fabricante de bases de datos que combina de forma transparente las tecnologías de bases de datos convencionales con la tecnología en memoria más avanzada para la aplicación.

De ello se derivan muchas ventajas. La base de datos requiere mucha menos memoria adicional en comparación con una base de datos 100% en memoria, ya que solo se definen adicionalmente tablas seleccionadas con almacenamiento orientado a columnas en la memoria.

Las consultas analíticas sobre grandes cantidades de datos pueden ahora acelerarse enormemente. Los índices personalizados para acelerar las consultas analíticas pueden volver a eliminarse, lo que también puede mejorar el rendimiento OLTP en estos objetos.

No es necesario migrar las tablas a este formato orientado a columnas. Todas las funcionalidades de la base de datos Oracle utilizadas anteriormente, como la compresión, el cifrado, los clústeres de aplicaciones reales o la copia de seguridad/recuperación, pueden seguir operando sin cambios.

La base de datos Oracle puede ejecutarse en todos los sistemas operativos habituales, y la solución en memoria no cambia esta situación.

La base de datos Oracle no reconoce una disyuntiva, in-memory o no in-memory, sino ambas. Ahora es posible realizar en paralelo transacciones de escritura y de lectura en las mismas tablas de una misma base de datos, tanto con los métodos tradicionales como con la moderna tecnología in-memory.

Esta es la base de la certificación 2015 de la tecnología in-memory de Oracle Database para todas las aplicaciones basadas en SAP NetWeaver. Esto convierte a Oracle en el único fabricante, además de Hana, con una solución in-memory que puede utilizarse para OLTP y OLAP en SAP.

Como resultado, un gran número de empresas pudieron implementar con éxito los requisitos de rendimiento existentes en SAP BW y SAP CRM en tan sólo unos días. Oracle Database In-memory también se caracteriza por una posición negociadora significativamente mejorada para futuras inversiones en hardware gracias a la variedad de proveedores y sistemas operativos, así como a la menor cantidad de RAM necesaria.

Con la implementación de "cubos planos" como nuevo diseño para InfoCubes en SAP NetWeaver BW 7.40, ahora son posibles nuevos desarrollos tecnológicos basados en la tecnología in-memory de la base de datos Oracle. Además de una mejora significativa en el rendimiento de los análisis sin la creación previa de agregados, que requiere mucho tiempo, esto también mejora significativamente el rendimiento de carga debido a la ausencia de índices y tablas de dimensiones. Se están buscando clientes piloto para ello.