Entender el futuro: la evolución de las bases de datos

Es sin duda uno de los temas más provocativos y que más me está llamando la atención del análisis de la tendencia que está suponiendo el fenómeno Big data en los estamentos empresariales: la enorme dificultad para entenderlo sin bajar hasta la sistemática que lo sustenta. Un tema sin duda relevante: mientras se intente explicar Big data ”recetando” como fórmulas mágicas los informes de analistas como Forrester, McKinsey, Gartner, etc. o recurriendo a casos de aplicación, el directivo medio no será capaz de entender lo que realmente subyace detrás de este mundo, y mucho menos, sus posibilidades.

¿De qué hablamos realmente? Para mí, la mayor dificultad inherente a entender la diferencia que supone Big data es hacerse a la idea de lo que supone pasar del esquema de base de datos que todos conocemos a distintos niveles, a la idea de bases de datos no relacionales o NoSQL. Un mundo que suele definirse en negativo, por “lo que no es”, lo que añade todavía más dificultad conceptual.

Suena intimidatorio, pero espera, no desconectes todavía :-) Vamos a intentar aproximarnos al concepto: las bases de datos basadas en SQL (Structured Query Language, o lenguaje de consulta estructurado) es lo que la gran mayoría de los usuarios conocen. Lo pueden conocer a muy diferentes niveles: desde quien opera con ellas, maneja el lenguaje como tal, entiende las reglas de normalización de una base de datos convencional o es capaz de analizar sus limitaciones; hasta quienes simplemente se las imaginan como un gran sistema electrónico de archivos a modo de cajones y carpetas de un archivador. Una base de datos relacional basada en SQL, típicamente gestionadas con sistemas como Oracle, MySQL, DB2, Informix, Microsoft SQL Server, Sybase, PostgreSQL, etc, supone una operativa que nos resulta, por así decirlo, “natural”: sigue las reglas ACID (Atomicity, Consistency, Isolation y Durability, o Atomicidad, Consistencia, Aislamiento y Durabilidad), lo que permite que las instrucciones puedan ser consideradas una transacción, y responden a una visión sencilla, en la que un dato se almacena de una manera inequívoca y con unas relaciones definidas. La visión de tablas con filas y columnas en las que una consulta siempre devuelve los mismos campos.

¿Qué pasa si extendemos el concepto para dar cabida a otro tipo de realidades cada vez más frecuentes en la operativa habitual en nuestros días? ¿Acaso todo dato tiene claras estas estructuras? ¿O simplemente estamos dejando fuera de nuestros análisis todo aquello que nuestra operativa de bases de datos no es capaz de recoger? Las bases de datos NoSQL (Not Only SQL, no supone que SQL esté muerto o no deba usarse, sino que hay soluciones mejores) suponen relajar muchas de las limitaciones inherentes a las bases de datos convencionales y a la forma de trabajar con ellas. Colecciones de documentos con campos definidos de manera laxa, en lugar de tablas con filas y columnas, que permiten análisis mucho más rápidos y eficientes y, sobre todo, no limitados a la estructura convencional. La idea es almacenar datos de manera masiva, lo que responde muy bien a la enorme riqueza de datos que genera el mundo actual, y analizarlos sin seguir necesariamente unos estándares que no necesariamente se adaptan a ellos. Donde las bases de datos relacionales resultan costosas y lentas, la alternativa NoSQL resulta mucho más eficiente y barata para manipular datos sin tener necesariamente que  adaptarlos a una estructura rígida. En puridad, un sistema de este tipo no es siquiera una base de datos entendida como tal, sino un sistema de almacenamiento distribuido para gestionar datos dotados de una cierta estructura, estructura que además puede ser enormemente flexible.

¿El problema? Para la mayoría de la gente, la dificultad de “pensar” en un sistema así. Nuestros esquemas mentales se adaptan a un sistema rígido, con normas claras y estructuras marcadas. Los paralelismos con los almacenes divididos en estanterías, archivadores y carpetas son algo que nos funciona mentalmente. Sin embargo, ¿cómo gestionar con un sistema de este tipo, por ejemplo, búsquedas enormes en bases de datos que contienen referencias completamente heterogéneas entre sí y con relaciones de todo tipo, no necesariamente únicas? En muchos casos, hablamos de sistemas que han sido precisamente desarrollados por empresas como Google, Yahoo!, Facebook y similares para gestionar sus propias operativas, usando casi siempre código abierto, con el fin de obtener una estructura que, con un coste y un rendimiento razonables, les permita tratar enormes cantidades de datos con muchísimas relaciones muy complejas entre sí.

En cierto sentido, para entender el tema es preciso “desaprender”. Pero la necesidad de hacerlo es evidente, dada la adaptación de este tipo de estructuras a las problemáticas de operar en el mundo en que vivimos actualmente. Pero no es sencillo: durante algún tiempo, muchas empresas seguirán o bien torturando sus sistemas de bases de datos relacionales hasta el infinito y más allá con costes y rendimientos sencillamente absurdos, o directamente perdiéndose un mundo analítico que no son capaces ni de plantearse cómo recoger. Un mundo del que van a surgir muchas de las ventajas competitivas que veremos en el futuro.

(Enlace a la entrada original - Licencia)