El documento presenta una agenda para un taller sobre la migración de bases de datos relacionales a MongoDB. Se discute cómo Amazon eligió NoSQL debido a problemas de escalabilidad con Oracle. También se explica cómo modelar relaciones comunes como uno a uno, uno a muchos y muchos a muchos en MongoDB usando documentos incrustados y referencias. Finalmente, se muestra una demostración del MongoDB Relational Migrator y se concluyen algunos puntos sobre cuándo usar NoSQL.

1. Jorge Ortiz-Fuentes
Developer Advocate, MongoDB
TALLER
Los mejores consejos para migrar
de RDBMS a MongoDB
Diego Freniche
Developer Advocate, MongoDB
https://www.linkedin.com/in/jorgeortiz/ https://www.linkedin.com/in/dfreniche/

2. Agenda
La gran migración: ¿por qué Amazon eligió
NoSQL?
Abriendo un nuevo camino - Encontrar el
camino hacia la libertad de la base de datos
Poniéndolo en marcha - Modelado de
relaciones en NoSQL
Ejecutando el plan

3. La Gran
Migración
¿Por qué
NoSQL?
“El cambio comienza al final de tu zona
de confort”.
Roy T Bennett

4. Amazon se fundó en 1995 y se
basó en servicios monolíticos.
Empresa de 5 millardos de
dólares cuando SOA se convirtió
en un estándar interno en 2005.
En 2018 problemas de escala:
● 3K instancias de Oracle
● 10K Servicios de
aplicaciones
● 25K Desarrolladores
El costo de RDBMS fue una gran
línea de pedido
● La licencia de Oracle más
grande del mundo
● Alto TCO de infraestructura
¿Alternativas?

5. Abriendo un
nuevo
camino
“La historia se repite porque nadie
escucha la primera vez”.
Erik Qualman

6. La ley de Moore ya no es el salvavidas
El rendimiento de CPU se aplana
El costo del almacenamiento
sigue bajando

7. Esto no es nuevo…
“La simplicidad de la representación matricial, que se
vuelve factible cuando todas las relaciones se expresan
en forma normal, no sólo es ventajosa para el
almacenamiento, sino también para la comunicación
de datos a gran escala entre sistemas que utilizan
representaciones de datos muy diferentes”.
“Si las fuertes redundancias en los resultados (named
set) se reflejan directamente en redundancias fuertes en
el conjunto almacenado (o si se introducen otras
redundancias fuertes en el conjunto almacenado),
entonces, en general, el espacio de almacenamiento
adicional y el tiempo de actualización se consumen
con una caída potencial del tiempo de consulta en
algunos casos y de carga en las unidades centrales
de proceso.
“Idealmente, la variedad de representaciones de datos
permitidas debería ser adecuada para cubrir el espectro de
requisitos de rendimiento del conjunto total de instalaciones.
Una variedad demasiado grande conduce a costos
generales innecesarios en el almacenamiento y la
reinterpretación continua de las descripciones de las
estructuras actualmente en uso”.
A Relational Model of Data for Large
Shared Data Banks
Edgar Frank "Ted" Codd
19 de agosto de 1923–18 de abril de
2003
Sobre la normalización: Sobre la desnormalización:
Sobre la definición de un ERD:

8. ¿Cuándo usar NoSQL?
Optimizado para almacenar Optimizado para la computación
Normalizado/relacional Desnormalizado/Jerárquico
Consultas a medida Vistas instanciadas
Escalado vertical Escalado horizontal
Bueno para OLAP Pensado para OLTP a escala
SQL NoSQL

9. Poniéndolo
en marcha
“Los datos son como la basura. Más
vale que sepas lo que vas a hacer con
ella antes de recogerla.”
Mark Twain

10. EN DETALLE
Los patrones de
acceso dirigen el
costo
En Amazon en 2017, el 70% de las
consultas accedían a una única fila de
datos
Un 20% adicional accedía a un rango de
filas de una sola tabla
El 50% de la infraestructura se dedicaba
al último 10%

11. Las relaciones lo son todo
Gestión documental Control de procesos
Redes sociales
Data lake
Monitorización de IT

12. Relacional
Tabla Colección
Documentos
Fila Documento
Columna Campo

13. Modelado de Datos con MongoDB
● Polimorfismo
● Incrustado
● Referencias

14. Modelado de Datos con MongoDB
● Polimorfismo
● Incrustado
● Referencias
Poli = Muchos
Morf(ismo) = Formas
Muchas formas

15. Modelado de Datos con MongoDB
● Polimorfismo
● Incrustado
● Referencias
Documentos dentro de
Documentos (dentro de
Documentos)

16. Modelado de Datos con MongoDB
● Polimorfismo
● Incrustado
● Referencias
Un valor hace referencia
a un par clave/valor en
otro documento

17. Ejecutando
el Plan

18. Modelado de
Datos
Relaciones Comunes
1:1 1:M N:M
Uno a Uno Uno a Muchos Muchos a Muchos

19. Movies
TITLE
DIRECTOR
GENRE(S)
WRITERS(S)
CAST
RATING
RUNTIME

20. Modelando relaciones 1:1
id title
573 Star Wars: Episode IV – A New Hope
Movies Table
movie_id director runtime
573 George Lucas 121
Movie Details Table

21. Modelando relaciones 1:M
id title
573 Star Wars: Episode IV – A New Hope
Movies Table
movie_id actor character
573 Mark Hamill Luke Skywalker
573 Harrison Ford Han Solo
573 Carrie Fisher Princess Leia Organa
Cast Table

22. Modelando relaciones M:M
id title
573 Star Wars: Episode IV – A New Hope
Movies Table
id location
106 Yuma, Arizona
movie_id location_id
573 106
Locations Table
Movie_Locations Table

24. MongoDB Relational Migrator

25. RELATIONAL
MIGRATOR

26. Docker Compose

27. Demo

28. Conclusiones
● NoSQL no significa no relacional
● El ERD sigue siendo importante
● La eficiencia de RDBMS está
disminuyendo
● NoSQL es ideal para la mayoría
de las cargas de trabajo de OLTP
● La API de MongoDB también es
compatible con OLAP

30. Gracias por su
tiempo