Se escucha mucho últimamente que SQL pasó de moda, que hoy lo cool es usar NoSQL (MongoDB, CouchDB, etc…) pero… ¿es siempre así?
Empecemos por entender qué es una base de datos NoSQL (formalmente no estoy muy convencido de que un almacenamiento que no respete las reglas ACID pueda llamarse base de datos, pero bueno… como para no entrar en más de una discusión a la vez, digamos que sí).
De lo que estamos hablando es de un medio de almacenamiento no estructurado, comúnmente conocido como base de datos documental.
Más allá de las formalidades (los registros de la base de datos relacional se llaman documentos en una base NoSQL, las tablas pasan a ser colecciones, etc..), existen diferencias muy concretas:
- Los documentos no tienen estructura (Pueden guardar literalmente cualquier cosa)
- No existen operaciones tipo JOIN
Su razón de ser se encuentra en la premisa de que, en un ambiente como es la web, la cantidad de escrituras vs. lecturas es prácticamente despreciable, con lo cual, si se busca darle a un sitio la mejor performance posible, no tiene sentido optimizar el almacenamiento en función de la operación menos frecuente (como sería el caso de usar una base de datos relacional).
Si bien esto es cierto, es muchas veces un arma de doble filo. Muchos desarrolladores poco experimentados (o seducidos por el último shinny object) olvidan hacerse la pregunta clave: ¿la premisa es válida en mi contexto?.
En aplicaciones web que reciben una cantidad enorme de visitas de usuarios no registrados (Un diario, Wikipedia, etc…) es claro que la respuesta es un sí rotundo. Sin embargo, cuando se trata de aplicaciones transaccionales (Un home banking, un sistema de adminstración, etc…), lo contrario es lo que sucede.
En estos casos la consistencia eventual que prometen las bases NoSQL no es un aliado si no más bien una carga pesada (Sí, me tocó trabajar con más de un sistema transaccional soportado por una NoSQL… no se lo deseo a nadie).
Y si bien las operaciones JOIN son costosas, el no usar una base relacional no las vuelve innecesarias, es el objetivo de la aplicación el que determina si vamos a requerir cruzar tablas o no.
Otra ventaja con la que se vende NoSQL es que, al no tener estructura, se puede desarrollar más rápido (No hay que perder tiempo en complejos diseños de estructuras de datos, migraciones y demás)… Mi opinión es que esto constituye un boomerang (Pero bueno, puede que ya esté poniéndome viejo…), ya que, por más que la base de datos no tenga siempre los mismos campos, la aplicación seguramente se beneficie de tener una estructura conocida (No habrá que andar llenando de if para ver qué tiene el objeto que estás queriendo manipular).
En mi experiencia, lo mejor es, en los escenarios que lo ameriten, usar un mix de ambas, para tener lo mejor de los dos mundos: una base de datos relacional para el almacenamiento duro y alguna caché tipo clave-valor (Memcached por ejemplo) para acceso rápido a los objetos más comúnmente consultados.
Los frameworks modernos ya vienen preparados para manejar la complejidad de invalidar los cachés en los momentos de escritura y aprovecharlos en los momentos de lectura, con lo cual… ¿para qué pelear? Todo en su justa medida y armoniosamente ayuda.
- Cómo agregar una página de error 500 en un proyecto PHP - 31/10/2024
- ¿Cuántos contenedoresnecesita tu php? - 28/10/2024
- Cuál es el mejor framework PHP para hacer APIs REST - 25/10/2024
1 comentario