Aplicando noSQL: Integración de Comunicaciones y Hardware en una Base de Datos Scale OUT

Clase 61 de 63 • Fundamentos de Bases de Datos 2017

Walter Lopez

student•

Solo como aclaración en cuanto a las nomenclaturas de unidades de medición: las velocidades de transmisión de datos datos se miden en bits (1 o 0 y se escribe con b minúscula en su sigla) por segundo, mientras que la capacidad de almacenamiento de datos se mide en bytes (unidades de 8 bits con B mayúscula en su sigla), en el video al referirse al ancho de banda como 10 GB la unidad de medición está haciendo alusión a Gigabytes, o sea almacenamiento, cuando lo correcto debería ser 10 Gbps para referirse al bandwidth.

Esteban Mendoza

student•

Correcto…eso también me confundió a mi y pensé lo mismo.

Kevin Andrés Cornejo Surichaqui

student•

Andric Alejandro Vargas Alarcón

student•

Variables a considerar en la administración en NoSQL
N numero de Replicas , Numero de Nodos (en hadoop recomienda 3 replicas, o más)
W Numero de Replicas Exitosas para hacer Update (se debe esperar que sea 3 siempre y cuando tengas 3 nodos)
R Replicas. Para consultar para lectura, cuantos nodos debo consultar para saber que la info es consistente.

Formula
W+R>N : Para que sea consistente

Andric Alejandro Vargas Alarcón

student•

InfiniBand es un bus de comunicaciones serie de alta velocidad, baja latencia y de baja sobrecarga de CPU, diseñado tanto para conexiones internas como externas.

Juan Miguel Jimenez

student•

Latencia: es la suma de retardos temporales dentro de una red.

Augusto Jesus Muñoz Liñan

student•

Buena!

Zalo Testa

student•

Mis notas:

Tanto para infraestructura física como en la nube esto que trataremos aplica.
Para soluciones de disponibilidad y escalabilidad tendré que tener en cuenta las conexiones que tendré en mi base de datos.

En este caso tenemos 3 nodos del cluster,
Tenemos replicación de la información en más de un nodo. Si se me cae un nodo aún tendremos la información. Ahora si se nos caen 2 nodos allí si ya no tendré consistencia en los datos,
Para estos casos trabajamos con conexiones infiniband que manejan más de 10GB, esto nos asegura que entre nuestros nodos no haya mucha latencia.

Tener en cuenta que estos sistemas no funcionan como los grandes data centers ya que en ellos tenemos separado almacenamiento, memoria y almacenamiento en disco.

Otro tipo de estrategia es cuando trabajo con LAN, aquí lo que importa es la tolerancia a fallos. Tenemos los sistemas distribuidos en varios nodos pero no tendremos mucha consistencia en la información porque tendremos delay o demora en el tiempo. Trabajando con un sistema LAN no aseguro consistencia en los datos pero tengo tolerancia a fallos.

Otra forma es hacer la replicación de los nodos por lotes bach. En este caso no envío de a un dato o paquete sino que acumulo una serie de paquetes y hago un envío masivo.
Es muy útil cuando uno sabe cuándo se tienen los picos de procesamiento.
Estos lotes se trabajan incluso con bases de datos relacionales. Un ejemplo sería para hacer cierres bancarios, no todos los cierres se hacen en línea ya que se trabajan esos cierres en horarios no productivos 10pm a 2am y dejo ciertos procesos corriendo porque no tendré usuarios haciendo consultas sino que estaré ordenando toda la info para salir al otro día con toda la producción.

Tendremos 3 variables que nos van a orientar:

N-El número de réplicas que se tendrá en la cantidad de nodos que tiene la bd,
W-Réplicas exitosas para hacer update: deberían ser 3 como mínimo,
R-Réplicas a consultar para una lectura: ¿cuántos nodos consultaré para saber que es consistente mi información?

Para que yo tenga una información consistente se debe cumplir: W + R > N

Carlos Uriel de Jesus Sánchez González

student•

BD scale out
Conectividad es muy importante.
Replicación entre nodos para hacerlos sincronos, lo que nos permite tener disponibilidad de los datos, dando consistencia a la información. Dando tolerancia a fallos. Si falla un nodo se pierde tolerancia a fallos.
Depende mucho el tipo de infraestructura de red.
Las conexiones LAN son lentas con una gran numero de información debido a las problemas de ancho de banda, costos bajos y alta tolerancia a fallos.
Lotes Bach: envío de paquetes por lotes regularmente utilizado en procesos sin supervisión de usuarios y procesos de mantenimiento, o procesos muy largos que requiere que no haya muchas transacciones, reorganización de datos.

Recomendación de tener 3 replicas
N - numero de replicas (numero de nodos)
W - replicas exitosas para update
R - replicas a consultar para una lectura

W + R > N entonces es correcto

Eduardo Kiriakos Piazza

student•

Ejemplos de por qué pueden fallar los nodos?

Diego Forero

Team Platzi•

Un equipo en el datacenter pueden fallar, pueden existir problemas de conectividad entre los cluster.

Marco Aguilar

student•

Reinicios de servidor, fallas en la electricidad, mantenimiento, corrupción de la DB, fallas de lectura, servidor ocupado y muchos motivos más.

Daniel Cadavid

student•

 Aca vamos a tener tres variables:
N = número de réplicas. En plataformas como Hadoop se recomienda tener 3 réplicas de la información, en Blockchain no obligan a tener un número mínimo de replicas

W = Replicas exitosas para update se considera exitosa cuando se tienen 3 réplicas si se tienen 3 nodos

R = Replicas a consultar para una lectura se refiere a cuantos nodos puedo consultar para ver la información.

W + R > N para que la información sea consistente

 Solo como aclaración en cuanto a las nomenclaturas de unidades de medición: las velocidades de transmisión de datos datos se miden en bits (1 o 0 y se escribe con b minúscula en su sigla) por segundo, mientras que la capacidad de almacenamiento de datos se mide en bytes (unidades de 8 bits con B mayúscula en su sigla), en el video al referirse al ancho de banda como 10 GB la unidad de medición está haciendo alusión a Gigabytes, o sea almacenamiento, cuando lo correcto debería ser 10 Gbps para referirse al bandwidth.

 Si tenemos replicación de la información en 3 nodos. Si se me cae un nodo aún tendremos la información. Ahora si se nos caen 2 nodos allí si ya no tendremos consistencia en los datos.

Para estos casos trabajamos con conexiones infiniband que manejan más de 10GB, esto nos asegura que entre nuestros nodos no haya mucha latencia.

 Tener en cuenta que estos sistemas no funcionan como los grandes data centers ya que en ellos tenemos separado almacenamiento, memoria y almacenamiento en disco.

 Otro tipo de estrategia es cuando trabajo con LAN, aquí lo que importa es la tolerancia a fallos. Tenemos los sistemas distribuidos en varios nodos pero no tendremos mucha consistencia en la información porque tendremos delay o demora en el tiempo. Trabajando con un sistema LAN no aseguro consistencia en los datos pero tengo tolerancia a fallos.

 Otra forma es hacer la replicación de los nodos por lotes bach. En este caso no envío de a un dato o paquete sino que acumulo una serie de paquetes y hago un envío masivo.

Es muy útil cuando uno sabe cuándo se tienen los picos de procesamiento.

Estos lotes se trabajan incluso con bases de datos relacionales. Un ejemplo sería para hacer cierres bancarios, no todos los cierres se hacen en línea ya que se trabajan esos cierres en horarios no productivos 10pm a 2am y dejo ciertos procesos corriendo porque no tendré usuarios haciendo consultas sino que estaré ordenando toda la info para salir al otro día con toda la producción.

 Cuando voy a solucionar un tema de disponibilidad o escalabilidad tengo que tener en cuentas las conexiones que voy a tener dentro de mi Base de Datos.

Una base de datos relacional es muy eficiente haciendo consultas estructuradas es muy ágil haciendo consultas. Sin embargo, cuando se trabaja en bases de datos distribuidas puede que el desempeño caiga si no se tiene en cuenta la conectividad.

Daniel Quispe

student•

blockchain es un sistema de registros, no una base de datos tradicional

Edgar Tasayco

student•

Excelente información Pedro.

Iván Toro

student•

Estos problemas se presentan en todo esquema de clusterización.

Nazareno Taibo

student•

No entendí muy bien la variable “W” “replicas exitosas para update”, alguien me lo puede aclarar?

Javier Alejandro Alamar Martínez

student•

Por lo que entendí, se refiere a que cuando actualizamos un dato, las replicas deben ser 3 ¿por qué? Explicaré el mismo ejemplo pero un poco mas entendible. Suponiendo que tenemos dos nodos los cuales contienen las letras “A” y “A” , entonces queremos actualizar ambas “A” por la letra “B”. entonces, ¿que pasaría si alguna de las actualizaciones no se hace correctamente? tendrías “A” y “B” entonces con 2 replicas no tendrías manera de saber si la actualización se hizo bien, es por eso que se necesitan 3, para que así, si dos fallan significa que no se actualizo, si dos están bien significa que se actualizo.
velo como el tipico “2 de 3” jejeje, espero no haberte confundido más 😦

Cristian Orozco Benjumea

student•

Cuando voy a solucionar un tema de disponibilidad o escalabilidad tengo que tener en cuentas las conexiones que voy a tener dentro de mi Base de Datos.
Una base de datos relacional es muy eficiente haciendo consultas estructuradas es muy ágil haciendo consultas. Sin embargo, cuando se trabaja en bases de datos distribuidas puede que el desempeño caiga si no se tiene en cuenta la conectividad.

Diego Adrián Sánchez Gutiérrez

student•

N numero de replicas W replicas exitosas para update R replicas a consultar para una lectura

Kevin Andrés Cornejo Surichaqui

student•

Conexiones Infiniband

Efren Almanza Lamas

student•

(Numero de Replicas +Numero de Replicas a Consultar)>Numero de Replicas, se podría decir que tenemos una informacion consistente

Aplicando noSQL: Integración de Comunicaciones y Hardware en una Base de Datos Scale OUT

Introducción al Curso Fundamentos de Bases de Datos

¡Vamos a renovar este curso!

Introducción al Curso de Bases de Datos

Teoría general de Bases de Datos

Propósito general de las Bases de Datos

Tipos de Bases de Datos y sus aplicaciones en la industria

Visión general de los datos

Tipos de Datos

Diferentes tipos de Bases de Datos

Reto ¿Hadoop y Blockchain podrían cambiar una Base de Datos tradicional?

Bases de Datos Relacionales

¿Qué es una Entidad?

¿Qué es una Relación?

Características o datos de una Entidad

¿Ya aparecieron las llaves?

Índices e Indexación

Constraints o Restricciones

Capas de abstracción del modelo Entidad-Relación

Metodología básica de 9 pasos con Barker (Paso 1) Identificar Cuáles son las Entidades Resuelven Nuestro Problema

Metodología básica de 9 pasos con Barker (Paso 2): Identificación de las Relaciones de las Entidades.

Metodología básica de 9 pasos con Barker (Paso 3): Entidades y Relaciones

Metodología de Diseño (Correcciónes del paso 2 y 3)

Metodología de Diseño (Paso 4): Asignar Atributos a las Entidades.

Metodología de Diseño (Solución del paso 4): Terminando de Asignar Atributos a las Entidades

Metodología de Diseño (Pasos 5, 6 y 7) 5. Generar un diagrama conceptual, 6. Modelo lógico, 7. Identificar nuevos atributos que generan nuestras entidades débiles.

Metodología de Diseño (Paso 8): Construir el Diagrama del Modelo Físico

Metodología de Diseño (Paso 9): Pasar al estándar de la base de datos (SQL)

Reto con el paso 4 de la Metodología de Diseño

Bases de Datos NO Relacionales y Otros tipos de Bases de Datos

Atomicidad y consistencia

Aislamiento y durabilidad

Bases de Datos In-Memory (Cambio de árboles a columnar)

Otros tipos de Bases de Datos en la industria

Bases de Datos In-Memory con indexación de columnar

Definiendo el Proyecto y Generando Entidades de PlatziStore: Pasos 1 y 2

Definir la Estructura de la Tabla Cliente del Proyecto: Pasos 3 y 4

Terminando de Estructurar Nuestras Tablas (Continuación del paso 4)

Metodología de Diseño (Paso 5): Diagrama Conceptual

Metodología de Diseño (Paso 6 y 7): Modelo Lógico y Entidades Débiles

Solución de atributos de entidad del proyecto - Atributos adicionales a entidad débil creada

Metodología de Diseño (Paso 8)

Llevando nuestro proyecto a SQL (Paso 9)

Terminando la Implementación del Proyecto (Paso 9)

Dependencias funcionales

Normalización, llevando el proyecto hasta tercera forma normal (primera forma normal)

Normalización, llevando mi proyecto hasta tercera forma normal (segunda forma normal)

Normalización, llevando mi proyecto hasta tercera forma normal (Cuarta y quinta forma normal)

Comenzando con SQL

DDL: Data Definition Language y DML: Data Manipulation Language

ACID desde lo no relacional

CAP

Scale Out y Scale Up

¿Scale out o Scale up?

DBMS en nube para poder iniciar una aplicación propia

IMPORTANTE: Preparación del entorno de trabajo

Estructura básica de un Query

Aprendiendo a Hacer más Querys

Estructura básica del Query con más de una tabla

Estructura básica del Query con más de una tabla 2

Tuplas y más tuplas

Insertar registros

Joins

Noo SQL Aplicado, Planteando el Problema

Aplicando NoSQL: Colecciones y Shards

Aplicando noSQL: Integración de Comunicaciones y Hardware en una Base de Datos Scale OUT

Aplicando noSQL: Integrando JSON a Bases de Datos No Relacionales

Conclusiones del curso