Si hemos visto que incluso un pequeño comercio electrónico puede encontrarse con problemas debido al tamaño de los datos generados, pongámonos en el lugar de las grandes empresas. ¿Cómo almacenan sus datos? ¿Cómo los gestionan? Comencemos por entender la magnitud del problema.
En el primer capítulo hemos visto que la segunda revolución en el mundo de las bases de datos llegó cuando las cantidades de datos a tratar desbordaron las posibilidades del modelo relacional. Ha llegado el momento de precisar un poco esto. Hasta la llegada de Internet y los dispositivos móviles, cualquier experto en bases de datos hubiera dicho que las bases de datos relacionales eran justo lo que se necesitaba para tratar grandes cantidades de datos. En efecto, una base de datos relacional puede tratar sin problemas tablas que contengan millones de filas. Empezamos este libro hablando de los censos como ejemplo típico de volumen enorme de datos. ¿Es posible imaginar bases de datos más grandes que el censo de un país como China o India? Pues en efecto, todos conocemos bases de datos mucho más grandes. Por ejemplo, los usuarios de Twitter envían casi 600.000 tuits cada minuto, lo que significa que en apenas 5 minutos Twitter acumula más información que el censo total de población de China e India. Eso es big data. Como ya vimos al hablar de las 3 V, además del ingente volumen de datos, hay que tener en cuenta la velocidad —todo el mundo espera que cualquier tuit sea visible de manera instantánea por todos sus seguidores—, y de la variedad de contenidos. Todo un reto para cualquier tecnología.
Cuando las grandes empresas vieron que la cantidad de datos que necesitaban almacenar empezaba a no caber en sus discos, la primera, y muy lógica, solución fue adquirir discos más grandes y ordenadores con más memoria. El problema es que ordenadores más grandes significa mucho más dinero. A menudo, estos enormes equipos necesitan incluso personal dedicado a ellos, y la inversión se vuelve difícil de asumir. Por ello, a mediados de la década de 1990 se popularizó una idea conocida desde bastantes años atrás pero no aplicada hasta entonces de forma masiva a las bases de datos: utilizar un clúster de ordenadores. La idea consiste en tener una gran cantidad de ordenadores pequeños, que pueden ser incluso ordenadores domésticos de gama baja, conectados entre sí y trabajando de forma conjunta de forma que parezca que tenemos un gran ordenador. En el caso de una base de datos, tendremos que distribuir los datos entre los diferentes ordenadores, pero de forma que a efectos del usuario siga viéndose como una única base de datos.
Por supuesto, si tenemos muchos ordenadores pequeños y baratos interconectados, es común que de vez en cuando alguno se estropee y nos arriesgamos a perder parte de nuestros queridos datos. Por eso, el programa que distribuye los datos se encarga de grabar cada dato en varios ordenadores distintos. Así se tendrá información repetida (algo que no hubiera gustado a Codd) y no habrá problema si algún ordenador se estropea. Los ordenadores, que se conocen como nodos del clúster, se suelen situar en bandejas situadas una encima de otra. Generalmente, estos ordenadores no tienen ni teclado ni pantalla y únicamente están conectados a otros nodos para compartir información. Podemos pensar en los nodos como las células de un organismo mayor, el clúster. Todos colaboran pero ninguno resulta imprescindible.
Esta idea supuso, y aún sigue siendo, la verdadera revolución detrás de big data. La mayoría de las bases de datos NoSQL están pensadas para ser ejecutadas en clústeres con muchos ordenadores interconectados, e incluyen la idea de la distribución y la redundancia de datos desde el primer momento. Un clúster puede alojar grandes volúmenes de información, y si se nos quedan pequeños, podemos simplemente añadir más ordenadores al clúster sin tener que invertir en grandes superordenadores. Se dice que se trata de un modelo escalable: hacerlo más grande no conlleva grandes inversiones ni supone notables pérdidas de eficiencia. Los clústeres también ofrecen velocidad, ya que todos sus ordenadores trabajan en paralelo, cada uno trabajando sobre un trocito de la base de datos. Más adelante veremos la importancia que tiene poder repartir el trabajo entre varias máquinas que procesan la información de forma simultánea.
Es justo este entorno altamente distribuido el que nunca ha resultado tan cómodo a las bases de datos relacionales y el que ha posibilitado la introducción de las bases de datos NoSQL. Cualquier persona con unos cuantos ordenadores modestos y una base de datos NoSQL, gratuita y fácil de instalar, puede llegar a manejar ingentes cantidades de información de forma cómoda y barata, superando en eficiencia lo que hasta hace poco solo podían conseguir carísimas bases de datos alojadas en también carísimos ordenadores.
Este resultado, presentado en 1998 por Eric Brewer, incluye en su nombre las iniciales de las tres propiedades que nos gustaría tener en nuestros sistemas big data: consistency (consistencia), availability (disponibilidad) y partition (partición). La consistencia la hemos visto ya, se trata de que un sistema nos proporcione siempre la misma respuesta si le hacemos la misma pregunta dos veces seguidas y no ha sucedido nada entre medias. La disponibilidad es simplemente requerir que el sistema conteste cuando le preguntamos, que no nos diga “vuelva usted mañana”. Finalmente, la partición es justamente un entorno como el descrito hasta ahora, que incluye información repartida entre varios nodos y replicada para evitar pérdidas de información. Pues bien, este resultado nos dice que si queremos un entorno distribuido de este tipo, es decir, si asumimos la existencia de la partición, tendremos que renunciar o bien a la consistencia, o bien a la disponibilidad. Todo junto no se puede tener.
Veamos por qué. Partamos de un sistema distribuido y con réplicas y supongamos que en este sistema está registrado que Bertoldo tiene dos propiedades inmobiliarias. Como sabemos, esta información no está solo en un ordenador, sino, digamos, en tres, de forma que evitemos posibles pérdidas de datos si se estropea alguno o se pierde la conexión. Llamemos a estos ordenadores A, B y C y asumamos que todos ellos tienen la información correcta: Bertoldo tiene dos propiedades. Pues bien, resulta que Bertoldo ha adquirido un nuevo inmueble y debemos incrementar su número de propiedades. Para ello, nos ponemos en contacto con uno de los ordenadores, digamos el A, y le comunicamos el cambio. El ordenador cambia el número de dos a tres y procede a informar a sus colegas B y C. Y aquí llega el giro dramático: B y C no le contestan. Puede que A haya perdido la conexión, que su tarjeta de red se haya estropeado…, no se sabe.
Pero es que en este momento la tensión aumenta, porque llega otro usuario y pregunta a A por el número de propiedades que tiene Bertoldo. El ordenador A tiene dos posibilidades, las dos malas. En primer lugar, le puede contestar “tres”, sabiendo que es la verdad. Pero es que puede que, a continuación, A sea retirado para reparación (o simplemente termine de estropearse) y que si el usuario vuelve a conectarse y repite la pregunta, quien le conteste sea B, que no se ha enterado de nada y que responderá tranquilamente “dos”. Hemos logrado disponibilidad, porque en ambos casos la pregunta ha sido contestada, pero hemos perdido consistencia al obtener dos respuestas diferentes a la misma pregunta sin que nadie haya cambiado nada. Si escuchamos atentos, seguro que podemos escuchar la voz de Codd, el padre de las bases de datos relacionales, que desde el más allá susurra “os lo dije”.
Volvamos atrás y tratemos de evitar esta inconsistencia y su consiguiente susurro sobrenatural. Si queremos hacerlo, el ordenador A, que sabe que sus colegas tienen una versión distinta del dato, solo puede decir al usuario que pregunta por las propiedades de Bertoldo “no puedo contestarle, vuelva usted en un rato”. En este caso no hay inconsistencia, pero hemos perdido disponibilidad.
El resultado es importante, porque sabiendo que nunca tendremos consistencia y disponibilidad completas, podemos elegir una de las dos propiedades dependiendo de la aplicación concreta. Por ejemplo, en los cajeros automáticos se prefiere respetar la consistencia, es decir evitar, por ejemplo, que podamos sacar más dinero del que tenemos debido a un fallo de conexión, a costa de la disponibilidad. De ahí el mensaje “En estos momentos no podemos atenderlo, diríjase al cajero más cercano”. En otros contextos sucederá lo contrario y primará la disponibilidad frente a la consistencia.
Pasemos a visitar la joya de la corona big data, el centro de datos donde se almacenan, en forma generalmente de clúster, los datos de las grandes organizaciones. Se suelen encontrar en lugares apartados y a menudo buscan pasar desapercibidos camuflándose en forma de naves industriales. Pero si entramos, descubrimos lo último en tecnología y todo tipo de soluciones ingeniosas para mantener latiendo el corazón de los grandes datos.
Un punto fundamental es el consumo eléctrico. Los algo más de 7 millones de centros de datos de los que se dispone en el mundo consumen un poco más del 1% de la electricidad mundial, llegando a cerca del 3% en algunas regiones como Europa. Se trata de un consumo superior al de países como Argentina o Egipto y solo ligeramente inferior al de Reino Unido. Una cantidad enorme de energía que se consume no solo en la corriente que hace funcionar los ordenadores, sino también en refrigeración. Los grandes servidores suelen alojarse en una sala conocida como “la pecera”, “la nevera” o la “sala fría”, que debe tener la temperatura ideal de entre 21 y 23 grados Celsius para asegurar la máxima duración de los equipos.
Pero ¿qué pasa si se corta la energía? Si todos los ordenadores se apagan, adiós datos, y esto no puede permitirse. Por ello, algunos grandes centros suelen tener gigantescos motores eléctricos diésel, en algunos casos motores de los grandes transatlánticos, para generar la electricidad necesaria. Como el motor auxiliar no se puede tener siempre en funcionamiento y tarda un tiempo en arrancar, durante esos minutos la energía la proporcionan miles de baterías de coche, que deben renovarse cada poco tiempo para asegurar su máxima eficiencia. Todo sea por los datos.
La idea de un clúster de ordenadores parece genial. El propietario de una pequeña empresa que vende por Internet puede pensar que los enormes centros de datos son una exageración, que le basta con alojar un pequeño clúster en un rincón de su nave. No siempre es una buena idea. Aunque más baratos, fáciles de instalar y mantener que los superordenadores, un clúster sigue exigiendo unos conocimientos mínimos. Además, a pesar de que los datos están replicados y sabemos que no pasa nada cuando un nodo (ordenador) del clúster se estropea, no queremos correr el riesgo de que se apague el clúster entero por un corte de luz en el barrio o de que una inundación en nuestra nave estropee los datos de nuestros clientes en todo el mundo, con la siguiente pérdida de pedidos y de confianza. ¿Qué hacer, dónde alojamos nuestros datos?
La respuesta se les ocurrió a los propietarios de los centros de proceso de datos: permitir alojar datos ajenos en sus centros de datos pagando un cierto alquiler. Es lo que se llama alojamiento en la nube. Utilizando el alojamiento en la nube, nuestros datos y páginas web se cobijan en los ordenadores protegidos de los grandes centros de proceso de datos, donde nos aseguran que no habrá caídas de tensión ni incendios que puedan dejar nuestra web sin servicio o perder nuestros valiosos datos.
La idea de nube no solo se aplica al almacenamiento de los datos y las páginas web, sino también a la gestión y análisis de los datos. Es lo que se llama computación en la nube. La idea es que podemos “alquilar” ordenadores que están alojados en centros de procesos de datos para instalar nuestros propios programas (con algunas restricciones). Si en algún momento necesitamos más ordenadores, se alquilan sin más, y si la necesidad baja, basta con no renovar el alquiler. De esta forma, los cómputos en la nube o cloud computing nos permiten adaptar los recursos que necesitamos para tratar los datos en cada momento, sin grandes inversiones en infraestructuras. Sabiendo esto, es fácil entender el éxito de la propuesta, y las grandes inversiones que han realizado empresas como Amazon con su servicio AWS (Amazon Web Services), el propio Google con su Google Cloud Platform o Microsoft con su servicio Azure.
Es conveniente aclarar que los ordenadores que alquilamos no existen físicamente, al menos como máquinas individuales, sino que los clústeres alojados en el centro de datos “simulan” ordenadores individuales con las características que desee el usuario, que en realidad está compartiendo recursos (discos, memoria, procesador, etc.) con el resto de máquinas virtuales contratadas por otros clientes.
Ya estamos listos para repasar la importancia del fenómeno big data en algunas empresas muy conocidas.
La historia del germen Google recuerda a la de Microsoft y a la de otras muchas empresas de éxito en el mundo de la informática: dos amigos se conocen en una universidad, en este caso Larry Page y Sergey Brin en la Universidad de Standford en 1995. Un año más tarde crean un motor de búsqueda que permite encontrar páginas en la web con solo teclear unas palabras. El motor se llama primero BackRub y en 1998 pasa a conocerse como Google. El éxito se basa en las rápidas y precisas búsquedas que lleva a cabo un método que han definido ambos, el famoso PageRank. El problema es que para ello necesitan almacenar información de literalmente todas las páginas web disponibles en Internet. Lo que comienza siendo un pequeño servidor de datos hecho por ellos mismos (cuyo armazón estaba formado por piezas de lego), pronto es un sistema más y más complejo. ¿Cómo almacenar tanta información? Las bases de datos relacionales parecían no ser lo suficientemente rápidas y Google decidió en 2004 crear su propia base datos, la BigTable, capaz de almacenar petabytes de información. En lugar de comprar ordenadores gigantescos para tan gigantesco volumen de datos, la BigTable se encontraba distribuida entre clústeres de cientos de miles de ordenadores personales. Pronto la “granjas de ordenadores” de Google pasaron a representar el mundo del big data.
La BigTable era un buen invento, pero Google, tan generoso a la hora de localizar información ajena, no quiso compartir su secreto hasta recientemente, cuando ya ha cambiado la BigTable por una nueva base de datos, Spanner.
Si bien la información sobre las bases de datos de Google se obtiene con cuentagotas, no podemos decir lo mismo de la información sobre sus centros de datos. Aquí no hay ni cuentagotas. Si buscamos en Google “Google data centers” obtenemos multitud de páginas del propio Google, todas llenas de fotos muy llamativas y recorridos virtuales por algunos centros destacados pero con poca información cuantificable. Los últimos datos conocidos hablan de cerca de tres millones de servidores en más de 20 centros de procesos de datos, pero se trata de meras estimaciones.
Como tiene que haber de todo, Amazon no fue fundada por dos amigos en una universidad americana. Su fundador, Jeffry Preston Jorgensen, más conocido como Jeff Bezos, tenía 30 años cuando decidió que la venta por Internet tenía un gran futuro. Examinó varios posibles productos y se decidió finalmente por los libros. El resto de la historia es bien conocido: Amazon es hoy en día la primera empresa de Internet en cuanto a facturación, por delante de Google, y Bezos ocupa el primer puesto en la lista Forbes 2021 de los más ricos del mundo.
Igual que le había sucedido a Google y a otras compañías, Amazon encontró problemas cuando la cantidad de datos creció hasta desbordar las posibilidades de sus bases de datos relacionales. En 2007 la compañía desarrolló una base datos NoSQL clave-valor llamada Dynamo. El artículo en el que se daba a conocer esta tecnología es conocido como el más influyente en la corta historia de las bases de datos NoSQL. Poco después, la compañía mejoró Dynamo dando lugar DynamoDB, otra base de datos big data.
Pero en lugar de guardarse su tecnología para manejar los datos de los pedidos de Amazon, la empresa vio inmediatamente que tenía una nueva oportunidad de negocio a través de los cómputos en la nube. Amazon fue una de las primeras empresas en ofrecer almacenamiento big data con NoSQL en sus centros de datos a través de DynamoDB, que almacena tres réplicas geográficamente distribuidas de cada tabla para mayor seguridad. Como sucede a menudo en el fenómeno big data, lo que para los expertos indica “más seguridad” a la mayor parte de la gente nos parece un tanto inquietante: en la nube, nuestros datos andan diseminados por cualquier lugar, duplicados o triplicados, puede que incluso en países diferentes. Parece que perdemos control sobre dónde están y puede que sobre quién los puede ver o utilizar.
La idea de Amazon de ofrecer su base de datos NoSQL para alojar big data en entornos de nube ha sido un éxito. En 2021 casi el 75% de los ingresos de explotación de la compañía se debieron a su plataforma cloud, lo que no está mal para la empresa de Internet con más beneficios del mundo por delante de Google. De hecho, mejor que decir que Amazon es una empresa de venta online que alquila sus ordenadores, la proporción de sus ingresos debida al negocio cloud nos sugiere que sería más correcto decir que Amazon es una empresa de alquiler de servicios cloud que también realiza venta online.
Volvemos a la universidad americana, está vez a Harvard en tiempos tan recientes como 2003, y a otro grupo de amigos con Mark Zuckerberg a la cabeza. Se trata de una historia similar a las anteriores y además uno de los casos más conocidos, por lo que lo dejaremos pasar para ir a lo que nos importa aquí: los datos.
Cuando Facebook empezó a hacerse famoso fuera de la universidad, empezaron los problemas de escalabilidad, es decir, demasiados datos que manejar a un ritmo demasiado alto. Por entonces, Avinash Lakshman, uno de los creadores de Dynamo en Amazon se había cambiado a Facebook, y junto Prashant Malik trabajaba en una nueva base de datos, Cassandra. Esta base de datos fue lanzada en 2008, pero lo hizo como código abierto, lo que significa que cualquiera puede utilizarlo. Y hoy en día, además de Facebook, entre otras muchas empresas, podemos encontrar Cassandra en Instagram, Spotify o eBay.
Quizás sea este un buen momento para matizar un poco: por razones de brevedad y simplicidad, estamos asociando cada empresa con una base de datos, la más famosa de todas las bases de datos que usa o con la que en algún momento fue la más novedosa. Pero en realidad todas las empresas importantes utilizan distintos tipos de bases de datos, relacionales, NoSQL y de cualquier otro tipo, cada una para un objetivo concreto. Y hacer este comentario al hablar de Facebook es pertinente, porque aunque Cassandra sea una base de datos NoSQL muy importante y aunque fuera creada por la propia compañía, en la práctica, solo es utilizada para las búsquedas en la bandeja de entrada de nuestra cuenta de Facebook. Para el resto de sus aplicaciones la compañía utiliza otras bases de datos NoSQL como Memcached, HBase o, sorpresa, una base de datos relacional de libre distribución, MySQL. En efecto, Facebook sigue confiando para labores primordiales como la gestión de mensajes en el muro en las viejas y fiables bases de datos relacionales. La empresa cuenta con uno de los mejores grupos de programadores MySQL del mundo y no piensa cambiar porque las modas digan lo contrario, mostrándonos de paso que las bases de datos relacionales siguen presentes. Así que, cuando a un amante de las bases de datos relacionales se le dice que estas no pueden trabajar bien en clústeres ni soportar big data, ya se sabe lo que se va a escuchar a continuación “¿y qué me dices de Facebook con MySQL?”.
Facebook (Meta) tiene, que se sepa, 18 grandes centros de datos incluyendo alguno instalado dentro del círculo polar ártico con el objeto de ahorrar en los enormes costes de refrigeración. Seguro que la mayoría de nosotros nunca imaginó que las imágenes que vemos en nuestro Instagram y en el de nuestros amigos descansan, cuando nadie las mira, en el círculo polar ártico.
Big data no solo es útil para las empresas relacionadas con las tecnologías de la información. Inditex, el gigante español del sector textil creado por Amancio Ortega, que incluye Zara, Pull&Bear o Massimo Dutti entre otros, tiene su propio centro de datos en Arteixo (A Coruña). El centro incluye 4.000 servidores de alta densidad (entre los que no se incluyen los servidores de Zara.com, alojados en Irlanda). Aunque, igual que todas las grandes empresas Inditex no da detalles sobre las tecnologías que utiliza para gestionar sus datos, sí han dejado claro que están empleando tecnologías big data ya existentes. Gracias a la gestión eficiente de los datos, cuando un cliente no encuentra una talla de una prenda, Inditex garantiza que repondrá el producto en menos de 48 horas. Para hacer esto, el sistema informático primero comprueba si la prenda existe en el stock de una tienda o centro de distribución cercano y en caso de que no sea así, es el propio sistema informático el que solicita la fabricación de nuevas prendas.
Esta velocidad de renovación y reposición, y sobre todo el haberlo conseguido sustituyendo los clásicos enormes almacenes de prendas textiles por una gestión eficaz de la información, constituye buena parte del éxito de la marca. Pero no todo es gestión de stock. Aunque no haya confirmación oficial, parece lógico pensar que la empresa también aplique técnicas de inteligencia artificial para averiguar, por ejemplo, qué prendas son compradas a la vez de forma habitual. Puede que los diseñadores piensen que este otoño se llevará la combinación de prendas verdes y grises, pero que al poco de lanzar las nueva línea de otoño, descubran al analizar los datos recopilados de forma inmediata de sus alrededor de 7.000 tiendas en todo el mundo que una cantidad significativa de clientes prefieren combinar verde y morado. Un análisis de este tipo puede llevar a cambiar la gama de colores en fabricación sobre la marcha, aprovechando que las tiendas ofrecen nuevas prendas hasta dos veces por semana. A los datos de ventas recopilados por las tiendas hay que añadir la información que se extrae sobre la navegación en las páginas de Internet de la empresa, la recopilada de forma automática por programas que examinan constantemente las redes sociales, etc. En resumen, el manejo de los datos permite a Inditex, y a otras grandes compañías textiles, descubrir nuevas tendencias de moda no solo consultando a especialistas, sino confiando en el criterio que marcan los propios clientes.