Cómo gestionar MILLONES de REGISTROS en la Base de Datos con DDD
HTML-код
- Опубликовано: 4 окт 2023
- Se suele criticar al Domain-Driven Design porque no tiene una buena performance, pero normalmente se debe a un mal diseño de nuestros agregados. Los JOINS de la base de datos nos suelen jugar una mala pasada, al igual que hacer queries que no son por índices.
Curso de Agregados: bit.ly/curso-agregados
﹤🍍﹥ CodelyTV
├ 🎥 Suscríbete: ruclips.net/user/CodelyTV?sub_co...
├ 🐦 Twitter CodelyTV: / codelytv
├ 🧔🏻 Twitter Javi: / javiercane
├ 💂♀️ Twitter Rafa: / rafaoe
├ 📸 Instagram: / codelytv
├ ℹ️ LinkedIn: / codelytv
├ 🥋 Academy: codely.com/academy
└ 📕 Catálogo cursos: bit.ly/cursos-codely 
Наука
Esta volviendo el viejo codely, me encanta.
No digo que me haya dejado de gustar pero estos temas son por los que subscribi y compre codely pro
Buen contenido, dicho eso, ni idea que intentan hacer con sus cabellos.
Clases de estadística Incluida, gran video 🎉❤
De hecho existen las vistas materializadas que precisamente son eso, son tablas creadas a partir de una consulta que pueden actualizarse cada determinado tiempo
Excelente video.. me quedé con ganas de repasar estadística.. tomen su Like..
Genial vídeo y gran información! Gracias! A ponerlo en práctica
Joder, tengo la filosofía de no gastar plata mientras aprendo a programar, pero estos cracks me vencen!
Excelente video ojala a futuro aparte de hablar de la temática, aplicaron algo mas practico al menos para los que no entienden de estadísticas.
Excelente video. Me resulta práctico para la optimizacion de consultas utilizar CQRS. Entonces el modelo de lectura no es necesariamente igual al modelo de objetos del dominio sino esta pensado para consultas puntuales y performsntes
El problema de performance de DDD yo creo que no viene por la lectura, eso además es mitigable con un modelo de lectura, el problema es que DDD no es práctico para un montón de casos de uso, por ejemplo, si tiene forma de crud y huele como un crud no tiene sentido meterle con calzador DDD que está más orientado a acciones unitarias dentro de los agregados. Si usas DDD y lo que estás haciendo carece de lógica de negocio (o tiene muy poca) es una idotez usar dicha metodologia, lo único que vas a hacer es que todo vaya peor y tenga mucho boilerplace.
DDD brilla en algunos casos, pero no es la mayoría ni haciendo 20 backflips y es un error usarlo para todo.
Hay conceptos (que no son de DDD pero están relacionados) como la separacion de los datos por contexto tanto a nivel de la aplicacion como a nivel de base de datos, trabajar con entidades, lanzar eventos, dividir el tipico mega servicio en casos de uso, que son un win/win en la mayoría de casos, luego vienen los backflips que aportan casi nada y son contraproducentes en la amplisima mayoría de escenarios y agregan dificultad a un codigo que podría haber sido sencillo.
Yo empece odiando DDD (porque además las primeras implementaciones que me enseñaron estaban fatal), luego me lo estudie todo (proceso largo y con mucha prueba/error/refinamiento), lo puse en práctica al 100%, vi que cosas aportaban valor realmente y me quede con eso, las cosas que en mi opinion son ruido dentro del codigo, las tengo presentes y se cuando tiene sentido usarlas y solo las usare en ese caso, tirando la vista atrás el resultado final no dista mucho de como hacia las cosas hace unos años y creo que de forma natural podía haber llegado al mismo resultado.
Me parece muy bien ser DDD astronaut, pero la realidad es que en los equipos trabajan distintos tipos de personas, algunas muy buenas y otras muy malas, si tu jefe tiene pensado hacer un equipo con un nivel similar y esta dispuesto a despedir, ok, será como una especie de cribado, pero si no va a hacer algo asi lo siento por el DDD astronaut que vea todos esos conceptos hechos un empastre y se vea sometido a discusiones eternas sobre PRs de decenas de archivos.
De acuerdo
Me gusta
Gran verdad.
Suele pasar que se culpa a la herramienta (DDD) de cosas que tu como desarrollador has hecho mal, pero no lo sabes 😂
¿Podéis contar más en detalle de forma técnica el tema de "aplanar" un dato como el de "ventas en los últimos 30 días"? No termino de verlo funcionar en mi cabeza: necesitas un cron/sistema de actualización en background que te esté actualizando ese dato cada X tiempo. Y si entre actualización y actualización pides el dato es posible que no estés mostrando el dato estrictamente real. ¿No?
Puedes hacerlo con un cron en cuyo caso te recomendaria si usas SQL que pusieses una columna delta (fecha) con un trigger de onUpdate que se actualiza cuando la fila cambia y tener indexado dicho campo, de este modo, puedes permitirte cada segundo preguntarle a la BDD que ha cambiado porque la query te va a salir prácticamente gratis.
También puedes tener eventos que te digan que X cosa ha pasado en tu sistema y suscribirte a esto para recalcular la info
Nosotros tenemos en la base de datos información general de pedidos en relacion a un cliente (cuantos RMAs ha hecho, cuandos Pedidos ha hecho, cuanto ha pagado, cuantos cupones a usado, etc..) y estamos suscrito a un OrderCreateEvent que nos viene de Kafka y también a un OrderUpdateEvent (Realmente está más desgranado el tipo de evento pero es para no confundir), cuando eso ocurre regeneramos la información del cliente, excepto si son clientes de ventas privadas que igual tienen ya 700K pedidos solo con 1 cliente y ese caso preferimos calcularlo de otra manera (básicamente nos guardamos que esos clientes deben recalcularse , se procesan cada X minutos y en tiempo real hacemos un calculo de lo que es viable calcular en tiempo real)
Le llaman aplanar, nosotros de siempre le hemos llamado congelar un dato, tomas información de X sistemas, la calcular y la persistes.
Similar a eso, por ejemplo tenemos para poder navegar facilmente desde el backoffice entre las decenas de millones de pedidos que tenemos en el sistema un ElasticSearch que podria decirse que se nutre de la misma manera, tiene información congelada de muchos sistemas distintos (SGA, ERP, Ecommerce, MarketPlace, Customer, etc...) y los "congela" de modo que sean "index friendly", es decir, que luego el dato se pueda indexar (mapping en terminologia de elastic) y que pueda usarse correctamente para buscar, ordenar, etc... Por ejemplo si quiero buscar clientes de la tienda de Alemania, que son Profesionales, que se registraron este mes, que tienen un ticket pendiente de más de 24H que nadie ha atendido sobre un pedido de más de 2000€, para darle prioridad absoluta no tiene sentido tener que preguntar a customer por unas cosas, a customer care por otras y a order por otras, sería en tema performance inusable (imaginate, igual clientes profesionales de alamenia tenemos 70K, tickets pendientes en las ultimas 24K igual tenemos 5K y pedidos de más de 2000€ igual tenemos 2 millones, pero la union de las 3 igual solo tenia que devolver 20 filas) y todo son busquedas de normalmente 0.2-10ms (salvo que se pidan cantidad de filas altas, en cuyo caso es más tema de trafico que otra cosa)
no hace falta un cron-job especificamente, solamente cada vez que se cierre una venta desde el marketplace disparas un mensaje de dominio y el servicio correspondiente a ventas estaría escuchando esos mensaje y obtendría el valor de esa venta actualizando el total de ventas para ese producto/vendedor en tiempo real, en caso contrario de haber una devolución vuelves a disparar otro mensaje de dominio desde el servicio de la tienda online y en el servicio de ventas restas el monto a la facturación de ese vendedor, si te quieres poner exquisito y en el momento que estas viendo los datos se cierra una venta entonces dede la app cliente te subscribes mediantes socket o un hub al backend y, cuando se acutalize el valor lo muestras.
Al grano 😅
salid de casa