Cesar Hernández Rafael Machado Sandra Jiménez

Presentación del tema: "Cesar Hernández Rafael Machado Sandra Jiménez"— Transcripción de la presentación:

1 Cesar Hernández Rafael Machado Sandra Jiménez
Universidad Central de Venezuela Facultad de Ciencias Escuela de Computación Administración de Bases de Datos Bases de Datos No SQL Cesar Hernández Rafael Machado Sandra Jiménez

2 Agenda Sistema Relacional y SQL ¿Qué es NoSQL? . Origen
Características de NoSQL Tipos de Base de Datos NoSQL Arquitectura y Funcionamiento Usuarios y Aplicaciones Ventajas y Desventajas 2

3 Sistema Relacional El modelo relacional para la gestión de una base de datos es un modelo de datos basado en la lógica de predicados y en la teoría de conjuntos. Es el modelo más utilizado en la actualidad para modelar problemas reales y administrar datos dinámicamente. Tras ser postuladas sus bases en 1970 por Edgar Frank Codd, de los laboratorios IBM en San José (California), no tardó en consolidarse como un nuevo paradigma en los modelos de base de datos. 3

4 Caracteristicas del Sistema Relacional
Codd perseguía una serie de objetivos: Independencia física. Independencia lógica. Flexibilidad. Uniformidad. Sencillez. Codd perseguía una serie de objetivos: Independencia física: El modo cómo se almacenan los datos no debe influir en su manipulación lógica. Independencia lógica: Añadir, eliminar o modificar cualquier elemento de la BD no debe repercutir en los programas y/o usuarios que están accediendo a subconjuntos parciales de los mismos (vistas). Flexibilidad: Ofrecer a cada usuario los datos de la forma más adecuada a la correspondiente aplicación. Uniformidad: Las estructuras lógicas de los datos presentan un aspecto uniforme (tablas), lo que facilita la concepción y manipulación de la BD por parte de los usuarios. Sencillez: Las características anteriores, así como unos lenguajes de usuario muy sencillos, producen como resultado que el modelo relacional (MR) sea fácil 4

5 Conceptos Básicos del Sistema Relacional
Tablas Atributos Esquemas Tuplas Dominios Nombre Año Temporadas Episodios The Big Bang Theory 2007 6 73 HOUSE M.D. 2006 132 How I Met Your Mother 2005 8 112 El modelo relacional proporciona una manera simple de representar los datos: una tabla bidimensinal llamada relación. Los atributos son las columnas de una relación y describen características particulares de ella. Es el nombre que se le da a una relación y el conjunto de atributos en ella. En un modelo relación, un diseño consiste de uno o más esquemas, a este conjunto se le conoce como "esquema relacional de base de datos“ (relational database schema) o simplemente "esquema de base de datos" (database schema) Cada uno de los renglones en una relación conteniendo valores para cada uno de los atributos. Se debe considerar que cada atributo (columna) debe ser atómico, es decir, que no sea divisible, no se puede pensar en un atributo como un "registro" o "estructura“ de datos. 5

6 SQL - Structured Query Languange
Los orígenes del SQL están ligados a los de las bases de datos relacionales. Los laboratorios de IBM definen el lenguaje SEQUEL (Structured English QUEry Language). Oracle introcuce SQL en 1979 en un programa comercial. SQL es un lenguaje declarativo de “alto nivel” de acceso a bases de datos que explota la flexibilidad y potencia de los sistemas relacionales permitiendo gran variedad de operaciones en éstos. Los orígenes del SQL están ligados a los de las bases de datos relacionales. Aparte del modelo, Codd propone asociado a éste un sublenguaje de acceso a los datos basado en el cálculo de predicados. Basándose en estas ideas, los laboratorios de IBM definen el lenguaje SEQUEL (Structured English QUEry Language) que más tarde sería ampliamente implementado por el SGBD (Sistemas Gestores de Bases de Datos) experimental System R, desarrollado en 1977 también por IBM. Sin embargo, fue Oracle quien lo introdujo por primera vez en 1979 en un programa comercial. El SEQUEL terminaría siendo el predecesor de SQL. SQL pasa a ser el lenguaje por excelencia de los diversos SGBD relacionales surgidos en los años siguientes y es por fin estandarizado en 1986 por el ANSI, dando lugar a la primera versión estándar de este lenguaje, el "SQL-86" o "SQL1". Al año siguiente este estándar es también adoptado por la ISO. SQL es un lenguaje de acceso a bases de datos que explota la flexibilidad y potencia de los sistemas relacionales permitiendo gran variedad de operaciones en éstos últimos. Es un lenguaje declarativo (O sea, que especifica qué es lo que se quiere y no cómo conseguirlo, por lo que una sentencia no establece explícitamente un orden de ejecución.)de "alto nivel" o "de no procedimiento", que gracias a su fuerte base teórica y su orientación al manejo de conjuntos de registros, y no a registros individuales, permite una alta productividad en codificación y la orientación a objetos. De esta forma una sola sentencia puede equivaler a uno o más programas que se utilizarían en un lenguaje de bajo nivel orientado a registros. 6

7 NoSQL  NoSQL (a veces llamado "no sólo SQL") es una amplia clase de sistemas de gestión de bases de datos que difieren del modelo clásico del sistema de gestión de bases de datos relacionales (RDBMS) en aspectos importantes, el más destacado que no usan SQL (Structured Query Language) como el principal lenguaje de consultas.  7

8 Origen del NoSQL El término NOSQL fue acuñado a principios de 2009 por un empleado de Rackspace, Eric Evans, cuando Johan Oskarsson de Last.fm quiso organizar un evento para discutir bases de datos distribuidas de código abierto. El nombre intenta describir la emergencia de un número creciente de bases de datos no relacionales y distribuidas que no suelen proveer garantias ACID. El término hace referencia a la manera de llamar a las bases de datos relacionales clásicas como MySQL, MS SQL, PostgreSQL, etc. Los sistemas NoSQL intentan atacar este problema proponiendo una estructura de almacenamiento más versátil, aunque sea a costa de perder ciertas funcionalidades como las transacciones que engloban operaciones en más de una colección de datos, o la incapacidad de ejecutar el producto cartesiano de dos tablas (también llamadoJOIN) teniendo que recurrir a la desnormalización de datos. 8

9 Características de No SQL
Consistencia Eventual. Estructura distribuida. Ausencia de esquema en los registros de datos. Escalabilidad horizontal sencilla. Alta velocidad de respuesta a peticiones. Consistencia Eventual: No se implementan mecanismos rígidos de consistencia como los presentes en las bases de datos relacionales, donde la confirmación de un cambio implica una comunicación del mismo a todos los nodos que lo repliquen. Esto se conoce también como BASE (Basically Available Soft-state Eventual Consistency) en contraposición a ACID, su analogía en las bases de datos relacionales. Estructura distribuida: Generalmente se distribuyen los datos mediante mecanismos de tablas de hash distribuidas (DHT) ya que realmente se trata, según las distintas implementaciones, de redes p2p. Ausencia de esquema en los registros de datos: los datos no tienen una definición de atributos fija, es decir: Cada registro (o documento, como se les suele llamar en estos casos) puede contener una información con diferente forma cada vez, pudiendo así almacenar sólo los atributos que interesen en cada uno de ellos, facilitando el polimorfismo de datos bajo una misma colección de información. También se pueden almacenar estructuras de datos complejas en un sólo documento, como por ejemplo almacenar la información sobre una publicación de un blog (título, cuerpo de texto, autor, etc) junto a los comentarios y etiquetas vertidos sobre el mismo, todo en un único registro. Hacerlo así aumenta la claridad (al tener todos los datos relacionados en un mismo bloque de información) y el rendimiento (no hay que hacer un JOIN para obtener los datos relacionados, pues éstos se encuentran directamente en el mismo documento). Escalabilidad horizontal sencilla: la posibilidad de aumentar el rendimiento del sistema simplemente añadiendo más nodos, sin necesidad en muchos casos de realizar ninguna otra operación más que indicar al sistema cuáles son los nodos disponibles. Muchos sistemas NoSQL permiten utilizar consultas del tipo Map-Reduce, las cuales pueden ejecutarse en todos los nodos a la vez (cada uno operando sobre una porción de los datos) y reunir luego los resultados antes de devolverlos al cliente. La gran mayoría permiten también indicar otras cosas como el número de réplicas en que se hará una operación de escritura, para garantizar la disponibilidad. Y gracias al sharding y a no tener que replicar todos los datos en cada uno de los nodos, la información que se mueve entre las distintas instancias del motor de base de datos no tiene por qué ser demasiado intensiva. Por supuesto, seguiremos encontrándonos con problemas de escalabilidad inherentes al tipo de software que estemos construyendo, pero seguramente podamos resolverlos más fácilmente con la ayuda de estas características. velocidad endiablada Por último, muchos de estos sistemas realizan operaciones directamente en memoria, y sólo vuelcan los datos a disco cada cierto tiempo. Esto permite que las operaciones de escritura sean realmente rápidas. Por supuesto, trabajar de este modo puede sacrificar fácilmente la durabilidad de los datos, y en caso de cuelgue o apagón se podrían perder operaciones de escritura o perder la consistencia. Normalmente, esto lo resuelven permitiendo que una operación de escritura haya de realizarse en más de un nodo antes de darla por válida, o disminuyendo el tiempo entre volcado y volcado de datos a disco. Pero claro, aún así, existe ese riesgo. 9

10 Tipos de BD NoSQL 10 Clave - Valor Documentos Familia de Columnas
Orientada a Grafos Familia de Columnas Clave - Valor Documentos 10

11 BD orientada a grafos La información es representada en nodos
Ya está normalizada No hay que definir un número determinado de atributos Recorrido ¿Cuándo usarlas? Algunas BD Neo4j HyperGraph-DB RDF 11

12 BD orientada a grafos Ejemplo: 12

13 BD de familia de columnas
Bigtable ¿Por qué se creó? Estructura Tablas: “tablets” Servidores master Chunkservers Hypertable Utiliza lenguaje HQL 13

14 BD de familia de columnas
14

15 BD clave-valor Se tiene una clave única y un valor que contiene toda la información asociada a la clave La información esta condensada en una súper lista en la que podemos tener índices Búsquedas Permite variar la estructura de la información que se almacena 15

16 BD clave-valor 16 Ejemplo: Claves Valores John Smith : Lisa Smith
Sam Doe 000 001 75475 754575 345435 Valores : 16

17 BD orientada a documentos
Soportan modelos de datos más complejos que el anterior tipo clave – documento No almacenan datos en tablas con campos uniformes para cada fila o registro Cada documento es almacenado de forma que tenga ciertas características, cualquier número o tipo de campos pueden ser añadidos a un documento 17

18 Tolerancia de Partición
Arquitectura de NoSQL Consistencia Tolerancia de Partición Disponibilidad NoSQL PAXOS S B D R 18

19 Arquitectura de NoSQL BASE Características: Basically Available
Generalmente arquitectura distribuida BASE Basically Available Soft-State Eventual Consistency Internet Características: Escalabilidad horizontal Tolerancia a fallas Redundancia 19

20 Usuarios y Aplicaciones
Cassandra es utilizada por Twitter y Facebook Couch DB es utilizada por Ubuntu Desktop Couch Mozilla y Adobe utiliza Hbase 20

21 Cassandra Es un sistema de almacenamiento distribuido escrito en Java de código abierto, descentralizado, escalable, altamente disponible, tolerante a fallos, eventualmente consistente, y orientado a columnas. Es mantenido por la fundación Apache. Se originó en Facebook en el 2007 para solventar los problemas de búsqueda interna de datos que tenía la compañía, la cual tiene que tratar con grandes volúmenes de datos. 21

22 Características de Cassandra
Distribuido y Descentralizado Escalabilidad flexible Alta disponibilidad y tolerancia a fallos Orientación a columnas Libre esquema Sin lenguaje de consulta Sin integridad referencial 22

23 Modelo de datos de Cassandra
Clúster Espacio Clave Familias de columnas Columnas Supercolumnas 23

24 ¿Quienes usan Cassandra?
Grandes Instalaciones: Ninguna de las cualidades de Cassandra son bien aprovechadas si esta se ejecuta en un solo nodo.Existen, sin embargo, una gran cantidad de situaciones en donde una base de datos relacional seatodo lo que necesitemos. Por lo tanto, hay que analizar el tráfico del sistema y las necesidades derendimiento para determinar cuál paradigma adoptar. Grandes Escrituras de Datos, Estadísticas y Análisis: Cassandra está optimizado para un excelente rendimiento en escritura de datos. Muchas de lasinstalaciones de producción que contienen Cassandra involucran el almacenamiento deactualizaciones de actividades de los usuarios, uso de redes sociales, comentarios /recomendaciones, y aplicaciones estadísticas, Estos son usos fuertes de Cassandra debido a querequieren una gran capacidad de escritura con menos operaciones de lectura y porque lasactualizaciones pueden ocurrir repentinamente en cualquier momento. La habilidad de llevargrandes cargos de trabajo que requieren alto desempeño en grandes volúmenes de escritura conmucha concurrencia de clientes es una de las características principales de Cassandra. Distribución Geográfica: Cassandra tiene soporte para la distribución geográfica de datos. Puedes configurar Cassandrapara la replicación de datos a múltiples almacenes de datos repartidos globalmente. Aplicaciones Evolutivas 24

25 Modelado de datos relacional vs un modelado de datos de Cassandra
25

26 CouchDB Base de datos documental sin esquema, consultable al estilo MapReduce, accesible por REST y con una funcionalidad de replicación integrada. Se trata de una base de datos NoSQL que emplea JSON para almacenar los datos, JavaScript como lenguaje de consulta por medio de MapReduce y HTTP como API. 26

27 Características de CouchDB
Plataforma de bases de datos simplificada sin esquema Centrada en documentos No sigue el modelo relacional Facilita la distribución Alta escalabilidad Tolerancia a fallos Replicación bidireccional Preparada para funcionar offline Orientada a Internet 27

28 CouchDb – Ejemplo de JSON
JSON, acrónimo de JavaScript Object Notation, es un formato ligero para el intercambio de datos. {"menu": { "id": "file", "value": "File", "popup": { "menuitem": [ {"value": "New", "onclick": “CreateNewDoc()"}, {"value": "Open", "onclick": "OpenDoc()"}, {"value": "Close", "onclick": "CloseDoc()"} ] } <menu id="file" value="File"> <popup> <menuitem value="New" onclick="CreateNewDoc()" /> <menuitem value="Open" onclick="OpenDoc()" /> <menuitem value="Close" onclick="CloseDoc()" /> </popup> </menu> XML JSON 28

29 Características de CouchDB
Plataforma de bases de datos simplificada sin esquema. No sigue el modelo relacional Centrada en documentos Facilita la distribución Alta escalabilidad Tolerancia a fallos Replicación bidireccional Preparada para funcionar offline Orientada a Internet 29

30 Ejemplo de documento en CouchDB
30

31 Ejemplo de Map en CouchDB
31

32 Ejemplo de Reduce en Couch DB
32

33 Ventajas Estos sistemas responden a las necesidades de escalabilidad horizontal que tienen cada vez más empresas. Pueden manejar enormes cantidades de datos. No generan cuellos de botella. Alta velocidad de respuesta. Diferentes DBs NoSQL para diferentes proyectos. Se ejecutan en clusters de máquinas baratas. 33

34 Desventajas El código abierto puede significar una "mancha" en el soporte para las empresas.  No están lo suficientemente maduros para algunas empresas. de experiencia. Limitaciones de Inteligencia de Negocios. Problemas de compatibilidad. Aquí están cinco Desventajas de NoSQL  El código abierto puede significar una "mancha" en el soporte para las empresas  Mientras que los principales proveedores de RMBMS tales como Oracle, IBM y Sybase ofrecen buenos soportes a pequeñas, medianas y grandes empresas y típicamente start-ups, los vendedores de código abierto esperan ofrecer un soporte comparable -con excepción de un puñado de clientes blue-chip.  Generalmente un vendedor de código abierto no tiene el alcance global, servicios de soporte, y la credibilidad de Oracle o IBM.  2.- No están lo suficientemente maduros para algunas empresas  A pesar de sus puestas en práctica en algunas grandes empresas, las bases de datos NoSQL aún se enfrentan a un problema de credibilidad importante con muchas empresas. Los críticos señalan la falta de madurez de NoSQL y los posibles problemas de inestabilidad, mientras que citan la madurez, y una gran funcionalidad y estabilidad de los RDBMSes.  3.- Limitaciones de Inteligencia de Negocios  Hay una o dos cuestiones acerca de las capacidades de BI de las bases de datos NoSQL. ¿Pueden estas bases de datos proporcionar la clase de minería de datos rigurosos que las empresas se utilizan con las RDBMSes? ¿Cuántos conocimientos de programación se necesitan para hacer la consulta ad hoc y análisis?  Las respuestas no son precisamente positivas. Las bases de datos NoSQL no tienen muchos ganchos para el uso general de herramientas de BI, mientras que la más simple consulta ad-hoc y análisis implica conocimientos de programación bastante buenos. Sin embargo, las soluciones están disponibles. Quest Software, por ejemplo, ha creado Toad para bases de datos en la nube, que proporciona capacidades de consulta ad-hoc para algunas bases de datos NoSQL.  4.- La falta de experiencia  La novedad de NoSQL significa que no hay una gran cantidad de desarrolladores y administradores que conocen la tecnología -lo que hace difícil a las empresas encontrar personas con los conocimientos técnicos apropiados. Por el contrario, el mundo RDBMS tiene miles de personas muy cualificadas.  5.- Problemas de compatibilidad  A diferencia de las bases de datos relacionales, que comparten ciertos estándares, las bases de datos NoSQL tienen pocas normas en común. Cada base de datos NoSQL tiene su propia API, las interfaces de consultas son únicas y tienen peculiaridades. Esta falta de normas significa que es imposible cambiar simplemente de un proveedor a otro, por si no quedara satisfecho con el servicio.  34