CAP

Clase 47 de 63 • Fundamentos de Bases de Datos 2017

Kevin Morales

student•

Consistency = Consistencia: Debe retornar un dato válido, me debe permitir a cualquier estructura de su base de datos
Availability = Disponibilidad: Cuando haga una solicitud no me va a importar que nodo del sistema esta up time o down time o sin funcionamiento. Un dato debe estar replicado en al menos tres nodos.
Partition = Particionamiento: Es como yo parto esa información por lo menos en tres nodos para evitar que se pierdan mensajes.

Yesica Lizeth Cortés Pineda

teacher•

Hola @iKenshu gracias por este resumen de la clase.

Cesar Octavio de Jesus Meza Carrillo

student•

Excelente resumen, Gracias

Cristyan Quintero Múnera

student•

Las bases de datos NoSQL están pensadas para ser escalables y distribuidas. Por ser distribuidas tendremos que tener en cuenta el teorema CAP.

El teorema CAP, dice que en sistemas distribuidos es imposible garantizar a la vez: Consistencia, Disponibilidad y Particionamiento.

Para ser escalables y distribuidas, las bases de datos NoSQL, siguen distintos métodos, por lo que no todas cumplen los mismos puntos del teorema CAP.

Según las condiciones que cumplan se pueden tener:

AP: garantizan Disponibilidad y Particionamiento, pero no la consistencia, al menos de forma total. Algunas de ellas consiguen una consistencia parcial a través de la replicación y la verificación.
CP: garantizan Consistencia y Particionamiento. Para lograr la consistencia y replicar los datos a través de los nodos, sacrifican la disponibilidad.
CA: garantizan Consistencia y Disponibilidad, pero tienen problemas con la tolerancia a particiones. Este problema lo suelen gestionar replicando los datos.

Ricardo Celis

teacher•

Hola Cristian! excelente resumen de la clase =)!

Iván Toro

student•

Buen resumen.

Daniel Eduardo Portugal Revilla

student•

Danny Richard Castillo Lozano

student•

Buen aporte, gracias

Ludwing Juan Homero Pérez Tzaquitzal

student•

Muchas gracias por la imagen, es muy ilustrativa.

Saludos!

Diego Forero

Team Platzi•

Particionamiento -> Tolerancia a Fallas

Jhon Fredy Beltrán León

student•

7:11 Wuhuuuuuu :v

Diego Forero

Team Platzi•

Fue un problema con el micrófono por el movimiento que hizo el profesor.

Irma Davila

student•

naaaaa

Andric Alejandro Vargas Alarcón

student•

Mensaje Valioso : “…Acá no tenemos límite de crecimiento, estas base de datos están hechas para que ustedes piensen en grande y puedan ejecutar proyectos aún más grandes”

Daniel Cadavid

student•

 Las bases de datos NoSQL están pensadas para ser escalables y distribuidas. Por ser distribuidas tendremos que tener en cuenta el Teorema CAP

 El teorema CAP se divide en:
Consistency: consistencia
Availability: disponibilidad
Partition: Particionamiento

 Consistencia: Al hacer una consulta en un nodo me devuelva un dato valido, se ve en la unión del trabajo de varios desarrolladores por medio de un merge. Consistencia permite que yo pregunte a un nodo maestro y el me entregue la información (si está disponible), no tengo que pasar preguntándole a cada nodo si tiene la información.

 Disponibilidad: Al hacer una consulta los nodos estén up time y arrojen datos, si un nodo esta down time o fallando la información de este debe estar respaldada por otro nodo, ejemplo el check y doble check de wp, cada uno es un nodo con copia de la información. Disponibilidad permite que siempre haya por lo menos un nodo que responda (por lo general un nodo maestro)

 Particionamiento: dividir y replicar la información en diferentes nodos para evitar que se pierda información. Particionamiento permite replicar la información en dos o más nodos para asegurar que la información pueda estar disponible ante fallas de alguno de los nodos. Hace que existan datos en nodos DownTime y en UpTime. Las fallas de comunicación son normales, con esto se soluciona el problema.

 No es posible cumplir las tres partes de CAP pero es posible que se pueda ejecutar varias combinaciones:
AP: garantizan Disponibilidad y Particionamiento, pero no la consistencia, al menos de forma total. Algunas de ellas consiguen una consistencia parcial a través de la replicación y la verificación.
CP: garantizan Consistencia y Particionamiento. Para lograr la consistencia y replicar los datos a través de los nodos, sacrifican la disponibilidad.
CA: garantizan Consistencia y Disponibilidad, pero tienen problemas con la tolerancia a particiones. Este problema lo suelen gestionar replicando los datos.

Joaquin Araujo

student•

Una vez me pareció escuchar a Freddy decir que no metieramos imagenes en una base de datos ¿que tan cierto es?

Diego Forero

Team Platzi•

No es una buena practica guardar imágenes o en general cualquier tipo de archivo en la base de datos, lo mejor es guardar el archivo usando el File System del servidor y en la base de datos guardar la ruta donde esta el archivo.

Joaquin Araujo

student•

Pero Pedro dice para guardar una imagen en la db…

Jaime Santamarta Martín

student•

C.A.P. : Consistency, Availability, Partition.
La mayoria de los sistemas NoSQL se basan en dividir la transacción en varios nodos.
No es necesario hardware caro para escalar, pudiendo utilizar BBDD en la nube.
Son muy buenas para trabajar imágenes o vídeos. (No es la mejor practica para BBDD)

Consistencia: Debe retornar un dato válido haciendo una petición a cualquiera de los nodos, debe permitir llegar a cualquier estructura de la base de datos.

Disponibilidad: En el momento de realizar la solicitud, los nodos en up-time se deben encargar responder aunque haya nodos en down-time(Desconectados). Se respeta la regla de mantener el dato, al menos, en 3 nodos.

Particionamiento: Se reparte la información de la base de datos replicandola en diversos nodos, evitando los fallos en la comunicación.

No es posible cumplir con las tres partes del CAP, pero si ir ejecutando diversas combinaciones. CA ,CP, AP.

CA: Consistencia con Disponibilidad.
Si no tenemos Particionamiento tendremos un sistema unificado sin replicación en nodos. Se utiliza la duplicación de la base de datos, pero no tendrian comunicación

CP: Consistencia con Particionamiento.
Tendremos un sistema que podría no estar disponible en un determinado momento
Se trabajarian colas de espera o mensajeria
AP: Disponibilidad con particionamiento.
Si tuvieramos varios nodos y varios desarrolladores están trabajando en el mismo archivo al terminar el día es necesario mezclar las distintas versiones del mismo, pudiendo quedar inconsistente.

Efren Almanza Lamas

student•

El teorema CAP, también llamado Conjetura de Brewer, enuncia que es imposible para un sistema de cómputo distribuido garantizar simultáneamente:1

La consistencia (Consistency), es decir, que todos los nodos vean la misma información al mismo tiempo.
La disponibilidad (Availability), es decir, la garantía de que cada petición a un nodo reciba una confirmación de si ha sido o no resuelta satisfactoriamente.
La tolerancia al particionado (Partition Tolerance), es decir, el sistema sigue funcionado incluso si algunos nodos fallan.
Según el teorema, un sistema puede tener no más de dos de estas tres características simultáneamente.

Ejemplos

AP: Cassandra y CouchDB.

CP: MongoDB y Paxos.

CA: RDBMS.

Luis Alberto Velez Tascon

student•

Marcos Sebastián Imfeld

student•

muy buena clase!!

Jenny Karen Guzmán Pulido

student•

Commits: Paquete de mensaje que emite un mensaje y espera recibir respuesta.

Julian Andres Builes Cajiao

student•

Las tres posibles combinaciones del teorema CAP (No siempre se van a poder cumplir las 3)

CA: se va ha trabajar en un sistema que solo va ha crecer en sí y no va ha tener Nodos del mismo sistema y que le permita trabajar en paralelo
CP: No se va ha tener la mejor disponibilidad
AP: No se va ha tener consistencia, se puede implementar el commit a dos faces

Ricardo Celis

teacher•

Excelente apunte Juancho! no olvides terminar el curso y presentar el examen!

Smerlyn Javier Eusebio Bonifacio

student•

DIVIDE Y VENCERÁS

Liliana Colls

student•

Comparto estos articulos para complementar la clase: https://www.swapbytes.com/teorema-cap-base-datos/ y https://www.genbetadev.com/bases-de-datos/nosql-clasificacion-de-las-bases-de-datos-segun-el-teorema-cap

Enrique Quimbayo Corredor

student•

los nodos de una base de datos no sql trabajan en sistema de estrella

Nasly Gordillo

student•

recordemos que hay tres posibles combinaciones, (no podemos cumplir siempre las 3)

/ / / CA CP AP consistencia consistencia disponibilidad disponibilidad particionamiento particionamiento

se debe ver que necesita nuestra base de datos

Marco Elizalde

student•

Que pasa sino tenemos consistencia?

Carlos Eduardo Repillosa Del Valle

student•

Que al momento de consultar la información en alguno de los nodos nos de información desfasada del resto o datos diferentes a los que se encuentran en los otros nodos.

Jasan Azael Hernández Bautista

student•

CAP: Consistency, Availability, Partition

Consitencia (consistency):
Cuando yo espero consistencia lo que espero es que yo pueda hacer una consulta a cualquiera de los nodos y me retorne un dato valido o que se correcto, o que por lo menos me entregue la ultima información que yo estaba esperando, por lo tanto la consistencia espera que yo no necesite preguntarle a cada uno de los nodos, si no que pueda preguntarle a este inclusive si la data que estoy buscando esta acá, los nodos y la estrategia de los nodos NO-SQL me debe permitir llegar a cualquier estructura de la bases de datos, así la data este distribuida como es el caso de este ejemplo.
Disponibilidad (Availability):
Cuando haga una solicitud no me va importar que nodos del sistema están up-time o down-time, puedo tener nodos down-time que no estén funcionando sin embargo, el conjunto de nodos que están funcionando dentro de mi arreglo de nodos me debe responder, un dato debe estar replicado por lo menos en tres nodos. Independientemente si mis nodos están arriba o están abajo me deben de dar una respuesta.
Particionamiento (Partition):
Esta palabra se va a parecer un poco a disponibilidad, porque básicamente el particionamiento es como yo parto esa información o esa estructura de datos por lo menos en 3 nodos, para evitar que se pierdan mensajes o no sean entregados. Esto soluciona que halla nodos en down-time, y que sin embargo yo pueda dividir un dato que estaba pasando acá que fuera a y que fuera a y lo tengo en un tercer nodo, cuando yo hago esto estoy teniendo tolerancia a esas fallas de comunicación.
que yo pueda tener varios nodos compartiendo la misma información para evitar fallas de comunicación.

CAP

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