Diseño de Arquitectura de Sistemas Distribuidos
Contenido del curso
Carlos Eduardo Gomez García
Junior Usca Huacasi
Carlos Eduardo Gomez García
Gilberto Pérez Garrido
VICTOR M. RUBIO C
Stiven Alejandro Manosalvas Jaime
Gilberto Pérez Garrido
Usuario anónimo
User
Carlos Fernando Aguilar González
Jesus
Stiven Alejandro Manosalvas Jaime
Marco Elizalde
Aaron Contreras Garibay
RUBÉN HERNÁNDEZ PUERTA
Cristian Daniel Gutierrez
Carlos Eduardo Gomez García
Maslov Viloria
Reinaldo Mendoza
Sergio Alexander Arellano Diaz
Irving Juárez
Luis Márquez
Rene Andres Palta
Daniel Echeverri
Julian David Alzate Cuervo
Reinaldo Mendoza
Aquí se empieza a ver lo que es un sistema distribuido, podemos ver como todo es agnóstico a todo y se unen por comunicación. Cuando hablamos de lectura (POST) recordamos que solo son 10 usuarios que van a estar escribiendo, es por eso que no hacemos tanto énfasis en ello, incluso una base de datos NoSQL puede bastar, ya que realmente se va a estar leyendo muy poco. . En cambio para la lectura, son mils de usuarios, así que ahí necesitamos tener poder de procesamiento, además de que tenemos que entregar respuesta de manera inmediata. Las bases de datos SQL suelen ser mejor para lectura, ya que con ellas podemos realizar querys complejas y obtener el resultado que deseamos (cosa que no podríamos con una NoSQL, a no ser que suframos) . De hecho, incluso podríamos tener una tercera base de datos que almacene esos datos que no se está usando y esa base de datos puede ser usada para Machine Learning y Business Intelligence. . Recomiendo el curso de Fundamentos de Bases de Datos para profundizar en para qué es bueno cierto tipo de bases de datos.
En este caso, no entiendo que justifica el uso de una base de datos relaciónale SQL, ya que con la base de datos NoSQL ya podemos almacenar, ordenar e indexar las reviews de la forma que más necesitemos. Quiero decir, las queries según los casos de uso no son complejas, xq usar SQL??
Desde este punto de vista donde usamos queries no tan complejas, una base de datos NOSQL podría bastar, pero pensamos en escalabilidad, recuerda que el sistema debe poder ser escalable así que es bueno pensar a futuro, y para lectura una base de datos relacional es una maravilla
Este curso debería estar en las rutas de desarrollo backend que hay en Platzi, lo encontré por casualidad
Debería ser uno de los primeros, así se va con conocimientos de como ir creando/modelando el proyecto.
Excelente clase! Lo resumo así:
Buen resumen sería ¿Todo?
Otra herramienta muy popular para diagramación es: Lucidchart
Team, me ayudan a entender como o en que momento se dispara el servicio 3 ?, me imagino algo como un job que dispare ese servicio o que el servicio de escritura dispare un webhooks asi desencadenar el servicio 3, tambien esta por eventos, pero quisiera saber si estoy por el buen camino de comprension
A mi entender si sería una tarea programada que se ejecuta una vez al día, seguramente con una expresión cron para dispararse automáticamente
Por ejemplo en AWS se programar la ejecución de una función Lambda utilizando los eventos de CloudWatch Tutorial: Schedule AWS Lambda Functions Using CloudWatch Events
Aquí mi diagrama, que mejorarían / cambiarían?
Ya se pueden observar desde el diseño las ventajas que ofrece un sistema distribuido, ya que los servicios están incluso en diferentes regiones el hecho de que nuestro servicio para subir reviews se caiga no afecta en los más mínimo a nuestros usuarios que leen las reviews.
Tengo una duda y es con el servicio 3, en que momento es optimo pasar lo que se inserto en la db no relacional, a la db relacional,de igual forma porque es mejor dejarlo con esa estructura que indica en el video y simplemente dejar una db de escritura y lectura y hacer un espejo en otro servidor para que cuando se caiga no afecte las operaciones, y asi podernos ahorrar el servicio 3 de estructurarla y despues insertarla.
¡Hola! En ningún momento decimos que "es mejor" la estructura que se propone en el video, recuerda que es un curso práctico y entre todos nos hacemos reviews.
Algo que se recalca MUCHO en este curso es: "siempre pregunta a otros qué les parece la estructura que propones", siempre surgirán nuevas ideas y se llegará a una mejor planeación backend.
El profesor da su punto de vista y así es como el considera que mejor funcionaría el sistema, pero la pregunta que haces es muy asertada porque estás proponiendo otra solución, estás proponiendo una idea que podría ser mejor para el sistema y es totalmente válida, recuerda que siempre que hagamos algo debemos preguntarnos "¿por qué?", "¿por qué esto es así?", "¿por qué quiero usar este servicio?", "¿por qué esta estructura me conviene más que la otra?", "¿por qué hacerlo de esta manera y no hacerlo de esta otra?"
Ahora, respondiendo tu pregunta, como te menciono, es solo una propuesta, desde mi punto de vista (y por el conocimiento que tengo en bases de datos), las bases de datos no relacionales suelen ser más rápidas en cuanto inserción se refiere, y las bases de datos relacionales (SQL) son las mejores para hacer búsquedas, además algunas como MySQL tienen motores optimizados para lectura de datos (sacrificando velocidad de escritura), cosa en la que las bases de datos no relacionales no son tan buenas, es más fácil usar SQL para búsqueda de datos (y si metemos índices entonces la velocidad lectura aumenta, pero los índices no se llevan muy bien con la escritura).
Esa es una posible justificación para el sistema que propone el profesor, recuerda que el objetivo es ser rápidos con la lectura de datos, y una base de datos que pueda procesar la lectura de una manera rápida nos ayuda mucho.
Si dejamos una única base de datos que sea de lectura y escritura estamos sacrificando velocidad de lectura para meter escritura también.
Yo más adelante propongo un modelo donde la data vieja se guarda en una tercera base de datos para no sobrecargar las bases de datos de lectura y hacerla más eficiente.
El momento para sincronizar ambas bases de datos depende de cuando tu quieras, yo en lo personal las sincronizaría a las 00:00 horas de cada día 🤔
Repito, hay muchas formas de estructurar los sistemas backend, no hay una forma mejor que otra, en todas las estructuras siempre se sacrificará algo (trade off), lo más importante es siempre preguntarte "¿por qué?", y pedir feedback, pedir un design review para tu design doument ^^
Tomar en cuenta el soporte de Postgresql en su versión XL que corre en clusters, el cual soporta procesamiento masivo en paralelo, datos no estructurados usando key-value de datos tipo JSON ideal para sustituir NoSQL en este diseño propuesto
No lo conocia, gracias por el aporte
Viendo el ejemplo, me viene en mente il patron CQRS, pero es al contrario. Quando subes los datos(Post) va a un RDBMS e cuando haces la lectura, la haces da un NOSQL.
Otro requerimiento podria ser, que tan en real-time se necesita la información?
Yo no creo que el cliente quiera esperar una vez al dia para que las bds de lectura se actualicen. Yo creo que en este caso pudiera haber otra función serverless con un trigger a un insert en la base de datos de escritura
Que tenga una BBDD NoSQL que inyecta su información cada 24hrs a una BBDD relacional significa que si un editor pública una review esta estará disponible a los usuarios lectores hasta 24hrs despues de su publicación cierto?
curso desactualizado
Yo prefiero Draw.io para hacer diagramas.
Este curso debería estar en la ruta backend
jaja, tiro la chapa ahora si, saco el faang
