Desde hace ya sus muchos años las bases de datos relacionales han gobernado el mundo de los datos. Estas, como bien sabe y ha sufrido todo estudiante de ingeniería informática, normalización va normalización viene, se basan en el modelo relacional, aquel que el gran Codd creara en los 1970. Pero en los últimos años, una visión alternativa ha vuelto a ponerse de moda: las bases de datos NoSQL (no relacionales).
Digo que las bases de datos NoSQL han vuelto porque los antiguos del lugar recordarán que hace ya sus años había populares bases de datos no relacionales, como las del modelo CODASYL o las jerárquicas (mucho más antiguas que las ahora modernas MongoDB, CouchDB, BigTable, etc).
Y no puedo evitar poner aquí eleste comentario: parece que toda moda vuelve, siempre volvemos a poner de moda cosas de hace años con nuevos nombres, vuelven las bases de datos NoSQL, las no relacionales, vuelven los lenguajes funcionales, etc.
También aclarar en este punto que se utiliza, y yo también utilizaré, el término bases de datos NoSQL de manera poco rigurosa, cuando se dice bases de datos NoSQL realmente lo que se intenta decir es que son BBDD que no utilizan el modelo relacional (ojo, el modelo relacional, no que no usan el entidad-relación, como he leído por ahí, no mezclemos). Pero no hay que olvidar que SQL es sólo un lenguaje típicamente usado para tratar con el modelo relacional de las BBDD.
Los principales argumentos a favor de las bases de datos NoSQL, los argumentos anti modelo relacional
Supongo que no serán los únicos, y que en este tema, como en todo, no hay una única respuesta, pero el argumento que yo más escucho a favor de las bases de datos NoSQL, contra las bases de datos relacionales, es el siguiente: Los “join” de las bases de datos relacionales ralentizan el sistema. Aquí te dejo algunas referencias con este argumento: una de slashdot, un debate en stackoverflow, y alguna más.
Conviene decir que esto de ralentización aplicaría cuando millones de usuarios hacen búsquedas en tablas con millones de filas, como es el caso de Google o Amazon, que por ello desarrollaron sus propias bases de datos NoSQL.
Luego hay otras críticas, como la de la difícil correlación, los mapeos, del modelo relacional con estructuras de datos jerárquicas, como XML, o con diseños de clases complejos.
Los principales argumentos en contra de las bases de datos NoSQL
Para los defensores de las bases de datos relacionales, los SGBDs potentes, como Oracle, son lo suficientemente potentes para optimizar “joins” complejos. Y como prueba, los bancos realizan miles de consultas, con miles de usuarios, y sobreviven utilizando SQL.
Quien defiende el uso de bases de datos SQL, las relacionales de toda la vida, argumentan que “es raro es que vayas a necesitar bases de datos NoSQL, no vas a construir un Google”.
Luego hay otros argumentos, como que prácticamente toda estructura de datos (como las de los XML y demás) se puede mapear al sistema relacional. Hay quien se atreve a decir que el problema viene de no entender el SQL.
¿Qué opináis vosotros?
Por mi parte, supongo que como en todo, habrá veces que será mejor usar bases de datos NoSQL y en otras no. Eso sin quitar ese toque que últimamente tienen tantas cosas en ingeniería software y desarrollo de volver a poner de moda cosas que tienen ya sus años, como algo nuevo, pero con cambio de nombre.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Si bien es cierto que nunca he trabajado con NoSQL y por tanto no tengo una opinión forjada en la experiencia, sí que puedo comentar un poco opiniones de expertos sobre las que he leído. Concretamente, en uno de los cursos de Coursera en el que estoy «enrolado» (Introduction to Data Science, de Bill Howe) hay un tema completo sobre este asunto y lo que vienen a decir es que, efectivamente, la nueva tendencia viene a imitar un poco a la tecnología de los 80, rompiendo con todo el aparato relacional. La
característica diferenciadora en positivo de NoSQL frente a las BBDD tradicionales es su escalabilidad a miles de nodos (o más), y su idoneidad para la resolución de cierto tipo de problemas paralelizables. Por lo demás, irónicamente, estas BBDD empezaron siendo schemaless, sin permitir joins, etc. y poco a poco, lo que está ocurriendo es que se están añadiendo cada vez más estas características (de manera quecada vez se parecen más a BBDD relacionales tradicionales). Véase Spanner, la última de Google. Hay un hueco para cada tecnología en función de su aplicación, con lo que si se necesita analizar terabytes de datos en tiempo cuasi-real a costa de sacrificar un poco la salud de estos datos, NoSQL es tu amigo.Aprovecho para lanzar una pregunta relacionada sobre algo que no entiendo muy bien: en la organización donde trabajo vienen usando un sistema heredado Natural/Adabas desde hace años. En vez de aprovechar y migrarlo a un modelo relacional, se está invirtiendo dinero (en este caso público) para mantenerlo vivo (hasta el punto de seguir pagando por licencias de software de nuevas versiones). El argumento que se maneja a favor es la supuesta alta productividad que existe en el desarrollo de aplicaciones para esta tecnología… Personalmente tampoco he trabajado con ellas, pero no hay más que hacer una búsqueda en Google Trends para ver qué pasa con esto. ¿Es posible que una tecnología de lo 80 que ya casi nadie usa sea más productiva – en términos de desarrollo de aplicaciones en el siglo XXI – que una tecnología relacional + lenguaje 4gl + metodología ágil? Sólo para encontrar a gente formada en esto ya tiene que haber un sobrecoste…
Hola…. No pude dejar de comentar tu pregunta que me parece muy interesante
¿Es posible que una tecnología de lo 80 que ya casi nadie usa sea más productiva – en términos de desarrollo de aplicaciones en el siglo XXI – que una tecnología relacional + lenguaje 4gl + metodología ágil?
La respuesta es un contundente «SI» y «NO».
Porque te hizo falta el elemento principal, «Las personas». Las herramientas son herramientas y será el Nivel Técnico, el Nivel de Análisis del Entorno, La Psicología aplicada al equipo de trabajo la que hará la diferencia.
A estas cualidades se les daba mayor importancia en los 80’s porque las inversiones eran mayores y se debía de apostar a ganar, adicionalmente había pocos proyectos la mayoría de gobiernos.
Hoy en día la inversión por cada institución es mucho menor, que da margenes para pruebas y errores, pero tambien son muchas instituciones por ende muchos proyectos, la calidad del equipo se ha descuidado y eso nos da factores que a veces asustan.
Un buen equipo técnico siempre hará la diferencia.
Saludos.
Perdona, Javier, en el comentario anterior he puesto
donde quería decir . Es lunes y he vuelto de vacaciones 🙂Pingback: Bitacoras.com
Yo, por mi parte, he de decir, que siempre he utilizado bases de datos relacionales y cuando me han dejado y he hecho un modelo bien normalizado y una aplicación bien diseñada utilizando algún ORM no he tenido ningún problema de rendimiento y eso que he manejado volúmenes grandes de datos.
Entiendo perfectamente el problema de Google y de Amazon, pero todos los proyectos en los que he estado no tienen esas dimensiones y sin embargo te encuentras a «lumbreras» que te dicen que «su problema o sus datos» no se pueden manejar en una base de datos relacional. Sin ir más lejos ahora mismo estoy en un proyecto en el que justifican descartar el modelo relacional porque tienen bases de datos «muy grandes», que al final resulta, que no llegan ni a las decenas de Gigas cuando una base de datos relacional bien configurada puede manejar sistemas altamente transaccionales hasta volúmenes de Teras. Lo más curioso del caso es que su «magnifica» solución consiste en tener una sola «entidad» con un atributo llamado «atributos» que es una lista de objeto primitivos y otro atributo llamado «relaciones» que es una lista de «ids» (Strings, por supuestísimo) que apunta a otras entradas en la misma tabla. Al final se está implementando una base de datos relacional con una integridad referencial en la propia aplicación. Y ésto, no es la primera vez que me lo encuentro.
Básicamente, estos «abogados» de la bases de datos NoSQL que tanto abundan terminan implementando ellos mismo una gestor de bases de datos relacionales en su código, con lo cual no entiendo sus críticas.
Por supuesto no me entendáis mal, no creo que las bases de datos SQL o relacionales sean la solución a todos los problemas, pero en ésto cómo en todo, hay que ser serios y reconocer que la mayoría de nosotros nos enfrentamos a problemas más sencillos que los señores de Google, por muy grandes y especiales que nos parezcan.
Hola,
Me suena mucho lo que cuentas, y creo que lo malo es cuando se implementa cada uno su gestor, porque creo que difícilmente será tan bueno como el relacional.
SAludos
Hola a todos, muy interesante el tema.
Continuando el hilo mi opinión es que si ocurre esto es que al final han pensado el problema de forma relacional clásica y usan una herramienta no adecuada para el entorno del problema. Hay casos donde este problema es más raro, como es el ejemplo que ponen más abajo del GIS. No soy un conocedor en profundidad de las tecnologías NoSQL, pero me las han usado en varias ocasiones, y entiendo el contexto lo suficiente, y mi experiencia con gente que usa motores NoSQL es que, en general (ojo, simplificación!!!), no saben explotarlos, y los motores les ofrecen posibilidades que no se usan y viceversa, se les piden cosas que no están diseñados para proporcionar. Es como el que simplifica y piensa en la OOP como estructuras más funciones. Y coincido en que emular uno con otro (o viceversa) solo es fuente de problemas. Por último, el argumento de Google para justificarlas es de una simplificación absurda. O es que Google solo usa BBDD NoSQL? y nada más que eso con independencia del contexto? No creo… Y al revés, aunque no maneje terabytes de datos, eso no quiere decir que una BBDD NoSQL no aplique a mi contexto.
Saludos!
Esto mismo me lo he encontrado en algún proyecto. Es decir, pones un sistema noSQL para luego intentar emular la funcionalidad de una base relacional ?? wtf?!?
Grande como siempre Javier…. Muy interesante.
En lo particular considero que nuevamente es un conjunto de Grises… de todas las tonalidades……
Si bien es cierto, en la mayoría de casos una BD relacional nos resuelve, tampoco podemos negar que un modelo no ralacional a veces es mas efectivo.
Los DataWarehouse son un ejemplo de ello, diseñamos esquemas para mantener una normalización que resulta en una desnormalización (jajaja no estoy seguro de la palabra, amigos de la madre patria me dicen si es correcta)
Pero tampoco termina ahí, la tendencia es que estamos y vamos hacia una globalización de la información, queremos gobiernos conectados, gente informada…. en este camino vamos hacia oData y similares, es correcto que muchas bases relacionales alimentarán a estas grandes dimensiones de datos, pero hacia ahí vamos.
Por eso los grises, a cada uno, en su propia instalación tendrá que evaluar que necesita de acuerdo a la información que utilizará, bien datos relacionales o No Relacionales. Cada una tendrá su ambiente.
Mi humilde opinion por lo que observo….
Saludos
Milton Rafael Beltrant
MBS
El Salvador
Yo creo que como todo en informática cada cosa tiene su momento, no hay una tecnología mejor o peor ya que depende de para que se vaya a usar.
Para un sistema de facturación en el que la consistencia de los datos es fundamental y no puedes permitirte el lujo de no mantener la integridad de los datos es necesario una bbdd relacional. Ahora bien si lo que quieres es una base de datos que use APIs Rest para traer datos mediante JSON (XML) que tienen estructuras distintas según algún parametro yo usaria una noSQL ya que me parece que es mucho mas flexible a tus necesidades.
Vaya al igual que no todos los proyectos tienen que hacerse en Java, no todos los proyectos tienen que tener bbdd noSQL
Muy de acuerdo con el post, sobre todo en lo referente a la aplicación de tecnologías basada en «modas» y el hecho de reimplementar un modelo relacional.
Un buen artículo, donde se explica la posible aplicación de un gestor de base de datos noSQL:
http://queue.acm.org/detail.cfm?id=1394128
Básicamente se dice que si te puedes conformar con consistencia relajada, por ejemplo en un sistema dirigido por eventos, una base de datos de este tipo puede ser una buena solución.
Donde he visto este tipo de bases de datos es para almacenar información geográfica, donde la principal utilidad está en hacer consultas basadas en distancias, intersecciones, superposiciones, etc., de los elementos.
Es típico de aplicaciones GIS, de localización o seguimiento de vehículos, sistemas catastrales, etc.
En mi caso, el almacenamiento era disjunto: los datos geográficos en su sitio (la base de datos la proporciona su proveedor), y los datos relacionales, aparte.
Saludos
Hay un buen articulo aquí
http://basesdedatosnosql.blogspot.com/
Saludos