No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Qué métricas usar para escalar

6/17
Recursos

Aportes 6

Preguntas 1

Ordenar por:

Los aportes, preguntas y respuestas son vitales para aprender en comunidad. Regístrate o inicia sesión para participar.

Sino estas decidido si usar SQL o NoSQL, preguntate que operacion realizara mas tu app:

 

  • Si sera mas de lectura deberias usar NoSQL, por ejemplo twitter donde hay millones de usuarios leyendo tweets que usuarios escribiondolos
  • De lo contrario deberias usar SQL

 

con base a mi experiencia SQL es mas facil de mantener y de verdad es rara la vez que necesitas NoSQL, son pocos las empresas con una demanda de lectura que lo requiera asi, quizas aplicaciones de IoT donde el tiempo de respuesta es importantge

 

Una señal muy importante para usar una BD NoSQL es si notas que estas haciendo desnormalización en tus esquemas relacionales para ganar velocidad (ya que evitaras usar Joins en tus queries, por ende seran mas veloces), entonces es probable que sea hora de usar NoSQL

cuando pablo habla acerca de los indices, que deben ser usados bien es porque con ellos ganamos rendimiento a la hora de lecctura en las tablas, pero el costo es que estas agregando complejidad a la hora de la escritura

ya que los indices literal son estructuras de datos que nos ayudan a la busqueda rapida, cuando esa estrucutura se tiene que atualizar (por cada registro agregado) entonces le costara mucho trabajo modificar dicha estructura.

 

Usa los indices sabiamente

En el curso de bases de datos de aws hablan sobre las estrategias para aumentar el performance, tal como dice Pablo el uso de replicas de lectura.
Acá les dejo la clase https://platzi.com/clases/1426-db-aws/15232-estrategias-de-performance-en-rds/

Cuando estamos escalando una aplicación, también tenemos que escalar datos. ¿Qué tipo de escalado deberíamos hacer en el motor de bases de datos?

Escalar en bases de datos siempre ha sido un problema, no es algo fácil y no es un problema fácil de resolver; es un problema relacionado con el equipo de SRE y SysAdmins.

Algo que debemos tener muy presente, y por lo que se tiene que preocupar el equipo de desarrollo es por usar correctamente los índices.

Una buena opción para escalar sistemas de bases de datos es utilizar réplicas de lectura. Es básicamente la creación de distintos servidores en donde, algunos se encargan de lecturas y escrituras, y otros se encargan solamente de las lecturas. Esta es una buena implementación en la mayoría de los casos, puesto que por lo general las aplicaciones suelen realizar más lecturas que escrituras en los sistemas de bases de datos. Siendo así, al multiplicar los servidores, se distribuye mucho mejor la carga.

  • Generalmente y de una manera manual, los desarrolladores pueden realizar las operaciones de lecturas a una réplica de lectura y las operaciones de escrituras a un servidor de escritura.
  • De manera automática, se puede interponer un proxy que nos ayudará a distribuir las operaciones de lectura y escritura de una manera inteligente; sin embargo, es una buena práctica la implementación manual de esta estrategia.

Con respecto a los sistemas de bases de datos NoSQL, lo más común es hacer sharding, que es básicamente separar varias partes de la bases de datos en varios servidores. De esta manera, podemos tener colecciones que no interactúan tanto con las otras separadas en distintos servidores. Así podríamos escalar horizontalmente nuestros servidores de bases de datos.

Escaladores automáticos

Esto generalmente está más relacionado con el orquestador. El orquestador es quien se encarga de manejar los servidores en donde está corriendo nuestra aplicación, y estos servidores comúnmente son contenedores que pueden estar corriendo en muchos servidores. Este orquestador se va a encargar de decidir cuándo nuestra aplicación tiene que escalar horizontal o verticalmente; pero somos nosotros quienes definimos cuándo se debe escalar.

Nuestra aplicación puede escalar de diferentes formas. Lo más común es escalar usando CPU o memoria como una métrica, y el orquestador conoce el comportamiento de estos recursos debido a que cuenta con un sistema integrado de monitoreo. Sin embargo, muchas veces desearemos escalar basándonos en otras métricas (pueden ser métricas de aplicación: cantidad de peticiones que llegan a nuestro servicio, cantidad de datos procesados, etc.). Otro ejemplo para esto puede ser una cola de mensajes; últimamente se maneja mucho la comunicación asíncrona entres servicios: un servicio recibe una petición, y en lugar de hacer otra petición a otro servicio que puede estar ocupado, la petición es almacenada en una cola de mensajes. De esta forma podemos escalar independientemente: puede que el servicio que recibe las peticiones no necesite tantos recursos, entonces podríamos utilizar la cola de mensajes para escalar el servicio que va a procesar estos mensajes.

Estos son varios ejemplos que podemos utilizar para escalar nuestra aplicación.

Buenas recomendaciones, casi siempre es por capacidad de los recurso-.

Les recomiendo ProxySQL