 Mi è presentato, io lavoro da 5 anni per MariaDB. Quanti di voi conoscono MariaDB? Bravi! Bella! No, lo dico con sincero stupore, perché in Italia si sta facendo un po' fatica a far conoscere MariaDB. Non ci stiamo impegnando molto, devo dire la verità, sono un po' da sola a fare questa cosa, perché il nostro mercato, la nostra diffusione è un po' più onegli Stati Uniti o nel Nord Europa, in Francia e in Germania, in Italia c'è un pochino più di fatica a far passare questa nuova evoluzione di quello che è stato il mondo MassSQL. Io oggi voglio parlarvi di alcune cose di MariaDB, per chi lo conosce, perché lo non lo conosce ancora meno, non lo conosce ancora abbastanza, per spiegarvi anche come il database in realtà influenza le prestazioni dei vostro lavoro. Voi fate delle bellissime cose a livello di frontenda, a livello di applicazione, a livello di PHP, usate Warp, etc. Poi queste cose vanno a toccare dei dati nel database e vi aspettate che vi torni qualcosa. Ecco, questo tragitto può essere costoso e certe volte avere una macchina, un'astronave, come diceva il collega prima, può fare la differenza, cioè la velocità in cui il database elabora le vostre query si riflette immediatamente sulle prestazioni del vostro sito. Voi magari voi spaccate la testa per ore a capire per come ottimizzare il vostro codice in modo che i risultati siano più brillanti e magari il problema è da un'altra parte. C'è sempre un po' di problemi del codice, ma certe volte effettivamente può essere aiutata la prestazione dell'applicazione anche dalle prestazioni del database, su cui alla fine le vostre query vanno a impattare. Io vi faccio un po' di piccola introduzione su l'open source. MariaDB, voi conoscete MySQL, immagino perché MySQL è dietro alle vostre applicazioni, i vostri e i vostri soluzioni. C'è qualcuno di voi che usa già MariaDB come database di riferimento? Bene. MySQL nasce vent'anni fa, ha compiuto vent'anni la scorsa primavera. Nasce ovviamente come soliti progetti da garage, di quelli che si mettono a fare code eccetera, in particolare in Finlandia, da due amici, compagni di università che si chiamano Montevideo News e David Axmark, che iniziano a sviluppare questo database. Quindi nel 1995 il vero proprio inizio di utilizzo e anche la nascita della società di MySQL dietro questo database e nel 2001, quando effettivamente c'è la MySQL Corporation viene fondata, anzi, quella B, e viene fondata e poi segua la sua storia. La fortuna di MySQL è stata proprio quella di sviluppatori come voi, cioè è nata in quello che si chiama lampstack che probabilmente tutti conoscete, perché scaricando la distribuzione Linux lo stack ci si trovava a MySQL come database open source di riferimento, quindi Linux, Apache, MySQL, PHP. MySQL è quindi stata la fortuna di tutti gli sviluppatori web perché ha consentito di far partire migliaia, se non centinaia di migliaia di startup a bassissimo costo, a bassissimo impatto. Ha potuto mettere in pratica delle idee senza aver per forza uccidersi di investimenti su un'idea che poteva avere una fortuna piuttosto che un'altra. La crescita è stata pazzesca, ci sono centinaia di milioni di installazioni di MySQL nel mondo, stimate. Nel senso che il conto si barra dai numeri dei download che arrivano dai vari mirror, ma poi i mirror sono talmente espansi nel mondo che non è impossibile perdere il conto e poi ci sono quelli che passano e infine, comunque si vano a centinaia di milioni di installazioni. Tutto questo è andato avanti fino al 2008. Nel 2008 MySQL è stata acquisita da Sun Corporation ed è stato un bellissimo matrimonio soprattutto per i due fondatori perché hanno portato a casa un bel revenu del loro investimento in tutti questi anni di lavoro, ma la cosa è stata seguita da un altro evento nel 2009, quindi meno di un anno dopo, con l'acquisizione di Sun da parte di ora, probabilmente molti di voi sono a conoscenza, l'acquisizione da parte di ora con di Sun ha avuto un impatto un po' meno neutro sulla vita di MySQL perché era un competitor grosso che acquistava un competitor open source veramente. Tenete conto che MySQL ha sempre avuto la filosofia dell'open source vera, cioè non c'erano feature solo enterprise, c'erano dei tool solo enterprise, quindi c'erano degli strumenti di amministrazione, di monitoraggio, di backup, eccetera che erano solo enterprise, erano closed source, venivano date solo i clienti enterprise, ma le database di per sé community o enterprise che fosse erano i binari negli stessi, quindi di fatto tantissima gente va in produzione i binari community e aveva un contratto enterprise con Oracle, quindi è sempre stata questa cosa. Nel tempo è un po' cambiata. L'acquisizione di Oracle ovviamente ha dato un impatto invece diverso perché essendo un competitor si è stato per un po' di tempo delle grosse perplessità se cosa avrebbe potuto fare Oracle due database decisamente. Non dico concorrenziale perché gli ambiti di applicazione erano molto diverse, Oracle ha un suo mercato, però comunque era un impatto molto grande. Sicuramente il mercato di MySQL poteva fare molto gola Oracle entrando con la sua soluzione e rimpiazzando quelle di MySQL. Quindi l'acquisizione soprattutto in Europa è stata passata per molto tempo attraverso l'antitrust che ha imposto da Oracle per 5 anni di mantenere progetti, sviluppo, riunione con le community, quindi mantenere tutto quello che era il commitment di MySQL e questo è stato fatto da Oracle, ovviamente nelle misure e nei modi che l'ho tenuto giuste però si è attenuto a queste cose e questo è stato un bene perché MySQL ha continuato a crescere, ha continuato a essere sviluppato. Però cosa è successo nel 2009? Che Montevideo News non riuscendo ad avere con Oracle un rapporto di trasparenza su quella che era la roadmap di MySQL, che è sempre stata pubblica, essendo open source. Lui aveva in mente le sue idee, il progetto era suo, era nato con lui, c'aveva 50, 60 sviluppatori sotto di sé che lavoravano con lui sulla sua roadmap che arrivava dalla community, dalle richieste, eccetera. Non davendo a che fare con Oracle ovviamente questa cosa è cambiata completamente nei tempi, nei modi e in tutto quello che era diverso da come si era sempre fatto per cui lui ha deciso di uscire, quindi è uscito dall'azienda, da Oracle si è portato dietro che era una quarantina più o meno di softwareisti, tutti quelli del core di MySQL, più il team di ottimizzazione e ha fondato una società che nel 2009 si chiamava un po' narcisisticamente Montiprogram, un po' solo. Un po' narcisisticamente perché tutto il progetto è narcisista, poi tanto non mi senti, perché MySQL, che a me piaceva tanto con questo nome mai che sapeva questa cosa in mio, piccola cosa, in realtà è MySQL dove è My, il nome della prima figlia di Monti e indovinate un po' come si chiama la seconda? Quindi noi stiamo seguendo praticamente un progetto a gestione famigliare, diciamo, warrwime ma molto famigliare e quindi la cosa è andata avanti in questo modo, per il bene nel senso che il concetto è stato, io voglio garantire alla community e al mondo che questo progetto rimarrà sempre open source, qualunque cosa decida nel futuro di fare ora con il bene e nel male, ma io voglio praticamente prendere questo codice e tenerlo comunque all'inizio di un branch, adesso poi come vedremo in un fork, in modo che rimanga proprietà della community. Quindi se un giorno qualunque proprietario di MySQL dovesse essere venduto, cambiato, cambiato, dovesse chiudere questo progetto o chiudere il codice, ci sarà sempre una parte open presente per tutti e questo è stato il primo principio. Monti, di solito quando lavora, ovviamente, lavora con noi e il nostro sitio, al momento, lui gira sempre con questa maglietta con scritto il mio software e fa girare il tuo business, che è vero, cioè la maggior parte della gente che in questo mercato sta facendo business sul suo lavoro, quindi per il bene e per il concetto generale dell'open source. Perché ho iniziato questa piccola conversazione su un po' di storia e su un po' che adesso vi racconto ancora, perché l'open source è un valore fondamentale per la nostra società. Questo vuol dire che non viviamo soltanto di filosofia, quindi un po' di business ci deve essere dietro a questa cosa, ma il modo con cui viene fatto è quello storico, cioè noi abbiamo continuato lo stesso modello di business che va MySQL nel 2001, quindi stiamo cercando di mantenere, finché si potrà e poi, ovviamente, il mondo sta cambiando anche su altre cose. Quello che è giusto è che la community, come state facendo voi con Wordpress, quindi voi avete ben chiaro quello il concetto, prenda idea. Noi riceviamo tanto dalla community, ma restituiamo anche molto. Noi abbiamo clienti anche molto grandi, voglio citarevi booking.com, voglio citaremi Financial Times, voglio citarevi queste aziende che non sono proprio delle cosettine che ci commissionano degli sviluppi. Noi abbiamo fatto delle feature che sono specifiche per loro, ma non sono mai specifiche per un cliente. Sono feature che ci vengono stimolate da un'esigenza di un cliente che noi riconosciamo di essere di utilizzo generale, che coprono un'esigenza che può essere decisamente più ampia del singolo cliente, la sviluppiamo finanziata da un cliente, ma la restituiamo alla community. Quindi la prima volta che il package con la nuova modifica viene rilasciato e rilasciato subito e tutti ne possono godere. Quindi questo è un prendere, un dare generoso e, diciamo, simmetrico. Quindi si dà quanto si prende. E questo è il valore che se vogliamo cercare di continuare a fare. Che nel futuro ci siano delle feature che sono veramente molto enterprise, che quindi servono soltanto magari a booking.com che fa un deployment di 500 server in 30 secondi perché ha bisogno di fare e di gestire un picco di utilizzo. Quindi è una cosa che riguarda la maggior parte degli utenti. Sicuramente credo nessuno di voi. E quindi su queste cose uno può pensare di targettare delle cose veramente molto enterprise, ma non toccheranno mai l'utilizzo della stragrande maggioranza dei clienti. Voi ne siete partecipe con sapevoli? L'open source praticamente domina tutto il mercato del web nelle varie declinazioni, nelle varie possibili sfumature. L'importante è questa piccola clause. Deve essere usato, modificato e redistribuito in ottemperanza quello che sono gli accordi di licenza, che sono licenze dell'open source. Quindi MariaDB è rilasciato sotto licenza GPL e quello deve essere quello che in qualche modo domina. Il nuovo mandato, il nuovo mandato di MariaDB è riprendere in pratica il ruolo di open source che è il modo del database. Vetto proprio banale e banale è rimpiazzare i MySQL. Questo è palese. Ovviamente il valore dei MySQL è altissimo e nessuno distingue per merito uno l'altro. Sono scelte. La nostra scelta è prevalente sulle feature e sulle seri open. Qual è la sfida ultima dell'open source che vedrete essere affrontata da MySQL e anche da MariaDB? Adesso se ne è parlato sempre di sicurezza, quest'anno sembra l'argomento dell'anno. Sono già stata almeno a 3 o 4 eventi di sicurezza nel mondo IT dove sembra veramente il piatto del giorno, si parla solo di questo. Si è MySQL, quindi ora così a noi abbiamo investito molto sulla sicurezza nell'ultimo anno. È stata la parte più grossa dello sviluppo. Ora ho portato una sola soluzione che è solo Enterprise, quindi solo per i clienti Enterprise. Noi abbiamo portato una nostra soluzione che nasce dalla community, nasce da una collaborazione con Google ed è quindi open source e quindi a disponibilità di chiunque. E questo è di nuovo un altro delle piccole cose che noi continuiamo a voler fare per la community. Queste Monti. Monti è il nostro, appunto, CTO, è quello che ha scritto MySQL, è quello che ha scritto e sta gestendo il progetto di MariaDB dal punto di vista della codifica e questo è il suo statement, è stata creata proprio per mantenere l'apertura in modo che riusciamo anche a mantenere un passo diverso. Cioè il tempo di inerzia che abbiamo noi nello sviluppo delle nuove feature essendo un'azienda piccola, relativamente piccole, siamo 100 persone distribuite su 14 paesi nel mondo con una trentina, 35 sviluppatori su due principali progetti, ci rende abbastanza agili. E anche questo continuo contatto con la community ci ti consente di portare dentro dei contributi che arrivano dagli operatori della community che facciamo a nostre abbastanza in fretta e questo consente dei rilasci più rapidi e con delle aggiunti edifici sempre rapide. Velocemente, l'ho già detto e MariaDB quindi è un dropping replacement. Perché? Perché è nato dallo stesso cor, quindi praticamente è partito dalla versione 5 di MySQL e da lì si è mantenuto un progetto di branching, quindi sempre prendendo il codice sorgente di MySQL si sono mantenute e le aggiunte le nuove feature che sono state sviluppate da noi in collaborazione con la community. Chi è proprietario del codice? Non è la MariaDB Corporation che se volete ha una connotazione un po' mista tra il commerciale e il puramente open, nel senso che poi noi softwareisti li dobbiamo pagare. Cioè, adesso proprio essere vero, la community ci aiuta tanto, ma qualcuno che coordina tutti le distribution che poi c'è in modo che tutto sia coerente che i contributi che arrivano dalla community siano coerenti con i progetti che ci sono in piedi con altri contributi, siamo noi, sviluppiamo le nostre cose, ma decidiamo che cosa è più adatto ad essere messo in produzione proprio perché è fatto bene nei termini del fatto bene del codice. Quindi la MariaDB Foundation è il vero proprietario del codice, quindi della proprietà intellettuale per lo meno della parte che è stata aggiunta, perché è una parte della proprietà intellettuale comunque Oracle. MariaDB Corporation è quella che in qualche modo contribuisci a finanziare la foundation per gli sviluppi. Quindi c'è questo mutuo, la foundation è fatta di poche persone, sono poche sviluppatori, la maggior parte ce l'ha la Corporation, però loro detengono proprio un po' i custodi, le vestali del codice e noi proprietà abbiamo queste. Il grosso nostro successo è stato in questi ultimi anni essere stati presi come adesso a database di riferimento per le principali distribuzioni open source. Quindi Red Hat, Debian, Suze e Ubuntu anche ormai hanno sostituito ma essi è quelle con MariaDB nel lamstack. Quindi se adesso voi da queste distribuzioni Linux scaricate il lamstack non trovate più mai SQL come database ma trovate MariaDB. E questo supporto delle principali distribuzioni Linux nel mondo, nei nostri confronti è stato sicuramente un grande successo per noi perché hanno riconosciuto il valore di cui io ho parlato fin'ora. Quindi di fatto adesso MariaDB è la nuova M del lamstack. C'è andato bene che non abbia cambiato nome con il mio serio mass di coerente. Come siamo adesso? Abbiamo circa noi come MariaDB quindi fra Foundation e Corporation ci sono riconosciuti 9 milioni di utenti basati sempre sui download e quella che sparsi più o meno in tutto il mondo. Questa è sempre una stima. Le stime e anche i download sono sempre un po' particolari perché noi per esempio non stimiamo i download dei lamstack. Non abbiamo i conti delle distribuzioni Linux, di quanti distribuzioni Linux vengono scaricate. Quindi è sicuramente una stima estremamente per difetto. Vi basti pensare che per esempio il nostro conto dei download arrivano dalla nostra guita. Per la stragrande maggioranza sono download versioni Windows che rappresentano credo meno del 5% dell'installazione di MariaDB nel mondo. Quindi è un po' falsato questo conto. Noi abbiamo un conto proprio di una parte. Tutto il resto arriva quasi tutto dalle distribuzioni o dai mirror. Ma in sequel ha avuto per anni un po' questa reputazione di essere una robetta. E me lo ricordo anche io quando ho iniziato a usarlo parecchi anni fa. Rispetto ai grandi database sembravano veramente una robetta molto mai, cioè proprio una roba da usare. All'inizio forse poteva anche esserlo, mancavano delle feature in confronto ai database più belasonati sicuramente delle cose non c'erano e sono state aggiunte nel tempo. Ma in sequel è dietro a questi nomi che vedete che in particolare in questo momento sono i nostri clienti più grossi, sono i nostri market più grandi. Ma tutti questi stanno facendo girare il loro business con Maria de Bio, mais e quelle alle spalle. Non ho più adesso fatto un controllo recente, ma fino a un sei mesi fa dei primi venti nomi dei city web del mondo 18 usavano mais e quelle. Quindi tra Google, Alibaba, Flickr, eccetera, tutti avevano dietro a mais e quelle. Wikipedia, Wikipedia, Maria de Bio, quasi tutti sono basate su questo. Qua è una slide che vi spiega quale è stata anche la crescita e perché continua crescendo da una parte. Ci sono le distribuzioni che hanno scelto Maria de Bio come database di fermento e dall'altra parte anche gli operatori di cloud che hanno aggiunto Maria de Bio ai database di fermenti. Qualcuno l'ha sostituito, qualcuno l'ha aggiunto come giusto. Cosa fa la corporation? Questo lo dico velocemente. Sempre perché appunto i softwareisti non sono sempre tutti volontari o per lo meno sempre solo di volontariato non si mangia sempre. Quindi noi paghiamo lo stipendio gli sviluppatori di Maria de Bio e lo paghiamo fornendo servizi. Quindi la proprietà intellettuale rimane così e noi forniamo servizi a chi li richiede. Quindi non impegniamo costi di licenza, non impegniamo nessun tipo di cosa, però noi abbiamo servizi di supporto, di assistenza, un portale per i clienti, forciamo servizi di database amministretto remoto, consulenza, training, facciamo delle sviluppi customizzati come abbiamo accennato prima e questo ci consente di mantenere il rilanziamento dell'azienda. Come vi ho detto tutto open source, tutto quello che rilasciato il sottolicenza GPL o l'SGPL come i connettori, il database dei bacchi è pubblico che sembra una cosina poco significativa. Invece lo è molto. Questo è stato forse il primo effetto negativo dell'accusizione di MySQL da Oracle che hanno chiuso il database dei bacchi. Quindi era difficile capire che cosa era o cosa non era, un comportamento che non risultava particolarmente limpido. Invece il nostro database dei bacchi è purtroppo aperto e quindi i bacchi che ci sono li potete vedere tutti. Cosa abbiamo fatto quando MariaDB è nata? Perché di tutto questo è tutta una bella storia però poi dice quel è stato il vero lavoro che ha portato a essere MariaDB diversa da MySQL? Innanzitutto il primo lavoro che ha fatto Monti è riscrivere all'ottimizzatore. Proprio livello di prestazione come ho accennato l'inizio certe query quando spesso non sto parlando di WordPress in particolare ma quando arrivano da framework io ricordo lavorato con Django per un po' venivano delle query alte così perché le costruiva ovviamente con dei modelli a qualche anno fa adesso probabilmente è migliorato però io avevo 740 join e il database incominciava a strozzarsi perché ovviamente quando deve saltare da una parte all'altra incominci a fare un sacco di lavoro temporaneo per accumulare i dati temporanei per poi rilavorare eccetera e questa cosa uccide la CPU del database scrive un sacco sul disco e quindi il risultato certe volte magari non c'è nemmeno cioè quindi a un certo punto arriva che non risponde. Quindi prima cosa che ha fatto è stato riscrivere all'ottimizzatore e questo è un punto che già potrebbe dare un vantaggio agli utilizzatori di MySQL come voi che sostituiscono semplicemente MariaDB e MySQL perché l'ottimizzatore è decisamente molto più ottimizzato e quindi le query soprattutto le xf query che certe volte non si materializzavano quindi di fatto finivano per non restituire nulla adesso nella stragrande maggioranza dei casi funzionano e quindi vuol dire certe possono anche non continuare a non funzionare come non funzionavano prima soprattutto se sono stati query molto complesse ma in tal caso mi rallaccio al discorso del collega prima riguardate la query forse si può scrivere meglio o forse si può farle in due colpi e arrivare ad avere un risultato invece di aspettare che il database soffra per non magari portare risultati. Ci sono poi tutta una serie di caratteristiche che nella versione di MySQL sono una versione enterprise che per noi sono invece open source che invece di nuovo possono toccare gli sviluppatori di WordPress per aggiungere prestazioni. L'altra differenza più grossa è che MySQL ha continuato a mantenere a supporto due storage engine non so se avete confidenza col concetto di storage engine ma MySQL di per sé proprio come core del database c'ha tre cosette c'è un parser del linguaggio SQL c'è un ottimizzatore per le query quindi quello che fa poi il query plan e poi ha quello che si chiama il vero proprio engine anche più di uno gli engine sono dove fisicamente vengono contenuti i dati quindi dove voi diciamo il motore che crea le tabelle dove vengono contenuti le tabelle e sono dei plugin la struttura è plugin questo è un grande vantaggio per me se quello perché consente di avere una scalabilità nel senso che se mi capitano delle funzioni particolari che un engine non funziona posso sempre sviluppare un engine specifico che possa farlo ora con l'ha deciso di focalizzarsi sui due principali uno è MyIsam che è figlio del vecchio metodo Isam della costruzione dei file indexati e l'altro è InnoDB che è un fantastico storage engine open source rimasto open source noi abbiamo accresciuto le funzionalità di InnoDB in collaborazione anche con Percona che è un altro branch di MySQL e abbiamo aggiunto delle cose ma noi supportiamo molti storage engine tanti sono veramente specifici e su questi ce ne può in particolare uno che potrebbe essere magari di vantaggio per voi e altre funzionalità oltre all'ottimizzazione sono anche i livelli di replicazione diversa e questo è un argomento che poi vorrei toccare un po' a parte perché la replicazione è un discorso che è spesso nelle soluzioni tipo le vostre non è molto toccata invece secondo me dovrebbe essere di più ci sono delle funzionalità io queste slide sono un po' verbose ho scritto molto non voglio leggerle una io le pubblicherò le metterò sul slide share quindi le avrete utilizzatele un po' come riferimento poi io sono disponibile se avete bisogno di chiarimenti però ho voluto darvi un po' un elenco di tutte le funzionalità anche un po' in dettaglio in modo che possiate farvi avere un piccolo reference da seguire una cosa che può interessarvi è la gestione dei dati di GIS di localizzazione che sono gestiti da MariaDB da 2 o 3 versioni fa e questa è una cosa che è stata estremamente gradita dagli sviluppatori Parliamo un pochino degli story engine extra DB è il transazionale e è l'ostero engine di default per MariaDB e appunto ci sono state fatte delle aggiunte alla versione alla versione di origine che è in noDB e soprattutto delle ottimizzazioni anche di percorso e quindi la transazionalità di l'ostero engine e lui che si occupa di capire se la transazione è stata completata bene e nel caso faccia rollback se tutto non è andato a posto viene gestita in modo leggermente più veloce e ottimizzato un altro storese ecco su MyAsa una piccola nota MyAsa è stato per tanti anni il database di riferimento per cui se voi avete dei database che hanno qualche anno quindi da 5 o 6 anni da questa parte credo che sia stato messo di default in noDB da un paio d'anni controllate perché MyAsa è un storese engine molto efficace ma è fragile e soprattutto non è transazionale cioè rompere gli indici o rompere la tabella non è così remoto e questo potrebbe non essere proprio un comportamento gradevole per voi quindi se avete delle tabelle MyAsa cercate di portare su in noDB è una semplice alteratable basta cambiare il tipo di engine che è menzionato nella createable e questo vi dà più sicurezza sul fatto che tutte le transazioni siano coerenti siano scritte effettivamente sul disco se sono andate buon fine non avere mai cose parziali Sphinx una parola su Sphinx forse voi conoscete Sphinx, Lucine questi gestori di contenuti quindi poter fare full texture su dei testi noi abbiamo un storage supportiamo un storage engine che è derivato proprio dalla community che è uno Sphinx storage engine e quindi se voi avete delle necessità di fare dei full texture su dei testi noi usiamo l'engine di Sphinx direttamente quindi le ricerche sono decisamente più ottimizzate fino ad ora l'unico modo per fare full texture c'era avere delle tabelle MyAsa ecco perché vi sto dicendo probabilmente molti di voi avete ancora MyAsa e adesso in noDB supporta full texture c'è anche lui però il motore di ricerca che ha Sphinx per sé è decisamente più efficiente TocoDB e Connect sono degli storage engine che forse voi interessano direttamente sono specifici per l'utilizzo di quando ci sono delle scritture massive e Connect è uno storage engine che consente di accedere dei database esterni di qualunque formato possono essere anche i falsi CSV file di Excel ecc. Il thread pooling questo è un'afficio che è MySQL e solo enterprise quindi non trovate una versione community che è scaricate e questo è una cosa da cui potreste probabilmente trarre vantaggio soprattutto se sviluppate in PHP il thread pooling consente di avere molte thread attive allo stesso tempo senza che il database patisca in prestazioni perché viene praticamente tenuto un pool di thread aperte e quindi le connessioni che arrivano dall'applicazione non vengono mai chiuse quindi tutto il tempo di apertura e chiusura viene mantenuto viene scartato quindi viene tolto viene eliminato dal processo e questo aumenta sicuramente le prestazioni tutte le open and closed connessioni che vengono sul database vengono in questo punto annullate ci sono dei riferimenti su questo sappiate che c'è e è semplicemente un'abilitazione che si fa da configuration file da MariaDB basta dire abilità di abilità il connection pooling e questo viene immediatamente gestito da MariaDB quindi se avete transazioni molte molto brevi che avete parecche connessioni tutto questo va insistere sulla CPU e sull'acceso e accesso questo sicuramente viene riflesso negativamente sull'applicazione il thread pooling può aiutarvi SAP Query se ne ho già parlato la SAP Query cresce tutto il discorso di query inestate query con molte join che agiscono pesantemente sulle prestazioni sono state decisamente migliorate dalla riscrittura dell'ottimizzatore di MariaDB Group Commit questo è diciamo di nuovo una parte leggermente tecnica la Commit verrà proprio in sincronizzazione quello che è stato fatto sull'avevo transazione effettivamente sul database le transazioni che sono eseguite in parallelo su diciamo sul nodo possono essere scritte tutte quanti in parallelo quindi non si fanno sequenze di Fsync ma ne viene fatta una sola che butta tutto quanto insieme questo è di nuovo una riduzione di tempi di apertura e scrittura sul disco che sono poi quelle che uccidono veramente tutte le volte che si tocca il disco è un massacro quindi meno lo si tocca è meglio è ovviamente i database più veloci che ci sono in questo momento sono comunque database in memory quindi la velocità della memoria ancora non è stata raggiunta dalla velocità del disco per ovvi motivi quindi tutto quello che riusciamo a fare che ottimizza la scrittura sul disco è un vantaggio per noi Colone Dinamiche è una nuova feature anche di MariaDB potrebbe essere il grosso vantaggio per voi perché è una cosa che per esempio viene usata tanto da coloro che fanno i commerce perché si può definire una colonna che abbia dei contenuti variabili quindi non è fissata ci sono possono esserci delle parti JSON possono esserci dei blog possono esserci delle sequenze di caratteristiche per magari per un modello di articolo, coloro, taglio e quello che è e può essere tutto ammucchiato in un'unica colonna con contenuti misti L'Online Alter Table questa magari è un po' di nuove una cosa che magari voi non fate a cambiare una tabella senza stoppare il database era una cosa impossibile prima bisogna fermare il database e fare la modifica oppure si poteva fare ma richiedeva tempi biblici per questo con qualcun accorgimenti adesso è possibile farla questa è una feature che ad esempio è stata sviluppata proprio per Booking.com che ne va bisogno la finanziata e adesso è stata restituita e non solo è possibile fare questa modifica della tabella online ma io ho anche un trattandamento la restituzione dello stato di questa modifica online in modo da sapere a che punto sono e l'applicazione potrebbe ovviamente averne bisogno prima di fare alcune azioni proprio sulla modifica in atto Gis, vi ho detto adesso si appa l'applicazione di Gis di Maria de Bissie appoggia su Open Gis io ho lasciato qua un po' di riferimento in modo da poter venderezzare lì la replicazione chi di voi usa sistemi replicati sui vostri database? pochi quindi voi vi basate sui backup immagino per tutto quello che riguarda la vostra integrità e la salvataggio di questa cosa quanto tempo ci mettete a fare un restore? chi lo sa? quanti di voi hanno tutto fare un restore di database? fate delle prove di restore ve lo consiglio proprio da amica tutti sono bravissime di capare io per prima quando hai da fare un restore prima scusate, ma sei veramente con le ginocchia che tremano e quindi rischi di far pasticcio solo per componenti motivi perché di solito c'è un casino in atto e quindi grave e poi non l'hai mai provato dovrebbe essere una pratica che si prova tutte le settimane cioè provare a fare il restore anche su una macchina virtuale non ha la importanza la buttate via ma fatelo perché quando succede il casino succede e dovrebbe essere una cosa su cui siamo tutti allenati la replica è una cosa che ci consente di avere invece un paracadute cioè avere un server replicato anche virtuale ripeto non avete bisogno di avere una macchina fisica ma avere una macchina virtuale che si prende le replica del vostro server e mantiene i dati replicati in tempo reale o quasi a meno della latenza tra i due sono relative vi darebbe una manovra in più vi basta switchare l'applicazione che replica se il master cade e poi vi preoccupate di mettere a posto il master ma intanto l'applicazione sui servizi in piedi e la gente lavora consideratelo come un consiglio della mamma noi abbiamo diversi diversi sistemi di replicazione quindi sono livelli un po' più avanzati per quello che ci vado velocemente vi lascio come differenza guardatevi che consentono di avere appunto modi diversi di replicare booking.com quando ha bisogno di gestire un picco da un master istanzi a 500 repliche in meno di 5 minuti 500 server virtuale ovviamente non puoi mettere su 500 macchine fisiche però lavorano sulla replicazione cioè garantiscono il servizio agli utenti che voi potete pensare quanti sono in un attimo veramente in un attimo e l'abbiamo fatto insieme Multistore Replication una cosa interessante posso avere tanti server con contenuti diversi ma per motivi miei vuoi aver bisogno di consolidare da una parte tutto quanto e non unico database in uno del server Maria Di Bilo consente da tutti i server posso dire replica e un po' inverso del master slave molti master independenti che si scaricano su un unico server e io ci posso lavorare per avere o un unico backup di tutti i miei lavori in giro per il mondo che potrebbe essere anche una soluzione o anche avere una macchina su cui usi i dati per fare dell'analisi e questo serve clustering soluzione di clustering ad alta affidabilità sistemi che qualunque cosa succede sui server che hanno il failover gestito in maniera automatica Maria Di Bilo si apposa su Galera che è un progetto open source di nuovo qua ci sono un po' di punti ve le guardate un ultimo appunto sulle cose di sicurezza come vi ho detto noi abbiamo lavorato tanto con quest'ultimo anno con la community con Google in particolare per mettere operazione di sicurezza anche sui database che riguardano i tre livelli dal firewalling all'authentication quindi alla gestione dei dati cryptati non solo dal punto di vista applicativo ma di l'intero database e non solo di quello ma anche di tutti dei file che si chiamano i data etrest cioè quelli che stanno fisicamente sul disco come i log come i binary log come i relay log degli slave che contengono molte informazioni sensibili del vostro database nel nome delle tabelle nel nome dei dati quindi anche quelli vanno cryptati tutta questa cosa è stata messa in piede da noi ed è open source vi lascio qua un po' di riferimenti qua ci sono tutti i link delle cose che ho parlato io se avete bisogno sono sono reperibile per chi è qua in zona stiamo discutendo con i ragazzi di di Warpress di cominciare spesso insomma tutte le volte che avranno piacere voglia di ospitarmi di fare delle piccole chiacchierati anche sui database nell'ambito dei meetup di Warpress che ci saranno qua e vi ringrazio abbiamo spazio per 5 minuti di domande quindi se qualcuno qualche dubbio per felicità se esiste una una soluzione facile quindi molto Warpress like per l'utilizzo di MariaDB quindi qualcosa che un plugin tipicamente che possa essere installato che oltre a essere un assoluto sostituto di MySQL con MariaDB però prende anche sia avvantaggia delle funzioni aggiuntive di MariaDB in Warpress in questo momento allora tutte se io dovesse sostituire MySQL che ho su una mia installazione di Warpress che poi MySQL non dipende da Warpress è lì quello che si fa e quello che si dice MariaDB è application independent cioè application compatible quindi se l'applicazione sta usando MySQL può usare MariaDB senza cambiare l'applicazione quindi tecnicamente quello che si fa è backupare il database stoppare il servizio installare MariaDB configurare giusto dove sono i dati e le cose del My.cnf quello che è riparto fina del problema cioè a quel punto lì io sto usando MariaDB i dati sono gli stessi e non devo migrare la cosa più pulita di solito è fare un dump del database e fare un reload del database in MariaDB i quelli più cowboy come dicevi tu prima vanno direttamente sui direttori di data senza toccare niente io preferisco fare dump per install per certe volte i dump sono anche molto lunghe molto coi quindi si può andare direttamente però è vero è proprio drop in the placement quindi tutte le le migrazioni da me se quelle MariaDB non richiedono anche che facciamo da clienti grandi la questione di quantità di tempo cioè ogni drop in semplicemente stop servizio backup install ricarico database fine e tutte queste funzionalità di cui vi ho parlato sono accessibili certo se voglio usare lo storage engine Sphinx devo specificare le tabelle che creerò certe in cui io sto tenendo i contenuti con cui lavoro siano di quel tipo lì però il thread pooling si abilita come vi ho detto con un parametro di configurazione l'ottimizzatore è già parte del server perché parte del core di MariaDB è una personalità sono stato al warpress forum 2 anni fa in hamster c'erano 4500 persone tanti sono dovute dirci che solo senza saperne molto di database come giusto non tutti gli sviluppatori di interfacce sanno molto di tecnica di database ma semplicemente rimpiazzando non ho già visto dei vantaggi in risposta dei loro prodotti l'ottimizzatore fa tanto riguardarsi le quere fa tanto se avete degli strumenti di monitor sul database che facciano vedere anche quanto il database soffre per certe quere quindi riuscire a scovare se c'è una quere che sta effettivamente mettendoci tanto ad essere eseguita dal database questo vi può di nuovo aiutare molto quindi ci sono degli strumenti di monitor open source che lavorano sui database e vi possono aiutare a vedere se per esempio che una quere molto pesante ci mette magari 5 secondi ogni volta e la chiamata è spesso quella vi ammazza la risposta ovviamente oppure magari una quere che sembra in acqua perché è velocissima ma guarda a casa non vi siete resi di conto che viene eseguito un milione di volte in un minuto e quindi poco ma tante volte risposto? prego questa è l'ultimo? visto che così funziona meglio visto che il nominato anche Percona volevo appunto chiedere che cosa accadrà in futuro se si può sapere nel senso questi Maria Squel Maria di B Percona continueranno a condividere il coro oppure ci sarà il rischio che qualcuno andrà per la sua strada non servirebbe a molti devo dire andare per la propria strada nel senso che tutti comunque Percona ha mantenuto una sua strada molto legata alla storia di Oracle quindi lei continua a essere un branch loro continuano a fare lavori di branch poi hanno aperto questa porta a Mongo quindi loro hanno una parte di server che si occupa di Mongo però loro fisicamente cioè tecnicamente sono un branch quindi loro aspettano praticamente che Oracle rilasci poi prendono al codice e ributtano dentro le loro cose ogni volta noi a un certo punto abbiamo spezzato questa strada soprattutto perché Oracle ci ha messo un anno e mezzo a fare una versione e noi avevamo troppa roba lì che aspettava di uscire quindi a un certo punto abbiamo preso la nostra decisione quindi la nostra posizione è quella di mantenere le stesse compatibilità di applica di funzionalità che metterà sul mai se quelle sul mercato ma se quelle farà qualcosa di blu lo faremo anche noi se farà qualcosa da righe lo faremo anche noi non sarà lo stesso codice faremo la stessa funzionalità chiamata allo stesso modo in modo che le applicazioni che usano la funzione in mai se quelle possono usare quella di MariaDB senza cambiare il codice però sarà codice diverso implementativo diverso che cambiano core non credo non servirebbe credo nessuno ottimizzazioni si feature in PUC il corsa era sempre lo stesso l'interesse di tutti di mantenerla la compatibilità è immenso nel mondo che ha senso di distinguersi ha senso di distinguersi e distinguiamo quei servizi con delle funzionalità ma di più di questo direi di no