El documento explora las tecnologías de 'cloud' y 'big data', definiendo sus tipos, modelos de servicio y cómo interactúan entre sí. Se discuten las bases de datos SQL y NoSQL, incluyendo sus diferencias, ventajas y desventajas, así como la necesidad de adoptar estrategias mixtas para aprovechar ambas. También se analizan los requisitos y desafíos para implementar 'big data' en la nube de manera efectiva.

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.