Etiquetas
Cada vez que comento de alguna optimización el SQL de la base de datos de Menéame, en el blog o en un tweet, surgen comentarios y tweets del tipo “Cambia a NoSQL”, o “Esa estructura es especial para NoSQL”. Están muy equivocados, no es una solución óptima pra todo, ni los NoSQL están optimizados para consultas a datos estructurados. Como me da pereza escribir un apunte largo para explicarlo (que se exige más cuidado y precisión que “hablar”), grabé un vídeo (en baja calidad, para no tardar tanto subiendo, pero lo importante es la voz, no el feo que sale en pantalla).
Nota 1: En el medio de la grabación se me ocurrió poner a Instagram como ejemplo de algo que puede hacerse con bases de datos relacionales. Aunque fallé por muy poco -“se puede implementar con MySQL-, luego lo busqué y usaron PostgreSQL (con Django, la misma combinación que usamos para SpokenPic).
Nota 2: En Menéame siempre usamos MySQL con replicación master-slave. Ahora estamos usando RDS Multi-AZ (con MySQL), lo que implica que tenemos también master-master con failover automático.
Galli, tienes errores de concepto en tus comentarios. No creo que tengas razón en tus afirmaciones. NoSQL no es un paso atrás, ni es un paso atrás, ni es un paso adelante.
Aunque el video está bien, es interesante escuchar gente hablando un poco sobre temas técnicos.
Gallir, una pregunta muy específica… Dices que es más rápido una única consulta sql con varios joins (por ej.) que varias consultas simples, aunque en tiempo de bbdd la suma de éstas sea más rápida, porque el tiempo de conexión entre la aplicación y la bbdd para cada una de las consultas simples es superior al del cálculo de la consulta compleja. Bien, aceptamos que es así, pero supongamos el caso en que puramente a nivel de base de datos las varias consultas simples se realizan en mucho menos tiempo, ¿no se podría implementar a veces una solución alterntiva usando una única conexión desde la aplicación? Usando por ejemplo “stored procedures”. Sólo hay una conexión y ahí la bbdd ya realiza las varias consultas simples en vez de una “pesada”. Entiendo también que si la base de datos está bien definida serán casos muuuuy anecdóticos donde la consulta pura sql no sea la más eficiente (aunque tenga muchos joins anidados…)
Buenas:
Google IO
@tronco En mi lenguaje corporal creo que dejo claro el “entrecomillado”. Los motores de NoSQL son muchos más sencillos y limitados en cuando a “operaciones algebraicas” y de consistencia que un SQL.
@jb No me gustan demasiado las “stored procedures”, estás llevando la lógica a la base de datos, y se suelen hacer aberraciones, como muchas que he visto con el PSQL en Oracle, que acaban haciendo muy difícil el mantenimiento, y además son mucho más lentas que poner esa lógica en C o Java.
Por otro lado, el renidmiento de las relacionales en consultas complejas no ha dejado de mejorar (grandes buffers en memoria, optimizadores, etc.). Aunque sí, es más complejo y necesita más esfuerzos y conocimientos, quizás por eso a la gente le gusta mucho el NoSQL, “parecen” más simples.
Mi única sugerencia…. utiliza un micro corbatero para mejorar la calidad de sonido, por lo demás muy interesante las explicaciones. Gracias!
No estoy muy puesto en sistemas NoSQL, pero creo que como todo en esta vida puede tener su nicho de utilidad. Otra cosa es que se pretenda desbancar todo el sistema relacional porque hemos ‘descubierto’ la panacea de algo más ‘sencillo’ y ‘rápido’. Digámoslo claro, a casi ningún programador le hace gracia vérselas de cerca con bases de datos a bajo nivel, ni con la complejidad que conlleva optimizarlas y mantenerlas. Otra cosa es que sabiendo utilizarlas, optimizarlas y mantenerlas vayan a ser peor solución que NoSQL para aquella finalidad para la que fueron pensadas. Y esto es muy improbable en la gran mayoría de los casos. Y para algunos de los casos que se piensa más efectivo un sistema NoSQL, muchas veces se puede solventar también con un sistema SQL, pero con bastante conocimiento y alguna argucia que otra. Esta batalla siempre me recuerda Hibernate y horrores parecidos, lo veo simplemente como una dejación de responsabilidad por parte del desarrollador.
Coincido bastante en lo que comentas en el video. En mi caso cuando he implementado algun NoSQL lo hice pensando en evitar lanzar querys pesadas varias veces, una caché.
Una de las ventajas de NoSQL es el clave-valor y siempre pensamos como clave a, b, id, nombre, que pasa si ponemos como clave “select id_comments from comments where id.. ” y valor el resultado de esta pesada query? Que luego haciendo una unica consulta por la clave, que en realidad es la query, tienes el resultado de manera “inmediata”. Eto no te evita que la primera vez, la carga la tienes, pero evitas tener que calcularla cada vez.
Esto mismo se podria hacer con SQL, pero la gestión de indices no es tan eficaz con indices tan especificos, el insert por ejemplo tardaria muchisimo más para mantener ordenado el btree, para su posterior consulta.
“@tronco En mi lenguaje corporal creo que dejo claro el “entrecomillado”. Los motores de NoSQL son muchos más sencillos y limitados en cuando a “operaciones algebraicas” y de consistencia que un SQL.”
Realmente lo que más me llama la atención es que la gente quiera decir que NoSQL no significa “No SQL” que significa cualquier otra cosa que se les pueda ocurrir.
En mi trabajo usamos una BBDD NoSQL del año de la catapúm: caché de Intersystems. Hace varios años decidieron proveer una capa SQL por encima por lo que puedo aportar algo a esto: en las aplicaciones que tenemos usando la capa “no sql” todas las relaciones entre entidades se han de controlar por programa, llegando a tener ramas o nodos prácticamente duplicados o totalmente inútiles. Hacer búsquedas por un campo es un horror de bucles por lo que al final acabas añadiendo otra rama con índices al revés. Ya sabéis el peligro que encierra que las relaciones las mantengamos a nivel de programa.
Sólo le veo ventajas al tema NoSQL si el modelo es muy sencillito, poco relacionado entre sus entidades, y aún así, la estructura que te provee una relacional acaba teniendo más lógica.