Hablemos de NOSQL

¿Habéis usado alguna vez una base de datos NoSQL?

Claro, Chip.

Por supuesto, hay una base de datos NoSQL desde 1960: IBM DL/1, que almacenaba datos en red.

No me refería a eso, prof.

Pero seguro que os tenéis que acordar: El Gran Debate, el capítulo donde hablamos sobre IMS y cómo se impusieron los lenguajes relacionales, ya sabéis, los antecesores a SQL.

Suena épico. Los ancestros de SQL luchando por instaurar una paz Jedi.

No me digas, ¡los Sith han resurgido!

Si por los SIF te refieres a sistemas que no usan lenguajes relacionales, entonces sí. Pero no ahora, llevan tiempo entre nosotros.

¿En las sombras?

No creo, todos han oído hablar de ellos y seguro que han usado o usan alguna de estas bases de datos.

¡Están en el lado oscuro!

Bueno, vamos al inciso rápido que quiero elegir base de datos para mi nuevo proyecto.

Antes de continuar, un inciso.

¿Te gustaría apoyar a nuestro canal?

No te olvides de darle a me gusta y, si no lo estás, suscribirte para no perderte futuro contenido. También puedes apoyarnos si quieres uniéndote al canal o enviándonos un gracias aquí abajo en el botoncito. Nosotros te lo agradeceremos igualmente y os avisaremos de ofertas y promociones del canal.

Y además también podemos acompañarte desde tu plataforma de podcast favorita.

Ahora sí, continúa.

La historia de NoSQL.

Uf, creo que esto no va a ser nada rápido.

Paciencia. Solo quería hacer hincapié en que la primera vez que se empleó el término NoSQL, en 1998, se refería expresamente a una base de datos llamada Strotsy NoSQL, que es relacional pero no emplea SQL.

Pues igual que el movimiento que surgió en 2009 en San Francisco para implementar bases de datos distribuidas.

Sí. Johan Oscarsson, TheLast.fm, ofició la reunión y atrajo grandes empresas que prestaron sus proyectos como Cassandra por parte de Facebook.

Sí, también CouchDB, iniciado por Demian Katz, que posteriormente donó el proyecto a la Fundación Apache.

MongoDB. Esta base de datos tuvo tanto éxito que la empresa que la creó, Tengen, cambió su nombre a MongoDB Inc.

HBase, inspirada en Bigtable de Google, que se ejecuta sobre Hadoop.

Redis por Salvatore Sanfilippo, que más tarde crearía Redis Labs.

No estoy seguro de que podamos considerar Redis una base de datos.

También Voldemort por la parte de LinkedIn.

Voldemort, ¿queréis más muestras de que NoSQL es algo oscuro?

Por cierto, HBase se inspiró en Bigtable de Google, pero en esta fecha ya existía otro documento por parte de Amazon llamado DynamoDB que hacía otra propuesta para base de datos distribuidas.

Exacto, Cassandra y Voldemort están inspiradas en este documento.

Pero, ¿por qué no seguir usando MySQL o Postgres? ¿Por qué estas nuevas bases de datos?

Por la dificultad de distribuir, Chip. Una base de datos relacional necesita enlazar de forma íntegra los datos de una columna cuando corresponde con una clave de otra tabla, y tener estos datos distribuidos hace el sistema lento y en ocasiones inconsistente.

¿Entonces la solución es no usar SQL?

No, la solución es no usar el modelo relacional.

Pero NoSQL dice no y SQL...

Sí, pero este término se malinterpretó. Como dijo en su momento Strozzi, el movimiento debería haber sido no real o algo similar. Pero como SQL se asociaba siempre a relacional...

Es un lenguaje relacional.

Pero no el único chip, de hecho... Los lenguajes de consulta de Couchbase, Nickel, o de Cassandra, SQL, o Particle de DynamoDB se parecen mucho a SQL.

Pero el documento de DynamoDB de Amazon no fue implementado. ¿O sí?

Amazon implementó su modelo en un producto en la nube llamado DynamoDB. Y aunque se basa en su documento DynamoDB, tiene otras características adicionales, por ejemplo, Particle.

Incluso la forma de construir las consultas para MongoDB muchas veces puede atribuirse al modo en que se haría en un lenguaje relacional.

¡Vaya! Pues entonces el nombre no estuvo bien elegido.

No. Por eso intentaron corregirlo cambiando su significado por el de Not Only SQL o No Solo SQL.

Hemos mencionado muchas bases de datos. Hemos dicho que no son relacionales. Pero si no son relacionales, entonces, ¿qué son?

Los modelos distribuidos.

¿Pasamos de modelo relacional a modelo distribuido?

No, eso no es un modelo per se.

A ver, Chip. De momento conocemos el modelo jerárquico, implementado por IMS, y modelo de red por IDMS en la década de 1960 y 1970.

Sí, en el gran debate dijimos que en 1970 surgió el modelo relacional y ganó al modelo anterior en 1980.

Exacto. En la década de 1990 el modelo relacional imperaba.

Dominio Jedi establecido.

Hubo un intento de hacer base de datos orientada a objetos en la década de 1980, pero ya sabemos que la orientación a objetos tiene sus deficiencias. Ya sabéis, nuestro capítulo del desastre del billón de dólares.

Entonces, en la década de 2000 surge NoSQL.

En verdad, en la década de 2000 surgen los modelos clave-valor.

El claro exponente aquí es Redis.

También podemos agregar a Couchbase y a ArangoDB.

El modelo de documentos MongoDB.

Este modelo lo domina MongoDB.

También CouchDB y Couchbase.

¿No son lo mismo?

No, no son lo mismo.

Un momento, has agregado a Couchbase otra vez.

Después te cuento.

Seguimos con el modelo de columnas.

Cassandra, obviamente.

Por último, y quizás el que más destacó inicialmente, fue el modelo de grafos.

Me suena a Neo4j, pero eso es solo para Java, ¿no?

No, Neo4j se puede emplear desde cualquier lenguaje de programación, aunque su nombre es verdad que confunde. No obstante, hoy en día es más llamativo ARANGO DB.

¡Vaya! Agregaste de nuevo ARANGO DB.

Lo he hecho porque en la década de 2010 comenzó a emplearse un nuevo modelo: el multimodelo.

¡Ah, vale! Que hay bases de datos que no se restringen a un solo modelo de datos.

¡Exacto!

¡Pro! Se te olvida otro modelo de esta década.

¿Cuál?

¡El modelo de series temporales!

¡Cierto! Gracias por el apunte, Violeta. En esta sección tenemos a InfluxDB.

Pues hay bastante diversidad, sí.

Estos modelos llegaron para cambiar las reglas del juego. Mientras los modelos relacionales se basan en ACID, estos modelos se basan en la distribución de datos en diferentes máquinas para poder gestionar grandes volúmenes de información.

Un momento, ¿qué es ACID?

Es una explicación larga, Chip. Hacemos una cosa: vídeo extra y explicamos ACID, CAP y PASELC para nuestros miembros.

Vale, pero aún no hemos dejado claro cómo y para qué sirven los diferentes modelos. ¿Podemos hacer un repaso a algunas de las bases de datos de referencia para cada uno de los modelos?

¡Vamos a ello! Modelo clave-valor: Redis. Es innegable que Redis es la base de datos por excelencia en este modelo.

Pero, pro, esta base de datos se emplea más como sistema de caché o para datos temporales que para almacenar datos duraderos.

Sí, pero es por su enfoque y características únicas que hacen posible tener un almacenamiento rápido y sencillo cuando los datos a almacenar no son muy complejos e incluso cuando tienen un carácter temporal.

Es buena opción si, por ejemplo, quieres hacer un programa de compraventa de entradas de cine.

En este caso Redis puede ser ideal para la gestión de cada sala, las butacas, las reservas y datos que tiene sentido almacenar y manejar con velocidad hasta 5 minutos después de que comience la película. Pero que al terminar esa misma película pues ya no se necesita.

Pero tampoco podríamos borrar los datos. Necesitamos la información de la venta y otros datos más que deben de ser permanentes.

Si hablamos de cuentas de usuarios con tarjetas de fidelización, anotar los pagos de tarjeta y otros datos más complejos o sensibles, quizás debamos elegir otra base de datos para ese menester.

Entonces, para la gestión de datos como sesiones de usuario, Situación temporal de un recurso como una sala de cine o las butacas es ideal, pero en otros menesteres no.

Exacto. Ten en cuenta que los datos de Redis se almacenan en memoria aunque se vuelquen de vez en cuando al disco, por lo que hay cierta limitación. Modelo de columnas: Cassandra. Cassandra es un claro exponente de este modelo de datos.

Las columnas se distribuyen en diferentes nodos en lugar de las filas.

Exacto, se almacenan por separado, por lo que cuando se hace una consulta y se retornan los datos, se toman esas diferentes columnas donde se distribuye la información y se retorna al usuario.

Se dice de Cassandra que es muy veloz escribiendo, por lo que suele emplearse para almacenar grandes volúmenes de datos que sean simples de consultar.

¿Cómo de simples?

No es una base de datos relacional, por lo que es mejor que toda la información quede en la misma tabla y no distribuida en diferentes tablas.

A menos que puedas permitirte hacer diferentes consultas simples cada vez.

Para hacer un cuadro de control entonces con consultas complejas no es la elección ideal, ¿no?

No, a menos que diseñes tu aplicación para almacenar los datos de forma que la lectura sea simple. Pero finalmente la limitación de índices puede hacer que el número de filtros se limite.

Pero esta base de datos sí la podríamos emplear para usuarios, tarjetas de fidelización, anotar pagos de tarjeta y otros datos en nuestro ejemplo del cine, ¿no?

¡Exacto! En este ejemplo podríamos tenerlo todo a excepción de los datos estadísticos, que se complican. Modelo de documentos.

¡MongoDB!

¿Por qué lo gritas siempre?

¡Es la base de datos que más conozco! En esta base de datos sí sé que podemos introducir los usuarios, compraventa de entradas y todos los datos.

Sí, esta base de datos te permite tener una colección de documentos para las salas de cine. Puedes tener un documento por proyección incluso, por lo que cada compra de entrada puede escribirse dentro del documento indicando qué butacas están ocupadas y cuáles libres. Pero... Bueno, MongoDB tiene sus puntos débiles: no soporta un alto volumen de escrituras concurrentes, su consistencia siempre es eventual y no permite realizar consultas complejas.

Discutible.

Depende de la carga, pero obviamente siempre es mejor emplear otros modelos para según qué tareas. Modelo de grafo: Neo4j.

Esta base de datos tiene un uso muy concreto, ¿no? Siempre la he visto muy de nicho.

¡Cierto! El típico caso de uso de relaciones de amistad entre usuarios y después extraer los amigos de nivel 2 y 3 de tus contactos.

Es normal, el modelo de grafo se especializa en relaciones entre elementos, por lo que en nuestro caso de uso Si tenemos página web y una sección específica con actores, directores y películas, podríamos utilizarlo para enlazar a esos datos y poder buscar películas en las que Tim Burton y Helena Bonham Carter trabajen juntos.

Pues serían casi todas las de Tim Burton.

También podríamos obtener las películas de Tim donde no salga Helena.

Vale, queda claro.

Modelos de series temporales: InfluxDB. Este modelo no suele incluirse en la mayoría de opciones cuando se habla de NoSQL, Pero ahí está.

Es ideal para almacenar datos estadísticos o datos de un fuerte carácter temporal.

¿Fuerte carácter temporal? ¿Eso qué significa?

¿Has visto que la mayoría de estadísticas de las páginas web muestran las últimas 24 horas, los últimos 7 días y franjas de tiempo similares?

Sí, las he visto. ¿Estas bases de datos permiten almacenar temporalmente datos?

No solo eso, ayudan para hacer esos cortes.

¿Permiten realizar cortes por hora, día y mes?

Exacto. No solo la configuración de tiempo la ponemos nosotros, podemos elegir. Un claro ejemplo de estas bases de datos es InfluxDB.

Entonces nosotros vamos agregando cuándo se venden las entradas y puede darnos datos para un gráfico que muestre las ventas por hora, día y semana.

No solo eso, Chip, también ayudan para extraer las estadísticas.

Multimodelo.

No hace falta que digas nada, pro. Está claro por el título que estas bases de datos podrán combinar clave valor con documentos, grafos, series temporales y o columnas según el caso.

Exacto. Aquí tenemos a ArangoDB que soporta documentos, grafos y clave valor.

También está OrientDB que soporta grafos, documentos, clave-valor y orientación a objetos.

Dijimos también Couchbase que es de documentos y clave-valor.

Exacto, pero a la hora de buscar una base de datos no solo hay que fijarse en el modelo, sino también en sus características específicas.

Entonces no me vas a ayudar a elegir la base de datos para mi proyecto, ¿no?

Conclusiones.

Ah, eso es un no.

Las bases de datos NoSQL no se refieren a no emplear SQL, sino a que no emplean el modelo relacional de bases de datos muy extendidas en uso en la década de 1990. Venían a resolver el problema de la distribución de datos y escalabilidad, pero... ¿lo hicieron?

La muestra está en empresas que emplean estas bases de datos como Facebook, Amazon o Google. Cada una emplea un modelo diferente e incluso dentro del mismo modelo emplean características diferentes. Pero ahora el turno es para vosotros.

¿Creéis que NoSQL es mejor solución que SQL para el almacenamiento y uso de los datos?

¿Qué bases de datos habéis usado de cada uno de los modelos?

¿A que también os gusta MongoDB?

¡Déjanos tus comentarios!

A ver, MongoDB es mi base de datos de elección, pero parece que Postgres puede almacenar campos JSON. ¿Por qué?

Chip, eso es por NewSQL.

¿NewSQL? ¿A qué te refieres?

¿No te acuerdas de ese movimiento para aportar a las bases de datos relacionales de un modelo híbrido para obtener mejor distribución?

Entonces, ¿no hace falta que use NoSQL? Usando Postgres puedo escalar.

Ay, Chip, Chip, Chip.

¿Qué?

Tenemos que hablar de NewSQL.

Continuará.