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 🙂
Terminamos el año con el tema del año: el futuro de la creación de software con las herramientas de IA generativa. Empezamos el episodio hablando de un atrevido artículo de Paul Kinlan (Google Chrome) titulado Will we care about frameworks in the future? donde lanza interesantes preguntas como ¿importan los patrones de arquitectura que hemos … Sigue
Para este episodio del podcast Andros Fenollosa tiene la suerte de contar con Ellie Fairholm y Josep Giralt D’Lacoste, autores del libro recientemente publicado por la editorial The Pragmatic Programmers, titulado Engineering Elixir Applications. Ellie y Josep además de ser dos auténticos apasionados del lenguaje Elixir, están detrás de la consultora de software BeamOps, especializada … Sigue
En este episodio Andros Fenollosa introduce el protocolo Gemini, alternativa ligera y minimalista al protocolo HTTP. Gemini está diseñado para ofrecer una experiencia sencilla y enfocada principalmente en la lectura de contenido, sin las complejidades de la web moderna. Es una vuelta a los inicios de la web, muy condicionada al consumo de documentos y … Sigue
Para este nuevo episodio vuelve al podcast Camilo Chacón Sartori y lo hace para hablar junto a Andros Fenollosa sobre su próximo libro Palabras y algoritmos, Cómo la inteligencia artificial transformará la escritura. A través de un recorrido por los hitos que marcaron la evolución del lenguaje escrito, Camilo Chacón nos invita a reflexionar sobre el … 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