Bd no sql conceptos basicos
2 recomendaciones1,197 vistas
Este documento presenta conceptos básicos sobre bases de datos NoSQL. Explica el movimiento NoSQL y cómo surgió para satisfacer las necesidades de escalabilidad de aplicaciones con grandes volúmenes de datos. También introduce el Teorema CAP, que establece que un sistema distribuido solo puede proporcionar dos de las siguientes tres propiedades: consistencia, disponibilidad y tolerancia a particiones. Además, contrasta las propiedades ACID de las bases de datos relacionales con las propiedades BASE más flexibles de las bases de datos NoSQL.
Bd no sql conceptos basicos
- 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 1970 1980 1990 2000 2010 Nace el modelo relacional Se desarrolla Oracle Se desarrolla SQL
- 4. Movimiento NoSQL Historia 1970 1980 1990 2000 2010 Nacen las BD OO Dominan las BD Relacionales
- 5. Modelo relacional Ventajas Persistencia Integración SQL como estándar Transacciones ACID Reportes
- 6. Movimiento NoSQL ¿Qué paso en el 2000? Internet Aplicaciones Redes Sociales Youtube Emails Motores de búsqueda Otros Alto tráfico de datos
- 7. Movimiento NoSQL Aumentar la capacidad de los servidores
- 8. Movimiento NoSQL Aumentar la cantidad de servidores
- 10. Movimiento NoSQL Historia 1970 1980 1990 2000 2010 Big Table DynamoDB 2006 2007
- 11. Movimiento NoSQL Historia 1970 1980 1990 2000 2010 Johan Oskarsson El nombre para la primera reunión de bases de datos distribuidas de código abierto #nosql
- 12. 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.
- 13. 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
- 14. Agenda Movimiento NoSQL Conceptos básicos Teorema de Brewer (CAP) Propiedades BASE BASE vs ACID Escalabilidad Fragmentación Replicación
- 15. Teorema de Brewer Con la llegada de internet surgió la importancia de la disponibilidad (availability) en sistemas distribuidos 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
- 16. Teorema de Brewer Consistencia: 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. Escritor X=5 Lector X=5
- 17. 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í.
- 18. Teorema de Brewer Propuesto en el simposio de “Principios de Computación Distribuida” de ACM en el 2000 por Eric Brewer como una conjetura. 18 Los servicios distribuidos no pueden asegurar en forma conjunta las siguientes propiedades: Consistencia (C) Disponibilidad (A) Tolerancia a Particiones (P)
- 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 Conclusión 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 • Cada solicitud garantiza una respuesta, bien sea correcta o no. Básicamente disponible (BA, Basically Available): • El estado del sistema puede cambiar con el tiempo, a veces sin una entrada (por consistencia eventual). Estado flexible (S, Soft state): • La base de datos puede estar momentáneamente inconsistente pero será consistente con el tiempo. Eventualmente consistente (E, Eventually consistence): 25
- 26. ACID vs BASE ACID -> CONSISTENCIA ◦ Pesimistas ◦ Consistencia estricta ◦ Aislamiento ◦ Centrada en el commit ◦ Sacrifica la disponibilidad BASE -> DISPONIBILIDAD ◦ 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. Escalabilidad en un sistema informático 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 Sistemas distribuidos Distribución de datos Fragmentación Replicación Paradigma Map-Reduce
Notas del editor
- #24: En un sistema CP, para garantizar la consistencia debemos asegurarnos que la operación se realiza en los 3 nodos al mismo tiempo. Como el sistema se ha particionado (y sigue vivo ya que toleramos las particiones), si la petición se procesa por el nodo {C} será imposible replicarla en los nodos {A, B}. Ante esta situación, el nodo {C} deberá rechazar la escritura hasta que se deshaga la partición (ya que no podría garantizar consistencia), lo que da lugar a indisponibilidad. En un sistema AP, nos importa más la disponibilidad, por lo que aunque haya una partición del sistema, la petición se procesará igualmente. En este caso, el sistema no nos puede garantizar la consistencia, ya que no sabe si la información procesada por un nodo (por ejemplo, {C}) ha sido replicada al resto de nodos ({A, B}). En el caso de un sistema CA, el tema se complica un poco más. Si el sistema no está particionado, cualquier operación se procesará y replicará al resto de nodos. Ahora bien, si el sistema se particiona, entonces el sistema debería fallar, ya que no podremos garantizar la consistencia de la operación, y si falla, entonces no podemos garantizar disponibilidad, por lo que estaríamos delante del mismo caso que un sistema CP. Resumiendo, que este tipo de sistema es bastante improbable, ya que para que funcione es necesario que la comunicación entre nodos siempre esté en perfecto estado (improbable), o en su defecto, tolerar las particiones como en un sistema CP.