Bene e benvenuti su Geekbar, nuova settimana e nuovo episodio qua nel bar degli sviluppatori Oggi non c'è nessun ammutinato con me ma non sono solo, ho un super super ospite Ma prima di presentarvelo, come sempre, il mio ruolo, ahimè, un po' noioso È quello di ricordarvi i nostri contatti Info@geekbar.it o @brainrepo sono i modi canonici per contattarci Ma c'è il nostro grandissimo gruppo Telegram e leggevo poco fa, è appena ripartito un altro flame riguardante le RAL.Lo so, prima o poi dovremmo farla una puntata, un episodio sulle RAL.Io sto cercando di tergiversare il più possibile ma mi sa che ci tocca.Però detto questo, è messo in silenzio, in non disturbare alle notifiche perché il gruppo è ormai infuocato possiamo iniziare Benvenuti su Gitbar, il podcast dedicato al mondo dei fullstack 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 [Musica] Senior Program Manager per Azure SQL a Microsoft, ma anche l'italiana Redmond o l'uomo dei database, abbiamo con noi Davide Mauri.Ciao Davide, come stai? Ciao Mauro, benissimo e grazie mille per ospitarmi.Secondo me l'etichetta "l'uomo del database" ti sta a pennello, no? Bene, effettivamente.Diciamo che ho investito la mia carriera, quindi sì, diciamo di sì.Da quanti anni lavori nel mondo dei database? Uh, dal 2000 direi, sì.Sì, perché avevo iniziato con SQL Server 6.5, no, quindi prima.no quindi prima perché è '97, '97 sì.Quindi questo svela anche quanto vecchio sono.Ti volevo prima fare una domanda sulla carriera per poi ritornare sull'evoluzione di database.Tu oggi sei Senior Program Manager a Microsoft nell'ambito di Azure SQL.Intanto ti volevo chiedere che cosa rappresenta il ruolo di senior program manager? Allora ti do una risposta veloce poi per chi è interessato c'è un mio amico Matthew Roche che ha fatto un video che spiega esattamente cosa vuol dire, insomma è il video migliore per capire cosa fa un PM.Mi ha detto in pochissime parole di fatto ci occupiamo di sviluppare il prodotto in maniera tale che sia al più aderente a quello che richiede il mercato, o quello che pensiamo richieda il mercato possibile.Quindi vuol dire lavorare con i clienti e gli sviluppatori, nel mio caso, per capire che cosa cercano dal prodotto, da lì estrarre informazioni su che cosa secondo noi va migliorato o che cosa non c'è va aggiunto, quindi creare le specifiche, questa è la parte più bella, cioè tu definisci esattamente come vuoi che sia fatto o che funzioni qualcosa.Quindi poi ti viene assegnato un team di ingegneri e con loro lavori nel dettaglio per avere, diciamo, le specifiche implementate e dopodiché ti preoccupi di lavorare con i clienti per fargli adottare queste nuove, queste nuove feature, ricevere feedback, migliorarla.Quindi vedi proprio tutto dall'inizio, dalla nascita, dall'idea proprio, fino alla fine.Ed è molto molto gratificante, nel senso che è proprio bello, Insomma, anche quando ti fanno vedere gli ingegneri la prima versione di un prodotto, qualcosa che funziona, è un po' come Natale.Nel senso che è una roba che dici "cavoli, io l'ho pensata e sta andando, funziona, fa quello che deve fare".Quindi è molto bello.Quindi sostanzialmente è un ruolo di manager di prodotto, fondamentalmente.Sì, sì, sì.Poi all'interno del nostro gruppo, non so se negli altri, ma nel nostro gruppo è proprio come manager, hai detto bene, ma addirittura come manager di una piccola società, perché il nostro gruppo è enorme e ognuno ha un'idea.Il problema è che il numero di ingegneri è finito.Quindi devi, non dico venderla, ma devi portarla dalle giustificazioni di business.Cioè se io faccio questa cosa e non facciamo un'altra, quali sono i pro e i contro, quindi gestire la priorità soprattutto.E quindi vedi un po' tutto, è come avere una piccola start-up, se vuoi, cui devi incubare un'idea, venderla internamente, in questo caso comunque spiegare perché secondo te è vincente, portarla a compimento, evangelizzarla e poi anche monitorare che tutto sia effettivamente corretto e poi procedere a versione 2, versione 3 nel caso ci fosse dell'evoluzione.Quanto incide, adesso questa domanda è un po' cattivella, quindi ti prego di concedermela, ma quanto fondamentalmente a quello che ho capito da quello che mi hai appena spiegato il product manager è colui che individua la feature che va portata a compimento e ne gestisce poi tutto il percorso.Nella selezione della feature, che importanza ha il marketing? Nel tuo caso? Dipende un po' da qual è l'obiettivo che si vuole raggiungere.Se l'obiettivo è quello di diventare leader nel Gardner Quadrant, chiaramente investi in un certo di questo tipo di feature.Una volta che magari sei lì, investi in altre, nel senso che magari incominci a pensare a limare un po', diciamo, a perfezionare le cose.Dipende veramente qual è l'obiettivo che si vuole perseguire.Per noi adesso è importantissimo essere il più possibile vicino agli sviluppatori.Ci sono mille cose che stiamo facendo, perché ti ripeto, il prodotto è enorme.Quindi guardiamo i DBA, guardiamo i data scientists, guardiamo gli sviluppatori.Io in particolare sono interessato agli sviluppatori e...Scusa, è a partita a Siria, infatti.[Risate] E...Io quindi dicevo, sono...Vabbè, devo dire qualche parola, aspetta che la stacco perché...[Sottotitoli a cura di QTSS] nel giorno in cui i Siloni decisero di uccidere i loro padroni.Non collaborava, ok, abbiamo ucciso Siri e siamo a posto.Io sono interessato soprattutto a fare in modo che il database, essendo io di background sviluppatore, sia il più friendly possibile per il sviluppatore.Quindi il mio focus in questo caso è, e i miei clienti sono i sviluppatori, quindi capire che cosa cercano, che cosa vogliono, che cosa manca nel nostro prodotto per essere competitivo con gli altri, che cosa abbiamo di competitivo che possiamo sfruttare.E quindi è molto, diciamo, molto legato all'obiettivo che ti stai dando.Ti ripeto, in un prodotto enorme come il nostro ci sono tanti obiettivi allo stesso tempo, perché non possiamo focalizzarci solo su uno, perché altrimenti poi perdiamo dall'altra parte, no? Quindi ad esempio io mi occupo di sviluppo, altri miei colleghi si occupano della parte infrastrutturale, altri miei colleghi si occupano invece della parte più di analytics, c'è chi si occupa più della parte di front-end, quindi il portale Azure dove tu crei il tuo database o dei tool.E ognuno chiaramente, se vogliamo, ha degli obiettivi specifici diversi.Poi il nostro obiettivo in generale è fare in modo che Azure SQL sia il miglior database per chiunque lo voglia usare, lo sviluppatore, alla persona che fa BI e medici.Volevo chiederti invece una cosa, ritornando un po' alla tua carriera, quindi abbiamo visto un po' il ruolo, quali sono state, quali riesci a proprio individuare, se ti sono chiare? Non ti sto sentendo.Non mi senti? Non ti sto sentendo.No, poi ultimamente sto avendo problemi con l'USB, quindi può essere.Non ho capito cosa è successo, da tre giorni ogni tanto Windows mi dice che l'USB malfunctioning.Simpatia.Io ho gli stessi problemi col Bluetooth.Ti volevo chiedere, la tua carriera parte come DBA, perché sono andato un po' a spulciarmi linkedin fino ad arrivare appunto a senior program manager.Quali sono le milestone a livello di carriera quelli che possiamo individuare i salti quantici perché la carriera solitamente non si evolve gradualmente ma ci sono dei piccoli salti che riesce a riconoscere e nei quali appunto vedi una crescita rispetto a tutto il progresso.Allora io ho iniziato come sviluppatore, Tutt'ora sono appassionato sviluppatore, a me piace sviluppare.Quindi ho iniziato lavorando per una piccola società a Monza e poi mi sono reso conto che mi piaceva tantissimo sviluppare, mi piaceva molto la ricerca delle performance, sviluppavo gestionale ai tempi, e però molte volte c'erano problemi quando i dati erano tanti.Ai tempi si usava Access o il primo SQL Server in 6.5 che avevo iniziato, che in Italia era una roba abbastanza nuova da poco.e per riuscire a farlo andare, ad un certo punto, finalmente ho deciso, miei responsabili ai tempi, di farmi fare un corso su database.E lì mi si è aperto un mondo, nel senso che in 30 secondi, una volta che sai fare le cose, veramente cambi le performance di un'applicazione, gestionare una fattispecie che usa database e le fai diventare da giorno alla notte, perché veramente usare bene un database significa veramente cambiare le performance di un'applicazione.ma da lì mi sono sempre di più appassionato e poi ho continuato a diventare prima, diciamo, un DBA un po' sui genres, perché a me è sempre piaciuta la parte di sviluppo, quindi cercavo sempre di coniugare i due mondi.E poi da lì ho iniziato a scrivere una serie di articoli ai tempi per infomedia su SQL Server, e lì è stato un po' il balzo, perché poi mi ho fatto entrare in contatto con Mondatore Education, che mi ha proposto di fare il docente, e quindi da lì mi sono licenziato, ho iniziato a fare libro professionista.Io ho scoperto che mi piaceva anche molto presentare, condividere la conoscenza, e soprattutto ho scoperto che più condividevo, più imparavo.Perché ogni volta che io entravo in aula o facevo qualcosa, chiaramente le domande che venivano fatte erano una sorta di spunto per approfondire.Per me questo era bellissimo, e tutto era bellissimo.Quindi poi ho iniziato a fare conferenze, nel 2003 credo che fosse stata la prima WPC, E poi da lì sono entrato in contatto con un'altra serie di persone in ambito internazionale, perché poi appunto ho scritto ma ho onorato di essere MVP, quindi sono iniziato a entrare un po' nel giro, a venire qua a Redmond, a conoscere gli sviluppatori di SQL, a entrare sempre più in contatto con una realtà internazionale.E lì il secondo salto è stato quando ho deciso di fare una società mia con questi soci internazionali e dedicarmi solamente alla parte di database.Poi io mi sono ai tempi specializzato sulla parte di business intelligence e data warehousing, sempre perché mi piacciono molto le performance.Lì, insomma, quando hai una buona mole di dati è divertente cercare di trovare il modo per ottimizzare la performance.E poi dopo dieci anni che ho avuto la società, cioè tuttora, ho avuto una proposta di venire qua in America a lavorare per una startup che tuttora fa wearables, quindi facevamo scarpe o calze con sensori i cui poi dati vengono presi e mandati sul cloud così puoi analizzare le tue performance, eccetera, eccetera.E poi da qui, appunto, essendo qua Redmond peraltro, e avendo molti conoscenze in Microsoft, ad un certo punto mi han chiesto se volevo entrare a far parte del team e ovviamente essendo un po' il mio primo amore SQL Server non potevo rifiutare.e quindi eccomi qua.Beh, si vedono comunque gli step, proprio le hai evidenziati con chiarezza e fondamentalmente sono quelle che sono le sfide nel quale ti butti anche con un po' di incoscienza.Ah, certo, quando abbiamo deciso di venire qua in America è stato un bel salto nell'ignoto, però devo dire che alla fine...Ha ripagato.Ah, sì, assolutamente.Poter stare qua nel team di sviluppo sviluppare una cosa che ti piace, forse una delle cose più belle che puoi chiedere sul posto di lavoro.Assolutamente sì.E allora parliamo della cosa che ti piace.Da dieci anni a questa parte cosa è cambiato nel mondo di SQL Server e naturalmente compresa la parte cloud? Beh direi sicuramente, il cloud è stata sicuramente la cosa più innovativa e più disruptive perché che ha cambiato le carte in tavola.Nel senso che oggi, come oggi, io credo di non aver più installato SQL Server.Forse l'ultima installazione che ho fatto è stato SQL 2012, credo.Sì, penso di sì.Banalmente oggi con il concetto del cloud, quindi container, piuttosto che infrastructure, etc., io non so chi installi ancora SQL Server.Oggi con Docker ti scarichi l'immagine, lo fai andare.Ci sono sicuramente dei casi dove ancora succede, però dal punto di vista dello sviluppatore banalmente...almeno c'è un giorno di lavoro che è stato banalmente recuperato semplicemente perché ti scarichi il container e pronti via e vai.E poi secondo me...Vai, scusa.No, no, vai, vai.No, e poi chiaramente è cambiato...c'è stato un bel periodo di up and down per database, chiamiamoli relazionali ancora, perché c'è stata poi tutta la parte sequel, no sequel, movimento.E siccome è stata interessante, perché sicuramente ha smosso un po' i grandi player, gli ha forzati a fare qualcosa che fosse un po' innovativo e non sedersi sugli errori, come è normale, nel senso che se sei l'unico sul mercato, poi ad un certo punto ti lascia andare, no? È successo così per la CPU, fin quando AMD non è diventata, o adesso anche Apple, veramente combattiva, c'era un po' di stagnazione, Intel faceva quello che voleva e quindi non c'era molta competizione.Mentre adesso è molto più interessante il mondo del CPU.Idem per i database.Il mondo no SQL ha aperto una porta e sicuramente questo ha dato un po' di vitalità a tutto l'ambiente.Rispondendo, direi, a delle richieste lecite dagli sviluppatori che evolvono sicuramente più velocemente di chiunque altro nel mondo dello sviluppo, perché ci sono nuovi framework tutti i giorni, nuovi modi di sviluppare, nuovi approcci.È molto interessante il mondo dello sviluppo da questo punto di vista, non si ferma mai, c'è sempre qualcosa di nuovo, quindi bisogna starci dietro.E secondo me una delle cose più belle che è stata fatta a questo punto, proprio all'interno del team di SQL, è cercare di fare una cosa che secondo me, da puntista ingegneristico è affascinante.Io una volta l'avevo e tuttora mi piace, forse in maniera esagerata, dire che è un po' come ristrutturare la cappella Sistina, nel senso che è bellissimo costruire un nuovo grattacielo, fare qualcosa di nuovo, ma è altrettanto bello e molto sfidante ristrutturare qualcosa, renderla moderna, ma senza essere - O disnaturarla.- O disnaturarla, sì.Nel senso che sicuramente è difficile creare qualcosa di nuovo, ma rivalorizzare qualcosa, renderla, diciamo, più bella di come era prima, è enormemente difficile.Nel senso che noi, una delle cose, delle sfide più grosse è stata far funzionare Azure SQL sul cloud esattamente come funziona su on-premises, ma passare da un'architettura monolitica a un'architettura distribuita, senza che i nostri clienti si accorgessero di nulla.È un po' come cercare di cambiare il motore della macchina mentre stai guidando, cioè non è esattamente banale.Però è una di quelle sfide ingegneristiche, secondo me, che capitano poche volte nella vita ed sono molto affascinanti.Proiettando SQL Server nel mondo dei vari competitor, senza fare delle comparazioni dirette, però ti voglio fare una domanda anche anche questa un po cattivella quindi sentiti libero di mandarmi a cagare Però pensi che in qualche modo sequel server abbia sofferto la sua natura di prodotto commerciale rispetto ad alternative open source o meno? questo è bella te l'ho detto che era cattiva no no è bella è bella Allora non questa Non so la risposta, però cerco di arrivarci.Nel senso che sicuramente il fatto di essere un prodotto commerciale ha il vantaggio di quello che noi vogliamo fare e fare in modo che i nostri clienti abbiano meno attriti possibili, meno friction possibili.Nel senso che, ad esempio, ogni volta che noi sviluppiamo un nuovo feature, ci assicuriamo che sia il più possibile e perfettamente integrata con quello che esiste già.Tipo quindi Azure SQL e SQL Server supportano il column store, quindi la memorizzazione a colonne.deve funzionare con tutto il resto, non è che possiamo dire, vabbè, questa feature magari è meno usata, e pazienza, t'arrangi te e vedi un po' te come fartela, no? Quindi non so, ColumnStore mi viene in mente e la possibilità di avere tabelle in memory, quindi senza lock e senza niente, mettere insieme queste due cose non è banale.Però il valore aggiunto del nostro prodotto è che noi ti offriamo un qualcosa che funziona bene tutto nel suo insieme, no? Questo paradossalmente ha un valore aggiunto enorme, ma è una sfida notevole per noi, perché vuol dire che noi possiamo lasciare una feature nuova ogni mese e chi se ne frega con l'integrazione con le altre.Con i database open source, siccome tutto va nella direzione di chi ha voglia di fare qualcosa, c'è meno coordinamento, se vogliamo, è un po' più facile rilasciare qualcosa e "sbatterne" del fatto che non sia perfettamente integrato con tutto il passato.Perché, giustamente, essendo spinto da quello che serve alla community, e tu dici, vabbè, se proprio a te serve questa cosa e non è compatibile, in teoria e te la fai o contribuisci tu, no? Io non posso venirti a chiedere, visto che giustamente paghi di contribuire a sviluppare una cosa perché a me costa troppo farlo, no? Sta a me trovare il modo giusto per equilibrare il fatto che va fatta, ma deve anche essere una cosa, diciamo, economica e sostenibile.Quindi, se vuoi, secondo me, ad esempio Postgres ha innovato tantissimo.Postgres è un database che a me piace da morire, è sempre piaciuto tantissimo.Adesso è molto stato rivalutato, una volta si parlava solo di MySQL, se ti ricordi, o se sei familiare con la cosa.Ricordo benissimo.Adesso Postgres è il database da usare, periodo.Non c'è molta discussione.Però questa sua possibilità è nata dal fatto che molti hanno contribuito e hanno contribuito nelle direzioni che più spingevano gli sviluppatori.Ha un supporto JSON fantastico.Però, ad esempio, il ColumnStore ancora non è all'interno integrato nel prodotto.è una libreria esterna, se non ricordo male.Però, diciamo, gli dà più flessibilità.Nel nostro caso, invece, il supporto JSON c'è, non è male, ma non è libero di Postgres, onestamente, però, ad esempio, è integrato con InMemory, LockFreeTable, ColumnStore e quant'altro, no? Quindi la risposta è sì e no, dipende in funzione del fatto se tu preferisci una innovazione spinta e come magari una startup sei disposto a dire "ma chi se ne frega del vecchio? Io sono nuova, voglio solo le cose nuove.Oppure invece se sei più un enterprise dici sì ho già 200 database non è che posso far finta che non esistano.E quindi ho bisogno di integrazione più che di innovazione.Chiaro.Hai citato più di una volta il Column Store.Sì.È stata una scoperta che ho fatto non tanto tempo fa leggendo un bellissimo libro Data Intensive Applications.Sì, sì.dal mio punto di vista è un capolavoro per gli ignubi come me perché in realtà mi ha fatto entrare a capire il sistema di locking, cosa è che magari usi ad alto livello e non sai cosa succede sotto il coffano e scoprendo alla fine cosa succede sotto il coffano è affascinante e oltre ad essere affascinante ti dà quella consapevolezza nell'utilizzo che poi come dicevi prima ti aiuta nelle performance, aiuta nella qualità del prodotto che vai a lavorare.Però per gli ascoltatori che non conoscessero questo approccio alla memorizzazione, di cosa si tratta? È un algoritmo, una tecnica inventata negli anni 70, 80 se non ricordo male, in cui oggi come oggi se tu immagini un database, adesso dico una boiata assurda però per semplificare, cioè tu hai una riga, una tabella, un enorme foglio Excel, una tabella, e ogni riga ha dentro dei valori che sono nelle sue colonne.Tipicamente questa riga viene salvata così com'è se vuoi su un file.Quindi se c'è il mio nome, Davide Mauri, e poi il mio indirizzo, quando tu cerchi il mio nome trovi anche tutto quello che viene accanto.Questo è perfetto per quando tu hai la necessità di fare una ricerca, diciamo, per cui trovando un dato hai bisogno di tutti gli altri.quindi tipicamente, non so, in un gestionale, quando devi aprire il forum di un cliente o una shopping cart, quando devi far vedere il carrello.Il problema è che se tu invece hai solo bisogno di accedere al mio nome o al mio cognome, perché vuoi contare quanti cognomi di un certo tipo ci sono in una nazione, quindi la distribuzione, ad esempio, dei cognomi piuttosto che il valore medio del carrello per geografia e quell'altro, e quant'altro, se tu hai 100 colonne e a te ne servono 3, tu paghi per accedere anche all'altro 97, ma butti via tutto quel tipo di risorse, perché non ti servono.Il column store, quindi, al posto che salvare i dati mettendo tutte le cose che sono legate allo stesso oggetto sulla riga, è come se facesse una distinct su ogni colonna.Quindi io prendo tutti i valori della colonna nome, faccio un bel distinct e me li salvo, usando poi tecniche a questo punto di comprensione o basilari, come il run length encoding, che è veramente banale, o più sofisticate come dictionary compression e quant'altro per cercare di dire, beh, se ci sono 100 Davide, diciamo, a Milano, è inutile che io per 100 volte scriva Davide, posso scrivere 100 e Davide.E questo veramente vuol dire che quando leggo, leggo pochissimo al posto che devo scansionare una mole importante di dati.Se tu immagini questo per ogni colonna, vuol dire che quando i dati sono così memorizzati, Quindi è molto facile rispondere a domande che sono legate ad aggregazione di dati, perché il dato è salvato in modo tale che sia efficiente leggerlo e aggregarlo.Chiaramente ci sono i pro e i contro, perché tu immagina che se io devo aggiornare un dato e devo decomprimere la parte che lo contiene, devo aggiornarla, poi magari l'aggiornamento è grosso, quindi devo splittare il dato, la parte in più di una.ci sono un po' di complessità nella scrittura, però ti dà una potenza in termini di analisi che è fantastica, incredibile.Query che passano da 100 secondi a 1, stiamo parlando di questo.Sì, questo pattern tra l'altro mi è sembrato di vedere che è molto usato nel mondo dei big data e delle analitiche.Assolutamente, perché se no muori via io.Esatto, che è la peggior malattia.Tante cose sono cambiate in questi ultimi 20-30 anni, che poi più o meno sono forse anche di più.Sono gli anni in cui esiste il linguaggio SQL.Ma ritieni il linguaggio SQL ancora attuale? Oppure ci possono essere delle altre soluzioni soluzioni interessanti.La butto là magari una una castroneria e censurami se sei in Italia.Però immagino un linguaggio di quelli più in stile GraphQL.Sì sì.Quindi pensi che SQL senta la sua vecchiaia? Inizia a sentire la sua vecchiaia? Allora, opinione personale un po' sì.Sicuramente va aggiornato.Il punto però è che che è anche perfetto per quello che fa.Nel senso che, prima di tutto, è un linguaggio dichiarativo.Quindi il fatto che tu dica cosa vuoi ottenere, non come, permette a te, sviluppatore, di non doverti preoccupare di scrivere l'implementazione.Cioè, ad esempio, se tu devi fare, diciamo, devi prendere dati da due tabelle o da due collection, visto che questa roba funziona a prescindere dal database, dal modello di dati che usi, e devi unirle, e ci sono diverse strategie per fare questo join di oggetti, no? In funzione di quanta memoria ha, di quanti dati sono, di come sono distribuiti i dati.Ora, se tu, sviluppatore, devi fartelo, tanti auguri, la maggior parte di noi farebbe un bel ciclo e tanti saluti.Performance ce l'escordiamo subito, perché il ciclo è la peggiore cosa che si può fare in questo caso, quando hai tanti dati.E quindi il fatto che SQL ti permette di dichiarare quello che vuoi, poi lasci all'optimizer, quindi al query engine, la possibilità e l'onere di risolvere in modo migliore le cose è quello che l'ha reso vincente.Tanto è vero che è usato non solo in Azure e SQL Server e non nei database relazionali, ma se pensiamo a Databricks, Spark, SQL alla fine è il linguaggio.Perché è facile, cioè tu puoi esprimere concetti molto complessi, molto complessi, in veramente una riga di codice o due.Però è molto elegante.Detto questo, a me sarebbe, col seno del poi, io toglierei la select come prima statement e lo metterei come secondo, almeno ci può essere un intelligence decente.No? Perché oggi come oggi siamo anche abituati ad avere dei tool che ci supportano, ma il linguaggio deve essere fatto affinché i tool possano, come dire, creare questo supporto che ci serve.Ad esempio, l'intelligence che possiamo fare noi adesso, siccome tu parti, dice, il linguaggio è stato fatto per essere il più possibile vicino al linguaggio umano, Quindi dici, voglio prendere A, B e C dal tabello della collection XY.Il problema è che A e B e C, l'intelligence compiler non sa da dove arrivano, fin quando non specifichiamo la clausola from.E questo si vuole un po' un sintomo del fatto che è una certa età.Detto questo, si può cambiare, la vedo dura, perché ormai è talmente usato ovunque che c'è chi ci ha provato, volte ci stanno ancora provando ma è talmente come dire conosciuto e ormai consolidato che è difficilissimo secondo me che si potrà cambiare in futuro.Io non so non so se in realtà è un sostituto però ho visto la la la la la la la la la la forte presenza del concetto di MapReduce.Vabbè voi perché a casa vivo con una big data engineer o ingegner.Quindi queste robe insomma me le sento tutti i giorni.Però dal tuo punto di vista ecco riesci a vedere qualche alternativa? Ti è capitato di vedere qualche alternativa valevole di interesse? Beh MapReducer è molto interessante secondo me.Peraltro è dentro l'engine di SQL da versione 7 se non ricordo male.Nel senso che ad esempio quando tu scrivi una così come in Postgres, non sono così esperto su quel frangente, ma sono sicuro che funzionino nello stesso modo, tu puoi scrivere una custom aggregation function, cioè tu puoi decidere che non ti basta Sam, vuoi fare una cosa tua, no? Ma siccome noi viviamo oramai in un mondo di multiprocessori, tu devi scrivere il codice in maniera tale che ci sia una parte che viene seguita su una porzione di dato su ogni core, e poi una parte che aggrega, no? Questo è MapReduce alla fine, perché ogni funzione fa un pezzettino di lavoro, la passa alla successiva che la riduce, fino a quando arrivi a una sola aggregazione.Quindi il paradigma, secondo me, è sicuramente vincente per tutto ciò che riguarda processi paralleli.Ultimamente è stato pompato all'inverosimile.È una nicchia, però, nel senso che non è che lo devi usare...cioè, se fai big data, probabilmente lo usi sì, perché hai una mola di dati così grossa che devi per forza romperla in pezzettini più piccoli.Però non è quello che si dice qua un free launch, nel senso che non è che arriva e magicamente risolve i problemi.Come partizione di dati è fondamentale, perché se tu hai un tera di dato, è 900 giga da una parte e 100 dall'altra, MapReduce non è che ti aiuta, perché è completamente sbilanciato.Quindi tutte le problematiche di data distribution, data modeling, ci sono ancora.Ma MapReduce è semplicemente un tool che, se usato correttamente come molti altri, ti permette di avere delle performance assolutamente ottimali laddove altrimenti dovresti andare con degli algoritmi magari seriali che evidentemente non sono vincenti in un mondo parallelo.Altre alternative sinceramente non ne ho viste, diciamo alternative a quelle anche perché non me ne vengono in mente attualmente, ma ti ripeto, lo vedo abbastanza di nicchia come cosa.Nel senso che si applica al mondo dei big data e fuori da lì non c'è moltissimo.Quindi non credo ci siano moltissime altre alternative che siano state analizzate.Infatti era la considerazione che facevo anch'io e mi chiedevo se ci potesse essere qualcos'altro nel panorama.Purtroppo diciamo, immagino che se ne possono fare.Quando hai tanti dati l'unico obiettivo che hai è cercare di spostarli il meno possibile.Esatto.Alla fine no? Verissimo.E allora andiamo all'argomento caldo, quello che so che ti fa inferocire.Quindi parliamo di No Sequel e del concetto di Schema-less.Sì, molto volentieri.Che è un trend che abbiamo visto negli ultimi dieci anni, otto anni più o meno.Sì sì sì sì sì sì sì dieci anni sicuro.E che ha catturato l'attenzione di un po' di tutti vuoi per moda, vuoi per trend, vuoi per quello che ti pare insomma, ma dove in realtà quello che passava era ok io non mi concentro troppissimo nello schema e butto i dati un po' come l'applicazione insomma modello tutto nell'applicazione e poi io butto come se stessi salvando su un file nel database e magicamente tutto accade.In realtà, cosa è che non è magico la tua faccia? No, no, ma guarda, hai accettato il punto.Che cos'è che manca? La magia.E' proprio quello.Nel senso che tu immagina di essere a casa tua e fai un trasloco, io l'ho appena fatto, e al posto che metterà a posto le cose butti tutto lì, no? Sarebbe bello se se io chiudo la porta, vado al ristorante, torno ed è tutto a posto, ma non è così.Cioè la magia è purtroppo quello che ci frega, perché manca.E quindi dire "schemeless", a parte il fatto che come ho già detto più volte, e non solo io ma anche persone ben più rinomate di me come Martin Fowler, non esiste come concetto, cioè è proprio una roba che non può esistere sulla faccia della terra, perché "schemeless" vuol dire che tu non hai neanche idea di come leggere qualcosa, perché sono dei dati senza nessuna struttura neanche implicita e quindi è una roba casuale, rando.È diverso dire che tu non vuoi imporre uno schema nel momento in cui vai a scrivere e lo vuoi avere, quindi si parla di schema on read versus schema on write, e lo vuoi invece avere al momento in cui leggi.Però se fai questa cosa, che ha il suo scopo in nicchie di mercato assolutamente, sta semplicemente spostando il momento in cui tu devi decidere come leggere i tuoi dati.Io posso buttarti dentro un bel file, JSON, YAML, TOMOL, quello che vuoi, alla rinfusa, non dico XML perché ormai non lo usa più nessuno, alla rinfusa e semplicemente io, che ho fatto questa cosa, sposto su di te la responsabilità di leggerlo nella maniera corretta.Ora, questo può essere a volte utile, perché tu dici "Beh, io non so cosa vuoi leggere tu, quindi ti do tutte le possibilità, state a decidere, però sto solo spostando la responsabilità su di te, perché sarà a te".Infatti, ad esempio, se prendiamo Spark, alla fine quando vuoi leggere qualcosa, cosa devi fare? La prima cosa? Dichiarare uno schema.È la prima cosa che fai, perché non c'è chance, altrimenti lo schema è metadata, ti dice che quella colonna è il cognome e non il numero di telefono.Non si può fare altrimenti, no? e anche quando nelle tue applicazioni vuoi essere completamente schemaless.Non è vero.Perché una classe è uno schema.Un tipo o una struttura è uno schema.Poi tu mi puoi dire "ah beh, io voglio essere più libero nel modificarla", ma hai assolutamente ragione.Quindi ci stiamo ponendo il problema del come faccio ad avere uno schema che sia flessibile, così che io possa aggiungere cose che non mi aspettavo di avere, però non possiamo far finta che non ci sia un altro problema.Cosa succede a tutto quello che ho già? Se tu decidi che uno schema cambia rispetto a quello che ho già, io quel cambiamento come lo assorbo? Tutte queste problematiche secondo me, un po' diciamo in maniera giustamente furbesca, in alcuni casi sono state completamente, si è fatto finta che non esistessero.Dici, usa questo prodotto e fai quello che vuoi, non hai più problemi.Gli indici vengono creati in automatico, non devi più pensare a uno schema up front.La realtà che quello che si sta vedendo è che non è vero.Tanto è vero che se tu vai su ormai direi tutti i prodotti NoSQL parlano di che cosa? Data modeling, schema definition, normalizzazione.Normalizzazione magari non chiamata così, ma la chiamano embedding versus referencing, ma è esattamente la stessa cosa.Quindi il problema di modellare i dati non è sul come lo faccio con un database relazionale o con qualcos'altro.È il problema di gestire correttamente i dati diminuendo il più possibile le duplicazioni, perché ogni volta che duplichi qualcosa hai la responsabilità di mantenerla coerente, oppure di duplicarla sapendo che lo stai facendo, quindi stai denormalizzando, perché vuoi ad esempio parallelizzare i processi, quindi ti serve duplicarla.Quindi tutta questa storia schemeless versus SQL versus non SQL, adesso secondo me è schemata molto, perché una volta era più una sorta di religione, se vogliamo, o comunque di diatriba sul "è possibile e non è possibile, è meglio e non è meglio".Adesso credo che nessuno dica "ah, vado no SQL, perché così non ho schema".Sappiamo benissimo che da qualche parte lo devi gestire.E spesso lo devi gestire nel lato applicativo, no? Secondo me quella è la peggior cosa che uno può fare, però quella è la mia personale...Ecco dov'è dov'è il lato negativo di doverlo gestire nel lato applicativo dove dove sente che è interessante questa domanda.Allora se tu sei da solo e sei bravo secondo me non hai in grossi problemi puoi farlo un po dove vuoi.Se vi se lavori in un team di 30 persone o sei veramente bravo a comunicare e a stabilire degli standard oppure cosa ti impedisce a te di fare la classe A e me la classe A2 che differenziano di pochissimo, semplicemente perché non ci siamo parlati.Cosa mi impedisce di magari fare, diciamo, prendere delle scelte, e ho visto fare anche delle tabelle resirazionali queste, quindi per dire che il problema è soprattutto la comunicazione, cosa mi impedisce di fare, non so, come mi è capito di vedere la colonna, last name e last underscore name.E poi alla fine, quando vai a fare una query, il problema è quando vai a usare i dati, come fai a sapere dov'è il dato corretto? Perché magari last name dice una cosa, last underscore name un'altra.Quindi inizia ad avere problemi di coerenza.Ora, questi ci sono dappertutto.Sicuramente se non hai un database, la comunicazione diventa importantissima e la validazione dei dati.Se hai un database, hai un vantaggio, che la gestione dello schema è centralizzata.Quindi, caro sviluppatore, se tu devi inserire i dati in questa tabella, o li inserisci così o non li inserisci.che è diverso dal...beh, buttali dentro comunque e poi vediamo dopo come metterli insieme.Perché per lavoro mi capita di lavorare con sistemi Data Lake e tutte le volte piango sangue.Perché i dati sono a volte in una colonna, a volte in un'altra, quando viene inserito un nuovo sistema c'è una terza colonna ancora, le mie query sono un'infinità di where, colonna 1 uguale a qualcosa, colonna 1b uguale a qualcos'altro, magari perché sto cercando, che so, un certo...un certo server o un certo database o una certa invoice o quant'altro.Quindi il problema è che lo schema va gestito dove, purtroppo non credo, almeno io preferirei gestire un database, poi capisco che ci sono problematiche però almeno è centralizzato altrimenti è una giungla.Sai io pensavo una cosa mentre parlavi, è che guardandomi intorno moltissime applicazioni dove ho lavorato mi è capitato di vedere sempre la cartella migrations ah si? che tu run le migration sincronizzi di quello che c'è da sincronizzare alla struttura del database e allora come le interpretiamo quella cartella migration o la cartella models che sta nella nostra applicazione come schema o anche in questo caso c'è quel tipo di vulnerabilità pur essendoci una source of truth condivisa e pubblica.Beh allora io direi che models la chiamerei di fatto uno schema, perché sono le tue classi, i tuoi modelli e quello di fatto definisce uno schema al quale la tua applicazione si conforma e chiunque voglia usare la tua applicazione si conforma.La migration è più una schema evolution se vuoi, che è comunque un altro problema che non si è ancora risolto perché perché evolvere uno schema è sempre...cioè è...è painful, nel senso che non c'è, come dire, per ora, soluzione.Come la metti e la metti è doloroso.Ma questo è il problema storico se vuoi dei database rispetto a un'applicazione.Un'applicazione la spegni, la riscrivi, diciamo che la puoi far andare.Un database lo spegni, lo cambi, e i dati dentro, quelli che c'erano prima, non è che possono sparire.Sì, o facciamo finta che spariscono, però non è bellissimo.il problema è che il dato persiste lì dentro, quindi ogni volta che fai una modifica devi sempre pensare al passato, cosa succede a quello che ho già.Quindi questo succede anche nell'applicazione, ma è più facile da gestire, metti un if o un controllo sulla versione ed è un po' più facile, perché l'applicazione per sé non persiste, sono i dati nel database che sono persistiti, quindi hai questa complessità in più.Ma poi soprattutto la complessità c'è quando si lavora in sistemi che sono acceduti da diversi sistemi contemporaneamente.Quindi se io e te non ci parliamo e dobbiamo usare lo stesso schema, e tu fai l'API, io sto facendo un'applicazione mobile che usa altre API, siamo molto bravi a cercare di parlarci, oppure alla fine ci rifacciamo a un contratto, che può essere un'interfaccia API, che cos'è? È uno schema, alla fine.Perché se l'interfaccia API dice solo "passami un JSON, quello che vuoi", io non so cosa passarti.non ho idea di cosa ti devo passare per far sì che tu possa fare il tuo lavoro.Quindi o ci parliamo o ci inventiamo Jason Schima, guarda caso che dopo che Jason è nato senza schema adesso c'è la proposta di avere Jason Schima.Ma è come dire, è una...capisco che è una fatica, ma attualmente non penso che ci siano soluzioni, perché ancora una volta come la giri, lo schema sono metadati di cui hai bisogno per lavorare.La cosa importante è trovare e capire dove deve essere la sorgente e la verità di questo schema se deve risiedere nell'applicazione se deve risiedere nel database perché io non ti nascondo che ad oggi sento una certa ridondanza di definizione.Certo.Vedendo le applicazioni come ti diceva la cartella model poi stai tracciando lo schema evolution con l'immigration e c'hai lo schema all'interno del database.È vero, è assolutamente così, hai ragione.Attualmente non mi viene in mente nessuna soluzione vincente per questo, ma anche perché in effetti poi se ci pensi magari il database è usato da n diverse applicazioni e queste hanno bisogno di parti diverse dello schema, quindi ognuno ha il suo schema locale.In teoria con l'architettura microservici, c'era l'idea che un microservizio ha il proprio database e quella è un'altra favoletta secondo me.perché è vero sulla carta funziona tutto perfettamente 10 microservice 10 database 70 reconciler e te lo dice uno che sta scrivendo un reconciler in questo momento questo è il problema poi come si dice ci sono due problemi nell'informatica due cose complesse che uno è dare i nomi alle cose il terzo invalidare il secondo invalidare le cache il terzo te lo dico io è un altro è reconciler perché quando hai 10 database con 10 dati diversi è un disastro, un disastro.Concordo, concordo.E allora...Vai, vai, scusa.No, quindi anche questo discorso di microservices ci hanno provato, ma la realtà come al solito poi ti si presenta nella sua brutalità, no? Cioè se non spendi i soldi facendo lo schema, li spendi scrivendo il reconcilio.Alla fine...Io posso portare la mia esperienza, sto riconciliando due postgres e tre istanze redis.È un bagno di sangue.Sì, sì, sì, guarda ci sono passato anch'io.Noi usiamo elasticsearch, redis e local storage database e ogni volta era un bagno di sangue.Cioè, come la fai la sbagli, nel senso che è difficilissimo trovare un modo che sia assolutamente quello corretto, perché hai dei conflitti che devi risolvere e non sempre la generalizzazione della risoluzione del conflitto va bene per tutto.Quindi non bagni il sangue.Ti faccio invece, visto che stiamo parlando appunto di schema, schema, di questo argomento, volevo chiederti cosa cambia nella gestione dei JSON da un modello relazionale o comunque SQL Server in questo caso o SQL che da questo punto di vista è lo stesso, dovrebbero essere le stesse due la stessa cosa, si si è esattamente lo stesso e invece un database no SQL? ah, guarda ti dico una cosa secondo me che negli ultimi anni allora dividiamo un attimo se tu mi parli di Key Value Store tipo Redis ok lì siamo proprio ad un altro pianeta nel senso che è proprio diverso l'approccio tu hai un Key Value Store e basta quello fa, lo fa benissimo, è fantastico Database tipo Cosmos DB o Mongo, che sono invece documentali, in realtà, per come la vedo io, non sono poi così diversi adesso dai modelli relazionali.Cambia lo storage, ma alla fine, ti dico, hanno tutti una primary key.Nei documenti hai il document ID che deve essere univoco, e ti identifica una chiave.Non puoi avere proprietà che hanno lo stesso nome, perché altrimenti non puoi avere nel JSON name e name, perché altrimenti cosa rappresenta il secondo, il primo, no? Quindi sono più vicini di quello che secondo me si voglia pensare.La vera differenza è che da una parte hai uno schema on write, quindi tipicamente i modalità base razionali, dall'altra hai uno schema on read, tipicamente i documentali, no? Poi è chiaro che dietro le quinte sono...lo storage è diverso, ma tutte e due usano B3 per fare gli indici, perché non c'è tantissimi algoritmi per fare un indice.Alla fine hai un B3 o un hash index o qualche altro modo di fare filtri che sono praticamente usati appertutto.Tutti i database usano qualche forma di B3 alla fine della fiera.O un hash index o gli algoritmi sono quelli.La cosa interessante, secondo me, è il grado di flessibilità che ti danno.Però i modelli relazionali, i database relazionali diventando sempre più flessibili, nel senso che aggiungere una colonna ormai è una roba che puoi fare senza grossi problemi, oppure puoi usare del JSON all'interno della database relazionale per darti quella flessibilità che ti serve.E ormai hai tutta una serie di metodi e di funzioni che ti permettono di fondere il relazionale con il JSON e ottenere una roba che è completamente ibrida.Azure SQL lo fa, SQL Server lo fa, Oracle lo fa, Postgres lo fa benissimo, MySQL ha le estensioni per JSON.Quindi diciamo che c'è molto grigio adesso, no? I documentali stanno diventando sempre più vicini al modello relazionale.JSON Schema di fatto è l'applicazione di un schema, un documentale che quindi vuol dire schema on write tipicamente, se vuoi rafforzare questa cosa.So che in molti ci sono diverse richieste per avere le transazioni supportate su database, non sicuro perché alla fine anche lì è tutto bello, ma poi ti serve garantire che i dati siano modificati in maniera consistente e corretta.Quindi stanno convergendo veramente molto.Chiaramente rimarranno prodotti diversi, però siccome ad un certo punto diventerà veramente la...ti piace di più il cioccolato o la panna, nel senso...è un po' come .NET con Python o con JavaScript o Node.Cioè mi puoi dire che uno è meglio dell'altro? No, direi che è più una questione magari di gusti, di team, di librerie che trovi e che dicendo.Capito.Altra domanda.Adesso cito Carmine uno dei nostri ammutinati che lui dice spesso quello che andiamo a sviluppare è molto più semplice di come sembra e lui tira in ballo il crudino della chiesa come come lo cioè la classica applicazione crude che fa quattro operazioni semplici al database e devo essere sincero spesso facendo l'attacco a molte delle nostre applicazioni sono il 90% crudo.E allora devo dire che questi ultime settimane ho buttato un occhio su Supabase.Che cos'è Supabase? Supabase è un'alternativa a Firebase o almeno a livello di marketing così si propone, open source, che in realtà ha una cosa molto molto particolare.Ha Postgres come cuore pulsante, ha un sistema di autenticazione JWT fatto con un piccolo moduletto scritto in Go, ma in realtà la verifica viene fatta direttamente da Postgres con un'estensione.Quindi dicevo, ha Postgres, ha delle sorte di Lambda Functions che secondo me sono semplici store.Store.Store.Può essere.E alla fine fondamentalmente tu hai sta roba con un API rest.Bella che sposta.Protetta.Sei contento.JWT è per il tuo crudino al volo per la tua applicazione mobile.Funziona da Dio.Domanda per questo tipo di applicazioni.Il back end e lo dico anche da back end.Andrà a morire.Cioè farà tutto il database? Oh no, non credo.Perché sarebbe un'ibridazione un po' troppo forte, secondo me.Nel senso che ancora...Allora, conosco un po' meglio, non conoscevo Superbase, conosco Firebase, conoscevo Postgres, ad esempio, che è un'estensione.È utilizzata da Superbase, infatti.Ah, ecco, ok, perfetto.Non andrà a morire, soprattutto nel caso per una semplice...una semplice necessità architetturale.nel senso che supponiamo di dover far scalare Postgres, right? Giusto? Ora, io voglio avere il database che è in grado di scalare indipendentemente dal frontend, e per frontend intendo ciò che espone il REST API.Perché devono rimanere separati? Perché io posso avere magari un miliardo di richieste via REST API, ma banalissime, e mi basta una semplicissima, diciamo, 16 core dietro le quinte per rispondere.Poi posso usare le cache e quant'altro.Viceversa posso avere un front-end piccolissimo, una macchina che accetta dieci richieste al minuto, ma sono enormi, perché sono richieste di analytics.E quindi dietro devo scalare il mio database tantissimo.Quindi la necessità di tenere il database separato da qualsiasi voglia di meccanismo di caching e dal front-end, dove ripeto, per front-end per me, essendo il back-end, sono le API, quindi il confine per me sono le API, è fondamentale perché il valore aggiunto al cloud è proprio che ogni cosa può scalare indipendentemente.Quindi è importantissimo tenere tutte queste cose separate dal database perché il database deve poter scalare per la sua tipologia di lavoro.Mentre invece un backend API, quindi il frontend per controllare l'API, deve poter scalare per la sua tipologia, Sono diverse, sono due lavori diversi.Quindi che si fondano a tal punto di diventare un unico prodotto, non credo, tranne in casi tipo Firebase, Superbase, dove il valore aggiunto è proprio quello di dire allo sviluppatore, non ti preoccupare, hai una cosa così semplificata che la usi in maniera assolutamente consistente, facile e quant'altro.Però quello di solito scala fino a un certo punto.Quando tu hai bisogno di scalare oltre, hai la necessità di avere i pezzi separati che si parlano tra di loro.Quindi, secondo me, dove andranno i database è una sempre più integrazione, o sempre più punti di integrazione con tutto ciò che permette di consumare i dati.Quindi REST API, GraphQL, hai citato prima, è sicuramente un altro fondamentale.Cioè, sarebbe bellissimo, anzi, è bellissimo come permette di fare Postgres, ma noi abbiamo scritto alcuni articoli con alcuni partner tipo Directus e Prisma.Io ho il mio database, lancio un tool e questo in automatico mi crea le front-end REST e front-end GraphQL senza che io debba scrivere codice.E la direzione, secondo me, è quella di togliere tutto ciò che è quello che si chiama plumbing.- Boilerplate.- Eh, o boilerplate code, perché alla fine quello è semplicemente una palla da scrivere e non è che aggiunge valore, no? Però serve, perché ti garantisce l'interdipendenza tra i due sistemi, ma anche la possibilità che uno usi l'altro, no? E ti dico, secondo me, le cose andranno in questa direzione perché poi l'interdipendenza ti permette anche più estendibilità.Cioè, diciamo che domani Apache Arrow diventa il nuovo...Arrow Flight diventa il nuovo formato di scambio al posto che JSON.E se fosse tutto nel database, aggiornare database è sempre complesso, perché è un sistema grosso e complesso.Se invece hai una cosa esterna, è molto più semplice, no? Quindi una modularizzazione io la vedo comunque come il futuro.Se vuoi una sorta di microservices più maturo, ecco, nel senso in cui ci sono sistemi distribuiti alla fine, quindi ogni servizio ha una sua parte, collabora con gli altri e alla fine spongono magari un'interfaccia semplificata tipo REST o GraphQL per accedere a tutto il resto.Questo è quello che avverrà.Sì, la domanda mi veniva perché mi è capitato di vedere molti sistemi di storage o database simili che espongono già un API HTTP e quindi mi chiedevo se in realtà la direzione era quella.Sicuramente è una direzione che va presa in considerazione visto che gli sviluppatori vanno lì.Sono maledettamente pigri diciamolo pure.Ci sta, ci sta alla fine.Il miglior sviluppatore è quello che scrive meno codici.Esatto.Per citare un amico, Valerio Galano, pensieri in codice dice uno sviluppatore è colui che risolve problemi talvolta anche scrivendo del codice.Vero, no è vero.Anche perché poi banalmente meno codice scrivi meno bagaglia, meno manutenzione.Quindi idealmente sì.È proprio così.Ti faccio allora una domanda.Avete da poco portato SQL Server sul cloud.È stato uno da poco insomma.L'ultima evoluzione è quella più nuova, magari tu ti riferisci a Hyperscale.Esatto, è stata un'impresa titanica.Sì, assolutamente.Puoi raccontarci le cose che è cambiato? Sì, molto volentieri.Quella secondo me è proprio una roba da raccontarci, sarebbe da farci un libro, perché è proprio bello, nel senso che, lascia stare che io ci lavoro dentro, però è proprio dal puntista ingegneristico affascinante.SQL Server è sempre stato un monolite, un eseguibile, un po' di DLL, ma di fatto era un eseguibile, un monolite.All'interno aveva diversi engine, lo storage engine e il query engine, però era uno.Allora, il primo step di portarlo sul cloud è stato quello di, diciamo, di semplicemente far andare SQL Server su una macchina virtuale, se vogliamo, in un container, ma di mantenere l'architettura identica.La differenza era che tu non scrivi più su un file che era sulla stessa macchina, schede su un file che era sul network fondamentalmente.Però l'architettura era quella.E funziona ancora benissimo.Se tu vai sulle classiche offerte che abbiamo, che sono tipo premium piuttosto che business critical o anche la standard, è sì quel server proprio tale e quale.Però ci siamo resi conto che così facendo ci perdavamo il bello del calcio.Cioè possiamo scalare in maniera praticamente infinita.Però come puoi scalare in maniera infinita? solo se puoi aggiungere macchine e queste possono sostenere il carico di lavoro che sta arrivando al tuo database.Allora abbiamo dovuto di fatto fare un enorme refactoring e un'enorme ridefinizione architetturale andando a separare completamente lo storage engine dal query engine e addirittura facendo in modo che ognuno fosse un servizio se stante.Quindi noi adesso Hyperscala ha quello che noi chiamiamo compute node che è dove gira il query engine.dove quindi tutti i colleghi fanno la tua query e lui si prende in carico di fare il parsing, capisce cosa stai chiedendo, quali sono gli oggetti a cui devi accedere.Poi, al posto che usare lo storage engine che c'è al suo interno, perché non c'è più, va a collegarsi a una serie di servizi, che chiamiamo page server, essendo servizi quindi è molto facile aggiungerli, perché sono semplicemente altre macchine che tiri su e le colleghi al primary node, al primary compute node, e questi si preoccupano di gestire 128 giga di dati ciascuno.E lì dentro c'è lo storage engine, uno storage engine dedicato a gestire 128 giga.Il tuo database cresce, altro server con altra memoria per gestire l'altra 128 giga e via dicendo.Poi adesso abbiamo messo un limite che è 100 tera, diciamo che è un limite attualmente artificiale, nel senso che non c'è motivo per cui non potremmo andare oltre, però 100 tera ci sembrava sufficiente, anche perché ogni volta che noi diamo dei limiti vuol dire che dobbiamo fare dei test, c'è una serie di procedure che dobbiamo fare per poter dire "puoi fare questo", perché poi ci sono degli SLA che dobbiamo garantire.Però la puntista architetturale possiamo crescere quasi all'infinito, fondamentalmente.E quindi è diventato un sistema distribuito.Quindi abbiamo adesso il Compute Node, abbiamo una serie di page server sulla quale il Compute Node si collega per andare a scrivere i dati nel data page che sono coerenti con la richiesta che stai facendo.Abbiamo dovuto separare quello che si chiama...sai che i database relazionali, anche non relazionali ultimamente, usano una tecnica che si chiama write-ahead logging, dove praticamente i dati non vengono confermati fino a quando non sono consolidati su un log, che è praticamente quello che a chi piace usare Kafka è nient'altro che Kafka versione file, perché è un append-only event log, dove scrivi tutto quello che succede su database.E siccome è append only, quindi sequenziale, è molto veloce nella scrittura.Quindi scriviamo lì dentro che cosa hai fatto e poi quando quella scrittura è confermata, allora possiamo andare a leggere dal transaccelogo e andare a, come dire, fare una sorta di summary di tutte le modifiche, no? E quindi aggregare l'ultima operazione e modificare la data page query.Una snapshot, no? Bravi, bravissimo.Alla fine l'architettura è quella, no? Diciamo che abbiamo appunto questo read only event, write only event log e poi uno snapshot della foto delle ultime modifiche.E tutte queste cose adesso sono dei servizi.Quindi ogni cosa che invece prima era, se vuoi, un pezzo di codice all'interno di un monolite è stato riscritto per essere un servizio che può scalare indipendente, su macchie indipendenti, e questo il tutto senza apportare alcuna modifica all'engine che tu vedi.Domanda.Quanto impatta a livello di performance la comunicazione tra questi nodi? Beh tanto.Tanto perché chiaramente devi muovere i dati.Allora noi stiamo cercando l'impossibile per far muovere meno dati, no, possibili, perché meno dati riusciamo a muovere meglio è.Poi è vero che i nodi sono collegati tra di loro, adesso non mi ricordo se abbiamo delle date ufficiali su che bandwidth vengono usate, ma tipicamente non è un problema.Ma in generale sappiamo che sarà un problema, perché più i database crescono, più se devo spostarti 20 tera per fare una join, questo non è esattamente il massimo.Allora, chiaramente c'è una serie di attività in corso per cercare di capire come possiamo minimizzare la quantità di spostata, perché alla fine di un database una cosa interessa, minimizzare l'I/O, che sia network, che sia disk I/O, cioè, quello è l'obiettivo, no? Quindi...però attualmente non...diciamo, le performance di hyperscale sono assolutamente in linea con quelle di...dello standard e per certi versi addirittura del business critical, quindi sono ottimali.Anche perché, proprio per evitare di sfostare dati, usiamo una architettura di cache a più strati.Cioè c'è un cache, c'è una cache in memoria, la classica buffer cache che hanno tutti i database, SQL Server anche, che sta in memoria nel compute node.Poi il compute node ha una secondary cache che è travolta alla memoria, che praticamente è un file memorizzato su una SSD molto veloce, che aiuta a una sorta di cache di secondo livello.Poi ogni page server ha un'altra cache che contiene tutti i dati di quel page server e alla fine, se dovesse, supponi che c'è un'invalidazione di tutte queste cache, solo in quel caso andiamo a leggere i file da disco, vero, che è un Azure Storage.Quindi stiamo cercando il più possibile di evitare di fare I/O, perché alla fine sappiamo che quello è il problema, no? Quindi usiamo o delle tecniche di riduzione degli I/O, o delle tecniche di caching.Stiamo studiando altre cose per cercare il più possibile di evitare di leggere quando non dobbiamo leggere.O leggere in maniera intelligente, ad esempio, quindi fare prefetch, queste cose qua.È un bel...- Sfida.- Una bella sfida.Ti volevo chiedere, non so se esiste già una feature di questo tipo, ma è prevista la possibilità di scalare a zero? Quindi non solo scalare in growing ma… Sì, sì, no assolutamente.Attualmente sì per una particolare versione di SQL che si chiama Azure Server, SQL Server Serverless, per cui tu puoi mettere in pausa il database e poi puoi anche farlo scalare in automatico.Quindi, diciamo, sì, è per una particolare, si chiamano skew, quindi una particolare tipologia, diciamo, o versione, che è sempre, diciamo, l'engine è sempre quello, ha dei costi diversi, ti conviene farlo se, ad esempio, hai delle cose molto spotty, quindi non so, lo usi un'ora al giorno, poi per tre ore basta, perché chiaramente, come al solito, la flessibilità ha un prezzo, come sempre, no? e quindi ti conviene farlo se il tuo workload ha quel tipo di imprevedibilità.Se invece è più una cosa costante, tu sai che 24x7 hai un certo tipo di workload o comunque varia dentro un range che conosci, hai altre possibilità che magari non ti permetti di mettere in pausa.Però sì, volendo c'è questa possibilità.Veramente figo.Guardavo l'orologio, siamo a un'ora e cinque minuti.che tra un po' devi scappare.Allora rimane giusto il tempo per l'ultima domanda giusto per scaldarci un po' e per il nostro momento paese di balocchi.La butto là perché perché diciamo è una roba calda spesso ne parliamo nella nostra community e quindi dico una sola parola ORM.Uhhh divertente anche guarda è divertente anche questo prima dei dei database NoSQL c'era un grossissimo dibattito, ricordo anche con i miei amici di UG.net che abbiamo fatto un sacco di discussioni al riguardo usarlo o non usarlo.Allora, come per i database NoSQL, loro schema, l'hai scritto prima, alla fine è un tool.Per me, come sviluppatore, è importante che la mia capacità di sviluppare non sia limitata dai tool che uso.Detto questo, io che per lavoro conosco molto bene SQL, non userei mai un ORM, perché, come dire, mi aiuta in alcune parti di sicuro, ma mi limita molto in altre.Perché il tuo RM ti limita su quello che puoi fare in database in funzione del fatto di quanto l'ORM supporta le feature di un database.Ora, quindi, se tu hai bisogno di fare qualcosa che è molto specifico o conosci molto bene SQL e vuoi, come dire, usarlo al meglio, ma secondo me l'ORM non è il prodotto adatto.Preferisco quelli che si chiamano micro ORM.Io sono un assoluto supporter di Dapper, per esempio, per .NET, se conosci la cosa.Oppure di tool magari tipo Query Generator, non mi viene in mente adesso quello che usa il Node.Però diciamo...- C'era Nex, però non so se lo puoi supportare.adesso non mi viene in mente, l'ho usato recentemente per un progetto, mi viene in mente un altro, Kata SQL, che però ha perduto, ne è anche quello, quindi...ma l'idea è che io voglio poter avere la libertà di sfruttare la mia conoscenza del prodotto SQL Server, in questo caso al massimo.Ora, questo va bene per me, però, perché ho un certo tipo di esperienza, ho un certo tipo di approccio.L'ORM va benissimo anche, però, invece, per chi magari dice "ma io SQL non lo conosco, non sono così esperto, prima di far danni, preferisco avere un aiuto.So che questo aiuto è limitato, è un po' come il cambio manuale rispetto al cambio automatico.Il cambio automatico è più semplice, non devo pensare, faccio quello che fa, magari consumo un po' di più, non ho la performance ottimale, ma 80% dei casi va benissimo.Se devo andare a fare una gara, il cambio automatico non lo voglio neanche vedere in foto, perché ho bisogno di ogni singola possibilità di, come dire, esprimere la mia conoscenza della macchina o del prodotto per poter fare il meglio che posso.Quindi l'ORM se usato correttamente, secondo me va benissimo, a patto che sia una scusa anche per imparare database, non per far finta che non esista.Questo è diciamo il punto diciamo di svolta.Guarda sei stato bravissimo, l'hai detto in un modo così democristiano.No perché poi giustamente anche noi abbiamo i nostri ORM che è assolutamente uso.In realtà uno dei veri problemi dell'ORM e l'ho patito poi io da utilizzatore storico di ORM e che poi ti allontana talmente tanto dal sequel che quando hai necessità di fare Queri complesse.Io qualche tempo fa mi sono dovuto trovare e mi sono trovato a fare una query articolata bella e picciosa.A primo acchito così tolto il query builder tolto l'ORM dici ok respira.No no sono d'accordo con te ma infatti se viene usato come strumento per imparare o sapendo i limiti che ha, come tutte le cose va benissimo.Il mio messaggio è quello di non usarlo per nascondere database, perché se lo fai in quel modo in effetti fa più danni che altro onestamente, perché ho visto query veramente mostruose che poi non puoi più mettere a posto, nel senso che quando hai una query generata che sono tipo 200 linee di codice e lì c'è poco da fare, anzi ecco lì mi stupisco ogni volta, vado gli faccio complimenti perché dico se siete riusciti a fare un engine che riesce a prendere questa roba qua e comunque tirerà fuori dei dati in meno di un secondo, chapeau perché vuol dire che tutto il lavoro che avete fatto è veramente stellare perché capirla è impossibile.Però come tutte le cose son tool, l'importante per me è che la gente conosca quello che c'è dietro, il bravo sviluppatore deve conoscere quello che c'è dietro e poi può decidere di rinunciare e dire ho bisogno di fare una cosa veloce va benissimo non remma ma assolutamente chiaro che non sono riuscito a farti arrabbiare allora devo proprio parliamo di database moderni così almeno te arrabbia no no no ma non è che mi arrabbia che mi fa ridere queste queste trovate un po marketing a volte per cercare di dipingere il passato o meglio la tecnologia del passato come una roba superata.Prima di tutto la tecnologia evolve si conserva di oggi non è neanche lontanamente il sicuro stato che ho iniziato a usare io.Però fortuna, nel senso che il nostro lavoro è quello di mantenerlo aggiornato.Come dire che tu oggi "ah, basta, uscito dalla macchina elettrica non userò mai più una macchina col motore a scopio perché è vecchia, non è moderna".Tutto vero, tutto vero.Ancora ci sono certe cose che devono evolvere, devono migliorare.Ci sono alcune macchine elettriche che hanno quindi non è tutto bianco-nero.Poi magari fra qualche anno, sicuramente fra dieci anni, le cose saranno ancora diverse rispetto ad adesso.Mi aspetto sicuramente molta più flessibilità, molta più possibilità di parlare un database magari usando direttamente GraphQL, se quello prenderà il sopravvento come modello di querying di oggetti.Però il punto è questo, secondo me quello che lo sviluppatore deve fare deve essere critico e non semplicemente dire "ah, c'è questo nuovo prodotto moderno, allora sicuramente è migliore".L'informatica evolve.C# di oggi non è il C# quando è nato, vent'anni fa.E quindi cos'è? È meglio Go perché è più moderno? È la stessa cosa con i database.Hai parlato di Go e io potrei iniziare a fare la mia sfasa fine.No, quindi per me è quello.L'importante è rimanere critici.critici e non prendersi diciamo non pensare che l'ultima novità sia necessariamente migliore perché quando ci dicono che c'è qualcosa che risolve tutti i nostri problemi a me viene da ridere perché se fosse così sarebbe bello ma è come dire se ci fosse la magia poi in un momento schiocco e sono a Milano dai miei amici.Non è così.Vedo che ormai il tempo è andato ti rubo giusto altri due minuti per il nostro momento Paese dei Balocchi, il momento in cui i nostri ospiti, ma anche i nostri host, condividono qualcosa che ha catturato la loro attenzione, che possa essere un talk, un libro, una conferenza, un software, qualunque cosa ti va di condividere con la nostra community.Cosa ti viene in mente? E conducono il Paese dei Balocchi.Ah, il Paese dei Balocchi.Sicuramente quello slide deck di cui ti parlavo prima di Martin Fowler su implicit schema, quindi quello poi magari ti mando un link, ho visto che nella pagina li mettete, è molto interessante.Consiglierei agli sviluppatori, se mi permetti faccio un po' di self promotion, l'anno scorso abbiamo scritto un libro pensato proprio per i nuovi sviluppatori, perché è una Una cosa che ho notato, io ho iniziato nel '90, quindi ho seguito la crescita del database di SQL Server, mentre lui cresceva, crescevo anch'io.Ma se adesso fossi un nuovo sviluppatore, sarei veramente un po' frustrato a vedere quanta roba c'è da imparare.Cioè, da dove parto? Mitzga, apro Visual Studio, apro Management Studio, ci sono 896.000 opzioni, non ho neanche capito cosa mi stanno chiedendo, mai ce la farò imparare a usarlo bene.Ora, invece abbiamo cercato di scrivere qualcosa che potesse essere proprio un punto di partenza.Quindi, quello è un'altra cosa che suggerisco, non perché l'ho scritto io, ma perché è il libro che io avrei voluto avere, e quindi alla fine ci siamo scritti.E poi, ultimamente, invece, di cose particolari nel mondo dell'informatica, ma in questo mi trovo impreparato, mi pensavo un po', perché ultimamente sono stato un po' focused su quello su cui stiamo lavorando, quindi ho avuto un attimo di distacco dalla realtà.Ma che altro mi viene in mente di bello? GraphQL sicuramente è una parte...adesso guarda, sto lavorando molto su quello, quindi quello me lo sto studiando molto bene, invito le persone a darci un'occhiata, perché è molto interessante come approccio.e poi...fuori...no, non mi viene in mente nient'altro, nel mondo informatico, fuori dal mondo informatico, moto, heavy metal, qualsiasi cosa di quel genere.Allora, spero un gruppo, il nostro buon Alessio.Ultimamente mi sto ascoltando molto volentieri Avantasia, se conoscete, è fantastico.Quindi gli ultimi due album, praticamente, non sono nuovissimi, però però tra che mi sono spostato, ce l'avevo lasciato un po' da parte, adesso me li sto scavando.Il Moonglow è fantastico, secondo me è l'enciclopedia del power metal, se piace il genere.E poi, invece, viaggi in moto, vabbè, sto solo sognando i viaggi che voglio fare quando i bimbi saranno al college, quindi ritornare in Norvegia, ritornare in Scozia, quelli sono degli ultimi viaggi che ho fatto prima di avere i bimbi, e sono cose che, se potete, la Scozia secondo me è il paese io lì ci andrò a vivere domani fantastico bellissimo, Dio quanto ti capisco, come hai detto bimbi e viaggi stop no, fai altri viaggi ecco però diciamo che l'altro giorno stavo rimettendo a posto un po' di foto e libri e quindi mi sono capitate le foto quando siamo fatti il giro in Scozia Eh, terra stupenda.Ti dico solo, ti dico solo che proprio oggi parlavo con mia moglie dell'ultimo giro che abbiamo fatto sul deserto in fuoristrada.Urca! Ah, eh.Lì non sono mai stato il deserto.Dev'essere un'esperienza notevole anche quella.Che mondo ragazzi, che mondo.Anch'io avevo un balocco ma me l'hai soffiato perché volevo portarlo io il tuo libro.Ah osti, vabbè, meglio, doppia pubblicità.Però ne ho un altro che è appunto Superbase, l'ho citato e se avete necessità di scrivere un'applicazione veramente solo front end, il crudino della chiesa come lo chiama Carmine, cioè una roba super semplice che ha bisogno di una semplice interfaccia e un'API REST che faccia il resto può essere la soluzione giusta.Buttateci un occhio perché è molto molto interessante anche perché ed è una cosa che volevo dire a Davide diciamo che i database stanno riprendendo piede a livello proprio della comunicazione collettiva in modo importante.Sì guardando su PubBase vedevo che fondamentalmente è tutto postgres cioè tutte le cose complesse le fa lui.La stessa cosa rinizio a sentir parlare in modo importante sia di Postgres che di SQL Server.Quindi cosa sta succedendo? Sì.Beh, io credo...La tua esperienza l'hai detta prima bene.La gente si è innamorata dei microservices e, ripeto, secondo me hanno il loro scopo, la loro, diciamo, posto nel mondo.Ma quando poi scopri che devi riconciliare le cose e spendi il 99% del tuo tempo lì, non è tanto divertente.E quindi magari dei micro...dove si può fare una sede microservices che comunicano con un solo database, potrebbe essere un'architettura magari vincente, perché unisce in medio due mondi, ci sono delle rinunce da fare, però per come la vedo io, per ora, è la migliore che ho visto, nel senso che è quella che dà un po' più di equilibrio e poche rinunce tutto sommato a quello che vuoi fare.Chiaro, chiarissimo, naturalmente con un contratto con diviso rigido, naturalmente, perché si è continuato a scrivere su database.Però questo si può fare adesso nel cloud, perché i database finalmente possono fare scale out anche lì, Cioè, capisco che una roba del genere on-premise potrebbe essere molto più difficile, ma sul cloud, ad esempio adesso con HyperScape, possiamo scalare fino a 30 nodi e quindi abbiamo tipo 2480 core per solo servire ai dati.Mi sembrano abbastanza sufficienti per qualsiasi architettura microservice che vuoi fare.Anche per il crudino della chiesa.Quello, diciamo, magari non so se riesci a usarli ancora tutti, però sì.*risate* *musica* è il momento di ringraziare chi sostiene in modo attivo il nostro podcast perché il nostro podcast è gratis però in realtà non vuol dire che sia appunto senza costi è la community che lo sostiene con delle donazioni, invitandoci una birra e permettendoci così di andare avanti e questa settimana abbiamo due donazioni, due birre la prima è da qualcuno, la cui email è nessuno, quindi è difficile individuarlo un donatore anonimo che quattro giorni fa ci ha invitato una birra Abbiamo poi anche Alberto Perra che ci invita tre birre scrivendo "Spero che il buon proposito di restare in un'ora e mezza puntata sia sempre contravvinuto" La seconda parte del messaggio non la leggo come Alberto ci chiede ma un messaggio del tutto privato ad Alberto e sì se lo permette detto questo io ringrazio infinitamente nessuno e Alberto grazie per aver sostenuto il nostro podcast la nostra community e il nostro progetto allora che facciamo alziamo in alto i calici e brindiamo [Musica] Davide io ti ringrazio è stato super super piacevole questa chiacchierata molto piacevole assolutamente.Come dico sempre a tutti i nostri ospiti da oggi Gitbar è un po' anche casa tua quindi quando ti va di bere una birra con noi o raccontarci qualunque novità insomma stiate lavorando su e possiate raccontarla vienici a trovare.Sì spero di avere gli usa breve quindi magari fra sei mesi ti pingo.Noi siamo qua un saluttone alla prossima grazie mille ciao ciao ciao GIT BAR il circolo dei full stack 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 full stack dev [Musica] [Risate] No.
