Noo SQL Aplicado, Planteando el Problema

Clase 59 de 63 • Fundamentos de Bases de Datos 2017

Andric Alejandro Vargas Alarcón

student•

Conceptos en esta clase :

Sharding: Son Paquetes o módulos que tienen pequeños partes de la bd o replicas, que permiten añidr mas shard a fin de poder escalar,

Los shards se manejan con llaves hash y llaves compartidas de un nodo maestro. (se estila muchos nodos).

El nodo maestro se puede dividir en varios shards interno (s1, s2, s3)

en Mongo de DB : tambien se dividen en shards
S1 mongo1
S2 mondo2

Mongos : es el nodo central
Las conexiones se hacen mediante protocolo JPA, pero se conectan al nodo central no a los shards (S1, S2)

Existen mongo de de configuración para velar por la relación y tipo de trabajo entre los mongos y los shards

Ivan Robles

student•

Nice!! 👍

Iván Toro

student•

Buen resumen.

Jaime Diaz

student•

Hola @GOLLUM23, que tan cierto es de que la licencia de MySql no permite un uso tan libre por así decirlo como antes al momento de monetizar una idea (comercial)? habrá algún artículo en la carrera de bases de datos dedicado a esta parte de políticas de uso? (comercial, académico, etc);
Gracias de antemano.

Diego Forero

Team Platzi•

Para evitar ese tipo de problemas puedes usar MariaDB es un fork open source que no vas a tener problemas de licencias.

También puedes usar postgreSQL.

Este artículo te puede servir, es algo viejo pero explica bien https://www.xaprb.com/blog/2009/02/17/when-are-you-required-to-have-a-commercial-mysql-license/

Celso Espinoza

student•

Me agarras frío, no sabía de este tipo de problemas…
Buena pregunta.

AARON OBED GIRÓN GARRIDO

student•

RDBMS: Ofrece escalabilidad en una sola máquina, mejorando así los niveles de servicio de la base de datos.

Ventajas

Esquemas de Replicacion
Esquemas de Backup
Esquemas de Disaster Recovery

**Desventajas **

Crecimiento Limitado
Imposibilidad de de escalar varios sistemas en un mismo equipo

Cesar David Ramírez Dimaté

student•

Resumen del vídeo

Sharding:

Se crean pequeños módulos o paquetes que van a tener pequeñas partes de la base de datos o pequeñas réplicas.
Esto lo que hará es permitir unir otros shard a la base de datos y escalarlo más fácil.
Utiliza llaves dentro de los shard. Pueden ser tablas hash o llaves compartidas.
Las llaves compartidas generalmente se trabaja dentro del nodo maestro. Es reccomenable clusterizar el nodo maestro para tener varios por si el principal falla.
Los diferentes shard se van a comunicar con el nodo maestro, el cuál le va a dar toda la indexación. Va a tener las llaves maestras para que todos los shard funcionen en el mismo sistema.
En cada shard se pueden manejar registros o transacciones diferentes.
En una BD NoSQL no se crea una base de datos hasta que no se tenga toda la data cargada. Las colecciones están en un módulo de datos que a su vez está en una base de datos y que será distribuida.
Aparte de pensar en la consistencia de los datos se debe pensar también en una estrategia de redes y comunicaciones.
Los shards tienden a estar en máquinas separadas con puertos diferentes para que los módulos controladores puedan saber dónde están.
MongoDB se divide en Shards. Los shards se llaman Mongod. Las estructuras principales se llaman Mongos. Un cliente se conecta (por ejemplo) a través de un JPA a los Mongos. Los nodos de configuración define toda la estructura de la base de datos.

Diego Ramirez

student•

Gracias Cesar!

Wilson Marino Pablo Mendez

student•

Buen resumen

Osmandi Gomez

student•

¿PostgeSQL tiene la posibilidad de hacer escalamiento horizontal?

Diego Forero

Team Platzi•

Básicamente puedes hacer escalamiento horizontal con cualquier motor de base de datos, solo que la configuración de los motores de bases de datos no relacionales es un poco más complejo ya que tienes que tener los mismos datos en todas las instancias.

Puedes leer un poco más aquí https://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling

Osmandi Gomez

student•

Excelente, muchas gracias Diego

Smerlyn Javier Eusebio Bonifacio

student•

Carlos Zea

student•

muy interesante la clase para las aplicaciones de no-sql, y deberiamos profundizar un poco en el hardware que se necesita y la arquitectura de la base de datos como complemento.

CARLOS GUZMAN

student•

Si consideramos que el trabajar con una base de datos relacional, generalmente implica un escalamiento vertical, de que forma puedo especificar o dimensionar el hardware necesario para poder escribir 12.000 registros en hora pico, que papel juega la conexión a internet y como podría calcularse? Hay alguna metodologia clara que permita obtener esa especificación de requerimientos de hardware?.. Mil gracias por sus aportes.

Diego Forero

Team Platzi•

No conozco una metodología para este propósito, lo que debes hacer es tener medición del consumo de la base de datos y la cantidad de usuarios conectados en los momentos pico, esto te permite hacer una relación entre estos, recuerda que puedes tener usuarios visitando tu aplicación que solo están leyendo datos o puede existir momentos donde lean y escriban datos esto hace que el consumo de la base datos cambie, tienes que medir para poder decidir si tu servidor esta bien, esta muy justo o ya esta pequeño para la cantidad de tráfico.

CARLOS GUZMAN

student•

De antemano agradezco tu respuesta, efectivamente sigue siendo un tanto arriesgado suponer hardware sin alguna relación como base, sobre todo cuando no se ha experimentando rendimiento en otros escenarios para aquellos que empezamos. Me surge una duda, hay métodos que me permitan generar o simular trafico de lectura y escritura para test?

Emmanuel Octavio Martinez C

student•

¿Que pasa si tengo una máquina muy muy poderosa? ¿puedo hacer scale out haciendo maquinas virtuales en esa misma computadora o forzosamente tienen que ser físicamente otras?

Diego Forero

Team Platzi•

La opción que propones es una opción valida si no estas consumiendo todos los recursos puedes tener mejor maquinas mas pequeñas pero varias maquinas. Es lo que hace por ejemplo aws cuando creas instancias, no es que cada instancia sea un servidor, es una maquina que internamente tiene maquinas virtuales con los recursos asignados.

Jecsham Castillo

student•

Scale Out

Carlos Uriel de Jesus Sánchez González

student•

MySqlCluster
MongoDB
BD de formato distribuido para trabajar con grandes volumenes de información

BD verticales
RDBMS - escalabilidad vertical en una sola máquina
Mejores niveles de servicio a nivel de base de datos
Sin embargo es limitado su crecimiento

Sharding: Son Paquetes o módulos que tienen pequeños partes de la bd o replicas, que permiten añadir mas shard a fin de poder escalar,

Los shards se manejan con llaves hash y llaves compartidas de un nodo maestro. (se estila muchos nodos).

El nodo maestro se puede dividir en varios shards interno (s1, s2, s3)

MongoDB también se dividen en shards (mongoD).

Mongos son los nodos centrales

Las conexiones se hacen a los mongos a través del protocolo JPA no a los shards.

Nodos de configuración es donde se encuentra la estructura de la base de datos.

Alexander Silvera

student•

Conceptos en esta clase :

Sharding: Son Paquetes o módulos que tienen pequeños partes de la bd o replicas, que permiten añidr mas shard a fin de poder escalar,

Los shards se manejan con llaves hash y llaves compartidas de un nodo maestro. (se estila muchos nodos).

El nodo maes

Damian Spizzirri

student•

MySQL también puede utilizar shards? No entendi eso.

Edilson Fernando González Martínez

student•

El manejador como tal no lo tiene, tendrías que crear una aplicación encima de MySQL que administre cada shard y sepa cual escoger al momento de que se le soliciten datos en una consulta.

Germain Sánchez Matus

student•

Excelente expliación!

Diego Adrián Sánchez Gutiérrez

student•

sharts clusters Json JPA nodos de configuracion

Asahi Cantu Moreno

student•

Sharding, Hash, llaves, etc...

Kevin Andrés Cornejo Surichaqui

student•

Sharding

Yury D. Morales

student•

Estructura de una Base de Datos en MongoDB

Noo SQL Aplicado, Planteando el Problema

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