Como ya hemos comentado anteriormente, la calificación de Big Data no debe atender sólo a criterios de volumen de los datos, sino que existen otras variables a considerar. Si bien es cierto que la inclusión del factor tiempo a la hora de almacenar una serie de datos críticos a lo largo de un periodo determinado (lo que hace su análisis mucho más provechoso) hace que el volumen de los mismos se multiplique, la velocidad con la que se realiza el proceso de análisis de los datos y extracción de conclusiones tiene un impacto crítico en el éxito de las aplicaciones diseñadas en este entorno. De hecho esta variable de velocidad es la que puede llevar al límite de su capacidad a sistemas de gestión de bases de datos más “tradicionales” y por ello entran en escena alternativas con otro tipo de sistemas para almacenar los datos a procesar.
Por otro lado, en muchos casos el uso de una estrategia que optimice la velocidad de análisis de datos (por ejemplo teniéndolos enteramente en memoria, como es el caso de algunos entornos de análisis de datos) hace que nos quedemos limitados en cuanto al volumen de datos que podamos manejar, lo que nos lleva a analizar detenidamente el compromiso entre un extremo (sistemas con gran capacidad de almacenamiento pero lentos en su proceso) y otro (sistemas muy ágiles para manejar volúmenes considerables de datos pero que están limitados para dar respuesta a necesidades extremas en cuanto a almacenamiento). Para resolver este compromiso la posibilidad de distribuir los datos juega un papel crucial, ya que puede permitirnos dividir el problema de análisis en trozos asumibles para sistemas que trabajan por separado haciendo la “parte pesada” del procesamiento y cuya interconexión posterior para componer el resultado final puede ser muy ligera (algo crucial para sistemas distribuidos en la nube).
Así como el tiempo es el principal multiplicador que genera el inmenso volumen de datos que manejamos en estas aplicaciones, es también el paso del tiempo el que determina los estándares de cada momento en términos de capacidades máximas y limitaciones, sobre las que habrá que ser capaces de ver siempre un paso más allá a la hora de diseñar estrategias de solución. Y es que cualquier aseveración que se haga en ese sentido parece condenada a quedar obsoleta en poco tiempo (todos hemos leído alguna vez esa famosa frase de inicios de los 80 diciendo que “640K de memoria deberían ser suficientes para cualquiera” -cuya autoría no está del todo clara-, e incluso el artículo de Jacobs hace referencia a las limitaciones de filas y columnas en las hojas de cálculo Excel y hasta qué punto podría ser suficiente o no la ampliación que tuvieron en 2007). El propio Jacobs era bien consciente de este efecto y, cuando al final de su artículo decidió “mojarse” y dar una definición de lo que entendía por Big Data, lo hizo teniendo el factor tiempo bien en cuenta:
Por otro lado, en muchos casos el uso de una estrategia que optimice la velocidad de análisis de datos (por ejemplo teniéndolos enteramente en memoria, como es el caso de algunos entornos de análisis de datos) hace que nos quedemos limitados en cuanto al volumen de datos que podamos manejar, lo que nos lleva a analizar detenidamente el compromiso entre un extremo (sistemas con gran capacidad de almacenamiento pero lentos en su proceso) y otro (sistemas muy ágiles para manejar volúmenes considerables de datos pero que están limitados para dar respuesta a necesidades extremas en cuanto a almacenamiento). Para resolver este compromiso la posibilidad de distribuir los datos juega un papel crucial, ya que puede permitirnos dividir el problema de análisis en trozos asumibles para sistemas que trabajan por separado haciendo la “parte pesada” del procesamiento y cuya interconexión posterior para componer el resultado final puede ser muy ligera (algo crucial para sistemas distribuidos en la nube).
Así como el tiempo es el principal multiplicador que genera el inmenso volumen de datos que manejamos en estas aplicaciones, es también el paso del tiempo el que determina los estándares de cada momento en términos de capacidades máximas y limitaciones, sobre las que habrá que ser capaces de ver siempre un paso más allá a la hora de diseñar estrategias de solución. Y es que cualquier aseveración que se haga en ese sentido parece condenada a quedar obsoleta en poco tiempo (todos hemos leído alguna vez esa famosa frase de inicios de los 80 diciendo que “640K de memoria deberían ser suficientes para cualquiera” -cuya autoría no está del todo clara-, e incluso el artículo de Jacobs hace referencia a las limitaciones de filas y columnas en las hojas de cálculo Excel y hasta qué punto podría ser suficiente o no la ampliación que tuvieron en 2007). El propio Jacobs era bien consciente de este efecto y, cuando al final de su artículo decidió “mojarse” y dar una definición de lo que entendía por Big Data, lo hizo teniendo el factor tiempo bien en cuenta:
"Big data should be defined at any point in time as “data whose size forces us to look beyond the tried-and-true methods that are prevalent at that time.”"
No hay comentarios:
Publicar un comentario