Motores de bases de datos y caché
Audiocurso de Fundamentos de Arquitectura de Alta Concurrencia
Contenido del curso
Escalabilidad
Herramientas
Seguridad
Protocolos
Negocios y casos de uso
Conclusiones
Motores de bases de datos y caché
Audiocurso de Fundamentos de Arquitectura de Alta Concurrencia
Contenido del curso
Motores de bases de datos y caché
Juan David Cajamarca Acuña
Estudiante
Alexis Dorado Muñoz
Estudiante
Leandro de la Paz Cabrera
Estudiante
Sergio Rivera
Estudiante
Jesus David Posada Escobar
Estudiante
Victor Hugo Vázquez Gómez
EstudianteAlexis Dorado Muñoz
EstudianteVictor Hugo Vázquez Gómez
Estudiante
Jair Israel Avilés Eusebio
Estudiante
Daniel Eduardo Rojas Pulido
Estudiante
Carlos Pinedo
Estudiante
JHENER LIRIO OVIEDO CHAHUA
Estudiante
MARIA TERESA PANIAGUA RIVERA
Estudiante
Nicolás Peralta Páez
Estudiante¿Qué motores de bases de datos son recomendables utilizar para este tipo de aplicaciones?
Podríamos dividir los motores de bases de datos en dos grandes grupos: bases de datos relacionales y bases de datos no relacionales.
El motor principal para las bases de datos relacionales es MySQL, y el motor principal para las bases de datos no relacionales es MongoDB.
La principal diferencia entre una base de datos en cada uno de los motores mencionados anteriormente, es que MongoDB es un gestor de bases de datos orientado a documentos, que por lo tanto tiene un enfoque totalmente diferente en cuanto al almacenamiento de datos. La diferencia fundamental es que mientras todas las filas de una tabla de una tabla MySQL tiene la misma estructura, en MongoDB los documentos no están sujetos a un orden fijo. Las filas de las tablas de MySQL tienen un mismo número de valores (cada uno con los mismos tipos de datos), por su parte, los documentos individuales de MongoDB tienen su propia estructura; de esta manera es posible crear nuevos campos con cualquier valor, mientras que para una base de datos relacional, se necesitaría una re-estructuración completa.
Otra diferencia fundamental que resulta de la comparativa de estos dos tipos de motores de bases de datos, es el enfoque dado a la recuperación de datos: como base de datos NoSQL, MongoDB no utiliza SQL como lenguaje de consulta, disponiendo de su propio lenguaje para el procesamiento de datos; esto permite la comunicación entre MongoDB y el respectivo cliente. Para este fin, la base de datos utiliza los métodos específicos del correspondiente lenguaje de programación del cliente, valiéndose de la ayuda de las librerías que pueden ser descargadas desde su página web oficial.
Al ser un motor de bases de datos no relacional, escalar MongoDB es mucho más fácil, ya que cada parte de datos está hospedada en un shard. Al tener estos shards, podríamos comenzar a crear y agregar más datos y más shards a medida que nuestra aplicación crece. Este no es el caso con un motor de bases de datos relacional.
Escalar un servidor de bases de datos relacional puede ser muy complejo. Posiblemente la única forma de escalar este tipo de servidores de bases de datos es agregando réplicas o escalando verticalmente. Hay algunas soluciones para escalar este tipo de servidores de bases de datos de manera horizontal, pero son complicada y dependen totalmente del equipo de infraestructura.
Una de las herramientas que se pueden utilizar para escalar horizontalmente un servidor de bases de datos relacional, es Vitess, que es una herramienta Open Source que viene de la mano de la CNCF (Cloud Native Computing Foundation), que es una de las aceleradoras que se encargan de fundar proyectos Open Source. Vitess es usado por YouTube para escalar sus servidores MySQL de manera horizontal.
¿Qué tipo de caché es recomendable utilizar?
Aquí, hay dos grandes grupos de caché. Generalmente se utilizan para almacenar sesiones, valores pequeños y sobre todo para la autenticación. Este tipo de caché generalmente es usado porque es muy rápido de acceder y las principales herramientas son Redis y Mencach. Estas herramientas están disponibles en la mayoría de los proveedores y es muy fácil de integrar con cualquier aplicación.
Otro tipo de caché es el caché de internet, como por ejemplo, para permitir que nuestra página web funcione más rápido o se descarguen los archivos estáticos de una manera más rápida para nuestros clientes, y la tecnología más usada son los CDNs (Content Delivery Network).
¡Gracias por tu aporte! 👏 Has explicado de forma clara y concisa las diferencias entre bases de datos relacionales y no relacionales. Además, has incluido información valiosa sobre la escalabilidad y las opciones de caché.
¡Un resumen muy completo! 🌟
La herramienta que menciona para escalar el MySQL horizontalmente es Vitess https://vitess.io/.
Alguna para MongoDB o SGBS No Sql
Genial!!
Los shards son bloques que dividen los documentos, bases de datos en un cluster de MongoDB. https://www.mongodb.com/docs/manual/core/sharded-cluster-shards/ !Shard en mongoDB
Motores de bases de datos para aplicaciones de alta concurrencia:
La elección del motor de base de datos es fundamental para el rendimiento y la escalabilidad. Veamos las opciones más populares:
1. Bases de datos relacionales (SQL):
2. Bases de datos no relacionales (NoSQL):
Diferencias clave:
¿Cuál elegir?
Tipos de caché:
😮 No sabia que el CDN es un tipo de cache. Muy buen dato
El concepto como tal de CDN es el de ser un grupo de servidores distribuidos geograficamente para reduir la latencia de peticion a contenido. Yo veria mas bien cache al software mencionado como Redis o Memchached.
Si conoces a profundidad la lógica de negocio del proyecto, hacer las relaciones en SQL será más fácil, en caso contrario es recomendable NoSQL
Memcached vs Redis
Motores de bases de datos • SQL MySQL (todas las tablas tienen la misma estructura, sujetos a un orden) Escalar es muy difícil, puede ser replicando o creciendo verticalmente Escalar horizontalmente (Vitess) • NO SQL Mongo DB (gestor de base de datos orientado a documentos, no están sujetos a un orden) Mongo DB no utiliza SQL como lenguaje de consulta Escalar es mucho más fácil
Gracias
Este profesor en 30 segundos me aclaro la diferencia entre db basadas en documentos y sql como en muchisimo tiempo no me habia quedado claro