Noviembre18, 2017 Concepción, Chile #sqlsatconce

CosmosDb and beyond Nombre Speaker: Sergio Borromei | Gustavo Vegas Cargos : Cowboy Coders @ Lagash Twitter: @SergioBLagash Email: sergiob@Lagash.com

Patrocinadores del SQL Saturday 3 | 16-09-2018 | SQL Saturday #684 – Concepcion, Chile

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

no SQL

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

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

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

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 | 16-09-2018 | SQL Saturday #684 – Concepcion, Chile

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 | 16-09-2018 | SQL Saturday #684 – Concepcion, Chile

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

RDBMS FIRST WORLD PROBLEMS: IMPEDANCE MISMATCH

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

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

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

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

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

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.

Not Only no SQL

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)

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

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

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

{“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}}

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… }

1001 “Ann”, [{032193533,2,48,96}, {032601912,1,39.,39}, {0131495054,1,51,51}}, “Amex”, 12345,04/2001 {“id”:1001, “Customer”: “Ann”, [“items”: {“productId”: 032193533, “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 0321293533 {2,48,96} 0321601912 {1,39,39} 0131495054 {1,51,51}

Aggregates

Key Value Aggregate Data Models Document Column Family

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

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

GROUP BY ProductId, CityId Total Items Total Revenue 0001 Concepción 234 $345.000 Rancagua 123 $134.000 0002 Santiago 2340 $678.933 … 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

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

Graph

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

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

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

Dijkstra’s algorithm

Key Value Column Family Document Graph

Demostración 41 | 16-09-2018 | SQL Saturday #684 – Concepcion, Chile

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

CAP Theorem

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

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

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

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

Modelos de Consistencia CosmosDB +RUs -RUs

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…

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

Sitio de la Comunidad Global www.pass.org 51 | 16-09-2018 | SQL Saturday #684 – Concepcion, Chile

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

Preguntas 53 | 16-09-2018 | SQL Saturday #684 – Concepcion, Chile

Gracias por vuestra asistencia!