Noviembre18, 2017 Concepción, Chile #sqlsatconce.

Presentación del tema: "Noviembre18, 2017 Concepción, Chile #sqlsatconce."— Transcripción de la presentación:

1 Noviembre18, 2017 Concepción, Chile #sqlsatconce

2 CosmosDb and beyond Nombre Speaker: Sergio Borromei | Gustavo Vegas
Cargos : Cowboy Lagash

3 Patrocinadores del SQL Saturday
3 | | SQL Saturday #684 – Concepcion, Chile

4 Distribuida Globalmente Alta Disponibilidad Multi-modelo
Esta presentación es acerca de Azure Cosmos DB, una base de datos multimodelo, globalmente distribuida, pensada para la baja latencia, la escalabilidad sostenida y la alta disponibilidad Multi-modelo Escalabilidad Sostenida Baja Latencia

5 no SQL

6 La pregunta que nos hacemos primero es… ¿Por qué necesitamos otra base de datos?
Multimodelo? Que es eso? Escalabilidad sostenida? ?

7 Agenda Un poco de historia… noSQL? Modelos de Datos en noSQL CosmosDB
Modelos de Consistencia Beyond… 7 | | SQL Saturday #684 – Concepcion, Chile

8 ¿Un mundo sin bases de datos relacionales?
8 | | SQL Saturday #684 – Concepcion, Chile

9 Titulo Desafio de estructurar datos
Hoy damos por sentado que hay un motor de bases de datos No siempre fue asi Todas las funcionalidades de las RDBMS son producto de 60 años de evolución Hoy la Transformación Digital nos sigue pidiendo continuar con esa evolución Pero como era un mundo sin bases de datos relacionales? Desde los inicios de la ciencia de la computación, uno de los grandes desafíos constantes fue la necesidad de estructurar los datos para su almacenamiento y recuperación. En la actualidad y en la gran mayoría de los proyectos que iniciamos, damos por hecho que siempre existirá algún tipo base de datos que resolverá el problema no solo de almacenar y acceder los datos, sino de otros problemas y complejidades que están ocultas detrás de lo que llamamos “motor de base de datos”. Esto es algo muy bueno, porque nos permite rápidamente avanzar con el desarrollo de nuestras aplicaciones, sin tener que dedicarle mucho tiempo a problemas de mucho mas bajo nivel como la concurrencia, el aislamiento transaccional, la alta disponibilidad, y muchos otros. Sin embargo esto no siempre fue así… todas estas bondades que hoy nos brinda hasta el mas modesto de los productos de base de datos, son el producto de una evolución a lo largo de casi 60 años, en donde la constante que impulsó esa evolución fue la gran demanda creciente de almacenar y procesar cada vez mas datos. Hoy hablamos mucho de transformación digital… y un poco consiste en como llevamos al plano digital la representación misma de la realidad, con el objetivo de poder operar con ella. Sucede que la realidad está compuesta por muchísima información, muchísima mas de la que los sistemas computacionales mas extensos puedan llegar a procesar, por lo cual esta evolución sigue y seguirá sin detenerse. 9 | | SQL Saturday #684 – Concepcion, Chile

10 Megabytes Gigabytes Terabytes & Petabytes Un poco de historia…
Edgard Codd inventa el “modelo relacional” IBM 305 RAMAC Charles Bachman crea uno de los primeros DBMS IBM desarrolla el lenguaje SEQUEL Random Access Method of Accounting and Control (RAMAC) -> 5Mb de Storage IDS -> Integrated Data Store, uno de primeros DBMS – “Navigational Database” UNIVAC I 1950 1960 1970 1980 1990 2000 2010 10 | | SQL Saturday #684 – Concepcion, Chile

11 RDBMS – Que nos dejó la época dorada
Transacciones Persistencia Concurrencia Reportería Lenguaje de Dominio Específico Integración de Aplicaciones

12 RDBMS FIRST WORLD PROBLEMS:
IMPEDANCE MISMATCH

13 Caso de una Orden de Compra…
Un solo objeto cohesivo en memoria debe ser despedazado para ser almacenado en la base de datos IMPEDANCE MISMATCH -> necesito dos modelos para representar lo mismo Asi aparecen frameworks ORM como Hibernate, EntityFramework

14 Mapping Logic Object A RDMBS Object B Object C Object D Object F

15

16 Muchísimo tráfico de internet
Esto también tiene sus limitaciones Es muy caro modificar un datacenter / cambiar el hardware Muy difícil de predecir la carga máxima que deberé soportar Todo hardware tiene un límite

17 Muchísimo tráfico de internet
Empresas como Microsoft, Google, Amazon, etc utilizan un enfoque muy diferente. Miles de pequeñas cajas, cada una responsable de atender a un conjunto de usuarios. Esto se llama escalabilidad horizontal

18 RDBMS FIRST WORLD PROBLEMS:
Las DB relacionales nunca escalaron muy bien de manera horizontal Para poder mantener y asegurar todas las propiedades es necesario que los datos estén en un solo lugar. Incluso las marcas mas prestigiosas luego de varios intentos desistieron de resolver el problema de la escalabilidad horizontal. HORIZONTAL SCALE

19 Bigtable Dynamo DocumentDB
Es por eso que las grandes empresas que se enfrentaban a este problema necesitaron crear nuevas bases de datos, muy diferentes a como funcionan las RDBMS, pero con la posibilidad de escalar horizontalmente. Es así que empiezan a aparecer publicaciones de como estas empresas resolvieron el problema de la escalabilidad y se empieza a hacer popular en la comunidad una nueva tendencia de modelamiento de datos diferente a la relacional.

20 Not Only no SQL

21 SQL no Características El modelado de datos no es relacional
Cluster-friendly -> Escalan horizontalmente Pensadas para la Web del siglo 21 No poseen esquema (schema-less) La mayoría son open source o son servicios pagos en la nube (PaaS)

22 ¿Cómo se modelan los datos?
22 | | SQL Saturday #684 – Concepcion, Chile

23 Estrategias de modelado de datos
Key-Value Document Column Family Graph

24 Key-Value Básicamente un diccionario persistente
“Sergio Borromei”, {17/04/1973}, ”Bahía Blanca”, “Argentina” Básicamente un diccionario persistente La DB solo indexa las keys El contenido (value) es completamente opaco a la base de datos. La información se busca por la clave 1234 “Fernanda Radetich”, {15/07/1983}, ”Bahía Blanca”, “Argentina” 1235 1236 A1G3B3F7D3A8E8E6E8B3A5D1C7C1A1G3B3F7D3A8E8E6E8BA 1237 12345,8739,928932,989832,98233,2333

25 {“productId”: 6790, “quantity”: 7}}
Document {“id”: 1234, “name”: “Sergio Borromei”, “birthDay”: {17/04/1973}, “city”: ”Bahía Blanca”, “country”: “Argentina”} Repositorio de “documentos” de diferente tipo Un documento es una estructura de datos con cierta complejidad Típicamente JSON El contenido es indexado, lo cual permite hacer consultas con lenguajes similares a SQL {“id”: 1235, “name”: “Fernanda Radetich”, “birthDay”: {15/07/1983}, “city”: ”Bahía Blanca”, “country”: “Argentina”} {“id”: 1236, “profileImage”: “A1G3B3F7D3A8E8E6E8B3A5D1C7C1A1G3B3F7D3A8E8E6E8BA”, “customerId”: 1234} {“id”: 1237, “customerId”: 1245, “orders”: [ {“productId”: 6789, “quantity”: 2}, {“productId”: 6790, “quantity”: 7}}

26 Column Family 1234 Name “Sergio Borromei” Birthday 17/04/1973 Profile
City Bahía Blanca Country Argentina 1234 0001 { Order data… } Row Key 0002 { Order data… } Orders 0003 { Order data… } 0004 { Order data… }

27 1001 “Ann”, [{ ,2,48,96}, { ,1,39.,39}, { ,1,51,51}}, “Amex”, 12345,04/2001 {“id”:1001, “Customer”: “Ann”, [“items”: {“productId”: , “quantity”: 2, “unitPrice”: 48, “totalPrice”: 96}, etc, etc, etc… } Name “Ann” Hacer énfasis en que el esquema está implícito. Introducir el concepto de Aggregate 1001 {2,48,96} {1,39,39} {1,51,51}

28 Aggregates

29 Key Value Aggregate Data Models Document Column Family

30 Aggregate Order 1001 La parte interesante es que toda la data se guarda junta y se obtiene junta

31 1001/2001 2002/3001 3002/4001 4002/5001 6001/7001 7002/8001 8002/9001 9002/9999 Como consecuencia, cuando tengo que ir a buscar la data de un aggregate, esta se encuentra en un solo nodo. Lo cual hace que la orientación a Aggregates sea muy natural para poder escalar horizontalmente en una arquitectura de clusters

32 GROUP BY ProductId, CityId
Total Items Total Revenue 0001 Concepción 234 $ Rancagua 123 $ 0002 Santiago 2340 $ … SELECT P.ProductId, S.CityId, COUNT(*) as TotalItems, SUM(S.Revenue) TotalRevenue FROM Products P, Sales S INNER JOIN bla bla bla GROUP BY ProductId, CityId

33 RDBMS FIRST WORLD PROBLEMS:
A veces no nos alcanza con modelar solamente Entidades… Ciertos problemas requieren poder modelar las relaciones entre esas entidades. REALATIONSHIP MODEL

34 Graph

35 Graph Permiten modelar entidades y relaciones Schema-less
Escalan horizontalmente Las búsquedas son mucho mas eficientes que en un modelo relacional Sobre todo relaciones tipo “friend-of-a-friend” Social networking, content managment, geospatial, recommendations Utilizan algoritmos diferentes

36

37 Depth First Search A-> B-> F-> E-> C-> G

38 Breadth First Search Búsqueda en anchura -> El camino con menos paradas

39 Dijkstra’s algorithm

40 Key Value Column Family Document Graph

41 Demostración 41 | | SQL Saturday #684 – Concepcion, Chile

42 Consistencia? ACID BASE Atomic consistent Isolated Durable
Basic Availability Soft-state Eventual Consistency Atomic Consisten Isolated Durable Basic Availability Soft-state Eventual Consistency

43 CAP Theorem

44 Web Page Web API Web API DB DB Web API Web Page

45 DB DB Web Page Web API Web API Web API Web Page GET SELECT GET SELECT
POST UPDATE POST UPDATE

46 DB DB Web Page Web API Web API Web API Web Page Transacción GET SELECT
POST UPDATE GET SELECT

47 DB DB Web Page Web API Web API Web API Web Page TX GET SELECT GET V1.0
POST V1.0 UPDATE TX V2.0 POST UPDATE

48 Modelos de Consistencia CosmosDB
+RUs -RUs

49 Conclusiones CosmosDB es la base de datos de alta disponibilidad multi-modelo, distribuida globalmente preparada para los desafíos de la Web del siglo XXI noSQL es una tendencia para el modelado de datos que complementa a los modelos relacionales La elección del modelo de datos y de consistencia es mas una decisión de negocios que técnica…

50 Sitio de la Comunidad en Chile
chile.pass.org 50 | | SQL Saturday #684 – Concepcion, Chile

51 Sitio de la Comunidad Global
51 | | SQL Saturday #684 – Concepcion, Chile

52 Sea cual sea su pasión datos – ¡hay un capítulo virtual para usted!
52 | | SQL Saturday #684 – Concepcion, Chile

53 Preguntas 53 | | SQL Saturday #684 – Concepcion, Chile

54 Gracias por vuestra asistencia!