aníbal goicochea

Las bases de datos tradicionales han definido la arquitectura de las plataformas de TI

Las características limitaciones de las bases de datos tradicionales (disk-based databases) han determinado las arquitecturas de las infraestructuras tecnológicas actuales, uniformemente divididas por un entorno transaccional y otro entorno analítico. Estas limitaciones son responsables, entre otras cosas, de lo siguiente:

División de la gestión de los procesos de negocio y el análisis de la información.
Necesidad de ejecutar procesos de cargas de datos, y en algunos casos, con complejos algoritmos de transformación.
Procesos de verificación de la integridad de datos entre los repositorios y los sistemas origen.
Imposibilidad de efectuar en tiempo real o inmediato el análisis de la información.
Limitación de la cantidad y naturaleza de la información a procesar.
Cantidad considerable de recursos para gestionar las infraestructuras.
Renuncia, por parte de los usuarios, de sus necesidades de información, en tiempo y contenido.
Inversiones constantes en hardware para mejorar las plataformas tecnológicas, cuyos resultados muchas veces son imperceptibles para los usuarios.

Por motivos como estos, el concepto de bases de datos con procesamiento en memoria, es una alternativa adecuada porque elimina la casi totalidad de estas limitaciones, pero lamentablemente, por razones económicas, no es una solución al alcance de todos.

Preguntas para valorar una idea de negocio

El artículo de referencia plantea una relación de 35 probables preguntas a las que se pueda enfrentar un emprendedor que busque inversionistas, pero creemos que también podrían ser útiles para valorar una idea de negocio y así avanzar con más seguridad al diseño del plan de negocios y quién sabe, hasta la búsqueda de inversores.

De las preguntas que se proponen, en cuanto a la valoración de una idea de negocio, las siguientes nos parecen imprescindibles:

¿Qué hace el producto?
¿Qué problema resuelve?
¡Qué otras alternativas existen actualmente para resolver el “problema objetivo”?
¿En qué se diferencia tu propuesta con relación a las otras alternativas?
¿Cuál es el mercado y segmento objetivo?

Y si es posible, también las siguientes:

¿Cuáles son los costes y las necesidades de inversión?
¿Cuál es el modelo de ingresos?
¿Cómo y cuándo se consigue el punto de equilibrio?

Referencia: Diario Expansión

Planificar respuestas a los riesgos negativos de un proyecto

En la gestión de un proyecto, una vez que se han identificado los riesgos, clasificado y analizado, el siguiente paso debería ser planificar la respuesta de los riesgos que se van a controlar y gestionar.

En la gestión de un proyecto, una vez que se han identificado los riesgos, clasificado y analizado, el siguiente paso debería ser planificar la respuesta que daremos a los riesgos que se van a controlar y gestionar.

Como señalábamos en una entrada anterior, los riesgos de alta probabilidad y alto impacto, no deberían ser ignorados, en general, ningún riesgo debería ser rechazado, especialmente los que hubiesen obtenido, como resultado del uso de la matriz “Probabilidad vs. Impacto”, el resultado “Planificar Respuesta” requieren una atención especial para proponer un plan de acción si estos se produjesen.

El planteamiento de una respuesta debería seguir alguna de las siguientes estrategias:

Mitigar la probabilidad o impacto del riesgo. Reducir la probabilidad o el impacto, o ambos se justifican siempre cuando las acciones que se emprendan para este fin sean rentables con relación al impacto del riesgo.
Planificar una contingencia. La alta probabilidad de un riesgo justifica el planteamiento de un plan de contingencia, esto también incluye la identificación de condiciones de su activación (descripción del momento).
Transferir el riesgo a otra parte. Trasladar el riesgo no lo elimina, lo externaliza (por ejemplo la contratación de seguros o suscripción de garantías)
Evitar el riesgo. El beneficio de una tarea no justifica el costo que puede significar el impacto de un riesgo si este ocurriese, si fuese así se podría eliminar la actividad o sustituirla por otra.
Aceptar el riesgo. El costo de cualquier respuesta es superior al coste del impacto del riesgo, la alternativa para este caso es aceptar que el riesgo puede ocurrir y gestionarlo de la mejor manera si este se concretara.

Referencia: ISBN 978-84-415-3225-0

Carga y descarga en memoria de tablas SAP HANA Database

Normalmente SAP HANA Database gestiona la carga y descarga de tablas en memoria de manera automática con el fin de tener los datos necesarios en memoria, pero sin embargo, es posible «forzar» la carga y descarga de tablas o columnas de tablas si fuese necesario.

Normalmente SAP HANA Database gestiona la carga y descarga de tablas en memoria de manera automática con el fin de tener los datos necesarios en memoria, pero sin embargo, es posible «forzar» la carga y descarga de tablas o columnas de tablas si fuese necesario.

Las tablas con almacenamiento basado en filas son cargadas en memoria desde que la base de datos es iniciada y permanecen en memoria durante todo su funcionamiento, no pueden ser descargadas.

Las tablas con almacenamiento basado en columnas se cargan bajo demanda, columna por columna en los primeros accesos (este comportamiento se conoce como Lazy Loading) de este modo, columnas que nunca se utilizan no son cargadas, haciéndose un uso más eficiente de la memoria. Este es el comportamiento por defecto (algoritmo “least recently used”), pero sin embargo en la definición de la tabla vía SAP HANA Studio se puede indicar que columnas se cargarán cuando la base de datos se ponga en funcionamiento. (También vía la consola SQL se puede utilizar las sentencias LOAD y UNLOAD para cargar y descarga tablas o determinadas columnas de una tabla)

Nota: Para cargar una tabla en memoria es necesario tener el privilegio UPDATE SQL sobre la tabla.

La «arquitectura» de las tablas basadas en columnas de SAP HANA

La denominada Column Store es un componente de toda la ingeniería que conforma la plataforma SAP HANA, gestiona en memoria las tablas con almacenamiento basado en columnas. La “Column Store” optimiza las operaciones de lectura y escritura, a través de dos estructuras de datos que tienen las tablas: «main storage» y «delta storage».

La denominada Column Store es un componente de toda la ingeniería que conforma la plataforma SAP HANA, gestiona en memoria las tablas con almacenamiento basado en columnas. La “Column Store” optimiza las operaciones de lectura y escritura, a través de dos estructuras de datos que tienen las tablas: «main storage» y «delta storage».

La denominada “main storage” contiene los datos comprimidos para llevarlos a memoria, esta área es utilizada para las tareas de búsqueda y cálculos sobre los datos. En cuanto a las tareas de grabación, se realizan sobre otra estructura, denominada “delta storage”, la cual utiliza una compresión básica que optimiza las tareas de actualización de los datos. Las tareas de lectura se realizan sobre ambas áreas de datos.

A través de operaciones denominadas “delta merge” los cambios realizados en la “delta storage” pasan a la denominada “main storage”, luego de estas operaciones, el contenido de la main storage permanece en disco y si fuese necesario la optimización y compresión es actualizada.

Main Strorage and Delta Storage of the column tables

La denominada “delta storage” sólo existe en memoria, como parte del procedimiento contra fallos, el sistema va actualizado un log (delta log) con las últimas modificaciones que se realicen en una tabla, el contenido de estos ficheros es utilizado si el sistema se reinicia y se debe restituir las últimas operaciones que no fueros grabadas en disco. Al realizar las operaciones “delta merge” los datos pasan a disco y el fichero log correspondiente queda limpio de operaciones.