Bene e benvenuti su Gitbar, nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori.Questa settimana insolitamente registriamo la mattina e sono con Leo, uno dei più mattinieri del Gitbar, no? Ciao Leo! Sì sì, io sono già quasi stanco, andrei quasi a dormire adesso, tanto sono sveglio.Sì sì, ricordo dalle ultime conferenze che abbiamo fatto insieme che la tua sveglia suona ancora prima del gallo e tu praticamente alle 10 hai già fatto mezzogiornata.Sì, più o meno, tranne quando le serate dei meetup finiscono tardi.No, posso confermare che anche quando le serate dei meetup finiscono tardi, perché io ricordo un meetup finito in tragedia e domani mattina Leo alle 6 era in palestra.Ah sì è vero, è vero.C'era la palestra nell'hotel e andava sfruttata.Io non so con quale forza d'animo, io mi sono alzato a mezzogiorno, però va bene lo stesso.Vabbè, poi sono tornato a letto dopo, non è che...Eh vabbè, però chapeau.Beh, a parte le nostre chiacchere personali, dobbiamo introdurre l'argomento della giornata, Leo, no? Sì, sì, questo è stato un argomento fortemente voluto dalla community, no non lo so diciamo abbiamo preso l'opportunità di chiamare una persona che lavora in MongoDB che non fossi io che fosse un pochino più skillata sulla tecnologia di MongoDB per raccontarci un po' di cose su questo splendido prodotto benvenuti su Gitbar il podcast dedicato al mondo dei full stack developer i mezzo artigiani, i mezzo artisti, che ogni giorno infilano le mani nel fango per creare, nel modo più efficiente possibile, quei prodotti digitali che quotidianamente usiamo.Buongiorno a tutti! E allora è il momento di presentare, ciao Matteo! Ciao, ciao a tutti, buongiorno! Ciao collega, buongiorno.Leo vuoi fare una presentazione a Matteo? Sì, brevissimamente.Matteo Sassi, italianissimo di Milano se non sbaglio.Però tanto noi siamo tutti distribuiti quindi la location non è importante.Ed è un solution architect a MongoDB.Io inizio subito con la domanda.Che cosa fa un solution architect? Questa è un'ottima domanda, è una risposta piuttosto allargata.Comunque, sostanzialmente quello che faccio io è sostanzialmente disegnare architetture, quindi il mio mestiere riguarda raccogliere requisiti, capire la fattibilità dei progetti, è un'attività a cui facciamo molta attenzione, quindi andiamo Quando si parla di progetti studiamo a fondo tutti i vari requisiti ed effettivamente poi l'applicabilità e i vari benefici di MongoDB e sostanzialmente il mio mestiere riguarda questo, quindi la fattibilità dei progetti, il disegno delle architetture e poi tutta quella parte che prevede l'inizio dei progetti e portare chi decide di utilizzare MongoDB progetti che funzionino bene in più delle volte.Quindi un mix tra tecnico e commerciale anche? Sì, la classica pre vendita mettiamola così una volta si chiamava pre vendita adesso è più adesso è solution architect sicuramente più votata la parte tecnica.Volevo chiederti tu tu di progetti ne vedi parecchi perché comunque il tuo tipo di consulenza diciamo ti porta a ragionare su progetti differenti ma ti è mai capitato di vedere un progetto, non ti chiediamo il nome tranquillo, senza capo né coda da dire "eh vabbè sì ma siete sicuri?" Diciamo che può capitare, come ti dicevo prima stressavo la parte di fattibilità, quindi può capitare, sostanzialmente magari spesso riguarda le skill o la volontà del cliente poi effettivamente di mettere a terra una nuova tecnologia, ma sostanzialmente sì, può capitare.Adesso casi d'uso specifici per dirti non è che dici "ah guarda, uno mi chiede di fare IoT o quant'altro, non va, funziona alla grande e lo facciamo in in continuazione.Magari quando uno vuole fare un big data, classico big data, puramente analitico, ecco magari noi ci concentriamo di più sui dati veloci, quindi questo è un pochino la parte dei vari studi.Al di là della tecnologia stessa, sempre ritornando sul ruolo invece del solution architect, quali sono le tecniche...allora fondamentalmente tu ti trovi a lavorare in situazioni dove ti devi confrontare con altri...anche altri architetti, no? Gli architetti che poi la società mette a disposizione ed è necessario per te quello di andare a costruire un ponte comunicativo produttivo, proficuo per entrambi i lati.Quali sono le difficoltà e quali le tecniche che utilizzi nell'instaurare questo percorso di comunicazione? Guarda, lo scambio più classico che avviene è con i DBA, spesso, che magari vengono da un mondo relazionale, quindi sono abituati a ragionare sui dati in un certo modo, con i classici crismi del relazionale, e sicuramente gli scambi più interessanti avvengono in senso con queste figure, perché sai che MongoDB ha un data model diverso basato a documenti, JSON e vengono fuori le classiche domande sull'acidità, sulla consistenza delle informazioni, ma come faccio a fare questo o quell'altro, perché giustamente è gente, come dicevo, che è abituato a ragionare in vari crismi.Il vantaggio che ho io in questo contesto è che, avendo lavorato tanti anni in un modo relazionale in un'azienda molto...- Al limite la bippiamo! - Ok! - Hai scritto sul tuo LinkedIn? - Sì, sì.- Allora lo puoi dire.- Vado.Ho lavorato tanti anni in Oracle, e quindi di database relazionali, sistemi ingegnerizzati e quant'altro ne ho visti tanti.Parlano la loro lingua e quindi quando si parla appunto di consistenza, di acidità, trigger, PL/SQL e compagnia cantante, alla fine è un dialogo tecnologia su tecnologia, riusciamo a comprenderci.Scusa, una domanda, visto che te hai lavorato in entrambi i mondi, sono insieme i disgiunti le soluzioni che si possono applicare con un database SQL e un NoSQL o possono risolvere gli stessi problemi? Guarda, questa è una domanda interessante, Allora, risolvono gli stessi problemi, il punto è sul non funzionale, quindi alla fine MongoDB è un database general purpose e Oracle è un database general purpose, quindi c'è un grosso insieme di soluzioni che possono essere indirizzate con entrambe le tecnologie.Il punto è l'idea alla base con cui sono state fatte le tecnologie, alla fine un database ci metti dentro i dati e ti ripori i dati.La grossa differenza secondo me, giusto per tornare al punto di prima, un grosso punto di partenza è settare le basi.Se sei abituato a fare query complesse a piacere, fai query complesse a piacere con MongoDB.Se sei abituato a gestire il dato con strong consistency e via dicendo, strong consistency ce l'hai.gli indici sono gli indici, quindi sicuramente ci sono tanti punti in comune.Come dicevo, la differenza tra i due sostanzialmente è la base con cui sono stati pensati, quindi da una parte è il relazionale che spinge molto verso l'efficienza del dato e la rappresentazione del dato in sé.Dall'altra, MongoDB spinge molto verso i nuovi requisiti che sono saltati fuori negli ultimi anni, poter andare più o meno ovunque, da Z-Linux al Cloud, ai vari Cloud, piuttosto che gestire enormi moli di dati, piuttosto che fare applicazioni mobile, archiviare dati, integrare dati esterni, sono tutte cose che gli sviluppatori oggi si trovano tutti i giorni ad affrontare.La differenza è che MoVDB essendo nato in questo mondo è pensato alla base per fare queste cose.Altri database che sono sul mercato da molto più tempo sono nati con un'architettura che ai tempi era per risolvere altri problemi, banalmente che 10 giga di storage ti costavano un sacco di soldi, invece adesso il collo di bottiglia è la produttività degli sviluppatori, quindi è la differenza alla base, poi molte cose le puoi fare con un database relazionale come le fai con Mongo, la differenza è in quanto tempo lo fai e quanto facilmente fai evolvere l'applicazione.Ecco, volevo fare un esempio, visto io per lo più ho sempre lavorato con database relazionali, faccio il classico esempio di un e-commerce che ha utenti, prodotti e ordini, mi viene molto facile pensare tre tabelle, pensare le relazioni tra gli ordini, gli utenti, eccetera eccetera, per poter tirare fuori sia tutti gli ordini di un utente che tutti prodotti di un ordine o varie altre cose.In MongoDB una cosa del genere, come si potrebbe strutturare? Cioè, immagino, faccio un esempio, io ho il documento utente, ci attacco dentro gli ordini, ma poi posso fare query sugli ordini lì, oppure li devo salvare anche in una collection di ordini memorizzando anche gli utenti? Certo, guarda...E mantenere sincronizzato il tutto? Ecco, questo voglio capire come si comporta Mongo, quale sarebbe una struttura ideale.Conto una cosa, il modo con cui si modellano i dati in MongoDB è diverso da come si modellano i dati in un relazionale, il modo in cui vado a pensare a come vado a creare il data model.Se in un relazionale è importantissimo sapere quali dati vado a gestire e la relazione tra vari dati, quindi classica tabella utente con relazione 1n su indirizzi di spedizione e relazione 1n su ordini e fatti, che poi sarà relazionata a prodotti, stock e compagnia cantante.In MongoDB non è tanto quello, ovviamente i dati sono importanti, i dati e indici, ma teni presente che essendo documenti JSON è molto facile cambiare i dati che sono dentro, non devi agire quasi nessun modo sul database, semplicemente a un certo punto metti dentro le collection documenti che hanno dati diversi, MongoDB va avanti.La differenza quindi quando modello i dati è pensare a come accedo i dati.La regola base è che dati a cui accedo insieme devono stare insieme, Quindi esempio, come modello l'utente? Modello l'utente con un documento utente che ha tutti i campi che descrivono l'anagrafica, qualcuno avrà campi diversi, quindi magari voglio rendicontare il fatto che qualcuno ha un animale domestico per dire alcuni documenti avranno il campo animale domestico, alcuni documenti non ce l'hanno, perché molti utenti non hanno l'animale domestico.E poi magari gli indirizzi, non so se siamo tutti abituati a usare e-commerce, ormai ognuno ha 4 o 5 indirizzi di spedizione a seconda di dove si trovano, quindi tipicamente ci sarà all'interno del documento un array che contiene tutti gli indirizzi della persona.Quando la mia applicazione deve accedere all'utente, accede al documento e automaticamente a tutte le informazioni che gli interessano nella stesso campo, diciamo tutte insieme.Questo poi porta ad un enorme vantaggio che vi dico magari tra un attimo.Gli ordini, l'elenco degli ordini effettuati, dipende poi dalla cardinalità.Quindi se io penso alla mia storia dell'e-commerce, ho migliaia di acquisti fatti, delle cose più stupide, questo magari può portare a, diciamo, vale la pena magari fare una collection degli ordini diversi e linkarla all'utente, no? Ma spesso magari quando accedo alla mia pagina voglio vedere gli ultimi dieci ordini fatti quindi posso fare documento utente con l'array degli indirizzi e l'array degli ultimi dieci ordini fatti quando tiro su il documento utente ho tutto insieme Ci sono tanti pattern, poi ci sono dei pattern che documentano la modellazione, il punto è che devo modellare i dati nel modo più efficiente per sviluppare l'applicazione.Ecco, ma se a un certo punto cambia o si evolve l'applicazione, esempio, voglio vedere quanti utenti hanno un indirizzo di spedizione a Firenze, io ce l'ho salvata nel documento utente, Posso fare una query che sia abbastanza ottimizzata direttamente sugli indirizzi degli utenti o a quel punto mi conviene spostarli? Il link che dicevi è mettere un Object ID in un campo e poi fare una specie di relazione non database? Esatto, è una classica chiave esterna che poi posso fare in join, che in MongoDB si chiama lookup, l'operatore.Per quanto riguarda fare query complesse a piacere non c'è problema, il linguaggio di interrogazione di MongoDB si chiama MQL e permette di fare query su complesse a piacere, su qualsiasi tipo di dato, a qualsiasi profondità nel documento Un'altra cosa interessante sono gli indici, perché sono pensati per JSON quindi posso indicizzare valori sotto documenti, valori in array, tutto quello che mi esprime JSON, la libertà di esprimere JSON, la posso indicizzare e posso sfruttarla per le query.Quindi poi devo fare analytics, ad esempio dammi l'elenco degli acquisti fatti per regione, Cose di questo genere esiste, un modo di interrogare i monodivisi si chiama aggregation framework, crea delle pipeline di interrogazione, i documenti vengono processati stadio per stadio, quindi molto facile da leggere, molto vicino al modo di pensare degli sviluppatori, non dei classici DBA, è molto facile da far evolvere e manutenere, perché appunto sono uno dietro l'altro, cambia il requisito cambia lo stadio.Quindi con quelli faccio trasformazioni, viste materializzate, analitics complesse a piacere e via discorrendo.Questo è forse uno dei valori più potenti di MongoDB, la possibilità di interrogare con modalità custom.Sì, infatti su Compass stiamo lavorando molto sulla parte di aggregation.È difficile fare un'interfaccia utente, è abbastanza complesso, però insomma visto i nostri utenti, almeno nel team dove sono io, i nostri utenti sono sviluppatori, diciamo riusciamo a metterci nei loro panni e capire più o meno cosa vogliono e poi si raccoglie feedback.Prima hai parlato di linguaggi di interrogazione e noi sappiamo che MongoDB ha il suo linguaggio per fare le query.Quanto l'avere un linguaggio diverso dalle SQL classiche, base, è stato un ostacolo per l'adoption e quanto invece è stato un valore aggiunto che ha permesso di fare delle cose che magari con il buon vecchio SQL venivano complesse, verbose o via discorrendo? Allora io la vedo come un enorme vantaggio perché, tieni presente, MongoDB nel suo suo intimo è pensato da sviluppatori per sviluppatori.L'SQL è potente a piacere, cioè è SQL, non lo voglio dire, è in piedi da 40 anni probabilmente, però ha uno svantaggio che è basato sull'algebra relazionale, quindi logica degli insiemi, sei costretto ragionare le quire sequelle complesse e le ragioni dall'interno verso l'esterno.Non è così che ragionano gli sviluppatori che hanno un approccio procedurale, dall'alto verso il basso.Ovviamente c'è un piccolo scoglio che devi imparare la sintassi, ma è sempre JSON alla fine della fiera, anche l'aggregation framework è espresso in JSON.Devi imparare un po' la sintassi, che poi è una cosa che impari abbastanza in fretta se sei abituato a gestire i dati, ma poi ha degli operatori potenti a sufficienza poi da essere super apprezzato.Un po' un tip in point è quando magari traduciamo SQL complessi in equivalenti in aggregation framework.la gente vede come funzionano, è auto esplicativo, è molto chiaro da leggere e di solito è il punto di volta per apprezzare e iniziare ad utilizzare MongoDB.Aggiungo una cosa che poi in realtà cambia molto la vista e la situazione.Abbiamo parlato di documenti, abbiamo parlato di oggetti di contenuti informativi, consistenti, autocontenuti che alla fine, se ci pensate, si mappano quasi automaticamente, voglio dire logicamente, con gli oggetti utilizzati nelle applicazioni.Questo consente a MongoDB di fare una cosa, di fare a meno di un ORM, cioè si fa a meno di Ibernate per intenderci.il driver di MongoDB in Java ad esempio è in grado di tradurre automaticamente un documento in oggetti e l'oggetto in documento varia il documento, varia l'oggetto, varia l'oggetto, varia il documento poi posso controllare lo schema ovviamente, se uno si mette a scrivere roba che non prevedo posso fermare la scrittura o fare un alert questo perché posso scegliere il livello di formalità o di agilità della mia applicazione però se ci pensate, soprattutto in approcci agili, l'ORM è un oggetto che introduce sempre un po' di ciclo a cascata lo sviluppatore pensa alla nuova applicazione, deve pensare a come cambiare l'Ibernet e deve pensare di conseguenza a come cambiare il data model finché non ho cambiato il data model non posso cambiare l'Ibernet, finché non ho cambiato l'Ibernet non posso cambiare il data model.Quindi all'interno di un DevOps in cui evolvo ciclicamente naturalmente c'è sempre questa interdipendenza.Togliendolo RM e ragionando a documenti, ragionando con l'aggregation framework, diventa tutto estremamente più agile.Tu che hai avuto modo di vedere diversi casi d'uso faccio un passo indietro, una premessa.Questo tipo d'approccio prevede una responsabilità nello strutturare il data model che deve essere esplicita formalizzata nel senso che grandi libertà derivano anche delle grandi responsabilità cioè è facile se non stai attento fare un bordello con i dati che vai a salvare quindi dal tuo punto di vista quali sono le buone pratiche adottare nello sviluppo di un'applicazione tenendo presente che devi inserire delle regole e in questo caso le regole se ho capito bene le metti la tua applicazione non la tua database.Prima costruivi lo schema delle tabelle, oggi ti vai a costruire il tuo data model nell'applicazione.Allora sì il punto di partenza è senz'altro l'applicazione ma banalmente perché come vi dicevo la regola principale nella modellazione dei dati è è che i dati che vengono acceduti insieme devono stare insieme.Quindi alla fine se ci pensi i dati che vengono acceduti insieme lo definisci nell'applicazione sostanzialmente, nel comportamento che ha l'applicazione.Come dicevo prima l'esempio dell'e-commerce, se vendo cose enormi, stimo che ogni utente acquista un numero limitato di oggetti, io l'array degli acquisti lo posso tenere nel documento dell'utente.se ogni utente fa migliaia di acquisti probabilmente ha senso fare una collection separata quindi stesso requisito, stesso modello dati voglio dire stessi dati da gestire probabilmente in un relazionale porterebbero in entrambi i casi allo stesso data model qua hai più scelta a seconda effettivamente delle performance di quello che fai dei dati e di quanti sono Non dimentichiamoci buone pratiche, esistono, lo dico sempre, poi usare MongoDB non è fantasia al potere, che ognuno scrive quello che gli pare e grociamo le dita che la roba funzioni.Esistono delle best practice formalizzate, che sono i design pattern, c'è il blog di Moog ODB che li elenca, c'è la University che ci fa i corsi sopra e via dicendo.Quindi esistono modi di modellare i dati e sono documentati.Prima best practice, fare riferimento ai pattern.Ci sono i blog, sono documentati, prima best practice è quella.Seconda cosa, non dimenticarsi che esiste comunque la possibilità di aggiungere una schema validation.Quindi, ripeto, non è fantasia al potere, o non è necessariamente fantasia al potere.Io posso sempre, lato database, validare che quello che viene scritto è quello che mi aspetto nella mia collection.quindi le prime due best practice che consiglio sempre è leggiti pattern e lavora con lo schema validation postilla, lo schema validation è pensato per evolvere nel tempo quindi io parto con lo schema 1, versione 1 e poi posso farlo evolvere alla versione 2, 3, 4 Siccome i documenti sono flessibili, i documenti versione 1 possono non soddisfare lo schema versione 2, ma MongoDB permette comunque di gestirli tutti insieme.Terzo punto, gli schemi sono interrogabili, quindi io posso fare una query per dire "trovami tutti i documenti nella mia collection che non soddisfano lo schema nella nuova versione" e posso magari farci azioni per sistemarli.Quindi, non lo so, una buona idea che mi viene sempre a dire è che alla fine MongoDB ha tutti gli strumenti per sviluppare dei SaaS facilmente.Un software as a service cosa fa? Deve stare sempre in piedi, deve gestire enormi quantità di dati, accessi variabili e con picchi pazzeschi, se hai una larga audience, spesso difficilmente prevedibili e deve continuamente evolvere.Ci hanno abituato ormai, mi collego ai famosi dispositivi applicativi di streaming, video, e via dicendo, o e-commerce, ogni 2x3 c'è una nuova funzionalità.Non si deve fermare.Dall'altro lato penso agli applicativi, magari il mio home banking l'altro giorno mi ha notificato una finestra di manutenzione programmata di sei ore.Mi ha dato fastidio! Quindi i requisiti stanno evolvendo e di conseguenza bisogna strutturarsi, di conseguenza il nostro vantaggio che ci viene riconosciuto è che MongoDB nasce in questo mondo e con questo nativamente offre soluzioni per questi problemi.Ciao, io sono in ritardo anzitutto quindi vi saluto a tutti e saluto come al solito gli ascoltatori del bar, ma ho una domanda e volevo riagganciarmi a quello che dicevi prima rispetto al blog di MongoDB, alle best practice e in generale al tema della formazione, nel senso che io come una buona parte degli sviluppatori anziani che adesso fanno questo mestiere ho studiato SQL all'università e quindi per quanto lo detesti, per quanto lo detesti Sì, io ce l'ho un po' incastrato nella testa.Non faccio fatica a ragionare in SQL, tuttora, perché non sono un DBA e perché non mi piace.Ma non ti dico che mi viene spontaneo, però lo conosco, so fare delle query anche infami.Per fare la stessa cosa con MongoDB, ho dovuto farlo da autodidatta, perché a un certo punto mi sono detto "Ah, MongoDB sembra figo".Ci ho fatto un progetto parallelo che faceva della data viz con l'aggregation framework e l'ho imparato and so on.Ma mettiamo caso che io invece sia...mettiamo caso che il mondo sia molto più bello e io sia molto più giovane.E quindi stia iniziando adesso a imparare a usare un tool nuovo.Quali sono, secondo te, i...come è fatto il learning path di MongoDB, secondo te? dove lo imparo, come lo imparo e come faccio a diventare cintura nera di MongoDB senza dovermi fare venire il mal di testa che mi sono fatto venire io all'epoca, premesso che io se va molto bene sono cintura arancione di MongoDB.Eh già, non male, dai! è gialla insomma.Allora, guarda, questa è una domanda interessante e dipende poi dal progetto in cui ti trovi e dal tempo che hai di conseguenza per realizzare il progetto e la criticità di un errore nel progetto e via discorrendo.Nell'ipotesi, partiamo da un caso, nell'ipotesi mega progetto, super strategico, l'azienda che si fonda su questo progetto e via discorrendo.In quel caso auguri.In quel caso auguri, ma ci sono in realtà i professional services di MongoDB, che è gente che mastica MongoDB da quando è nata, l'ha visto applicare in qualsiasi cosa, queste persone sono in grado di fare formazione, di fare sviluppo, di fare consulenza, dalla A alla Z, conoscono veramente in maniera estremamente intima il tool con esperienze di casi pratici, best practice e quant'altro.Quindi nel caso di appunto un mega palazzo da costruire in due settimane, con questa gente porti a termine il progetto con best practice e con competenze, perché poi fanno i corsi, fanno il trasferimento di competenze e quant'altro.Ho visto veramente fargli fare delle magie, quindi questa è la prima questione.Andando verso più tempo, meno criticità e quant'altro.Il mio consiglio è la University.La University di MongoDB è strutturata bene per learning path, sono tanti video rapidi e estremamente sul pezzo ed estremamente chiari.Quindi io posso non farmi tutto il learning path del developer che mi spiega dall'A alla l'aggregation framework, la gestione dell'alta affidabilità delle sessioni, ma problema specifico, video specifico, quindi posso anche andare cherry picking sui corsi.La university poi è, quando uno ha una sottoscrizione Atlas è liberamente accessibile, ma è facilmente accessibile la university, quindi tanti corsi, li faccio quando voglio, ci sono le certificazioni, c'è certificazione per DBA e per developer con il loro learning path e quant'altro, quindi anche seguire quel percorso con la study guide, quel percorso è sicuramente valido.Terzo fattore, esistono tanti libri, tanti libri anche liberamente accessibili che spiegano tutto quanto.ce n'è uno nello specifico, che poi magari vi mando, vi consiglio, è liberamente accessibile, l'ha scritto un mio collega, nel senso che è uno dei, nel senso che lavora, è anche di Leonardo, è della stessa azienda nostra, ma è uno dei padri fondatori di MongoDB, che descrive proprio l'applicazione pratica dell'aggregation framework, che è poi, come dicevo il tipping point, con quello effettivamente un libro online abbastanza contenuto ma che dà un'enorme quantità di best practice e di modi facili per iniziare a usare e per andare a fare cose molto specifiche con l'aggregation framework.Una volta che si capisce l'aggregation framework è tutto in discesa.L'ho, me lo segno.Sì sì.Io devo ammetterlo, vengo dal mondo relazionale quindi porto anche quella forma, quella forma Mintis.Leggevo un po' in giro e approfondivo un attimino e mi sono trovato davanti alla famosa domanda che hai citato prima tu, quando ti arrivano delle persone che vengono dalla formamenti israelazionale e ti chiedo visto che da quello che mi è sembrato di capire non c'è un supporto alle transazioni multioggetto esiste un modo per uviare a questo tipo di problema? Se vuoi la tagliamo eh? No, no, no, no, no, fermi tutti.Le transazioni multi oggetto, io la dico come transazioni multi documento, ok, perché mediamente un oggetto è un documento, transazioni multi documento sono iper supportate, ma da tanto.Questa qui è una domanda fantastica, spesso mi ritrovo a gestire questo punto, ma sono tanti anni che MongoDB supporta transazioni acide di tanti documenti tutti insieme, quindi esecuzione all or nothing, poi a me piace anche entrare, sai che si dice acidità, poi ogni lettera ha un suo significato, quindi atomico ok, all or nothing, e poi ci sono consistenza, isolamento e persistenza, quindi italiano sarebbe "acip", però suona male.Poi quando uno va a vedere ci sono tante cose da verificare per ognuna di queste.La più importante probabilmente è l'isolamento, perché poi va a toccare anche la concorrenzialità.Quindi quanta gente può agire su quanti documenti senza che il database sia fossi in una marea di lock, di come dire, di lock, i famosi deadlock appunto.Allora conta che, giusto per, l'implementazione delle transazioni in MongoDB è fatta con la snapshot isolation come siamo abituati da Oracle.Tra l'altro abbiamo collaborato, diretto, fun fact, collaborato direttamente con chi negli anni al suo tempo aveva inventato il concetto di snapshot isolation, quindi è entrato proprio a far parte del design team di MongoDB.Quindi snapshot isolation ci permette di gestire le transazioni con atomici carichi.La puoi descrivere in un minuto cos'è una snapshot isolation? Per quelli del pubblico non lo sanno tipo me.Ok, guarda nel momento in cui apre una transazione MongoDB si crea un mondo parallelo per quella transazione dove lavora sui suoi dati come se fosse da solo.Questo è la snapshot isolation, cioè vivo nel mio db come se fossi da solo.Quando faccio commit, diciamo, le gomme del carrello toccano terra, quindi vado a verificare cosa è successo mentre il database continuava a lavorare.E qui è dove entra il concetto di isolamento.Quindi a seconda dei vari livelli di isolamento, se voglio prediligere la concorrenzialità, posso permettere ad altri utenti di scrivere dei dati, gli stessi dati che io mi ero riservato nella mia snapshot.A seconda dicevo del livello di isolamento scelgo chi dei due fallisce, cioè o fallisce la mia transazione perché nel frattempo sono cambiati i dati o diciamo le altre persone non possono scrivere quei dati perché me li sono riservati.Si va da nessun isolamento alla serializzabile, che è il livello massimo di isolamento dove ognuno lavora come se fosse da solo sul database e tutte le operazioni sono ordinate nel tempo.Ditemi se sto partendo per la tangente.Assolutamente, tra l'altro ci tengo ad aggiungere un libro che consiglio, alla fine sto consigliando a ogni puntata che è "Designing Data Intensive Application" dove queste cose sono spiegate molto molto molto bene.Questo è uno dei libri fondanti della formazione necessaria, ti ringrazio per averlo citato.Il bello qual è? Che puoi scegliere tu il livello di isolamento a seconda della importanza dei dati che stai scrivendo e a seconda del livello atteso di concorrenzialità.Ovviamente se sei nel mondo finanziario ci stai molto attento a quello che scrivi, se sono transazioni finanziarie, date di pagamento, è importantissima la consistenza che è figlia poi dell'isolamento, quindi userai livelli di isolamento importanti.Se sono applicazioni, un social network, una una cosa dove è più difficile, dove ci sono tantissimi utenti contemporanei, ma è difficile che scrivano gli stessi dati, ovviamente vado per isolamento inferiore, per prediligere le performance.Lo posso scegliere molto facilmente e con questa flessibilità è uno dei valori aggiunti che portiamo.Mattia, Leo avete qualche domanda? No per ora.Alla ne ho una io e faccio anche la marchetta.Sto preparando il talk per il nuovo Codemotion.Parlerò di Supabase.Supabase è un back-end da service fatto on top di Postgres.Poi faremo anche una puntata su questo.Però una cosa che ho trovato super interessante è un concetto chiamato "Raw Security Level" cioè la possibilità di "securizzare" non so se in italiano è è un obrobrio ma passatemelo una certa...un certo record per un certo utente.La parte di definizione dell'utente con Postgres si fa utilizzando dei trick, delle sorte di variabili globali, c'è tutto un giochetto ma la mia domanda è siccome è una feature molto figa questa perché alla fine diciamocelo noi siamo pigri e delegare tutta la parte di autorizzazione, accesso ad alcune porzioni di dati al database diciamo ci solleva di una certa responsabilità e soprattutto anche di una certa mole di codice da scrivere e ti volevo chiedere c'è qualcosa del genere in MongoDB? Ci sono diversi modi e strati per rispondere a questa domanda La sicurezza in MongoDB è basata su, come tutti i database, Authentication, Authorization, Auditing e Encryption i vari strati.Quindi chi entra, chi è, può entrare e vabbè c'è user, scrum, quindi user e password, x509, led up, Kerberus e via dicendo, no? Oauth, Samel, Samelle, non ho mai capito come pronunciare, scusate.Poi c'è la parte di authorization, questa qui è quella più legata a quello che mi stavi dicendo, che è il classico role based access control, quindi entro, posso entrare, non posso entrare, posso scrivere, non posso scrivere, posso vedere.Lo faccio a livello di collection, questa parte qua, quindi la collection è il contenitore dei documenti se vogliamo il nipote delle tabelle relazionali.Quindi posso andare a dire il gruppo utenti X non può vedere scrivere quella collection.Poi c'è l'auditing, quindi chi fa qualcosa lo vede, e poi c'è l'encryption.Non c'è un concetto di lock, come dicevo prima prima nella transazionalità il lock avviene a livello di singolo documento, quindi questo qui per il concetto di transazionalità prima.Per il concetto di sicurezza del singolo documento noi abbiamo al netto di chi può accedere, che è a livello di collection, c'è un tema di visibilità, quindi chi accede a quel documento, quanti campi può vedere di quel documento in base al suo livello di sicurezza e per dire l'aggregation framework, dicevo, molto utile e molto potente tra i suoi operatori e l'operatore Redact che automaticamente ti permette di taggare il livello di sicurezza dei campi e di vedere solamente quello che tu come utente hai diritto di vedere in base ai tuoi diritti di accesso.E lo fa automaticamente, mettiamola così.Quindi visibilità, siamo a posto.Poi c'è un altro tema, una cosa che facciamo è l'encryption dei singoli campi o dei singoli documenti con delle chiavi specifiche che possono essere legate all'utente.Quindi quando io scrivo un documento come utente, ci voglio accedere solo io o magari quel documento contiene dei dati sensibili di cui voglio dare la protezione, faccio in modo che il driver di MongoDB, che come detto traduce anche un oggetto intelligente il driver di MongoDB, ha funzionalità estese, permette anche di automaticamente prendere una chiave specifica da un key vault, criptare quei dati e a quel punto quei dati sono scritti criptati.Se ci va uno che non ha quel criterio di accesso, che non ha quella chiave, quel campi non ci capisce niente.Sempre per pigrizza degli sviluppatori e per necessità che adesso ci sono, il diritto all'oblio con GDPR e compagnia cantante.È difficile, lo puoi fare forse sul db di produzione con i dati live non si riesce mai a fare sul backup, quindi questo può dare dei problemi.Se noi usiamo questa funzionalità e usiamo una chiave per utente, nel momento in cui l'utente esercita il diritto all'oblio io do fuoco alla sua chiave e ho fatto il diritto all'oblio per tutti quanti i suoi dati.Quindi non so se ho risposto alla tua domanda, ci sono diversi livelli, poi la sicurezza bisogna esattamente capire il requisito.Ma mediamente, quello che posso dirti è che mediamente con un insieme di questi meccanismi veniamo usati tantissimo in applicativi di tipo sanitario, di tipo bancario, con dati estremamente sensibili di cui bisogna fare un enforcing estrema della sicurezza e riusciamo a soddisfare i vari requisiti.Assolutamente sì, hai risposto alla mia domanda anche se con una prospettiva diversa.Questa cosa della chiave è un approccio diverso da come lo immaginavo, è comunque molto interessante.Ti volevo chiedere invece, per quanto riguarda la replica, come funziona? Anche questo è un punto che quando parlo con colleghi relazionali, diciamo, crea sempre… La rottura delle relazioni.Infatti, era una domanda che ti volevo fare anch'io e la side question che ti volevo fare era "ma quanto ti rompe le palle da 1 a 10 la gente che ti chiede le cose pensando relazionale e tu invece devi spiegargli un mindset diverso.Guarda, onestamente...E perché proprio 15? Onestamente poco, perché è lo stesso percorso che ho fatto anch'io.Io ho iniziato a lavorare in MongoDB un anno fa e, come dire, poco prima festeggiavo l'installazione di un sistema ingegnerizzato.È stato un percorso duro.Le discussioni allo specchio, gli schiafi contro un vetro.Esattamente.Come dire, la replica è come gestiamo l'alta affidabilità.Io faccio sempre parallelismo con Oracle, perché è quello che conosco meglio.Se noi siamo abituati a pensare a Oracle, Oracle come fa l'alta affidabilità? La fa col RAC e la fa con il Data Guard.Fermatemi se dico cose che non si capiscono.Ma guarda, sopra la mia testa c'è la scimmietta che batte i piatti alla Homer Simpson, non so se è presente l'immagine.Perfetto, perfetto.E io ti invidio perché queste cose di Oracle volevo non saperle e invece… E invece ti tocca.Andando più diretti, MongoDB come fa l'altrifiabilità? La fa con il replicaset, molti altri database, il concetto poi di replica su più macchine completamente isolate, a differenza del rack di Oracle che condivide lo storage per intenderci, quindi simile al DataGuard se vogliamo, replica su altro datacenter o nello stesso datacenter e via dicendo.Quindi un MongoDB in alta affidabilità è fatto da tre nodi in replica tra di loro, tre nodi in replica tra di loro, niente di troppo nuovo sotto al sole, minimo tre nodi, ne posso mettere fino a 50 e distribuiti in data center in giro per il mondo.E poi è fatto con il concetto di primario, secondario, secondario.A differenza di altri non ha il multi master, a meno che non fai sharding.Non mi spoilerare la prossima domanda sullo sharding.No no no no no no.Quindi tu cosa fai? Scrivi sempre sul primario, questo ti consente di fare strong consistency dei dati.Scrivi sempre sul primario, gli altri due secondari sono in replica.In replica come? Con un algoritmo, scusate, con un protocollo di comunicazione diciamo efficiente a piacere, sempre layer 3, perché così andiamo in cloud, andiamo dove ci pare, a differenza di altri più datati che magari usano layer 2, che vincono ad usare cloud specifici o soluzioni specifiche.Questo protocollo fa sicuro, criptato, compagnia cantante.Ogni volta che scrivono il primario i dati vengono replicati nei vari secondari.Con che latenza, con che requisito di consistenza del dato, di aggiornamento del dato, lo scelgo io.Lo scelgo io quando scrivo il dato.gli dico "guarda, write concern è il concetto di questo tipo di replica, majority, quando scrive un dato, lui aspetta il commit dalla maggioranza dei nodi di un replica set prima di dare commit all'applicazione".In questo modo so che il dato è durabile perché è già replicato.Posso sceglierlo, se devo prediligere la performance, magari dico ok dai comic subito una volta che l'hai scritto te primario subito dopo sincronizza gli altri ok oppure di cinque nodi dammi il comic quando l'hai replicato su due che non è la maggioranza ma è sempre meglio di uno lo posso scegliere in base a cosa lo scelgo in base alle performance che devo dare dell'applicazione parlavo parlavo l'altro giorno di rapplicazione di sensoristica per il lancio di razzi nello spazio.Questi sparano, quando avviene il lancio, sparano 8 milioni di dati al secondo.Sta roba devi fare in gestione.Quindi magari fai un bright concern più lascolo.Oppure dati bancari...Se posso, scusami, ti interrompo un secondo per aggiungere la mia storia personale, nel che io ho avuto un problema esattamente identico dieci giorni fa o la settimana scorsa addirittura.Avevo appunto una coda Rabbit con qualche milionata di messaggi al minuto da scodare in fretta e cambiare il write concern da majority a zero perché sono dati di cui la consistenza non mi interessava in quel momento perché è un log di dati storici mi ha alzato la velocità di scrittura di tipo un 30 per.Sì, ci sono anche altri trucchi, diciamo.Quello però veramente mi ha svoltato la settimana.Quello lì cambia tutto, ma perché se ci pensi comunque una latenza di rete c'è, no? Certo.E io veramente non avevo bisogno di assoluta certezza della persistenza del dato in quel caso lì, per cui veramente mi ha fatto tutta la differenza del mondo.Il bello è proprio questo, cioè che scegli tu il livello, in base alle tue requisiti.Altro tema, se tu fai un'applicazione e la vuoi distribuita in tutto il mondo, difficilmente farai un right concern majority se la tua maggioranza dei nodi è in tre continenti diversi.Magari fai dei tagging per repliche di alcuni… Se non hai il fretto di scrivere! Sì, ovviamente! Però dipende dall'applicazione, ovviamente.Magari dici "guarda, tra tutti i nodi replicami solo tra quelli vicini, come vrai concern, e dopo replichi gli altri".Quindi lo scegli.Qual è il bello di questo approccio qua? Il bello di questo approccio qua sono sostanzialmente due.Il primo è che nel momento in cui salta in aria il primario, tre cose interessanti, il primo è che quando salta in aria il primario, gli altri due, essendo dispari ed essendo più di uno, si accorgono che il primario è caduto, si accorgono che non è una partizione di rete, il famoso split brain.Altra cosa, essendo dispari, sono in grado di fare un'elezione automatica tra di loro.Terza cosa, il driver, che come vi dicevo è intelligente, conosce tutti i nodi del replica set, quindi nel momento in cui viene fatta un'elezione il driver se ne accorge e riscrive le transazioni non committate dal vecchio primario sul secondario.Per l'applicazione c'è un po' di rallentamento di qualche secondo ma neanche se ne accorge.Quindi primo beneficio failover trasparente, secondo beneficio quando torna su il nodo che è caduto saluta i fratelli del replica set si risincronizza da solo dei dati che si è perso e torna come nuovo primario.Self healing è la seconda idea.Terza idea è la manutenzione.Vi ricordate quando vi dicevo applicazioni SAS che non si devono fermare mai? La manutenzione io la faccio sempre a caldo, non c'è un reale motivo per fermare MongoDB.Faccio manutenzione sul secondario, cioè fermo un secondario, gli faccio la manutenzione, fermo un altro secondario, manutenzione, forzo l'elezione, quindi mi sposto su un nuovo secondario aggiornato, aggiorno il vecchio primario.Quindi non si ferma mai il servizio una volta che hai questa logica qua.Ultima cosa, diciamo la manutenzione, quant'altro, i nodi secondari sono aperti in lettura.Quindi io posso farci analytics sui nodi in real time, con i dati in real senza che le mie query vadano a inficiare le performance del primario che intanto macina le scritture, mettiamola così.Quindi è molto flessibile.Posso anche dedicare nodi secondari espressamente per l'analytics, a quel punto posso metterci sopra anche degli indici diversi per fare analytics.Quindi è estremamente flessibile, non so come dire, da un punto di vista architetturale, sono concetti semplici, ma quando li inizi a mescolare tra di loro ottieni un buon vantaggio.Scusa, domanda completamente random che mi è venuta in mente adesso perché potrebbe essere una roba che mi interessa operativamente.Io posso dire, non lo so, posso dire allo stesso driver all'interno di un'applicazione "questi update falli sul master e queste query invece falli su una replica"? Certamente, questo è un'altra grossa differenza rispetto ai database relazionali.Io posso avere anche con i database relazionali il famoso DataGuard di cui parlavamo prima, se uso l'Active DataGuard il secondario è aperto in lettura e io posso farci le query sul mio secondario che è sincronizzato.diciamo alla singola transazione in maniera più lasca anche quello si imposta ma qual è la differenza? che io devo puntare direttamente a quel lost, cioè alcune query le faccio di là e le devo fare necessariamente di là.In MongoDB dire questa query, farla sul secondario o farla sul primario è un parametro della query, cioè quando faccio la query gli dico secondary preferred e lui mi seleziona uno dei secondari.Questa cosa è una figata probabilmente come mi ha svoltato la settimana scorsa il write concern questa cosa mi svolta questa settimana.Poi naturalmente le fatture si faranno a parte a fine puntata, quindi prepara il libretto degli assegni Matteo, Mattia che sembra una chiamata di sales.Assolutamente uso privato di un mezzo pubblico.Matteo volevo chiederti al di là dell'installazione.Allora noi sappiamo Mongo ha una versione community che ti puoi installare tranquillamente nel tuo cloud di fiducia oppure ha dei servizi quali sono i vantaggi in realtà che l'utilizzo dei MongoDB, scusa ci tengo a Quali sono i vantaggi che hanno invece l'utilizzo dei servizi cloud offerti? Ma allora intanto MongoDB è community ed è sostanzialmente il motore di MongoDB è la stessa codebase sempre, quindi community, versione enterprise on premise, atlas, codebase precisa, quindi mi muovo, mi sposto, le feature da un punto di vista di interrogazione, di nodi disponibili nel motore database sono le stesse.Cosa cambia nella versione, quindi oltre alla community e oltre ad Atlas, MongoDB Atlas che è la versione as a service di MongoDB, c'è anche la versione Enterprise.Nella versione Enterprise hai la differenza e quindi anche in in Atlas, hai la sicurezza, quindi l'encryption at rest e quell'encryption dei campi specifici che vi raccontavo prima trasparente fanno parte o di Atlas o della versione Enterprise.Hai l'ops manager che è quello che ti tiene sotto controllo tutto l'installato, mille metriche, mille alert, sempre per parlare in oracolese è l'enterprise manager di Mongo quindi ti tiene sotto controllo, ti aggiorna, ti fa in automatico tutte le operazioni su MongoDB senza dover andare da riga di comando.Quindi anche gli aggiornamenti, alla fine gli dico.Ops Manager fa anche l'installazione automatica, è molto interessante.Tu predisponi gli host, ci metti dentro un agent, li fai vedere a Ops Manager e poi gli dici "guarda, queste tre macchine sono il nuovo shard per il mio database che non è shardato".quindi shardami il database e metti in queste tre macchine un nuovo shard e lui, sereno, predispone tutto, installa e migra i dati gli spezzette e li migra a caldo quindi hai questa funzionalità qua l'ops manager gestisce anche il backup quindi fare un backup consistente di un db shardato può essere complesso l'ops manager lo fa di default questo vale anche per atlas quindi ha sicuramente la sicurezza, il backup, l'automazione e il monitoring questa è un po' la differenza tra la community e l'enterprise Atlas, MongoDB Atlas, che ti dicevo è la versione ESA service di MongoDB ha delle feature aggiuntive ancora di più e tra l'altro è l'oggetto di punta di MongoDB in questo momento sicuramente dove stiamo ottenendo più soddisfazioni, maggiori risultati, maggior apprezzamento.Fa tante cose in più.Atlas è l'enterprise edition di MongoDB, quindi come ti dicevo, automazione, vi dicendo è.Gira su AWS, Google e Azure tramite Marketplace, quindi in maniera trasparente, chiunque ha un account AWS può andare nel Marketplace e attivare Atlas.e fa tutto quello che fa MongoDB Enterprise, che è quello che ci siamo detti finora.Ha delle cose aggiuntive ulteriori, ah un'altra cosa, è anche multi cloud, cioè io posso fare dei cluster distribuiti, abbiamo parlato di replica, posso mettere delle repliche in una region AWS, delle repliche in una region Azure, delle repliche in una region GCP.ci sono persone che conosco che fanno transazionale su AWS e l'analitico su GCP, sui dati in real time.Come si dice? Oltre a questo, quindi volendo sei anche tollerante al fault di un intero cloud provider, eventualità un po' estreme, secondo me se cade un cloud provider hai altri problemi.Prova a dirlo ai russi che si sono visti sparire avs.Forse non mi preoccuperei troppo dei servizi di notazione tavoli al ristorante, non lo so, però si può fare.Come dicevo, fa delle cose in più, a mio avviso pazzesche, grazie sei in MongoDB, però sono veramente utili.Quindi, permette di fare applicazioni mobile offline first automaticamente.Non so se conoscete Realm come database mobile.È un po' uno standard de facto nello sviluppo di applicazioni mobile.Si dice, hanno fatto delle statistiche, si dice che se hai uno smartphone hai almeno un Realm installato, perché è usato tantissimo.È completamente open source.Una roba tipo CouchDB, PouchDB che si sincronizza, no? Esatto, si sincronizza automaticamente, mediamente ha delle feature estremamente avanzate rispetto a Firebase, ovvero permette di partizionare i dati in verticale e in orizzontale, permette di dare criteri di accesso sul singolo campo all'utente, fa validazione del formato dati all'ingresso e ha un meccanismo automatico di risoluzione dei conflitti nel momento in cui uno nel suo mobile offline cambia dei dati, nel server cambia dei dati contemporaneamente, cosa succede quando il mobile torna online e prova a sincronizzare? C'è un meccanismo automatico di risoluzione di conflitti, super testato.Quindi sostanzialmente quello che devo fare quando faccio un'applicazione mobile, la sviluppo su Realm, come posso fare open source senza problemi, e poi gli dico "guarda, sincronizzati con MongoDB e quello là".Atlas gestisce partizioni di database centrali per utente o per tutti gli utenti, condivisa e non condivisa, e vi dicendo, e sincronizza da soli dati.è molto facile e funziona molto bene.Grazie, potete provarlo.E poi ha una piattaforma serverless in più di gestione dei dati, di creazione API, quindi io posso creare API di accesso ai dati che fanno enforcing tutte le regole, tutti i criteri di sicurezza della schema validation e via dicendo.Quindi io posso mettere il mio Atlas, posso crearci uno strato di API di accesso ai dati al contorno che fanno logica di business o forniscono servizi avanzati, serverless, quindi applicazioni con picchi elevati e variabili a piacere vanno avanti tranquillamente, poi faccio i miei microservizi sulle API di accesso.C'è la piattaforma che lo fa, integrata con tutti criteri di MongoDB.Un'altra cosa, sempre applicazione pensata, piattaforma pensata, slogan che sembra a anni '80, database moderno per un mondo moderno.Hai enormi moli di dati, moltissimi dati da gestire.Come fai su un relazionale quando i dati sono tanti e storici? partizioni, fai le partizioni, le sposti magari in altra parte.Il brutto qual è delle partizioni? Che poi devi sapere te dove vai a pescare i dati.Quello che fa MongoDB semplicemente ha un meccanismo che si chiama online archive che archivia i dati automaticamente.Tu gli dai un job, lo imposti, gli dici "guarda questa collection che contiene 10 miliardi di documenti, fai una cosa, i documenti più vecchi di sei mesi archiviali e lui da solo ogni tanto fa la verifica e archivia i dati, dove li mette? Li mette in uno storage trasparente all'utente gestito da MongoDB.E diciamo cosa cambia per l'utente? Sostanzialmente nulla, cambia la stringa di connessione, quando io faccio la query identica prima, esattamente come prima, stesso linguaggio di prima, MongoDB automaticamente sa quali sono i dati caldi e manda la query sul cluster MongoDB, quali sono i dati freddi e va a spazzolarsi sto storage che vi dicevo prima, impacchetta i dati come un unico result set e lo restituisce all'utente.Quindi sostanzialmente io tolgo dati dal cluster, tengo il mio dato snello, tengo il mio database snello e performante perché i dati vecchi tanto non ci accedo magari o ci accedo solo per fare statistiche ogni tanto o anche spesso, ma comunque ci accedo in sola lettura, li sposto, ci faccio query uguali a prima ed è una cosa che avviene trasparente dal punto di vista del DBA perché una volta che imposto la regola i dati si spostano e trasparente dal punto di vista dell'applicazione perché la query è uguale a prima.Quindi è una cosa che è veramente game changer, ad esempio per applicazioni IoT.Stavo lavorando su un'applicazione IoT l'altro giorno che scrive un tera di dati al mese.Ora, se tu vuoi tenere un orizzonte temporale di 5 anni per farci le statistiche su questi dati, sono un sacco di dati.Tenerli tutti nel database è una follia.Metterci di fianco un data lake è una rottura di scatole, diverse da imparare, tecnologie in più da gestire, manutenzione...Risorse umane differenti, professionalità diverse...Esattamente, abbiamo fatto uno studio, abbiamo fatto dei test e abbiamo risolto in maniera trasparente con sta roba e funziona, quindi diciamo che cambia un po' il modo di pensare l'applicazione.Dopo 8 anni, quando i dati non servono più, automaticamente vengono cancellati e poi saranno nel backup, però è tutto gestito in automatico.Ultima cosa in più è il Data Lake, quindi ho stesso meccanismo dell'online archive alla fine, ho i miei dati in MongoDB, voglio arricchire queste query con dei dati esterni che magari mi arrivano ogni tanto da da un csv, magari risultato di chiamati di API di terze parti, SaaS e compagnia cantante, prendo questi dati, li metto su un S3 e li faccio vedere a MongoDB e da quel momento in poi li interrogo come se fossero MongoDB.E che formati supporta, ti ricordi? i principali sono Jason, ovviamente, Parquet, Avro, CSV.Ok, perfetto, hai già citato i due che mi interessavano.Che tra l'altro per i software engineer sentire Parquet e Avro è un grande punto interrogativo, invece nel mondo dei big data sono alla fine lo standard de facto.Esattamente, poi spessissimo questa cosa viene usata col CSV alla fine della fiera, perché magari una esigenza che incontro spesso è che io devo fare delle query, ad esempio mi dicevano un'altra query di forecasting, di giacenza di magazzino e via dicendo, e alcuni parametri mi vengono forniti dal business in Excel e io ci devo fare comunque sopra l'algoritmo.Alla fine abbiamo risolto che buttare il file su un S3 e MongoDB lo riconosce e ci fa le query sopra con l'aggregation framework, fa l'algoritmo di forecasting e lo gestisci in automatico.E ricordiamo che Excel è il moderno business intelligent tool.Non è né modern, né business, né intelligence.Ma è così.Guarda, io per dovere familiare, frequento tanti persone che lavorano nel mondo della business intelligence, cioè io sono rimasto scioccato da A) cosa fanno fare ad Excel, gli fanno fare le capriole.B) quanto lo usano Excel? Cioè, il mondo è fondato su questi strumenti.Sono già contento che è stato abbandonato Access.Questo mi sembra un enorme passo avanti.Un po' come quelle pagine che fanno vedere che usano i mobili Ikea o li smontano e li rimontano in maniera convenzionale per fare, non lo so, mensole o cose uguali.Ultima mia domanda, poi non so se Mattia e Leo hanno qualcosa da chiederti, ma questo serverless? Allora perché mi fai con questo tono questa domanda? Sono assolutamente sibillino di Mosh.No, assolutamente, nel senso mi è capitato di vedere, non ho avuto modo di approfondire, ma dici qualcosa di più perché so che è tipo una delle killer feature di Atlas sì, corretto.Adesso probabilmente ve l'ho bacchettato perché non ve l'ho nominato subito però tra le modalità di fruizione di Atlas c'è anche la modalità serverless io che son braccino a cortolo subito ad occhiata È fantastico, è fantastico.Quello che, sostanzialmente l'esperienza è la stessa di quello che vi ho raccontato prima di Atlas.No, direi che sostanzialmente è la stessa, la differenza che appunto è serverless.Qual è la differenza tra servered, scusate, risorse dedicate e serverless? La differenza è che alla fine il billing, cioè quello che paghi, è in base a quanto solleciti i dati.Ho avuto esperienze con tanti sistemi serverless, i classici function, esa service, senza citarne altri.quindi anche i cloud provider hanno creato un impero su questa cosa.Sono carini e coccolosi all'inizio e dopo diventano Cthulhu quando l'applicazione scalano e non puoi mai più uscirne.È un po' il tema.Assolutamente una storia vera.E' così.Ci sono tanti database serverless nel mercato cloud, c'è tanta gente che cerca di fuggirne quando l'applicazione diventa grossa, ma sono fantastici per sperimentazioni veloci, sono fantastici per applicativi piccoli, sono veramente fantastici.Quindi è giusto che esista una piattaforma serverless, è giusto che MongoDB sia disponibile serverless e lo è.iterazioni piccole, dev and test, piccoli use case, io li faccio col serverless e sono felice.Ma le API sono le stesse? Le API sono le stesse, uno dei mantra di MongoDB è "unica API per tutto quanto".Anche le cose che vi ho raccontato prima, l'online archive, Atlas, poi un'altra cosa importante per cui verrò bacchettato, che è importantissima, Atlas fa una cosa in più rispetto a MongoDB, che è la full text search in maniera trasparente, in maniera gestita con le stesse API devo solo impostare la funzionalità search che crea sostanzialmente gli indici inversi sul documento basato sull'usin e poi con le mie API in MongoDB faccio la full text con fuzzysearch, con tutte quelle cose lì, con i vari analyzer con i vari linguaggi e compagnie cantanti questo è un altro enorme vantaggio di Atlas nel senso che ormai la Google search bar se la aspettano tutti nelle applicazioni e normalmente ci devo mettere di fianco un elastico, un busin, un solar, quello che serve con i TL e via dicendo.Competenze, tecnologie, cross certification, compagnie cantanti.Invece in questo modo fai la search trasparente.Quindi unica API per tutto, anche per il serverless, unica API per tutto.È fantastico, parto, voglio provarlo, voglio...Al netto che c'è un Atlas Free sempre, quindi tu quando fai una sottoscrizione Atlas, un Atlas ce l'hai a disposizione piccolino sempre per provarlo.Ma è anche il serverless.Come dire, appena ti stanchi del serverless, grosso vantaggio, puoi passare alla versione a risorse dedicate, col cluster a te dedicato.Quindi, mediamente si vede che quando l'applicazione diventa grossa, diventa tanto utilizzata, un meccanismo a risorse dedicate è molto più conveniente e offre garanzie maggiori diciamo di performance e compagnia cantante.Questo proprio è, come dire, è uno dei mantra, è uno degli elementi fondanti dei servizi cloud.Ci sono servizi che una volta che sei serverless, sei serverless per sempre e non è detto che ti convenga tendere, qui c'è il serverless, felice di utilizzarlo, ma dopo hai la scelta anche di passare a risorse dedicate.Questa qui credo sia la grossa differenza.Faccio la persona veramente cattiva perché mi hai dato un gancio bellissimo per una domanda cattiva.Il mantra, la stessa API, sempre a me piace tantissimo ed è una figata.Rispetto a questa cosa, quanto dà noia il fatto che i cloud provider abbiano il loro documento di BD AWS per non fare nomi che è Mongo compatibile, ma forse no? Personalmente io ne sono molto felice, nel senso che molti fornitori di tecnologia, ultimamente soprattutto si proclamano MongoDB compatibili.Io la vedo come una cosa per dire l'SQL.L'SQL a un certo punto è diventato lo standard per tutti.Le API Mongo stanno diventando lo standard.Questa è la miglior certificazione della qualità della tecnologia.è un vantaggio, vuol dire, una cosa positivissima, quindi io la vedo come una cosa positiva.Poi, Poi, quando tu vai su questi servizi, c'è sempre una differenza, se non altro per la versione.Chi ha le imi Tator API di MongoDB mediamente si attesta sulla 3.6 o sulla 4.0 come versione, poi si potrebbe guardare i test di correttezza delle API e vi dicendo "ma insomma, strumenti che..." Qual è la grossa differenza? che MongoDB è la 5.2 e MongoDB nasce su quell'API ed è implementato dalle sue fondamenta su quell'API, non è un adattamento di una tecnologia preesistente per gestire quell'API.Questo qui alla fine della fiera qualche forzatura te la dà nel dettaglio, adesso non voglio andare nel dettaglio, però la grossa differenza è una differenza che proprio devi valutare subito alla versione.Nella 5.2 abbiamo aggiunto il live resharding, cioè già dalla 5.0.Abbiamo aggiunto le stable API, cioè API fisse che non ti costringono ad aggiornare l'applicazione quando tu aggiorni il database.Quindi se tu sviluppi un microservizio con il driver 5.0 su MongoDB 5.0 con le stable API, poi tu sei libero di aggiornare il MongoDB 5.1, 5.2, 6.0, 6.1, 6.2 risponde sempre come una 5.0 col driver 5.0.Il servizio che sviluppo dopo sullo stesso cluster usa il driver 5.2 perché nel frattempo MongoDB è arrivata da 5.2 e può utilizzare le funzionalità aggiuntive che ci sono da 5.0 a 5.2 per fare quella parte là.Quindi quando sviluppo con la 5.0 io devo toccare realmente l'applicazione, il codice dell'applicazione quando voglio dare dei servizi aggiuntivi ai miei utenti.E allora magari aggiorno il driver e sfrutto le nuove funzionalità.Se no, io la tengo lì, sono felice di essere in micro servizi, la tengo con la 5.0, intanto sotto ho un database che è sempre più sicuro, sempre più performante e sempre più avanzato per fare i nuovi micro servizi.Questo dà un'efficienza spaziale.Ricordiamoci che il collo di bottiglia di oggi è l'efficienza degli sviluppatori, e come dire, togliere il fatto che se tu fai un upgrade del database devi andare a verificare tutto il codice che hai scritto è uno snellimento pazzesco del ciclo di vita dell'applicazione.Altra cosa sono le time series, che ci sono nella 5 e non ci sono nella 4.Quindi, Time Series, io devo fare un'applicazione IoT, si sono sempre fatte con MongoDB, perché si presta molto, ovviamente devi fare un data model specifico, no? Magari in un documento, come si fa? In un documento metti un'ora di misurazioni, invece che un documento per ogni misurazione.Questo ti permette di essere molto efficiente in storage, molto efficiente in indici, molto efficiente in ingestion, per intenderci e vi dicendo.è un pattern, famosi pattern che dicevamo prima, che si chiama bucketing.Lo devi fare e implementare tu però, perché sfrutti la flessibilità di Data Model, ma te lo devi fare.Con la 5.0 ci sono le collection time series.Questo bucketing lo fanno in automatico.Quindi tu scrivi un documento per misurazione, molto facile da scrivere, fai query e leggi un documento per misurazione, molto facile da leggere, sotto lui fa il bucketing trasparente.enorme efficienza di indici, enorme efficienza di storage e diciamo enormi performance in gestione del dato.Ci sono tante cose, c'è il "Library Sharding", quindi tu fai lo sharding di una collection, ma nel mondo, qualsiasi database fa sharding, devi scegliere la chiave di sharding, no? Qual è la logica con cui distribuisci i dati? Scegliere la chiave di sharding è un po' come farsi un tatuaggio in faccia, Devi essere molto convinto, perché dopo cambiarlo… Ho poco furbo! Mi fa ridere perché questo parallelismo me l'aveva fatto un mio amico quando è nato il mio primo figlio.Guarda che fare un figlio è come farsi un tatuaggio in faccia, devi essere molto convinto.Quindi che chiave di sharding ha tuo figlio? Adesso ne ho due, quindi effettivamente potresti shardarli.Esatto.Come si dice, però se la tua applicazione evolve, se la tua applicazione va avanti, se hai sbagliato chiave di sharding, cambiarla è un delirio.Devi mediamente creare un altro cluster, esportare i dati, rimportare, dicendo.Nella 5.0 c'è il "Live Resharding", quindi vuoi cambiare chiave di sharding, gli dai un comando, gli dici qual è la nuova chiave di sharding e lui duplica i dati, li ridistribuisce con la nuova chiave di sharding, riallinea le collection, quando è tutto allineato fa lo switch.Tutto mentre l'applicazione funziona, cioè senza fermarsi.Ancora una volta, è una cosa che devi prendere in considerazione quando lanci un'applicazione, ma mi ci sono trovato, no? Applicazioni shardate per performance su database locali sono diventate global e bisogna pensare a una strategia per shardarle per region.come le shard, è enormemente invasivo, anche perché in quel caso lì sono decine di teradidati.Con questo, al netto che è un'opzione comunque da prendere, è un evento importante cambiare sharding in ogni caso, ma sicuramente non puoi fare in maniera con un gradino all'ingresso minore, mettiamola così.Quindi tornando ai famosi cloud provider che fanno servizi mongo like, secondo me è più un attestato di stima che altro, perché poi le differenze ci sono e diciamo che poi essendo disponibile nei vari cloud provider come nel marketplace non c'è neanche una reale competition con i cloud provider, spesso collaboriamo con i cloud provider, quindi spesso ci troviamo a lavorare insieme ai solution architect di cloud provider terzi, famosi, per posizionare MongoDB, anche se poi magari hanno una loro soluzione di documento però alla fine della fiera spesso anche il cliente che sceglie quindi collaboriamo insieme tanto è sempre per dire le cose brutte è sempre consumo per il loro cloud e quindi è quindi sì c'è competition ma in realtà c'è anche molta collaborazione.Io guardavo guardavo l'orologio siamo andati naturalmente off time come sempre ma sono ben lieto di essere andato off quindi rapidamente chiedo a Leo e a Mattia se hanno qualche altra domanda no io volevo solo dire php perché si rischiava di fare una puntata senza dominarlo io sono arrivato in ritardo ma avete letto gruppo telegram? no non ancora non vi posso lasciare da soli un minuto? che cavolo è colpa mia parla di RAL? mea culpa mea culpa è arrivato il momento tipico e topico dei nostri episodi, il momento il paese dei balocchi, cioè quell'istante dove sia i nostri guest che i nostri host tirano fuori dal cappello, dal cilindro, una roba che ha catturato la loro attenzione, sia esso un libro, un talk, un video, un articolo, un giocattolo, qualunque cosa abbia davvero catturato attenzione è reiputino importante condividere con la nostra community."E con tu con il paese dei balocchi" "Ah, il paese dei balocchi" Chiedo subito a Matteo, hai qualcosa da condividere con noi? Guarda, la prima cosa che mi sento di, sempre per stare nel tema MongoDB, la prima cosa che mi sento di condividere è quel libro di cui vi parlavo prima, se non altro perché è online, liberamente disponibile, ed è molto chiarificatore, estremamente utile, estremamente pratico, si chiama Practical MongoDB Aggregation ed è appunto quella sorta di "Va de me cum" su come scrivere le aggregazioni in MongoDB.Questo qui è uno dei consigli che mi...questo momento è il consiglio che mi sento di darvi, insomma.Fantastico, lo mettiamo nelle note dell'episodio.Leo? Allora, io oggi mi voglio rovinare perché vi darò come balocco, come gingillo, come lo vuoi chiamare, una specie di meta-gingillo perché ci ho tirato fuori altri balocchi altre volte.Una newsletter si chiama console.dev e ogni settimana manda dei tool per sviluppatori.Alcuni tool sono, come dire, production ready, alcuni sono in beta, quindi seguono anche nuove tendenze.È molto interessante, con https://console.dev o nelle note di episodio.Ma è un qualcosa dove devo allocare budget? In che senso? Nel senso che sono tipo software con licenza? No, ma solitamente è roba open source disponibile, ma ogni settimana ne propongono 4, 5, 6, quindi non è nemmeno una cosa troppo pesante da avere No, perché se no ero già pronto ad allocare il budget, perché già il nome è abbastanza catchy per farlo Mattia? Allora io faccio una cosa che faccio spesso quando ho i balocchi, cioè propongo un libro che non ho letto, perché come sapete io ho questo odio viscerale per tutti voi, perché la mia cura di lettura è già molto lunga e Matteo un po' ti disprezzo perché adesso ha un libro in più, Leo che mi hai linkato una newsletter che ha tante cose e sappi che questa me la paghi, e quindi nella mia cura di lettura attualmente c'è anche un libro che si chiama "Modern Software Engineering" ed è di un tizio che si chiama David Farley.L'ho comprato perché ho letto praise gigantesche da persone di cui mi fido e in effetti ho anche spizzato l'indice.La sparo molto grossa, secondo me, è un libro figo a livello de "Pragmatic Programmer".Nel senso che i concetti di cui parla sono più o meno allo stesso livello.Non è molto, diciamo, approfondito tecnicamente, non va molto in dettaglio sulle questioni tecniche, ma parla di principi che stanno a un livello superiore, come ad esempio come fare a ricevere feedback in fretta quando scrivi codice o cose di questo tipo e quindi sono molto fomentato di questa cosa.Appena finisco il libro di Maccio Capatonda che ho iniziato l'altro ieri leggerò questo.Devo avere un po' di varietà nella mia cosa di tuttora, scusatemi.E allora, anch'io aggiungo un libro per la vostra felicità, però devo fare una premessa.è molto molto carino qualche tempo fa un amico Alessandro mi ha mandato in preview un libro un libro che ha scritto sulla crittografia e già là mi si è ghiacciato il sangue non era ancora uscito e mi ha detto Mauro leggilo e dimmi cosa ne pensi io solitamente diversi amici mi mandano libri raramente ne parlo su github però questo mi ha gasato tantissimo perché non ho mai capito una cippa di crittografia perché tutti i libri di crittografia che ho preso in mano erano delle robe con robe di matematica che si numeri che si mischiavano tra di loro grafici cose e alla fine dopo la ventesima pagina buttavo al cestino tutto ci rinunciavo infatti la mia libreria ne è piena e quindi vi voglio suggerire invece questo libro che è Essential Cryptography for JavaScript Developers di Alessandro Segala che tra l'altro abbiamo avuto ospite da noi qualche settimana fa perché vi voglio suggerire questo libro? perché in realtà ha un approccio troppo pragmatico cioè la roba figa è approccio super pragmatico è scritto in javascript quindi comprensibile ai più e la cosa bella di questo libro è che in realtà parla di crittografia lato back end con degli esempi fatti su node.js e lato front end con degli esempi sul browser senza praticamente neanche una formula matematica.Quindi c'è tanta roba.Complimenti ad Alessandro e se avete la curiosità di approfondire questo mondo almeno come introduzione per me è stato il libro perfetto.Interessante, molto.Soprattutto l'assenza di matematica mi sembra assolutamente un benefit.Io credo di aver premuto reset una volta passato l'esame di matematica 2 all'università, ho proprio fatto un wipe completo.Il famoso flash post esame.Esatto.Quanto avrei voluto farlo anche con la sequella.[Musica] E' arrivato il momento di ringraziare chi ci supporta in questa pazza follia di Gitbar chi infatti grazie a delle piccole donazioni fa sì che le bollette mensili vengano pagate e Gitbar possa arrivare alle vostre orecchie ogni settimana Questa settimana abbiamo un donatore da ringraziare, donatore che ci ha invitato una birra un attore che tra l'altro conosciamo perché fa parte della nostra community e ci ha scritto un messaggio.Quindi ringraziamo Stefano Mainardi che ci ha scritto "grazie per tutto il lavoro di divulgazione che avete fatto in questi anni, continuate così".Grazie Stefano, grazie di cuore appunto per supportare questo podcast perché in realtà sì, noi ce la mettiamo tutta e lo facciamo gratis Gitbar non è senza costi grazie a Stefano questa settimana Riusciremo a pagare una parte delle bollette grazie di cuore Solleviamo in alto i calici e brindiamo alla salute di Stefano ragazzi siamo andati lunghissime ma è stata super super super piacevole quindi ringrazio di cuore Matteo grazie a voi grazie per essere venuto a trovarci e grazie per aver condiviso con noi anche questa prospettiva perché quando si parla di MongoDB spesso non si scende così nel dettaglio non si non si esplorano queste queste particolarità o particolezza Poi, mamma mia, più sto qua in Francia, più mi dimentico l'italiano, ma non apprendo il francese.E questo è un grande problema.Ringrazio anche i miei compagni di viaggio, Leonardo e Mattia.Grazie a te di averci invitato.Grazie mille.Invitato! Invitato! Hai le chiavi di casa! Mi sono reso conto che abbiamo detto gruppo Telegram, abbiamo detto PHP, ma non avevamo ancora detto Dipende.E questa cosa non la posso tollerare.non abbiamo avuto domande con risposta di Fendi la risposta del consulente di Fendi cerca sempre di parlare bravissimi anche in questo detto questo io come diceva Mattia e Leo vi ricordo il nostro gruppo Telegram se non l'avete fatto facetelo e ahimè vi devo salutare è arrivato il momento di passare lo straccio sul bancone del nostro Gitbar quindi grazie Matteo, grazie Mattia, grazie Leo, alla prossima! Ciao! Ciao, ciao, ciao! Gitbar, il circolo dei fullstack developer.Una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei fullstack dev.[Musica]
