Muy buenas! Seguro que más de uno ha oído hablar de las bondades de las bases de datos llamadas “nosql”. Yo también y la verdad es que me intrigaba mucho así que me puse a analizarlo fríamente. Todos los benchmarks y comentarios de la gente dan como absoluto ganadador a las “nosql”, obligando al destierro a las bases de datos relacionales. Después de analizar qué es cada cosa y las necesidades reales he llegado a una conclusión: Nada más lejos de la realidad. Intentaré explicar lo mejor posible mis razonamientos, quizá de manera demasiado abstracta, del por qué las “nosql” no son la panacea. No obstante, esto es mi opinión y alguien puede pensar que sólo digo chorradas o que en algún aspecto estoy totalmente confundido. Si es así, me gustaría saberlo ya que mi intención siempre es aprender más y nunca imponer mis ideas. Pero siempre desde el respeto Lo primero de todo y de las cosas que más rabia me da es que la mayoría de los benchmarks (muchos son más bien pruebecillas que hace alguien en 10 minutos) miden sólo el tiempo que tarda en leer n entradas o en insertar otras tantas. Bien, ahí la verdad es que las nosql son muy rápidas pero pensemos un poco: ¿qué base de datos se centra exclusivamente en esas tareas? Muy pocas y en casos muy concretos. Normalmente obtener información no es simplemente meter la mano en un cubo y sacarla sino que es algo más complejo. Esta complejidad  se trata de abordar mediante lo que las bases de datos relacionales llaman relaciones.

Por ejemplo, tengo una base de datos en la cual quiero saber cuanta gente es de cada país. Con una sóla consulta sql lo tengo mientras que con una nosql tengo que hacer, el mejor de los casos, tantas consultas como países haya. Ahora dime cuanto tiempo has tardado en hacer todas las consultas. A eso hay que sumarle que estás acoplando tu base de datos a la aplicación, ya que será la aplicación quien mediante funciones propias recorrerá y hará las tareas pertinentes (con su pérdida de eficiencia). Otro factor muy importante son las técnicas y estrategias con las que cuenta un sgbd relacional. Mediante estas técnicas es capaz de acelerar las consultas ya que, como sabe lo que quieres, trata de conseguirlo de la mejor manera posible.  Estas estrategias de optimización son imposibles en una nosql, ejecutarás todas y cada una de las consultas. De esta manera el tiempo total crecerá (en los mejores casos) de manera lineal frente al número de entradas mientras que en una relacional el crecimiento sería bastante más logarítmico.

Cojunto de SGBD Relacionales, los hay de todos los colores. Aunque si sabes SQL podrás manejarte con cualquiera de ellos.

Al usar una nosql estamos renunciando a un montón de funcionalidades. Todo aquel que haya trabajado a un nivel un poco avanzado con bases de datos relacionales será consciente de que hacer una consulta SQL tiene por qué se trivial: cuentas con un montón de posibilidades y hay que encontrar la mejor. Tenemos joins (unir tablas en base a relaciones entre ellas), conjuntos de datos (group by), un completo manejo de fechas (intervalos, sumas, restas, comparaciones…), integridad de los datos, transacciones, excepciones… un sin fin de posibilidades. Tarde o temprano te tocará hacer algo más que leer y escribir datos, y esa tarea la tendrá que hacer tu aplicación (java, php…). En ese momento, justo en ese momento la eficiencia de tu programa caerá por los suelos y todos los milisegundos que has creído ganar te están saliendo caros. Muy caros. Imagina una web donde quieras consultar un trayecto para un día concreto, a unas determinadas horas y que el tren (o lo que sea) pase por unas determinadas estaciones. Hacerlo con una nosql sería realmente doloroso y totalmente inviable.

También existen detalles más concretos como el que voy a comentar. Las nosql no proporcionan ninguna garantía ACID. Por decirlo de manera simple, un sistema ACID cuando dice que un dato se ha guardado, se ha guardado. Ya pueden pasar cualquier cosa que no vas a perder esa información. En cambio, las nosql te pueden decir que ya han guardado el dato pero todavía lo tienen por ahí en memoria de manera temporal y si en ese momento pasa algo “extraño” (se va la luz y el ordenador para, por ejemplo) el dato puede que no se haya guardado (aunque tu pienses que si porque te lo ha “asegurado”) y en ese caso habrás perdido ese dato para siempre. Alguno pensará que esto es una chuminada pero ya me dirás que pasa si surge algún problema de este tipo cuando te ingresen la nómina

Otro tema realmente importante es la integridad de los datos. Esto viene a ser que la información que hay en la base de datos sea útil y verídica. Por ponernos en situación, imagina que tienes una base de datos con autores y libros que han escrito.  En un determinado momento, borras a un autor pero sus libros quedan en la base de datos. ¿A quién pertenecerán ahora esos libros? Tenemos datos que no nos son útiles, sabemos que existen pero… hay muchas lagunas. Otro caso parecido es intentar meter un libro sin indicar su autor. Podemos exigir que todo libro tenga su autor a la hora de insertarlos pero nada nos permitiría saltarnos esta “restricción” en una nosql. Todo esto queda delegado a la aplicación, con todos los inconvenientes que trae. Una buena base de datos es aquella que vela por su integridad. Si unos datos no son fiables, esa información no vale nada. Los datos lo son todo en una base de datos.

Por supuesto no estoy diciendo que las nosql son algo que se debería quemar o guardar en un cajón ni mucho menos. Se diseñaron con un objetivo en mente y la verdad es que lo cumplen muy bien. Este objetivo es el que dije al principio y es insertar muchos datos y acceder a ellos muy rápido, y estos datos no deben ser complejos. Facebook o Twitter dicen que utilizan Cassandra (una base de datos tipo “nosql”) y es normal, ahora te explico. Twitter consiste en insertar mensajes y ver los últimos. Por así decirlo, vas metiendo en un cubo cientos de mensajes y lo único que haces es “ver” los que están por encima. Este es un caso donde una nosql sería lo óptimo. No hay relaciones complejas y el orden viene definido por el orden de inserción (recordemos que ordenar es de las tareas más duras en informática). En Facebook es algo diferente. No puedo decirlo a ciencia cierta, pero aseguraría que no usan (ni tienen pensado hacerlo) una nosql para toda su base de datos. Los casos ideales es en sitios como el muro o comentarios de fotos. El motivo es lo mismo que en caso de twitter. Para el resto, no me cabe la menor duda de que usan algun tipo de base de datos relacional.

Son bastantes diferentes entre sí pero genéricamente se les puede llamar "nosql"

Tarde o temprano se hace alguna relación entre los datos y si esa relación la gestiona el SGBD mucho mejor que manejarlo nosotros a mano. Sinceramente, no me imagino a Facebook haciendo 3 o 4 consultas y luego desde php comprobar las coincidencias para buscar “amigos en común” (de listas enormes). O la alternativa, que sería un trabajo mínimo en php pero una cantidad de consultas exponencial (ambas opciones son totalmente inviables). La única opción donde tendría alguna posibilidad es mediante de la redundancia de datos. Pero la redundancia sería tal que el tamaño de la base de datos sería monstruoso, y toda la velocidad que ganas por ser más rápida podrías perderla por la “distancia” tan grande que tocaría recorrer.

Sin embargo, todas estas limitaciones de las nosql tienen otras ventajas (además de la velocidad). Estas bases de datos son excelentes para sistemas distribuidos y ahora que todo tiende a ponerse “en la nube” se pueden aprovechar desde ese punto de vista. Eso es lo que hace que google ofrezca BigTable en AppEngine (un servicio de hosting). Sin despeintarte puedes tener funcionando un sistema distribuido en tantos nodos como quieras. Esta tarea es bastante más compljea en una db relacional, precisamente por el tema de las relaciones.

Podría simplificar todo esto en una frase: La diferencia entre una db relacional y una nosql es como aquel que le quita los asientos a su coche para que corra más. Correrá más, pero pierdes prestaciones.

Aunque más bien lo relacionaría las churras y las merinas. Se parecen pero son muy diferentes. Pues lo mismo con db relacionales y “nosql”, las dos “guardan datos” pero su finalidad es muy diferente. Y como siempre, queda a criterio del diseñador usar una herramienta u otra (o las dos a la vez).

Para terminar, muchos pensarán que he escogido ejemplos concretos para intentar “machacar” a las nosql. Es cierto, y el motivo es para dar a entender que una base de datos nosql no puede sutituir a una base de datos relacional si lo que tenemos son datos altamente relacionados entre sí. No existen productos milagrosos, todo tiene sus contras. No existe (ni existirá) un sistema gestor de bases de datos (ni ningún software ni cosa en el mundo) que se comporte a la perfección en cualquier situación.

Un saludo y espero que alguien esté es desacuerdo, para así debatir y enriquecer el post un poco

Entradas relacionadas.

Entradas relacionadas.

Ante todo disculpad la tardanza en subir las imágenes que había prometido desde el pasado fin de semana. Tenía pensado hacer un montaje en vídeo algo interesante, pero justo se me ha estropeado el PC y no puedo hacer nada

Ya que estamos, disculpas de nuevo por no hacer el podcast esta semana, pero ya tenemos material calentito para el numero 4, que lo haremos para la semana que viene.

¿Tengo que recordar que es esto de las pegatinas de GPodcast? En el GPodcast 1.3 lanzamos un concurso, en el que, respondiendo una sencilla pregunta podrás ser el poseedor de las maravillosas pegatinas de GPodcast que regalaremos!

Por ultimo antes de poner las fotos, decir que la mayoría de los diseños son de openstickers con licencia MIT. Nuestros propios diseños (que solo hay 2 o 3) los subiré en cuanto arregle el ordenador bajo Creative Commons.

Recordad que aún tenéis mas de 15 días para participar en el concurso!.

A continuación, sin más espera, las fotos. Todas ellas están alojadas en nuestra cuenta de flickr. Pronto mas información en el GPodcast 1.4.

Pegatinas pequeñas

Pegatinas Grandes

Pegatinas de promoción de GPodcast (para los oyentes mas fieles xD)

Aspire One en su salsa sobre lecho de pegatinas

Aspire One cerrado (con pegatinas claro)

Entradas relacionadas:

1. Gpodcast TV #1 Entrega de pegatinas Aquí tenemos la entrega de las pegatinas al ganador del...
2. Gpodcast 1.4 – Bimbo y pizza Volvemos … cada día con mas retraso, el 1.3 con...
3. GPodcast 2.8 – “GPodcast en vinagre” Casi un mes mas tarde del último GPodcast volvemos, pero...

Es un hecho que la tecnología avanza, actualmente los ordenadores se suelen empotrar en un hueco debajo de la mesa (unos 0.001 campos de fútbol) y el consumo medio será de unos 500W (menos que tu microondas cuando calientas la pizzas). Pues parece que las cosas han cambiado un poco, eh? Pues Linux igual, los comentarios de los años 80 quizá estén un poco anticuados (nótese la ironía).

Demostraremos que hasta el usuario mas cateto (en términos informáticos claro) es capaz de usar un cacharro de esos con Linux sin llegar a cortarse las venas. Te enseñaremos todo aquello que te hará pensar “¿Cómo he podido vivir sin linux?”
Ofreceremos alternativas libres a todo eso por lo que siempre se anda buscando un crack o un serial.

Pero sobretodo irá dirigido a aquellos que, ya iniciados, busquen soluciones que solucionen sus problemas, explicando las soluciones para compartir nuestros pequeños conocimientos o cosas interesantes sobre su sitema operativo favorito.

Todo esto aderezado con todas las cosas interesantes (o no) que se nos puedan pasar por la cabeza.

Pues lo dicho, buenas noches y buena suerte, nos vemos!

Entradas relacionadas.