Diseño de sistemas - diseño de arquitectura de alto nivel (para mayor escalabilidad, fiabilidad y consistencia) | Tanmay Varshney | Skillshare

Velocidad de reproducción


1.0x


  • 0.5x
  • 0.75x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 1.75x
  • 2x

Diseño de sistemas - diseño de arquitectura de alto nivel (para mayor escalabilidad, fiabilidad y consistencia)

teacher avatar Tanmay Varshney, Software Developer, Tech Educator

Ve esta clase y miles más

Obtenga acceso ilimitado a todas las clases
Clases enseñadas por líderes de la industria y profesionales activos
Los temas incluyen ilustración, diseño, fotografía y más

Ve esta clase y miles más

Obtenga acceso ilimitado a todas las clases
Clases enseñadas por líderes de la industria y profesionales activos
Los temas incluyen ilustración, diseño, fotografía y más

Lecciones en esta clase

    • 1.

      Diseño del sistema

      2:16

    • 2.

      Fundamentos

      4:35

    • 3.

      Balancers de carga

      7:17

    • 4.

      Almacenamiento en caché

      5:44

    • 5.

      Políticas de desalojo en caché

      5:40

    • 6.

      Tipos de caché

      5:41

    • 7.

      Particionado de datos

      15:08

    • 8.

      Redundancia de datos

      7:00

    • 9.

      SQL Vs NoSQL

      10:50

    • 10.

      Teorema de la PAC

      9:20

    • 11.

      Hashing consistente

      12:11

    • 12.

      cola de mensajes

      6:42

    • 13.

      CDN

      6:08

  • --
  • Nivel principiante
  • Nivel intermedio
  • Nivel avanzado
  • Todos los niveles

Generado por la comunidad

El nivel se determina según la opinión de la mayoría de los estudiantes que han dejado reseñas en esta clase. La recomendación del profesor o de la profesora se muestra hasta que se recopilen al menos 5 reseñas de estudiantes.

543

Estudiantes

1

Proyectos

Acerca de esta clase

El diseño de sistemas es el proceso de diseñar la arquitectura, los componentes y las interfaces para un sistema para que cumpla con los requisitos de los usuarios finales.

Diseñar sistemas a gran escala es cada vez más crucial. No importa si eres ingeniero de software de nivel básico o eres gerente técnico en tu lugar de trabajo, deberías estar al tanto de estos conceptos. Cómo escalar un sistema, hacerlo más confiable y disponible, y cómo mantenerlo mantenido definitivamente te dará una ventaja sobre otros.

Este curso tiene como objetivo ayudarte a aprender a diseñar sistemas a gran escala y prepararte para entrevistas de diseño de sistemas. Te presentarán los temas que debes considerar antes de empezar a trabajar en tu proyecto para que puedas construir una base sólida.

Vamos a aprender.

Conoce a tu profesor(a)

Teacher Profile Image

Tanmay Varshney

Software Developer, Tech Educator

Profesor(a)

I am a Senior Software Engineer with vast experience of working in top tech giant companies.
I have more than 6 years of industry and teaching experience in domains like:

1. Designing scalable architecture for complex and distributed systems.

2. Developing components in a system across the full stack.

3. Solving complex data structures and algorithms related problems.

These are the major skills needed to be a good software developer who can excel in any tech company easily. I am really passionate about sharing my knowledge and expertise with you.

Thus, I am on board to create awesome technical courses on Skillshare based on my expertise which can be understood in the simplest manner.

Come, join me in this learning adventure!! I will... Ver perfil completo

Habilidades relacionadas

Diseño Más de diseño Arquitectura
Level: All Levels

Valoración de la clase

¿Se cumplieron las expectativas?
    ¡Superadas!
  • 0%
  • 0%
  • Un poco
  • 0%
  • No realmente
  • 0%

¿Por qué unirse a Skillshare?

Mira las galardonadas Skillshare Originals

Cada clase tiene lecciones cortas y proyectos prácticos

Tu membresía apoya a los profesores de Skillshare

Aprende desde cualquier lugar

Ve clases sobre la marcha con la aplicación de Skillshare. Progresa en línea o descarga las clases para verlas en el avión, el metro o donde sea que aprendas mejor.

Transcripciones

1. Diseño del sistema: Durante los conceptos básicos de diseño del sistema. ¿ Sabes que la cantidad promedio de videos vistos en Netflix, pero a vk es aproximadamente alrededor de mil millones de horas. El número de tuits publicados birdie rondan los 500 millones. Eso son alrededor de 6 mil. Los griegos comen pollo y etiquetas, solo el número de tuits publicados. Ni siquiera estamos hablando de los retiros bajo saludos les gustó. Corrió estos números. Fascinante. ¿Eso no te hace preguntarte, cómo es posible incluso para empresas con un montón de ingenieros que manejan volúmenes tan enormes de tráfico. En tanto que el usuario casual, como desconocedor de la complejidad. Como diseñador de sistemas, debes enfrentarlo Manejo. Tendrás que estar al tanto de la arquitectura de alto nivel de la aplicación sobre la que se construyen estos productos. Todos tienen una base muy sólida y vamos a codificar. Es muy importante para estas empresas estarían funcionales todo el tiempo. En el mundo actual, es difícil imaginar incluso un solo minuto al día sin estos servicios. ¿ Qué hace que estas herramientas estén disponibles para nosotros? ¿24 por siete? La respuesta es la evasión. Estos sistemas están diseñados. Y eso se está convirtiendo más en una habilidad. Entender cómo mantener sus sistemas funcionales todo el tiempo. Ahora se considera una habilidad primaria de tener. Cuando te estás preparando para una entrevista, estás tratando de construir un sistema para tu organización o para tu propio producto. Y aprender a diseñar sistemas escalables te ayudará a convertirte en un mejor ingeniero. El objetivo de este curso es ayudarte a aprender a diseñar sistemas a gran escala y prepararte para financiar las entrevistas de diseño de sistemas, te introducirán los temas que debes considerar diseñando tus sistemas. Entonces, empecemos. 2. Fundamentos: Oigan chicos. En este video, vamos a hablar de los conceptos básicos del diseño de sistemas. En primer lugar, vamos a entender qué diseñadores de sistemas. El diseño del sistema es. El proceso de diseño de la arquitectura competente e interfaces fotosistema para que cumpla con el requisito del usuario final. En la ingeniería de software, diseño de sistemas es un dominio en el que todos deberían estar algo familiarizados con él. No importa cuál sea tu papel. Vil diseñando sistemas. Hay tres preocupaciones primarias que deben ser atendidas. Confiabilidad, escalabilidad, mantenibilidad. Entonces ahora veamos qué significan indican todos estos. Aproximadamente. El pasivo significa seguir funcionando correctamente, incluso cuando las cosas salen mal. En el dominio de diseño de sistemas. El pasivo significa la capacidad de un sistema de validar para otros problemas con el fin de evitar fallas en los apagones completos. Se construyen grandes sistemas utilizando empresas intolerantes a fallas. El bello y el arco del diseño de sistemas es construir un sistemas tolerantes a fallas utilizando empresas intolerantes a fallas. No. Las fallas se pueden categorizar como formas híbridas, también vacíos llenos. Las formas híbridas ocurrieron mucho en los grandes centros de datos. Un gran conjunto de datos que valvula espesor, discos duros van busto todos los días. La memoria se corromperá de manera regular. Las metáforas del VIH pueden abordarse agregando redundancia. Es decir, los centros de datos pueden tener múltiples copias de seguridad ilimitadas para evitar los puntos únicos de falla. Software Ford's puede suceder debido a una variedad de razones. Abundante de un proceso puede generar recursos del sistema de origen y causar un umbre sistemático en todos los nodos. O los supuestos operativos de las aplicaciones de BI pueden cambiar y desertar en bloqueos. Por lo tanto, se puede manejar entendiendo los requerimientos del negocio y la resiliencia respiratoria para manejar eliminaciones de la misma licitación de amoníaco iniciada, para publicar advertencias o pruebas de mega unidades de Leland. Y por último, diseñando mejores abstracciones e interfaces para aislar fácilmente el problema. escalabilidad es la capacidad del sistema para entregar un rendimiento razonable ante el aumento de la carga. Por ejemplo, para el social liberando la placa, el número esperado de derechos o puestos o para engrosar o leer. Es decir, en tu vista de línea de tiempo. Lo que se puede usar un engrosado para describir el rendimiento, se puede pensar como las características de funcionamiento de los sistemas que el podómetro cargado del sistema se cambia. Por ejemplo, podría medir el rendimiento en términos del tiempo de respuesta promedio del sistema. Por supuesto, hay muchas formas de medir el desempeño de un sistema que actualmente está fuera del alcance de nuestra discusión. Mantenibilidad significa escribir código que puede ser fácilmente comprendido, refactorizado y actualizado por alguien que no es el autor original del código. Cualquier pieza de espaguetis código confuso será en última instancia entendida por las máquinas. Un buen código debe ser legible y fácilmente comprensible para que pueda colaborar. buen código siempre debe tener el nivel adecuado de abstracciones, obteniendo API e interfaces. Tan oscura nueva funcionalidad se puede construir fácilmente encima de las bases de código existentes. A continuación, veremos los diferentes componentes que deben combinarse juntos para construir sistemas escalables. 3. Balancers de carga: Oigan chicos, bienvenidos a la primera conferencia en el diseño del sistema ciudades básicas. hoy, vamos a hablar de equilibradores de carga. Un equilibrador de carga es un componente muy importante de cualquier sistema distribuido. Los equilibradores de lectura distribuyen las solicitudes de los clientes entrantes a los recursos informáticos, como un clúster de servidores de aplicaciones y bases de datos. En cada caso, el equilibrador de carga devuelve la respuesta siempre y cuando el cómplice este OLS los servidores o las bases de datos al cliente apropiado. El propósito básico de un equilibrador de carga es mejorar la capacidad de respuesta y la disponibilidad de una aplicación, sitio web o una base de datos. Un equilibrador de carga también realiza un seguimiento del estado de todas las fuerzas británicas mientras distribuye Nyquist. A ver. Un servidor no está disponible para asumir nuevas solicitudes, o no está respondiendo, o podría tener una tasa de error, el equilibrador de carga dejará de enviar tráfico como null. Esto se logra vía Celtx. El equilibrador de carga intenta regularmente conectarse a los servidores back-end para asegurarse de que los cuerpos celulares estén escuchando. Si eso se siente un chequeo de salud. Se retira automáticamente de la alberca y el tráfico no se le enviará hasta que responda de nuevo al Healthix. Ahora echemos un vistazo a la arquitectura básica. Horrible. Equilibrador de carga. Normalmente, un equilibrador de carga se sienta entre el cliente y los servidores, exceptuando el tráfico entrante de red y aplicaciones, y distribuye el tráfico entre varios servidores back-end utilizando diversos algoritmos como round robin. No, aquí hace algo de arquitectura básica. Podría usar un equilibrador de carga. Ahora, aquí tenemos un cliente. Ya que eso iguala a través de internet, nuestro equilibrador de carga. Ahora es responsabilidad del equilibrador de carga distribuir el tráfico entre nuestros diversos servidores web. Al equilibrar las solicitudes de aplicaciones a través de múltiples servidores. Un equilibrador de carga reduce esa carga individual del servidor y evita que cualquier aplicación que se convirtiera en un único punto de falla. De esta manera se mejora la aplicación, disponibilidad y capacidad de respuesta en general. Sue para declarar con precisión, equilibradores de carga son efectivos para evitar que los lingüistas vayan a Sanders impío tendría cualquier sobrecarga de los recursos y ayudando y eliminando puntos únicos de fracaso. Sin retrasos, escalabilidad completa y redundancia. Podemos tratar de equilibrar la carga en cada capa del sistema. Se pueden agregar saldos de carga en reemplazos entre el usuario y el observador. Entre los servidores web y una capa de plataforma interna, como los servidores de aplicaciones, un servidor de caché. Y entre cualquier familia negra interna y bases de datos lo verán a través de diagrama. Entonces aquí está nuestro primer equilibrador de carga. Sentado entre el cliente y conseguiré servidores. Ahora, aquí hay un segundo equilibrador de carga sentado entre nuestros servidores web y servidores de aplicaciones. Ahora bien, este es un tercer equilibrador de carga. Se utilizan perras entre los servidores de aplicaciones y las bases de datos. Por lo que el primer equilibrador de carga distribuye los lingüistas de la glándula entrante creen epsilon_1 o el servidor web al equilibrador de carga secundario, distribuye aún más el tráfico en el servidor de aplicaciones o el servidor de aplicaciones lo hacen. Y el tercer equilibrador de carga distribuye el tráfico entrante desde las bases de datos de servidores de aplicaciones. Esto básicamente es distribuir la carga en las interfaces. Ahora repasemos las ventajas de usar un equilibrador de carga. Primero usa conveniencia o más rápido. Y un servicio ininterrumpido, los usuarios no tendrán que esperar a que un solo luchando para terminar sus tareas anteriores. En cambio, sus peticiones, de inmediato pasaré a un recurso más fácilmente disponible. En segundo lugar, prestadores de servicios, conveniencia, menos desalentador y mayor rendimiento. Incluso una bóveda de fallas de servidor completa afecta la experiencia del usuario final ya que la carga lo equilibra, simplemente notarán alrededor de ella al servidor pesado. Remolcado. El equilibrio de carga facilita a los administradores del sistema manejar las solicitudes entrantes al disminuir los usuarios dolorosos de lectura. Y a continuación, administradores de sistemas, conveniencia. Menos alimentan todos los componentes sincronizados. En lugar de un solo dispositivo o formando mucho trabajo. El equilibrio de carga tiene varios dispositivos se están formando un poco de suerte. Ahora pasemos a algunas desventajas de usar un equilibrador de carga. El equilibrador de carga puede convertirse en un cuello de botella de rendimiento si no tiene suficientes recursos o si no está configurado correctamente. En segundo lugar, la introducción de un equilibrador de carga para ayudar a eliminar puntos únicos de falla resulta en una mayor complejidad. Totalmente. Un solo equilibrador de carga es un único punto de falla. La configuración de múltiples equilibradores de carga aumenta aún más la complejidad. Por lo que teniendo en cuenta las ventajas y las desventajas, bit que ofrece un equilibrador de carga. Benito incluyen asesoradamente como pero nuestras necesidades en el sistema que estamos diseñando. 4. Almacenamiento en caché: Si tuvieras en la lenta conexión a Internet y la construcción un sitio web que está antes cualquier imagen de alta calidad. No obstante, en sus posteriores visitas al mismo estado, que la página renderice imagen extendida al instante. Sede visita un sitio web totalmente nuevo. Se tarda más tiempo en cargar. Entonces un visitaba con frecuencia el mismo navegador. Ahora veamos otro caso. Notado al ver un video de YouTube que sigue burbujeando simultáneamente. Entonces tienes una conexión a internet más lenta no se interrumpe. El video continúa reproduciéndose hasta alcanzar la cantidad tampón. En el uso de la red budista, el mecanismo interno que está sucediendo es el almacenamiento en caché. Entonces ahora vamos a discutir sobre el caché. Los libros de caché por el principio de localidad también financian, el gash actúa como una herramienta para que los datos aceleren la búsqueda en. El. También Ganesh es deducir que cada agencia y amplificar el rendimiento. Ahora veamos un verdadero out dorado. Y digamos que quieres cocinar la cena esta noche. Necesitas diferentes ingredientes, verduras, espacios, etcétera, para la preparación. Pero sí usa en el supermercado todos los días. Ya sabes, eso sería demasiado engorroso. Por lo que revisas los datos de audio de tu cocina definitivamente para buscar los ingredientes requeridos. Esta vista de los datos del supermercado. Ahora aquí, tu refrigerador está actuando como invitado. Y el supermercado es tu fuente de datos o datos almacenados. Todo. Entonces el beneficio de usar el caché y esta entrevista es que te ahorra tiempo para visitar el supermercado y dejar caer tus ingredientes. Entonces ahora veamos cómo funcionan las aplicaciones y cómo podemos usar el gash. En términos generales, cualquier aplicación de backend almacena los datos en una base de datos. Entonces un cliente intenta enseñar cualquier dato. Está mal. La aplicación, la aplicación consulta la base de datos, recupera los datos y la base de datos, y los devuelve al usuario o al cliente. El no necesario ser plata podría estar ejecutándose al servidor de aplicaciones en el mismo sistema que un proceso separado, o el servidor de base de datos que se ejecuta en un equipo diferente por completo. Ahora, tomar los datos de una base de datos consume mucho tiempo ya que necesita una operación para obtener los datos del sistema de archivos. Si los datos se almacenan en la caché, la operación de lectura será agradable rápidamente, porque leer desde la memoria es Vz. Después leyendo desde el sistema de archivos. Y las bases de datos almacenaron los datos en sistema de defensa por Lagash mantiene los datos en la memoria. Entonces cuando un cliente solicita algo de información, así que no dejes que una aplicación, las aplicaciones que fueron solo toma el lugar de los datos para buscar los datos de la caché. En caso de que los datos se encuentren en la caché, será de aplicación. Y el servidor de aplicaciones podría entonces devolver los datos a declinar. Ahora, en caso de que los datos no se encuentren en la caché, se comprometerá con la base de datos. Entonces la base de datos estaría devolviendo el servidor de aplicaciones con los datos. Y el servidor de aplicaciones podría almacenar esos datos. Nb Gash. A fin de evitar más consultas en la base de datos o las mismas o similares solicitudes. Dobló la glándula los mismos datos repetitivamente. Tiene más sentido convención desde la caché, luego desde la base de datos. Y veamos un ejemplo de un verbo para usar dinero en efectivo. Digamos si se convierte ¿Por qué todos los usuarios y recuperaron los datos del mismo tweet? Y como total no ha Melinda, usuarios que utilizan la caché, entonces ven millones de llamadas a la base de datos y los usuarios serían visitados con información a un ritmo mucho más rápido. De esta manera, un caché en la base de datos. Si los datos se encuentran en el corte, guardará una llamada a la base de datos reduciendo la presión sobre la base de datos. 5. Políticas de evacuación de caché: Hola chicos. En este video, vamos a hablar de la política de desalojo de caché. Dado que la caché tiene una capacidad limitada , puede llenarse en algún momento. Y luego, dependiendo del Big Data está siendo accedido por la aplicación. De ahí que tengamos que idear una estrategia. Otra política, Buda mueve los datos de la caché y lo reemplaza por la que tiene más probabilidades de ser accedida en un futuro próximo. Existen múltiples políticas de desalojo de caché. Lru menos usado recientemente, LRU menos utilizado. Y más recientemente utilizado. Estas son las políticas de desalojo más utilizadas. ¿ Ya lo verás? No. Hablemos de estos individualmente. Hablando de LRU. Esta política elimina el NPV de la caché, que es la menos utilizada recientemente. Por lo que tan pronto como el gas se llena, auditoría está a punto de convertirse para ellos en los usos menos decentemente. Se desaloja la entrada de ella. Y la entrada reciente se agrega a la caché. Por lo que te puedes imaginar Facebook. Es hacia celebridades, fotos en un caché. El patrón de acceso a datos de los seguidores tal que les interesan las fotos más recientes. Entonces esta celebridad fotos en efectivo se llena. Se patearán las fotos que menos recientemente se le añadieron. Entonces digamos por ejemplo, b1 foto, B2, B3, B4 son los trabajos fotovoltaicos que, eso sumado a la caché. Y pero x y d, p más uno, p más 23. Por lo que esto representa el momento en el que se accedió por última vez a estas fotografías por el corte. Y vamos a ver, necesitamos agregar b5 a la caché y solo soportes para fotografías terminadas I. Así que necesitamos quitar una fotografía y luego solo podremos agregar si así en este caso, incluso se eliminaría de la caché porque esta fotografía se ha utilizado menos recientemente antes, fue la más utilizada. Y así b1 será retirado de la herida, y B5 tomará su lugar. Y el tiempo de su eje será p más cuatro. L de u Ese es el menos utilizado. Se hace un seguimiento de la frecuencia son el número de veces que se accede a un elemento de datos. En caso de que el tamaño de caché cruce un umbral dado, emitirá a la entrada con la frecuencia más baja. Por ejemplo, venue escriba cualquier palabra a través de mensajes de texto en su smartphone. Tu teléfono empieza a sugerir múltiples palabras que puedes seleccionar. En lugar de escribir toda la palabra. Internamente, se forma software mantiene un caché de todas las palabras que tienes tiempo junto con su frecuencia. Las élites liberales, que la frecuencia más baja. Entonces digamos que horneas más Vasa. Por lo que tan pronto como empieces a escribir W y a, tu teléfono comenzará a sugerir que te wassup inmediatamente. Porque esto tiene el mayor número de frecuencia y tienes efectivo. Ahora, en caso de un empate entre múltiples modos, entonces la lista utilizada esencialmente para quemar es desalojada de la caché. Mrd, o el más recientemente utilizado en MIT usted, el N3 utilizado más recientemente se elimina y se da preferencia a las entradas más antiguas en la caché. Si el patrón de acceso a datos es tal que el usuario es menos probable a la entrada más reciente. Entonces esta estrategia se utiliza para el desalojo. Un ejemplo para este tipo de efectivo son las apps de citas como Tinder. Generalmente guarda en caché todas las coincidencias potenciales de un usuario. Entonces el usuario ya sea de izquierda o derecha viola o proporciona. El app no debe recomendar que se le proporcione al usuario. Nuevamente, si esto sucede, se traducirá en una mala experiencia de usuario. Por lo que es necesario editar las entidades que absorberían más recientemente. La aplicación debe eliminar la entrada en caché del perfil que ya sea a la izquierda o a la derecha. 6. Tipos de caché: En este video, vamos a hablar de diferentes tipos de cachés. Conjeturar es fantástico. Sí requiere algún mantenimiento para mantener la caché coherente con la fuente de agravio. Es decir, cuando las bases de datos, si los datos se modifican en la base de datos, se debe invalidar en la caché. De no ser así, esto puede causar un comportamiento inconsistente de la aplicación. Resolver este problema se conoce como invalidación de caché. En base a la invalidación de caché, Hay tres tablones principales de cachés. En primer lugar, para romper que mala racha, y en tercer lugar, anotar gash. Ahora veamos lo que todos estos significan indegree, justo a través del caché. A medida que el nombre se mueve, los datos se escriben primero en la caché y luego hacen la base de datos. Este es un servidor de aplicaciones. Tan pronto como necesite leer algunos datos. Primero lee los datos de la caché, y después escribe en la base de datos. Esto asegura la consistencia entre los datos en la caché y los datos en la base de datos. Cada ventaja entonces en el gash sigue la tasa más reciente. No obstante, la desventaja de este enfoque es que la latencia de la tasa de aplicación aumenta porque los datos se escriben primero en la caché y luego se persiste en la base de datos. Este enfoque no es adecuado para ningún sistema de escritura pesada. Es útil para aplicaciones que reducen los datos con frecuencia. Bollos, es persistente en la base de datos. La latencia de escritura puede tomar un golpe, pero se compensa con una menor latencia y consistencia. A continuación, tenemos caché de reescritura. Como vimos, los dos últimos en efectivo no son adecuados para sistemas pesados de escritura ya que la latencia puede aumentar. Un enfoque alternativo es escribir los datos en la caché primero y Marcar al líder como modificado, que se puede actualizar en la base de datos más adelante. Por lo que un servidor de aplicaciones escribe los datos en la caché. Y entonces un trabajo honesto podría dirigir regularmente todas las entradas modificadas en la caché y actualizar sus valores correspondientes en la base de datos. Este enfoque necesitaría que impactara la lectura, no retrasara la latencia. El único inconveniente es que habrá un rezago por el pensamiento de datos entre la caché y los vivos. Ahora, como la base de datos es la fuente del bruto, cualquier obligación de leer de dB leería aún encarna. El sitio como YouTube. Utiliza caché de reescritura, va hacia el buccal de cualquier video. Actualizar la base de datos para cada vista individual de cualquier video vital sería costoso. Escribir datos en la caché. Y luego hundirse en la DB es una mejor solución. Tenía. Uso de caché de reescritura, asegura latencias de lectura y escritura. Siguiente ES gas radón. Aplicaciones de back-end de combustible no frecuentemente Realmente, los datos más recientes, en este caso, se utiliza gas radón. Y esta política, la base de datos, se actualiza sin romper los datos a la caché. Por lo que el servidor de aplicaciones primero escribe los datos al db. Y luego para cualquiera de ustedes come el gash consulta la base de datos. Si las entradas no son agradables en el corte. Este enfoque no carga la caché, los datos que no se retrasarán. El inconveniente de este enfoque es que si la aplicación comienza a consultar los datos más recientes, se desertará y mi doble caché se pierde. Por lo que estos son los tres tipos de cachés, que tienen algunos positivos y algunos negativos. Depende enteramente del escenario que ¿qué caché deberías estar considerando al diseñar tus sistemas? 7. Partición de datos: Oigan chicos. En este video, vamos a hablar de particionamiento de datos. También se le conoce como sharding de datos. Sharding de datos es un proceso de descomponer tablas grandes en múltiples tablas o chatarra más pequeñas, conocidas como jibes, y distribuir los datos a través de múltiples máquinas o intercluster. Cada gráfico tendrá el mismo esquema y columnas como el de la tabla original. Pero los datos almacenados en cada niño son únicos e independientes de otros cargos. Existen dos formas de Sharding de datos. En primer lugar, el afilado vertical o el particionamiento vertical. Y el segundo se llama particionamiento horizontal. En el particionamiento vertical, la tabla principal se divide en múltiples particiones separando el número de columnas. Aquí, como se puede ver, esta tabla principal cuenta con información específica del usuario. Eso es un ID de usuario, nombre de usuario, y el correo electrónico del usuario. Esta información se divide en tablas. El primero que contiene el ID de usuario y el nombre de usuario, y el segundo que contiene el ID de usuario y el usuario emitido. En caso de que necesitemos recuperar la información de un usuario en particular. Podemos unirnos ambas tablas con base en el ID. Aquí. Hemos dividido la mesa verticalmente. De ahí que se le conozca como particionamiento vertical. En particionamiento horizontal, v divide la tabla principal según el número de filas. Eso está sin cobrar. Uno, V mantener un par de filas. Y en cargado a V vino otro conjunto de filas. El dato en ambas tomas combinadas nos dará los datos originales. Aquí. El dato podría haberse dividido en base a unos pocos factores, lo cual veremos en el próximo tardío. Base de datos. Sharding es bastante similar a la escala horizontal. Es decir, agregar más máquinas, autoescalar hacia fuera. De ahí. Nos permite agregar más máquinas cuando existe cluster con el fin de extender la carga, permitir más tráfico y un procesamiento más rápido. También, el chiding ayuda a que esa aplicación se distribuya, así, minimizando un solo punto de falla. Sharding de la base de datos necesita hacerse de tal manera que los datos entrantes se inserten en el gráfico de recopilación. No debe haber pérdida de datos. Y las consultas del desierto no deben ser lentas. Considerando estas cosas. Veamos, cuáles son las técnicas para astillar la base de datos. Primero es Hashmi sharding, o también conocido como GIS brillante védico. Un par clave-valor, como un ID de cliente en IB planeado o inmolar de las nuevas líneas son los datos. Después pasarlo a una función hash e insertar los datos en el no cree shied. De nuestro ejemplo anterior. Digamos que tenemos los siguientes datos para ser insertados. ID de usuario, nombre de usuario, y utiliza correo electrónico. A ver, el primer valor es uno. El nombre de usuario es ABC. Y algún correo electrónico. Abc en gmail.com. Aquí, rediseñado para fragmentar nuestros datos en base a este ID de usuario. Entonces el bus, este ID de usuario hacen una función hash para nuestro ejemplo, pero versículos esta función hash, solo hace el modulo del id de usuario por tres y asigna un buen hijo resultante. Por lo que el modulo 43 resultaría en 012. Entonces cada vez que el resultado es 0, es una misma carrera de Bouchard. Siempre que el resultado sea uno, se asigna a SIO2, y siempre que el resultado sea dos, se asigna a la partición tres. Por lo que en este caso, el usuario ID uno, se asignaría a nuestra gráfica a. Por lo que esta regla se insertaría también en nuestro tiro. En caso de que necesitemos agregar otra regla, ese usuario ID dos y algunos otros atributos. Esta función hash entonces elegiría do modulo tres, lo que resultaría en dos, y asignaría los datos. Bouchard tres. Este es el algoritmo de Sharding más simple y se puede utilizar para distribuir uniformemente los datos entre tomas. Y evitar el riesgo de tener un hotspot de datos. El problema de hotspot de base de datos surge cuando se accede a un solo hijo más en comparación con los otros puntiagudos. Y de ahí que, en este caso, cualquier beneficio de brillar se esté cancelando. El principal problema con este enfoque es que se pone realmente desafiante agregar o quitar dinámicamente un servidor de base de datos. Cada vez que esto sucede, necesitamos llegar a la base de datos, lo que significa que necesitamos actualizar la función hash y reequilibrar los datos. Además, si ocurre con frecuencia, esto puede provocar la pérdida de datos. Entonces, vamos a ver. Necesitamos eliminar o servidor, que hosts son fragmentos tres. En este caso, tendremos que modificar primero nuestra función hash. Y luego el hash, todos los datos que se han almacenado dentro de uno, SIO2 y niño tres respectivamente. Porque a medida que cambiemos la función hash, también cambiará la distribución de los datos. Ventilación. Pero este problema es usar hashing consistente. El almacenamiento en caché consistente proporciona escalabilidad incluso cuando tenemos muchos datos entre muchos servidores. Y el número de servidores disponibles cambia continuamente. Vivi, aprende sobre hashing consistente y las próximas conferencias. A continuación tenemos a los decanos para estar brillando y reingresando Sharding. El trozo se elige sobre la base de la gama de un Schottky. El rango de afilado se elige de tal manera que es probable que el Schottky caiga en cualquiera de los valores posibles. Entonces digamos que tenemos un sistema de recomendaciones que almacena toda la información sobre el usuario y recomienda películas basadas en los usuarios. Se. De ahí que podamos crear unos cuantos cargos diferentes y dividir información de cada usuario en función de qué rango de edad se devolve en algo como esto. Si el usuario cae en el rango de edad de 0 a 18 años, los datos se almacenarían en número de niño, pero si cae en la edad de 19 a 27 años, el niño asociado se quedaría conmocionado. Y de igual manera, el sharding de interfaz también es muy fácil de implementar. Basta con revisar el rango en el que faltan nuestros datos actuales e insertar o leer los datos del shied correspondiente. Además, cada trozo contiene un conjunto diferente de datos. Pero se ve el esquema de todos los esquirlas. El mayor inconveniente de esta técnica es que si lo hice eso se distribuye de manera desigual. Puede llevar a hotspots de base de datos. Entonces tenemos el sharding y el gráfico directamente basado. Tenemos una tabla de búsqueda. Es hacia la schottky mantener la pista de qué arte almacena qué entradas, flúor o leer los datos. Motor declinado primero se refiere a la tabla de búsqueda para encontrar el shied Número cuatro, los datos correspondientes utilizando el Schottky y después visita un trozo en particular para realizar diferentes operaciones. lo que un ejemplo del literalmente ser sharding aspiraba a almacenar los datos basados en la geolocalización del usuario. Es decir, si el usuario se encuentra en nosotros, se almacenaría en la infancia. Si el usuario se encuentra en Reino Unido. Su información se almacenaría en el gráfico do. Si lo está mirando en India, entonces es información la encontraría en el chat tres. Este afilado es más o menos similar al brillo basado en rango, excepto en lugar de determinar la victoria y los datos obtenidos caen en. Cada llave, se tiñe con su propio shied específico. A diferencia de lo que ha sido el cierre, que utiliza una función hash fija y rango antes de decidir, lo que requiere que especifiquemos un rango de antemano. Dedicatory be sharding te permite usar cualquier sistema en algoritmo que quieras que EU asigne datos en súplicas a las tiendas. Y también es un relativamente fácil, bueno agregar dinámicamente gráficos usando este enfoque. El tema principal del sharding basado médicamente es que necesitamos conservar una tabla de búsqueda antes de cada consulta de escritura y escritura. De ahí que pueda incrustar el rendimiento de la aplicación. Además, la tabla de búsqueda se sopla a través de un único punto de falla. Una solución. Pero este problema es usar balanceadores de carga. Pero de nuevo, actualizar frecuentemente la copia de la tabla de búsqueda en cada servidor sería una sobrecarga? No. Hablemos de algunos de los beneficios de sharding. Base de datos. Sharding nos ayuda a facilitar los extremos de escalado horizontal. Podemos agregar más máquinas al clúster existente y distribuir la carga para escalar aplicaciones. respuesta de consulta más rápido. Sin el sharding de la base de datos, la base de datos necesita comparar un arenoso con todas y cada una de las filas. Y puede ser un enorme revés. Pero con chiding, en lugar de recorrer todas las filas, necesitamos pro entrega solo unas cuantas filas presentes en el lado particular. Sharding facilita el mantenimiento porque cada lado contiene un trozo de datos. Sharding de bases de datos elimina el problema de un solo punto de falla y hace que nuestra aplicación sea más tolerante a fallas. Que Sharding. Tenemos costo reducido. Porque si tratamos de agregar más RAM y almacenamiento a una máquina existente con el fin de escalarla verticalmente. Se trata de un gloses caro al tener varios nodos. El menor poder de cómputación es más barato. Obviamente, hay algunos inconvenientes de brillar. Base de datos. Sharding se vuelve complejo. Ventilado llega a implementaciones prácticas. Además, si es incorrecto, puede conducir a la pérdida de datos y tablas corruptas. Otro tema importante con el sharding es que la carga podría volverse desequilibrada. En caso de problemas de hotspot de base de datos. Un gran trozo de datos podría caer sólo en un conjunto particular de cargos, y los disparos restantes podrían permanecer vacíos. Almuerzo afilado está hecho. Es muy difícil volver a la versión original desconocida de la base de datos. Entonces esta fue tu breve introducción a la base de datos, sharding 8. Redundancy de datos: Por lo que el tema de discusión para este video es la replicación de datos y redundancia. Replicación significa duplicación de servicios de datos críticos con la intención de aumentar la confiabilidad del sistema. Por ejemplo, si solo hay una copia de un archivo almacenado en un solo servidor, entonces perder ese servidor significa perder el archivo. Ya que perder datos nunca es algo bueno, podemos crear copias duplicadas o redundantes. Para resolver el problema. El mismo principio se aplica a los servicios a si contamos con un servicio crítico en nuestro sistema, asegurando que múltiples copias, todas las versiones del mismo se estén ejecutando simultáneamente, nos puedan asegurar contra la falla de cualquier particular nodo. Crear redundancia en el sistema puede eliminar puntos únicos de falla y proporcionar respaldo si alguna vez es necesario en una situación de crisis. Por ejemplo, digamos que tenemos dos instancias de un servicio funcionando en producción. Supongamos nuestro campo de servicio primario o degradar. Entonces el sistema puede fallar al segundo desservicio. En tales escenarios. Estos vehículos pueden ocurrir automáticamente o pueden controlarse manualmente. También podemos sentirnos bien a base de datos sin medidor en caso de que nuestros campos de base de datos primarios. Ahora, otra parte importante de la redundancia de servicio es crear una arquitectura de nada compartido. En la arquitectura nada compartida, cada nodo puede operar independientemente el uno del otro. Esto significa que no debe haber ningún servicio más simple administrando estado o nuestros invitados leyendo actividades para los otros nodos. Esto ayuda mucho con la escalabilidad ya que se pueden agregar nuevos servidores sin condiciones especiales en el conocimiento. Y lo más importante, y lo más importante, tales sistemas son más resistentes al fracaso. Ya que no hay un único punto de fracaso. Siempre tenemos un servidor secundario o la base de datos secundaria en caso de que necesitemos activar una conmutación por error. Ahora veamos las ventajas de la replicación de datos. ¿ La replicación de ADN se realiza generalmente para lograr mayor disponibilidad, menor latencia, escalabilidad e interrupciones de red? No, hablemos brevemente de cada uno de estos. Disponibilidad contratada significa garantizar la disponibilidad de un sistema distribuido. Eso significa que el sistema sigue funcionando incluso en da la mitad de uno o pocos nodos que se llenan. Por lo que simplemente podemos afirmar que sigue funcionando. Ahora, la replicación de latencia reducida ayuda. Al reducir la latencia de las consultas de datos al mantener los datos geográficamente más cerca del usuario, ejemplo CDN, mantiene una copia de los datos replicados más cerca del usuario. ¿ Alguna vez has pensado en cómo reducen las transmisiones de Netflix? Eso dijo latencias de gráfico? Will Data Replication es una de las razones de eso. Escalabilidad Dude. Por lo que tendrías consultas se pueden servir a partir de copias replicadas de los mismos datos. Esto aumenta el rendimiento general de las consultas e interrupciones de la red. Artista algunos libros, incluso bajo culpa de red. También es importante entender las desventajas de la replicación de datos. En primer lugar, la mayoría de los estudiantes bases necesarias como almacenar la réplica de los mismos datos en diferentes, digamos, consume más espacio.. En segundo lugar, replicación no se vuelve cara, réplica de proveedor en diferentes sitios necesita ser actualizada. Y en tercer lugar, mantener la consistencia del Día D en diferentes sitios implican medidas complejas. Ahora veamos una técnica para la replicación de datos. Esta técnica se llama replicación maestro-esclavo. Es una de las prácticas más comunes en la replicación de datos. En técnica de replicación maestro-esclavo. El líder, o se podría decir maestro, o el nodo primario. Aquí. Podríamos decir que tiene líder. O un nodo primario, replica datos a todos sus seguidores, que podrían llamarse como esclavos, son réplicas de lectura. En algunos casos. Nuestros nodos secundarios. Este es el modo de replicación más utilizado. Siempre que llegue una nueva tarifa al maestro. Mantiene su mercancía seca almacenamiento local. Y ya que los mismos datos a todas sus réplicas como un registro de replicación de orden de secuencia de cadena. Come en vivo, luego actualiza su propia copia local de los datos ya que fue poseída por el nodo líder. Muchas bases de datos relacionales como MySQL, PostgreSQL, y sus bases de datos SQL como MongoDB, repensar BB, y espresso utiliza este modo de replicación. Tarjetas azules de mensaje como Kafka y tacos como Rabbit MQ también emplean replicación basada en líder único. Datos. Dos réplicas de un líder se copian ya sea de forma asincrónica o sincrónica. El Iit método de configuración de replicación tiene su propio conjunto de pros y contras, que actualmente están más allá del alcance de esta discusión. Entonces espero que tengas cierta claridad o replicación y redundancia de datos, que es un principio que hay que seguir mientras diseñas sistemas. 9. SQL Vs NoSQL: Y el mundo de las bases de datos. Existen dos tipos principales de soluciones. relacionales y bases de datos no relacionales. Estamos más familiarizados con ellos como SQL y NoSQL. Ambos por defecto indivi, desarrollando el tipo de destructor de información y el V distorsionado. Las bases de datos Sql y relacionales almacenan datos en una fila y columnas. Cada fila contiene toda la información sobre una entidad. Se podría imaginar en forma de mesa. Tener múltiples filas y múltiples columnas. Cada fila contiene toda la información sobre una entidad. Y todas las columnas son los puntos de datos separados. Algunas de las bases de datos relacionales más populares incluyen MySQL, Oracle, servidor MS SQL, SQLite tanto a verde como a MongoDB. Hablando de bases de datos no relacionales, bases de datos NoSQL, los siguientes son los tipos más comunes. En primer lugar, las tiendas clave-valor. En las tiendas clave-valor, los datos se almacenan en un eddy de pares clave y valor. El clave es un nombre de atributo, que es un buen valor. Las tiendas clave-valor de Villain incluyen Voldemort y DynamoDB. A continuación vienen las bases de datos de documentos. En estas bases de datos, los datos se almacenan en documentos en lugar de filas y columnas de una tabla. Y estos documentos se agrupan en forma de colecciones. Por lo que los datos se almacenan en documentos. Y a un grupo de documentos se le llama colección. Cada documento puede tener una estructura completamente diferente. Entre los ejemplos de bases de datos de documentos se encuentran CouchDB, impar MongoDB. Ahora vamos al tercer tipo de base de datos llamado bases de datos de columnas ID. En lugar de mesas. En bases de datos columnar, tenemos familias de columnas, que son contenedores para filas. Y como bases de datos relacionales. No necesitamos conocer todas las columnas volteadas al alza. Y ito no tiene que tener el mismo número de columnas. Podrías imaginarlo como algo así. Las bases de datos luminosas Go son las más adecuadas para analizar conjuntos de datos de gran tamaño. Ahora, los ejemplos incluyen Cassandra, base de datos HBase. Después tenemos bases de datos gráficas. Estas bases de datos se utilizan para almacenar datos. Quién es un deleciones se representan mejor en forma de gráfico. Al igual que esto. Los datos se guardan en estructura gráfica con nodos llamados entidades. Propiedades. El dato sobre las entidades y líneas, las conexiones entre las entidades. En los ejemplos de bases de datos de gráficos se incluyen Neo4j en gráfico finito y otros. No, veamos algunas diferencias de alto nivel entre SQL y NoSQL. Sql básicamente viene bajo los sistemas de gestión de bases de datos relacionales RDBMS. Líderes. Nosql entra bajo sistemas digitales no relacionales o distribuidos. Estas bases de datos tienen esquema fijo o estático o predefinido. Vedas. Las bases de datos Nosql no tienen esquema, son esquema muy dinámico. Las bases de datos Sql no son adecuadas para historia de datos jerárquicos. Vid, como las bases de datos NoSQL son las más adecuadas para el almacenamiento jerárquico de datos, las bases de datos SQL son las más adecuadas para consultas complejas. Visión, necesitas fusionar múltiples entidades para sacar algo de información. Las bases de datos Versus NoSQL no son tan buenas para consultas complejas. Las bases de datos SQL son particularmente buenas Fit Vertical Scaling. Vid como no hay bases de datos secuela muy bellamente soporta escalabilidad horizontal. Ahora veamos las razones por las que deberías estar usando bases de datos SQL. En primer lugar, si necesita asegurar las quejas ácidas, ya que se queja, reduce las anomalías y protege la integridad de su base de datos al prescribir exactamente cómo interactúan las transacciones con la base de datos. Generalmente, las bases de datos NoSQL sacrifican queja ácida por escalabilidad y velocidad de procesamiento. Pero para muchas aplicaciones de comercio electrónico y financieras, como se quejó, las bases de datos siguen siendo la opción preferida. Entonces tus datos están estructurados e inmutables. Si su negocio no está experimentando un crecimiento masivo, eso requeriría más servidores. Solo trabajando con datos que sean consistentes, entonces puede que no le sirva usar una base de datos diseñada por el sistema para admitir una variedad de tipos de datos y un alto volumen de tráfico. No cuando deberías estar usando bases de datos NoSQL. Entonces todos los demás componentes de su aplicación son rápidos y sin fisuras. Bases de datos Nosql. Datos de ser desviados en. Big data está contribuyendo a un gran éxito bases de datos no SQL, principalmente porque maneja lo hizo de manera diferente a las bases de datos relacionales tradicionales. Algunos ejemplos de base de datos NoSQL en MongoDB, CouchDB, Cassandra, HBase, como vimos anteriormente, null. Los motivos para utilizar la base de datos MySQL son los siguientes. Al almacenar grandes volúmenes de datos que a menudo tienen poca o ninguna estructura. Y la base de datos NOSQL establece límites en los tipos de datos que podemos almacenar juntos y nos permite agregar diferentes formas como los nuevos peligros. Vid, bases de datos basadas en documentos. Se pueden almacenar datos en un solo lugar sin tener que definir muchos datos. Esos son los Países Bajos. Entonces querrás aprovechar al máximo la computación en la nube y el almacenamiento. El almacenamiento basado en la nube es una excelente solución de tamizado de cursos, pero requiere que los datos se distribuyan fácilmente entre múltiples servidores para escalarlos. uso de hardware de commodities, in situ o en la nube, le da la molestia de software adicional. Las bases de datos Nosql como Cassandra están diseñadas para ser escaladas a través de múltiples centros de datos fuera de la caja. Si agrega otra fase de pre-desarrollo. No, SQL es extremadamente útil para un desarrollo rápido ya que no necesita que estés preparado con anticipación. Si está trabajando en iteraciones más rápidas de su sistema, que requieren realizar actualizaciones frecuentes al sujeto de datos sin mucho tiempo de inactividad entre versiones, una base de datos relacional lo ralentizará. Ahora surge la pregunta, ¿cuál utilizas? Sql o a lo sumo igual? Cuando se trata de tecnología de bases de datos, no existe una solución de talla única para todos. Es por eso que muchos negocios confían en bases de datos tanto relacionales como no relacionales para diferentes necesidades. A pesar de que no hay bases de datos secuelas están ganando popularidad por esta velocidad y escalabilidad. Todavía hay situaciones en las que la base de datos SQL altamente estructurada puede funcionar mejor. Elegir la tecnología adecuada depende de su caso de uso. La gran mayoría de las bases de datos relacionales son ácidas quejadas. Es decir, este aborto, atomicidad, la consistencia, el aislamiento, y la durabilidad. Vds, las bases de datos NoSQL se quejan de base. Es decir, básicamente están disponibles. Estado blando. Es decir, podrías modificar la base de datos cuando quieras y proporcionan consistencia eventual. No fuera de la caja, pero sí, sí proporcionan consistencia. Entonces cuando se trata de disponibilidad de datos, vea si obtiene D por realizar transacciones bases de datos SQL. Todavía he debatido con la mayoría de las soluciones Nozick, sacrificar ya que se queja por rendimiento y escalabilidad. 10. Teorema de la CAP: Oigan chicos. En esta conferencia, vamos a hablar de principios de vinculación en los conceptos básicos del diseño de sistemas. C significa consistencia, disponibilidad, y B significa dominio de audiciones. Por lo que la brecha hacia ellos establece que es imposible que el sistema de software distribuido creciera simultáneamente en más de tres, disponibilidad garantizada, consistencia y tolerancia de particiones. Entonces diseñamos un sistema distribuido. Negociar entre brecha es casi lo primero que queremos considerar. Al diseñar un sistema distribuido. Podemos escoger cualquiera de los tres. ¿ Qué significan todos estos? Hablando de consistencia, se dice que un sistema es consistente si todos los nodos ven los mismos datos al mismo tiempo. Entonces consideremos un sistema distribuido. Están interactuando las tres incógnitas. Por lo que simplemente hablando, si realizas una operación de lectura en un sistema consistente, se debe hacer el valor de la operación de escritura más reciente. Y esto significa que el lead debe causar todos los nodos en los mismos datos. Ese es el valor del MOSFET y la tasa. Entonces vamos a entenderlo con el, por ejemplo. Entonces que se proporcione C nuestro sistema de entrada incorporada como x. Así que digamos que estos son nuestros datos y relacionados esta entrada y esto es básicamente una operación de lectura. Sé radón, relacionate con nuestro sistema. Entonces si estás leyendo los datos, no hizo nuestro sistema desde ninguno de los otros nodos. Digamos que estamos leyendo del C. existente Así que en su mayoría hecho. Hecho x ha sido más reciente. Solo dominación. Tampoco asumamos v, algunos datos nuevos a nuestro sistema B. Así que digamos datos como brecha de aprendizaje de esta operación de escritura es d más uno. Entonces ahora si realizas un sistema de arreglo legal, mira, se debe hacer brecha de aprendizaje en lugar de biónica. Porque en este momento, la brecha de aprendizaje es nuestra población reclamada más reciente. Ahora vamos a discutir sobre la disponibilidad. La disponibilidad en un sistema distribuido asegura que el sistema permanezca operativo el 100% del tiempo. Eso significa que la endogamia obtiene una respuesta independientemente del estado individual. Pero esto no garantiza que la respuesta contenga la calificación más reciente, ninguna garantía del derecho. En la respuesta. Ejemplo para este sistema, digamos V, habían estado a tres en nuestro sistema. V, x, y, z en el tiempo t más uno. Entonces estamos tratando de extraer del sistema POR un sistema de alta disponibilidad, lo hemos hecho, o bien fue a tres XYZ. Dependiendo de la sincronización entre los sistemas. Esto no garantiza consistencia, pero los sistemas están altamente disponibles. Es decir, el sistema está operativo. Está dando alguna respuesta. Cualquiera de los lingüistas. Ahora veamos qué significa tolerancia. Esta es una condición que establece que el sistema no falla independientemente de si los mensajes me caen bastantes mil millones entre los nodos y el sistema, el dominio de particiones se ha convertido más en una necesidad que una opción en unos sistemas distribuidos. Es posible por lo suficientemente los registros de inicio a través de combinaciones de normas y redes. Entonces en nuestro sistema, tenemos tres nodos. Digamos que tenemos tres nodos. En nuestro sistema. Tenemos tres nodos. Estos nodos están conectados al al sistema. El sistema sigue funcionando. Sólo. Este nodo en particular comienza a funcionar mal. Pero no podemos ver que el sistema esté hecho. Sigue funcionando. Y esta edición en particular se ve afectada. Si algún dato, estaría determinado por alguna otra norma que tiene duplicado. Este nodo. Ahora, B no puede ser un género que nos lleve a que esté convenientemente disponible. A, consistente. Y cualquier falla de partición sólo puede hacer un sistema que tenga tres propiedades cualquiera. Porque para ser consistentes, todos los nodos deben ver el mismo conjunto de actualizaciones en el mismo orden. Pero si se actualiza el soporte de red, edición podría no llegar a las peticiones antes una glándula partición desactualizada después de haber actualizado. De lo único que se puede aprender. Esta posibilidad es dejar de liquidar a los lingüistas de la variación fuera del juego, pero entonces el servicio ya no sería un 100% disponible. Por lo que los ejemplos de sistemas altamente disponibles y consistentes podrían no caer. Tolerante a particiones. Bases de datos como MySQL, SQLite, bases de datos relacionales. Por otro lado, los ejemplos de sistemas de dominio de alta disponibilidad y por paciente no son almacenes de datos de condominios como Cassandra y tolerancia de consistencia y partición. Y no nos importará la disponibilidad. Entonces el ejemplo sería MongoDB. Entonces para concluir, podemos ver que sólo podemos esperar dos de los tres discutidos. Conseguir cualquier sistema distribuido. 11. Hashing consistente: Bienvenido al video sobre el almacenamiento en caché consistente. Antes de avanzar con hashing consistente, primero necesitamos entender las tablas hash distribuidas. La tabla hash distribuida es uno de los componentes fundamentales utilizados en sistemas escalables distribuidos. Como sabemos, los hashtables necesitan una ganancia. Nuestro valor, y la función hash. La función hash, mapea la clave a una ubicación donde se almacena el valor. Entonces cuando pasamos la clave para la función hash, devuelve el índice en el valor de datos de la tabla hash se almacenaría. Ahora supongamos que estamos diseñando un sistema de almacenamiento en caché distribuido. Dado n servidores de caché. Y en función hash butano sería d modulo m Es decir, para encontrar qué servidor de caché AGI está presente, simplemente necesitamos hacer este modular. Y el valor resultado nos proporcionará el índice del servidor de caché donde se almacena nuestro valor. Se trata de una función hash simple y de uso común. Pero tiene dos grandes inconvenientes. En primer lugar, no es escalable horizontalmente. Siempre que se agrega un nuevo host de caché al clúster, rompen todas las mappings existentes. Porque a medida que cambia nuestro número de servidores de caché, nuestra función hash cambia. Y todos los mapeos ya realizados en el sistema existente van a ganar. Por lo que será un bin se desvaneció en mantenimiento si el sistema de almacenamiento en caché y en gran cantidad de datos que típicamente se vuelve difícil programar están abajo Dane que actualizan nuestros mapeos de equipaje. En segundo lugar, puede que no esté balanceada de carga, especialmente para datos no distribuidos de manera uniforme. En la práctica, se puede suponer fácilmente que los datos no se distribuirán uniformemente. Para el sistema de almacenamiento en caché, se traduce en que algunas cachés están calientes y saturadas, mientras que las otras están inactiva y casi vacías. Entonces si tenemos tres servidores de caché, C1, C2, y C3, podría suceder que la mayoría de las lecturas de caché se estén haciendo desde C1 y C2 y C3 no se califiquen mucho DAG. Esto desierta en un dato no uniformemente distribuido. Por lo que en estos escenarios, pasión consistente es una buena manera de mejorar el sistema de almacenamiento en caché. hashing consistente es una estrategia muy útil para sistemas de almacenamiento en caché distribuidos y tablas hash distribuidas. Permite distribuir datos a través de un clúster tal manera que minimice la reorganización. Se agregan o eliminan nodos Ven. De ahí que el sistema de almacenamiento en caché sea más fácil. Esa escala hacia arriba o hacia abajo. Hash inconsistente. Entonces se recita la tabla hash. Ejemplo. agrega una nueva plata de gash al cluster. En ese caso, sólo se necesita mapear las claves k by n . Si recuerdas. En el sistema de almacenamiento en caché, utilizamos el modo como función hash. Por lo que fue d modulo N. Así que sólo estos tendrían que ser remapeados. Pero en este caso, sólo k by n mirada necesita mapear realmente. Aquí. K es el número total de claves, y N es el número total de sílabas. Entonces veamos cómo funciona. Como un típico sistema de función hash, la pasión mapea un B a un entero. Supongamos que la salida de la función hash está en el rango de 056. Imagina que los enteros en el rango están complacidos honrando tal que los valores se envuelven alrededor. Es decir, y b al 0 se almacena en algún lugar aquí. Y el dígito uno se almacena un poco aquí. Entero do se almacena en algún lugar aquí, y así sucesivamente. Y estos son 255, que probablemente se almacena aquí. Ahora, dada una lista de servidores de caché, primero necesitamos hackearlos a los individuos de nuestro rango. Entonces digamos que teníamos tres servidores de caché y Hashing ellos a enteros desiertos en los siguientes números. A0 se asigna a cinco, B se asigna a un 100, y C se asigna a relativo y NP. Zoom soviético que se coloca en el índice cinco. B se complace con el índice 100, y C se complace con el índice de fondo MP en nuestro enlace. Ahora, entonces necesitamos mapear cualquier clave a un servidor en particular. El primer peligro. Entonces digamos que necesitamos mapear el vn. Por lo que lo pasamos a nuestra función hash. Digamos que si sale a, Vamos a revisar en nuestro índice. Por lo que B se moverá en el sentido de las agujas del reloj en el enlace hasta que nos encontremos con nuestro primer efectivo. Por lo que índice a Watson sí golpeó. Entonces. Esto debió haberse mapeado a esta ubicación, pero tenemos nuestra sílaba de efectivo más cercana en el índice cinco. Por lo que esta clave se mapearía a nuestro servidor a. Del mismo modo, digamos que tenemos DK2 y la función hash para k2 devuelve 115, que probablemente está aquí en nuestro anillo. Por lo que este gueto sea mapeado aquí. Pero como no hay efectivo festejar aquí, nos movemos en el sentido de las agujas del reloj. Y el primer servidor de caché Vn contador está en la vanidad de índice, eso es un servidor de caché c. Así que el mapa, este esquema en el servidor de caché c. Así que así es como mapeamos nuestros p. que son servidores de caché. Ahora vamos a ver qué pasa cuando agregamos un nuevo configurable. En este caso, digamos que agregamos efectivo que estaría en la ubicación del índice 125. Entonces esto es a los 500, esto a los 80. Ahora, le ha dado todavía resulta en un grupo de entidades el cual se mapea aquí. Y nuestro servidor de gas más cercano es un esclavo atlántico. Esto ya estaba almacenado aquí. Pero para eso, el gueto para el que la función hash devolvió 115 tableta de mapa aquí y se mostró complacido en nuestro servidor de caché c. Entonces lo que tenemos que hacer es que necesitamos mapear la piel para hacer que nuestros invitados alguna vez necesiten. Por lo que sólo necesitamos mover las claves antes del índice 125 ya que la mirada restante se almacenaría en la caché, ver sólo las claves que está apuntando al efectivo ver se cree que se dividen. Algunos de ellos serán cambiados por los otros gays, no serán tocados. De igual manera, si por casualidad nuestro servidor invitado E baja y se retira de un clúster, sólo tendrá que moverse dado D de aquí a aquí. Al igual que B sería el primer servidor de caché en este anillo. Entonces se retira este gas. Todas las claves que originalmente se le asignaron caerán en B. Y sólo esas claves necesitarían ser movidas para ser otras claves no se verán afectadas. Por lo que el único vivió para mover d por n llaves. En cualquier caso, si agregamos o eliminamos un servidor de gash en particular. No para balanceo de carga. Como se discutió al principio, el verdadero líder se distribuye esencialmente al azar y por lo tanto puede no ser uniforme. Puede significar que los gansos en los cortes desequilibrados. Para manejar este tema, agregamos réplicas virtuales, guiones de financiamiento. En lugar de mapear cada caché a una sola varilla en durante el mapa ella a los múltiples puntos en el anillo. Eso son réplicas. De esta manera. Cada caché está asociado con múltiples porciones de contar. Podemos hacer esto teniendo múltiples hashes para los propios servidores de caché. A medida que el número de réplicas en Grecia, los gansos estarían más equilibrados. Para esto, podemos tener múltiples funciones hash para nuestros servidores gash y de manera similar para b y de manera similar para C. Pero al hacer esto, podemos lograr un gash equilibrado. 12. cola de mensaje: En este video, vamos a discutir sobre las colas de mensajes. Y lo hizo ventaja mientras diseñaba un sistema. Es una cola de mensajes. On MessageQueue es un componente del middleware de mensajería que permite que las aplicaciones y servicios independientes intercambien información. Colas de mensajes. Los mensajes almacenados son paquete de datos que la aplicación crea para que otra aplicación consuma en el orden en que se transmiten hasta que la aplicación consumidora pueda procesarlos. Esto permite que los mensajes esperen de forma segura hasta que la aplicación receptora es ese Eddy? Entonces si hay algún problema con la red o la aplicación receptora, los mensajes en la cola de mensajes o no perdidos. Esa cola de mensajes se utiliza para la asíncrona a la comunicación de la aplicación? No. ¿ Qué significa la comunicación asincrónica entre aplicaciones? Comunicación asíncrona significa aplicación cuando quiere enviar un mensaje m aplicación. Pero no requiere una respuesta inmediata para continuar con su procesamiento. Eso significa que la aplicación uno seguiría funcionando independientemente del mensaje M que reciba la solicitud a. La aplicación dos podría estar ocupada o podría estar desconectada. En la red. Se dispone de aplicación. Y de vuelta una respuesta a la aplicación cuando en la aplicación de mantenimiento uno puede realizar algún otro sésil crepúsculo. Entonces, ¿dónde almacenamos estos mensajes? Obviamente, no queremos que nuestro mensaje m se pierda. Ahora, aquí viene el mensaje va a un rescate. Las colas de mensajes proporcionan almacenamiento temporal. El programa de destino del proveedor está ocupado, lo que no está conectado. Ahora, el mejor ejemplo para la mensajería asíncrona es entonces que se envía un correo electrónico. El remitente puede seguir procesando otras cosas sin una respuesta inmediata del receptor. Entonces una herramienta de mensajes no es más que la agregación de mensajes Gautama y cola. El cola contiene una secuencia de mensajes enviados entre las aplicaciones están esperando su turno para ser procesados. Mensaje se complace en una Q. almacené hasta que el consumidor los crea. Enviar esa solicitud se llama el productor. Y la aplicación del receptor es Goldie consumidor. Que todo el productor es producir los mensajes. Y el papel del consumidor es consumir los mensajes. Mensajes que datos a enviar del productor al consumidor. Puede ser o una respuesta de solicitud. Mensaje. Las colas no procesan mensajes. Simplemente los almacena. Esta forma de manejar los mensajes desacopla al productor del consumidor. El productor y el consumidor del mensaje no necesitan interactuar con la cola de mensajes a la misma cosa. Ahora hablemos de las ventajas de Massachusetts. Las colas de mensajes son importantes porque ayudan a desacoplar las aplicaciones. O las aplicaciones se desacoplan. Si pueden comunicarse entre sí sin estar conectados. Además, ejecutar aplicación no es completamente consciente de la implementación de la otra aplicación. En otras palabras, no hay dependencia entre ellos. Ahora bien, la aplicación desacoplada, cualquier cambio hecho a una aplicación no afecta a la otra aplicación. En tanto no se infrinja el contrato de comunicación. Baliza rompe fácilmente la aplicación monolítica ven en aplicaciones más pequeñas. Vetted reduce la complejidad general. Se vuelve más fácil de mantener y las aplicaciones depuradoras pueden tener aplicación multiplataforma es más pequeña. Las aplicaciones pueden desarrollarse de forma independiente en cualquier lenguaje de programación y escalarse en consecuencia. Eso significa que las aplicaciones podrían ser agnósticas del lenguaje de programación. Ajusta las colas de mensajes. Ded es un aumento en el pasivo y el desempeño de un sistema. Los productores no tienen que esperar a que los consumidores estén disponibles. Nuevamente, simplemente agregue solicitudes en la cola. Los consumidores pueden procesar los mensajes siempre que estén disponibles. Y eso simplemente no es sobrecarga en la lectura. El mensaje va. Mensajes de fotosistema. Incluso si las diferentes empresas de aplicaciones que vieron tus datos se perderán y el sistema se vuelve más tolerante a fallas. 13. CDN: Hola y bienvenidos al video en red de entrega de contenidos, o popularmente conocido como las Redes CDN. Una red de distribución de contenido o CDN es una red distribuida globalmente de servidores web. Puntos de presencia impares cuyo propósito es proporcionar una entrega de contenido más rápida. Ahora primero, hablemos de los beneficios de Simeón. El contenido se replica y almacena a lo largo de la temporada. Por lo que el usuario puede acceder a los datos que se almacenan en la ubicación que se encuentra geográficamente más cercana a él. Esto es diferente y más eficiente que el método tradicional de almacenar contenido en un solo servidor central. Ya que evita el cuello de botella en ese servidor y proporciona una alta velocidad de carga de contenido. Entonces ahora veamos cómo funciona Internet con y sin CDN. En caso de que denotemos tener una red CPM. Todas las solicitudes de nuestros usuarios están siendo atendidas por el contenido proporcionado. Pero en caso de que tengamos una red cd entre el ContentProvider y nuestros usuarios. El contenido es servido por la CDN en lugar de lo proporcionado. Esto evita posibles cuellos de botella. Por ejemplo, el contenido proporcionado. Dado que la red de CD está distribuida globalmente, declinado accede a una copia de los datos cerca de sí mismo, en contraposición a que todos declinaron acceder al mismo servidor central. Esto es en alta velocidad de carga de contenido, mejorando así la experiencia del usuario. Si todos los datos se encuentran en el servidor central, la experiencia del usuario se ve afectada negativamente por una velocidad de carga limitada. Cuanto mayor sea la distancia entre el usuario y el servidor, más tiempo tardará el contenido en leer cualquiera de la planta. Por decirlo de manera más sencilla. El propósito de un CDN es mejorar la experiencia del usuario y proporcionar una utilización de red más eficiente. Un ejemplo perfecto de siembra es Netflix. Fuente de Netflix, todos sus datos en esta red. Entonces cada vez que empiezas a reproducir un video, Vamos a ver, Netflix lo tiene Silvers con sede en EU. Y vamos a ver, si estás decidiendo en India, sin coelom, Netflix tendría que traer todos los datos de ella, nosotros servidores a ti aquí en India. Esto habría dado como resultado supresiones de números para amortiguar el video. Pero nunca notas una falta vital viendo tu video porque el contenido está almacenado en redes CDMA. Tú como usuario en India, estás accediendo al contenido de esta red en su lugar, vítreo, geográficamente mucho más cerca de ti. De ahí que resulte en una mejor experiencia de usuario y también esperar a acelerar los servidores de Netflix. En EU. Proveedores de contenido, como empresas de medios y vendedores de comercio electrónico, bcb y operadores para entregar sí punto final. ¿ A quién le hizo Audiencia? Y hecho un ISPs, transportistas, y operadores de red de un CBGB para hospedar centros en sus centros de datos. Existen dos mecanismos clave que explican cómo funciona la CDN. En primer lugar, mantener contenido importante distribuido a múltiples centros de datos distribuidos globalmente. Por lo que está más cerca del usuario final y por lo tanto más rápido de descargar. Y en segundo lugar, lo configuras optimizaciones basadas en el tipo de contenido para obtener el contenido al usuario de la manera más eficiente. Esto significa que si estás almacenando en buffer los videos en tu smartphone, es responsabilidad de la CDN proporcionarte sólo la versión SD del video. Si estás poniendo el video en tu laptop, audio, incluso te proporcionaría video de resolución HD. Esto desierta en una mejor optimización de redes. Como no necesitas un video iterativo, habrá buffered en tu smartphone. Por lo que este v, un CDN descarga el auto gráfico directamente del ContentProvider, resultando así en posibles goslings. La ubicación es clave para la velocidad de entrega de contenido. Cuanto más lejos esté el usuario del programa de estudios en el que se almacenan los datos, más tiempo tardará el contenido en llegar al usuario. Y esto intenso afecta negativamente la experiencia del usuario. Y deducir el CB1 resuelve este problema y proporciona al usuario una experiencia de usuario mucho mejor.