Bd NoSQL Conceptos Básicos PROFA. MERCY twitter.

Presentación del tema: "Bd NoSQL Conceptos Básicos PROFA. MERCY twitter."— Transcripción de la presentación:

1 Bd NoSQL Conceptos Básicos PROFA. MERCY OSPINA mercy.ospinat@gmail.com @abducv twitter

2 Agenda Movimiento NoSQL Conceptos básicos Teorema de Brewer (CAP) Propiedades BASE BASE vs ACID Escalabilidad Fragmentación Replicación

3 Movimiento NoSQL Historia 19701980199020002010 Nace el modelo relacional Se desarrolla Oracle Se desarrolla SQL

4 Modelo relacional Ventajas Persistencia Integración SQL como estándar Transacciones ACID Reportes

5 Modelo Relacional Desajuste de Impedancia

6 Movimiento NoSQL Historia 19701980199020002010 Nacen las BD OO Dominan las BD Relacionales

7 Movimiento NoSQL Aplicaciones en Internet con alto tráfico de datos Redes SocialesYoutubeEmails Motores de búsqueda

8 Movimiento NoSQL Aumentar la capacidad de los servidores

9 Movimiento NoSQL Aumentar la cantidad de servidores

10 Movimiento NoSQL Relacional

11 Movimiento NoSQL Historia 19701980199020002010 Big Table DynamoDB 2006 2007

12 Movimiento NoSQL Historia 19701980199020002010 Johan Oskarsson El nombre para la primera reunión de bases de datos distribuidas de código abierto #nosql

13 Movimiento NoSQL Una total negación de los RDBMS y el fin de dichos sistemas ¿? No relacional, no Acid, no Join Michael Stonebraker Not Only SQL: sistemas de almacenamiento que no sigue el modelo relacional y que busca resolver problemas de escalabilidad Científico especializado en la base de datos de investigación y desarrollo. Su carrera abarca, y ayudó a crear, la mayoría de la base de datos relacionales del mercado existente hoy en día.

14 Movimiento NoSQL No es un solo producto o una sola tecnología Ha habido el miedo de que sea una moda No existen estándares A pesar de ser muy reciente usa técnicas ampliamente probadas

15 Agenda Movimiento NoSQL Conceptos básicos Teorema de Brewer (CAP) Propiedades BASE BASE vs ACID Escalabilidad Fragmentación Replicación

16 Teorema de Brewer Propuesto en el simposio de “Principios de Computación Distribuida” de ACM en el 2000 por Eric Brewer. Conjetura Los servicios web no pueden asegurar en forma conjunta las siguientes propiedades:  Consistencia (Consistence C)  Disponibilidad (Availability A)  Tolerancia a particiones (Partition Tolerance P)

17 Teorema de Brewer  Consistencia: Un sistema distribuido es generalmente considerado consistente si después de una operación de actualización de algún escritor todos los lectores ven esa actualización de alguna fuente de datos compartida.  Disponibilidad: Cada petición recibida por un nodo activo debe dar por lugar una respuesta. Aunque se produzcan fallos en la red cada solicitud debe terminar

18 Teorema de Brewer  Tolerancia a partición: se entiende como la capacidad del sistema para continuar la operación en presencia de particiones de red.  Esto ocurre si dos o más "islas" de nodos surgen en la red (temporal o permanente) las cuales no pueden conectarse entre sí.

19 Teorema de Brewer  En el año 2002, Seth Gilbert y Nancy Lynch de MIT publicaron una demostración formal de la conjetura de Brewer, convirtiéndola en un teorema  Aunque esta demostración ha sido criticada, el teorema ha sido adoptado por compañías como Amazon y Facebook y por la comunidad de NoSQL. ¿Cuál es la confusión?

20 Entendiendo la tolerancia a particiones – confusión Gilbert y Lynch definen la tolerancia a partición como sigue: “The network will be allowed to lose arbitrarily many messages sent from one node to another” Es decir, no es una propiedad de la aplicación distribuida sino de la red donde se ejecuta. Entonces no es algo que podamos escojer cuando se diseña el sistema. Si se presenta una partición Consistencia: se permiten actualizaciones a ambos lados de la partición Disponibilidad: se detecta el error y se cierra el sistema hasta que sea resuelto se pierde

21 Entendiendo la tolerancia a particiones Esta es la gran enseñanza del teorema de CAP: Si se tiene una red donde se pueden perder mensajes Entonces No se pueden tener ambas propiedades, Disponibilidad y Consistencia, se debe elegir una. http://blog.cloudera.com/blog/2010/04/cap-confusion-problems-with- partition-tolerance/

22 Teorema de Brewer Algunos diseñadores concluyen incorrectamente que el teorema impone restricciones en los sistemas de bases de datos durante su normal funcionamiento y por lo tanto implementan los sistemas innecesariamente limitados.

23 Teorema de Brewer AP: el sistema siempre responderá A aunque se pierda la comunicación entre nodos P. Los datos procesados pueden no ser consistentes C. CA: el sistema siempre responderá A y los datos procesados serán consistentes C. No se considera la perdida de comunicación entre nodos P. CP: el sistema ejecutará las operaciones de forma consistente C, aunque se pierda la comunicación entre nodos P, pero no se asegura que el sistema responda A. http://www.rodenas.org/ferdyblog/2011/02/25/el-teorema-de-cap/

24 Propiedades ACID en SMBDR Distribuidos Atomicidad Consistencia aIslamiento Durabilidad ¿Qué pasa con la tolerancia a particiones? 2-Phase commit protocol

25 Propiedades BASE ACID -> Consistencia BASE -> Disponibilidad ◦Básicamente disponible (BA, Basically Available): Cada solicitud garantiza una respuesta, bien sea correcta o no. ◦Estado flexible (S, Soft state): El estado del sistema puede cambiar con el tiempo, a veces sin una entrada (por consistencia eventual). ◦Eventualmente consistente (E, Eventually consistence): La base de datos puede estar momentáneamente inconsistente pero será consistente con el tiempo.

26 ACID vs BASE ACID ◦Pesimistas ◦Consistencia estricta ◦Aislamiento ◦Centrada en el commit ◦Sacrifica la disponibilidad BASE ◦Optimistas ◦Consistencia débil o eventual ◦Disponibilidad primero ◦Mejor esfuerzo ◦Respuestas aproximadas ◦Permite mayores niveles de escalabilidad http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf

27 Escalabilidad Define la manera en que un sistema o plataforma puede crecer para aumentar su capacidad de dar servicio al negocio El análisis de escalabilidad es el resultado del estudio de la escalabilidad de los distintos componentes y sus relaciones Existen dos formas en que un componente puede escalar

28 Escalabilidad

29 Escalabilidad horizontal Es la cualidad que tiene un componente de cooperar con componentes de su misma naturaleza y de esta manera incrementar el rendimiento de la tarea que se está realizando. ¿Cómo se mide?

30 Escalabilidad horizontal Por lo tanto es fundamental conocer los límites del escalado horizontal de un componente para evitar una degradación de la capacidad

31 Escalabilidad en un sistema informático Capacidad para crecer sin perder calidad en los servicios ofrecidos. Suficiencia de dicho sistema informático de variar su tamaño, características y capacidad de servicios para adaptarse a una nueva situación.

32 Escalabilidad en un sistema informático

33 Se basa en poder distribuir el trabajo entre los componentes La función de distribución la realiza el Balanceador que arbitra el reparto de la carga entre los componentes cooperantes El principal problema es estimar cuánta carga deberá soportar el sistema para evitar la degradación HORIZONTAL

34 Próxima Clase Clúster Fragmentación Replicación Paradigma Map-Reduce