Estamos de vuelta con el estudio de David Vaquero sobre el uso de tecnologías web y esta vez tratamos las bases de datos. En su propio estudio David analiza el uso de tecnologías de bases de datos sobre el millón de sitios web proporcionado por Alexa, tomando además dominios españoles. Este trabajo nos sirve para comentar los resultados y explicar las diferencias entre las bases de datos relacionales como MySQL, Percona, MariaDB o PostgreSQL y las basadas en las llamadas noSQL, con MongoDB como principal protagonista y claramente orientadas a soluciones distribuidas y escalables.
En el episodio David explica con detalle las diferencias conceptuales de este tipo de base de datos y los usos a los que va dirigidos. Es una explicación muy útil para tener una idea global sobre estas tecnologías y lo crítico que puede resultar para el rendimiento y la escalabilidad de nuestros proyectos.
Tradicionalmente las bases de datos se han visto como una caja negra, con una abstracción muy elevada para evitar preocuparse en los detalles de acceso y manipulación de los datos. Esta abstracción libera a los profesionales de las complejidades del software, aunque la exigencia y naturaleza de ciertas aplicaciones requieren tener un control más exhaustivo de cómo funcionan, destacando la importancia de contar con profesionales que optimicen los sistemas.
3 respuestas a “Estudio sobre uso de bases de datos relacionales y NoSQL”
Hola!
Lo primero muchas gracias por el programa, no me pierdo ninguno, o no planeo hacerlo. Con esto de la cuarentena voy retrasado, acabo de escuchar este :).
Muy buena la explicación de David sobre las diferencias entre SQL y NoSQL se nota que se dedica a esto, vaya piquito. Aunque debo decir que estoy bastante en desacuerdo con su afirmación de que toda startup debe empezar con Mongo (o cualquier otra NoSQL, entiendo) para no ponerse palos en las ruedas. Pese a que toda su argumentación es cierta, todos los beneficios de una base de datos no relacional vienen subditados al modelado de los datos, para mi la mayor diferencia entre ambos tipos:
– SQL, construyes tu modelo de datos para que sea consistente basado en entidades, luego aplicas queries en función de las necesidades del negocio.
– NoSQL, conoces las necesidades del negocio y construyes tu modelo de datos basado en sus requisitos para optimizar las queries, idealmente una por acción.
IMO, meter una NoSQL en un entorno donde los requisitos son tan cambiantes como una startup puede ser un suicidio (lo digo por experiencia, maldita ElasticSearch). En mi opinión, lo mejor es poder usar los dos modelos para aprovechar las virtudes de ambos en donde aplique, como bien habéis dicho.
Perdón por contaros mi vida pero si no lo decía reviento. Un saludo.
Hola Rober! Muchas gracias por contarnos tu experiencia y por tu punto de vista. Está claro que hay que valorar bien el tipo de proyecto y tampoco dejarse llevar por soluciones más «cool». Las bases de datos relacionales siguen demostrando un gran rendimiento y a fin de cuentas no todos los proyectos serán el próximo Uber. Muchas gracias por escucharnos y por tu apoyo cafetero. Un abrazo.
Buenas Rober.
En mi caso lo de «domar al caballo» es como llamo yo a ponerle límites a las BBDD NoSQL. MArcar esos llímites para que las cosas no se vayan de madre. Si usal cualquier tipo de ORM, te lo permite hacer de una manera muy sencilla 🙂
Proyectos y negocios a menudo se suelen presentar como surgidos de un punto clave o una idea original. La realidad parece más compleja y según el Principio de Ana Karenina, todo apunta a que la viabilidad de un proyecto está fundamentada en que todos factores clave deben estar alineados y funcionar adecuadamente. Si uno de … Sigue
Nuevo episodio con Andros Fenollosa para hablar de su experiencia implementando Arquitectura Limpia con Python. Recientemente Andros escribió un artículo con este título donde explicaba los conceptos esenciales para comprender la Arquitectura Limpia (Clean Architecture) con Python. Este artículo viene motivado por una necesidad que tuvo el equipo de la empresa de Andros para introducir … Sigue
Episodio del podcast dedicado a comentar el artículo de Christopher Mims en el Wall Street Journal titulado «What I Got Wrong in a Decade of Predicting the Future of Tech«. Se trata de un artículo muy honesto (y sin paywall) donde este columnista tecnológico habla sobre lo que ha aprendido tras una década escribiendo sobre … Sigue
El pasado jueves 9 de mayo se celebró el Simposio Internacional de creación de sitios web realmente buenos con Eleventy. Se trató de un encuentro virtual de diferentes presentaciones alrededor del proyecto Eleventy, creado por Zach Leatherman. Eleventy es un potente generador de sitios web estáticos basado en JavaScript y que tiene un enfoque incremental … Sigue
Hola!
Lo primero muchas gracias por el programa, no me pierdo ninguno, o no planeo hacerlo. Con esto de la cuarentena voy retrasado, acabo de escuchar este :).
Muy buena la explicación de David sobre las diferencias entre SQL y NoSQL se nota que se dedica a esto, vaya piquito. Aunque debo decir que estoy bastante en desacuerdo con su afirmación de que toda startup debe empezar con Mongo (o cualquier otra NoSQL, entiendo) para no ponerse palos en las ruedas. Pese a que toda su argumentación es cierta, todos los beneficios de una base de datos no relacional vienen subditados al modelado de los datos, para mi la mayor diferencia entre ambos tipos:
– SQL, construyes tu modelo de datos para que sea consistente basado en entidades, luego aplicas queries en función de las necesidades del negocio.
– NoSQL, conoces las necesidades del negocio y construyes tu modelo de datos basado en sus requisitos para optimizar las queries, idealmente una por acción.
IMO, meter una NoSQL en un entorno donde los requisitos son tan cambiantes como una startup puede ser un suicidio (lo digo por experiencia, maldita ElasticSearch). En mi opinión, lo mejor es poder usar los dos modelos para aprovechar las virtudes de ambos en donde aplique, como bien habéis dicho.
Perdón por contaros mi vida pero si no lo decía reviento. Un saludo.
Hola Rober! Muchas gracias por contarnos tu experiencia y por tu punto de vista. Está claro que hay que valorar bien el tipo de proyecto y tampoco dejarse llevar por soluciones más «cool». Las bases de datos relacionales siguen demostrando un gran rendimiento y a fin de cuentas no todos los proyectos serán el próximo Uber. Muchas gracias por escucharnos y por tu apoyo cafetero. Un abrazo.
Buenas Rober.
En mi caso lo de «domar al caballo» es como llamo yo a ponerle límites a las BBDD NoSQL. MArcar esos llímites para que las cosas no se vayan de madre. Si usal cualquier tipo de ORM, te lo permite hacer de una manera muy sencilla 🙂
Un saludo
David