Objetivo In-memory computing (SAP HANA): Mover los datos lo menos posible

Para lograr tiempos de respuesta reales la tecnología In-Memory Computing se vale de una serie de técnicas que tienen por objetivo mover lo menos posible los datos en las bases de datos y entre la base de datos y las aplicaciones.


Para lograr tiempos de respuesta reales la tecnología In-Memory Computing se vale de una serie de técnicas que tienen por objetivo mover lo menos posible los datos en las bases de datos y entre la base de datos y las aplicaciones.

Compresión

A pesar que se pueda contar con grandes cantidades de memoria, con la compresión se persigue evitar el tránsito de los datos. Una técnica habitual es el uso de diccionarios, un método sencillo, porque al final, de lo que se trata es no sobrecargar la capacidad de procesamiento del CPU. Esta técnica consiste en sustituir los textos y fechas por números enteros, tal como se muestra en la siguiente imagen:

Con esta técnica se consigue un factor de compresión que depende de la cantidad de valores distintos. Hay otras técnicas más eficientes, pero lo que se busca es un método flexible que no afecte el tiempo de respuesta al acceder a los datos.

Almacenamiento en Columnas

El almacenamiento basado en columnas (column-based, columnar storage o columnar) es una alternativa al tradicional sistema de bases de datos relacional con su almacenamiento basado en filas.

Como se puede ver en el anterior cuadro, las debilidades del almacenamiento basado en columnas están en las operaciones de actualización e inserción de datos, la tarea menos habitual en un entorno de análisis.

Lógica de aplicaciones en bases de datos

Las técnicas anteriores están enfocadas a agilizar el acceso a la información contenida en las bases de datos.  Pero las aplicaciones pueden realizar operaciones con los datos, generando un «tráfico» de ida y vuelta que puede repercutir en el rendimiento general, aumentando los tiempos de latencia o espera.  Para evitar estos inconvenientes, los cálculos u operaciones que requieren las aplicaciones son procesados en donde están los datos (BBDD).

En «in-memory computing» (técnica de SAP HANA), los datos están en disco

Se entiende por in-memory computing, el procesamiento de grandes cantidades de datos en la memoria principal (RAM) para ofrecer resultados inmediatos en las transacciones y tareas de análisis. El llamado procesamiento en tiempo real es posible por la aplicación de los siguientes principios


Se entiende por in-memory computing, el procesamiento de grandes cantidades de datos en la memoria principal (RAM) para ofrecer resultados inmediatos en las transacciones  y tareas de análisis.  El  llamado procesamiento en tiempo real es posible por la aplicación de los siguientes principios:

  • Mantener los datos en la memoria principal para acelerar el acceso a la información.
  • Reducir el mínimo el movimiento de datos, aprovechando técnicas de almacenamiento en columnas, compresión y cálculos a nivel de base de datos.
  • Maximizar el uso de la arquitectura tales como los procesadores multi-core, entornos distribuido o procesamiento multiservidor.

 La respuesta a la pregunta ¿por qué utilizar la memoria como almacén de datos? se encuentra en el siguiente gráfico:

Las dos primeras alternativas son más rápidas pero se limitan al procesamiento de datos.  La memora RAM es la única, de las alternativas más rápidas, que permite el almacenamiento de un gran volumen de datos.

Podría pensar que tener los datos en memoria es un»riesgo» si se pierde la fuente de alimentación de energía, pero tal riesgo no existe: «El almacenamiento utilizado por una base de datos para guardar los datos (en este caso en la memoria) se divide en páginas. Cuando una transacción cambia los datos, las páginas correspondientes se marcan y se escriben en almacenamiento  no volátil en intervalos regulares». Esto asegura que todas las transacciones son permanentes.

La evolución de las tecnologías SAP para llegar a HANA

IBM es uno de los cinco socios de hardware que tiene SAP para SAP HANA, el denominado “Gigante Azul”, recientemente ha publicado un libro sobre la tecnología de procesamiento en memoria (in-memory computing) y HANA, en pocas páginas plasma importante información sobre la evolución, principales conceptos y características técnicas de esta tecnología sobre la arquitectura de IBM.


IBM es uno de los cinco socios de hardware que tiene SAP para SAP HANA, el denominado “Gigante Azul”, recientemente ha publicado un libro sobre la tecnología de procesamiento en memoria (in-memory computing) y HANA, en pocas páginas plasma importante información sobre la evolución, principales conceptos y características técnicas de esta tecnología sobre la arquitectura de IBM.

SAP HANA no es un “invento reciente”, es el resultado de la evolución de varias tecnologías que han confluido en un producto que inicialmente fue pensado sólo para mejorar las tareas de análisis de datos, pero que muy pronto, SAP identificó su potencial y cambió su alcance y ahora está llamada a ser la base de datos y plataforma sobre la que funcionarán todas las aplicaciones de SAP.

Una sugerencia para conocer más sobre Agile

Pretender recoger todos los requisitos o necesidades de los usuarios para un proyecto en concreto, en unas cuantas reuniones y luego de lo cual, dar por cerrada esta fase, impidiendo cualquier cambio o adicional posterior, “so pena” de cobro adicional. Seguro que nos parece “razonable” si pensamos como implementadores, pero nos parece algo incompresible si nos ponemos en el papel del usuario.


Pretender recoger todos los requisitos o necesidades de los usuarios para un proyecto en concreto, en unas cuantas reuniones y luego de lo cual, dar por cerrada esta fase, impidiendo cualquier cambio o adicional posterior, “so pena” de cobro adicional.  Seguro que nos parece “razonable” si pensamos como implementadores, pero nos parece algo incompresible si nos ponemos en el papel del usuario.

Ya sea porque siempre se “escapará” algún aspecto o porque el panorama es muy cambiante, el afán de tenerlo todo “atado” para iniciar un proyecto, debería superarse para lograr la real satisfacción del usuario.  Cambiar este paradigma es posible con metodologías Agile, nada nuevas, pero muy desconocidas en cuanto a su estructura y puesta en aplicación.

“No debemos esperar a probar el nuevo producto en la fase final ya que la resolución del problema será, en sí misma, un problema.”

Un enfoque tradicional de un proyecto, propone fijar los requisitos con un alto nivel de detalle al inicio del proyecto y a partir de ellos, se hace una estimación del coste y de la fecha de entrega del mismo.  Los métodos ágiles parten de un presupuesto y unas fechas de entrega y a partir de ahí se trabaja para implementar la funcionalidad, de este modo se logra un alcance flexible.

Para conocer más sobre Agile, sugerimos un libro que recientemente hemos “descubierto”, se trata de “Métodos Ágiles y Scrum” de Anaya (ISBN 978-84-415-3104-8), por lo poco que lo hemos leído, nos parece un documento de mucha utilidad.

¿Las herramientas colaborativas son la solución al uso del email?

Pretender acabar con el protagonismo del correo electrónico en las comunicaciones que se generan en una organización, para utilizar alternativas basadas en portales o herramientas sociales, es una batalla perdida. Por más funcionalidades agreguen los programas de “email”, resulta muy difícil seguir los debates, convocatorias e intercambio de documentos, sobre todo, si el tránsito de información corresponde a proyectos o temas distintos. Pero el software colaborativo parece que no terminar de gustar.


Pretender acabar con el protagonismo del correo electrónico en las comunicaciones que se generan en una organización, para utilizar alternativas basadas en portales o herramientas sociales, es una batalla perdida.  Por más funcionalidades agreguen los programas de “email”, resulta muy difícil seguir los debates, convocatorias e intercambio de documentos, sobre todo, si el tránsito de información corresponde a proyectos o temas distintos.  Pero el software colaborativo parece que no terminar de gustar.

A esta batalla perdida contra el uso/abuso del email, le encontramos mucha similitud con el caso de uso/abuso del “Excel” en las organizaciones, ambas herramientas deberían ser usadas para realizar temas puntuales pero no para cubrir aspectos que implican procesos.  Cómo apunta un artículo en «The Decision Factor«, el email debería ser usado sólo para comunicar algo concreto.

¿Por qué fracasan las herramientas colaborativas que pretenden sustituir el email?

Google Wave pretendía ser el sustituto del correo electrónico para gestionar de un modo más eficiente las comunicaciones entre personas, muchos lo aplaudieron, pero en la fase Beta del producto fueron muy pocos que lo adoptaron y Google abandonó el producto.  SAP StreamWork es una herramienta quizás aún mejor de lo que pretendía ser Google Wave, muy útil para compartir información y en función de ella debatir y tomar decisiones, pero tenemos la impresión que está teniendo poca acogida, muchos la aplauden, pero pocos la usan, esperemos que no tenga el mismo final.

Creemos que la razón de estos “fracasos” de las herramientas colaborativas es apuntar a eliminar el uso definitivo del email.  La similitud del uso del email con respecto al Excel, no lo encontramos sólo en los problemas que producen, sino también en la solución.  Creemos que la solución no pasa por eliminar definitivamente el uso del correo electrónico, al igual que el uso del Excel, las herramientas para gestionar procesos tales como la planificación, previsiones o los presupuestos, que más aceptación tienen, son aquellas que tienen el Excel dentro de la solución.

Al igual que del Excel, son muchos años de uso del email como para pretender sustituirlo repentinamente por una herramienta social/colaborativa, debemos buscar un mix, ¿existe?.