NoSQL: No es oro todo lo que reluce por Maxpowel en ene.

31, 2011

Muy buenas! Seguro que ms de uno ha odo hablar de las bondades de las bases de datos
llamadas nosql. Yo tambin y la verdad es que me intrigaba mucho as que me puse a
analizarlo framente. Todos los benchmarks y comentarios de la gente dan como absoluto
ganadador a las nosql, obligando al destierro a las bases de datos relacionales. Despus de
analizar qu es cada cosa y las necesidades reales he llegado a una conclusin: Nada ms
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
opinin y alguien puede pensar que slo digo chorradas o que en algn aspecto estoy
totalmente confundido. Si es as, me gustara saberlo ya que mi intencin siempre es aprender
ms y nunca imponer mis ideas. Pero siempre desde el respeto Lo primero de todo y de las
cosas que ms rabia me da es que la mayora de los benchmarks (muchos son ms bien
pruebecillas que hace alguien en 10 minutos) miden slo el tiempo que tarda en leer n
entradas o en insertar otras tantas. Bien, ah la verdad es que las nosql son muy rpidaspero
pensemos un poco: qu base de datos se centra exclusivamente en esas tareas? Muy
pocas y en casos muy concretos. Normalmente obtener informacin no es simplemente meter
la mano en un cubo y sacarla sino que es algo ms 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 pas. Conuna sla consulta sql lo tengo
mientras que con una nosql tengo que hacer, el mejor de los casos, tantas consultas como pases haya. Ahora dime cuanto tiempo
has tardado en hacer todas las consultas. A eso hay que sumarle que ests acoplando tu base de datos a la aplicacin, ya que ser la
aplicacin quien mediante funciones propias recorrer y har las tareas pertinentes (con su prdida de eficiencia). Otro factor muy
importante son las tcnicas y estrategias con las que cuenta un sgbd relacional. Mediante estas tcnicas es capaz de acelerar las
consultas ya que, como sabe lo que quieres, trata de conseguirlo de la mejor manera posible. Estas estrategias de optimizacin son
imposibles en una nosql, ejecutars todas y cada una de las consultas. De
esta manera el tiempo total crecer (en los mejores casos) de manera lineal
frente al nmero de entradas mientras que en una relacional el crecimiento
sera bastante ms logartmico.
Cojunto de SGBD Relacionales, los hay de todos los colores. Aunque si sabes
SQL podrs manejarte con cualquiera de ellos.



Al usar una nosqlestamos renunciando a un montn defuncionalidades. 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
montn 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 ms que leer y escribir datos, y esa tarea la tendr
que hacer tu aplicacin (java, php). En ese momento, justo en ese momento la eficiencia de tu programa caer por los suelos y
todos los milisegundos que has credo ganar te estn saliendo caros. Muy caros. Imagina una web donde quieras consultar un trayecto
para un da concreto, a unas determinadas horas y que el tren (o lo que sea) pase por unas determinadas estaciones. Hacerlo con una
nosql sera realmente doloroso y totalmente inviable.
Tambin existen detalles ms concretos como el que voy a comentar. Las nosql no proporcionan ninguna garanta 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 informacin. En cambio, las nosql te pueden decir que ya han guardado el dato pero todava lo tienen por ah en
memoria de manera temporal y si en ese momento pasa algo extrao (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 habrs perdido ese dato para siempre.
Alguno pensar que esto es una chuminada pero ya me dirs que pasa si surge algn problema de este tipo cuando te ingresen la
nmina
Otro tema realmente importante es la integridad de los datos. Esto viene a ser que la informacin que hay en la base de datos sea
til y verdica. Por ponernos en situacin, 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 quin pertenecern ahora esos libros?
Tenemos datos que no nos son tiles, sabemos que existen pero hay muchas lagunas. Otro caso parecido es intentar meter un li bro
sin indicar su autor. Podemos exigir que todo libro tenga su autor a la hora de insertarlos pero nada nos permitira saltarnos esta
restriccin en una nosql. Todo esto queda delegado a la aplicacin, 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 informacin 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 debera quemar o guardar en un cajn ni mucho menos. Se disearon
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 rpido, 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 estn por encima. Este es un caso donde una nosql sera lo
ptimo. No hay relaciones complejas y el orden viene definido por el orden de insercin (recordemos que ordenar es de las tareas ms
duras en informtica). En Facebook es algo diferente. No puedo decirlo a ciencia cierta, pero asegurara 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 genricamente se les puede llamar "nosql"
Tarde o temprano se hace alguna relacin entre los datos y si esa relacin 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
comn (de listas enormes). O la alternativa, que sera un trabajo mnimo en php pero una
cantidad de consultas exponencial (ambas opciones son totalmente inviables). La nica opcin
donde tendra alguna posibilidad es mediante de la redundancia de datos. Pero la redundancia sera tal que el tamao de la base de
datos sera monstruoso, y toda la velocidad que ganas por ser ms rpida podras perderla por la distancia tan grande que tocara
recorrer.
Sin embargo, todas estas limitaciones de las nosql tienen otras ventajas (adems 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 ms compljea en una db relacional, precisamente por el
tema de las relaciones.
Podra 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 ms. Correr ms, pero pierdes prestaciones.
Aunque ms bien lo relacionara 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 diseador usar una
herramienta u otra (o las dos a la vez).
Para terminar, muchos pensarn 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 ningn software ni cosa en el mundo) que se comporte a la perfeccin en cualquier situacin.