1.
“CLOUD” & “BIG DATA”Trabajando el “CLOUD”, explotando “BIG DATA”. ¿Cómo pueden ayudarnos estas tecnologías?. ¿Convivimos con ellas?.

2.
Índice. (I)‣ Introducción.‣ ¿Qué es “CLOUD”.‣ Tipos de “CLOUD”. ‣ Pública. ‣ Privada. ‣ Comunitaria. ‣ Híbrida.‣ Proveedores de “CLOUD” pública.‣ ¿Qué es “BIG DATA”?. ‣ Convivimos con “BIG DATA”.

3.
Índice. (II) ‣ Como llegar a “BIG DATA”.‣ Bases de datos “SQL”. ‣ Productos “SQL”.‣ Bases de datos “NoSQL”. ‣ Productos “NoSQL”.‣ Bases de datos “SQL” Vs “NoSQL”. ‣ A.C.I.D. Vs B.A.S.E. ‣ ¿Podemos usar siempre “NoSQL”.‣ Entornos mixtos “SQL” & “NoSQL”.‣ ¿cómo usar“BIG DATA” en “CLOUD”?.‣ P & R.

4.
Introducción.‣ Tecnologías independientes pero relacionadas.‣ Orígenes. ‣ Cloud. No es fácil definir el origen del “Cloud Computing”, pero si tiene claros predecesores: SOA, VM, etc. ‣ Big Data. El origen de “Big Data”, como lo conocemos hoy día, puede ubicarse en las VLDB que fueron creciendo (escalando) de manera horizontal. Pero su origen es tan antiguo como las BBDD “tradicionales” como puedan ser las RDBMS, JDB, etc. No se ofrecían como una alternativa a estas ni de manera “popular”.

5.
¿Qué es “CLOUD”?. ‣ Es complicado encontrar una definición universal. ‣ Existen puntos comunes que hacen aceptables diferentes aproximaciones a definir “CLOUD”. ‣ Convivimos con “CLOUD” a diario.

6.
¿Qué necesita? “CLOUD”.‣ Según los estándares, CLOUD consta de:‣ Según las necesidades particulares, se pueden implementar las soluciones adecuadas a cada caso.‣ Existen “Service Models” muy particularizados: DBaaS, MaaS y DaaS, derivados de los tres generales.

7.
¿Qué necesita? “CLOUD”.‣ Nueve requisitos de almacenamiento en “CLOUD”. ‣ Escalabilidad y elasticidad “MASIVA”. ‣ Almacenamiento de objetos. ‣ Asignación bajo demanda. ‣ “Agnóstico” en cuanto a aplicaciones. ‣ Seguridad multi-propietario. ‣ Cobro por uso. ‣ Acceso primario (a datos) REST o SOAP. ‣ Localización geográfica no importante. ‣ Accesible vía internet.

8.
Modelos de servicio (I) ‣ SaaS. Software as a Service. ‣ PaaS. Platform as a Service. ‣ IaaS. Infrastructure as a Service. ‣ Evoluciones. ‣ DBaaS. DataBase as a Service. ‣ MaaS. Mobility as a Service. ‣ DaaS. Desktop as a Service.

9.
Modelos de servicio. (II)

10.
Tipos de “CLOUD” (I).‣ “CLOUD” pública.‣ “CLOUD” privada.‣ “CLOUD” comunitaria.‣ “CLOUD” hibrida.

11.
¿Qué es “BIG DATA”?.‣ Cuando los sistemas de BBDD “tradicionales” no son suficientes para gestionar enormes volúmenes de datos.‣ Cuando los sistemas disponibles son heterogéneos pero queremos aprovecharlos.‣ Cuando la cantidad de sistemas es amplia y la cantidad de fallos a ocurrir es elevada.‣ Cuando el software a utilizar es capaz de asegurar la disponibilidad mínima requerida. ESTAMOS ANTE UN ESCENARIO PARA “BIG DATA”.

12.
Convivimos con “BIG DATA”‣ Aunque no seamos conscientes de este hecho, en nuestro día a día USAMOS “BIG DATA”.‣ Ejemplos de “BIG DATA”:

13.
¿Como llegar a “BIG DATA”?‣ Existen 5 puntos a tener en cuenta para poder llegar a implantar o aprovechar “BIG DATA”: 1. Definir las necesidades y comprender los requisitos y limitaciones de “BIG DATA”. 2. Descubrir los datos que necesitamos y donde se encuentran. 3. Obtener los recursos necesarios para implementar “BIG DATA”. 4. Dar con la tecnología más adecuada para nuestra casuística. 5. Asegurar que contamos con el equipo y las habilidades necesarias.

14.
¿Como llegar a “BIG DATA”?‣ Una vez en “BIG DATA” encontraremos un desafío principal: E S C A L A B I L I D A D.‣ Existen 2 posibilidades: Vertical u Horizontal, cada una de ellas con sus pros y sus contras. VERTICAL. HORIZONTAL.+ Rápido y sencillo. + Rápido y sencillo *. + Límite más lejano.− Hasta un límite. + Flexible.− Caro.− Suele “casarnos” con un − Añade complejidad. proveedor.

15.
Bases de datos “SQL”.‣ RDBMS: Bases de datos RELACIONALES.‣ Son los sistemas de BBDD más extendidos en la actualidad.‣ Transacciones que deben cumplir ACID.‣ A.C.I.D. ‣ Atomicity. ‣ Concurrency. ‣ Isolation. ‣ Durability.‣ Son dinámicas y escalables hasta unos límites.

16.
Productos “SQL”.

17.
Bases de datos “NoSQL”.‣ BBDD NO relacionales y distribuidas.‣ Muchos nodos componen la misma BBDD.‣ Cumplen 2 de 3 requisitos C.A.P. ‣ Consistency: Todos los clientes ven los mismos datos. ‣ Availability: Todos los clientes SIEMPRE acceden a los datos. ‣ Partition tolerance: Habilidad para continuar trabajando ante un fallo.‣ No dependen del “TODO o NADA” de RDBMS. ‣ Elegiremos entre varios niveles de C.A.P. ‣ Estrictos con A + P minimizamos el riesgo de fallos en C.

18.
Bases de datos “NoSQL”.‣ B.A.S.E. ‣ Basically Available ‣ Soft State ‣ Eventually Consistent.‣ Las NoSQL escalan gracias a B.A.S.E.‣ Clases de NoSQL: ‣ Key / Value. Ej: Riak, Voldemort, Redis. ‣ Column (BigTable). Ej: Cassandra, Hbase,Hypertable. ‣ Document. Ej: MongoDB, CouchDB. ‣ Graph. Ej: Neo4j, Pregel, AllegroGraph.

19.
Productos “NoSQL”.

20.
“SQL” Vs “NoSQL”. (I)‣ Estructuras de datos:‣ SQL: ‣ NoSQL: ‣ Tablas, columnas y ‣ Eliges tu estructura de filas. datos. ‣ Todas las filas tienen ‣ Estructura natural la misma estructura. para los datos.‣ Esquemas:‣ SQL: ‣ NoSQL: ‣ Esquemas monolíticos ‣ Estructuras de datos pueden cambiar ‣ Mantiene relaciones y dinámicamente. fuerza la integridad de ‣ Estructura de datos los datos. puede ser opaca.

21.
“SQL” Vs “NoSQL”. (II)‣ Normalizaciones y relaciones:‣ SQL: ‣ NoSQL: ‣ El modelo de datos se ‣ La denormalización no es mala. normaliza para eliminar ‣ Las relaciones no son definidas duplicidades. explícitamente. ‣ La normalización ‣ Datos relacionados se suelen establece las relaciones encontrar agrupados y entre tablas. almacenados como una unidad.‣ Acceso a los datos:‣ SQL: ‣ NoSQL: ‣ Operaciones C.R.U.D. ‣ APIS propietarias. ‣ Obtener datos de varias ‣ Usan algoritmos tablas necesitan JOINS. “MapReduce” y ‣ APIS genéricas. “Graph traversals”.

22.
“SQL” Vs “NoSQL”. (III)‣ Capacidades para “reporting”:‣ SQL: ‣ NoSQL: ‣ División “slice & dice” y ‣ Dificultad en reunificación “ad-hoc”. reformatear “ad-hoc”. ‣ Cubos y datamining. ‣ Todo reporte debe ‣ “Drill down”, “Roll up”, estar “pensado” por “Pivot”. adelantado.‣ Resumen: ‣ Elegir la BBDD adecuada a cada caso. ‣ SQL no debería ser preeminente. ‣ NoSQL es superior para determinados casos. ‣ Podemos hacer que trabajen juntas.

23.
Entornos mixtos “PolyGlot”.‣ PROS: ‣ RDBMS con tablas grandes y creciendo. ‣ Alcanzamos limites en la RDBMS incluso usando técnicas para VLDB. ‣ NoSQL usada para almacenar datos viejos. ‣ Uso de “vistas materializadas” con esos datos en la “NoSQL” actualizando durante la noche. ‣ Migrar ciertas partes de las aplicaciones para acomodarse a la distribución de datos de la “NoSQL”.

24.
Entornos mixtos “PolyGlot”.‣ CONS: ‣ Las “VM” en la “NoSQL” consumen mucho almacenamiento. ‣ Determinadas funcionalidades (Querys) no pueden ser sustituidas por “VM” en “NoSQL”. ‣ Indexar documentos para busquedas por texto es muy costoso en tiempo en “NoSQL”. ‣ El desarrollo para “NoSQL” requiere más tiempo y los modelos “MapReduce” más planificación. ‣ Los cambios de las “VM” en “NoSQL” no es algo sencillo.

25.
“BIG DATA” en “CLOUD”.‣ Los factores principales, pero no únicos: ‣ La cantidad de almacenamiento de “BIG DATA”. ‣ La disponibilidad inherente a “CLOUD”. ‣ El origen de los datos a integrar en “NoSQL”.‣ Aumentaremos la disponibilidad.‣ Adquirimos la posibilidad de agregar nuevas funcionalidades.‣ Nos permite analizar esas cantidades de datos en un tiempo “razonable”.‣ Nos permite usar varias “NoSQL” diferentes.

26.
Preguntas & Respuestas.