Oracle: le novità per l'Autonomous Database e la nuova generazione di Exadata Cloud Infrastructure X9M

Non si fermano le novità per Oracle che continua a effettuare costanti ma significativi aggiornamenti alle sue soluzioni. Fra le principali novità delle ultime settimane una riguarda l'infrastruttura cloud legata all'hardware, con la disponibilità della nuova generazione di Exadata Cloud Infrastructure X9M, molto più potente della precedente. A questo si aggiunge la possibilità di eseguire contemporaneamente database autonomi e non-autonomi sulla stessa macchina Oracle Exadata Cloud@Customer.

Exadata Cloud Infrastructure X9M: maggiori performance allo stesso prezzo del precedente modello

Fino a qualche settimana fa Exadata Cloud Infrastructure X8M era considerata l’architettura più veloce in assoluto per la gestione degli Online Transaction Processing database in cloud (OLTP). Un record che però è stato infranto dal successore di questa macchina, Exadata Cloud Infrastructure X9M. Questa nuova incarnazione offre un numero di core superiore di 2,5 volte (si passa da 3.200 vCPU a ben 8.064), capace di scambiare dati verso OCI Fabric alla velocità di 1.600 Gbps, contro i “soli” 800 Gbps di X8M. Rimane invariata la quantità di memoria (44 TB) e la latenza del sistema, che si attesta al di sotto dei 19 microsecondi. Molto interessante il fatto che il prezzo rimane lo stesso di X8M, così come rimane uguale il modello di consumo: si paga solo per il reale utilizzo delle CPU. Un approccio differente rispetto ad altre realtà, che invece prevedono un canone indipendentemente dal fatto che i clienti sfruttino o meno la potenza di elaborazione a loro disposizione.

Secondo Oracle, questa architettura è a oggi quella che garantisce le migliori prestazioni di Analytics Database Cloud sul mercato, con un troughput massimo di 2.880 GB/s. Per fare un paragone, è 137 volte più veloce di Azure SQL e 7,5 volte più veloce di AES RDS, sotto questo profilo.  

Ma a chi serve tutta questa potenza? Le applicazioni spaziano in vari ambiti ma sicuramente le imprese più interessate a questo tipo di soluzioni sono quelle che operano nel mondo bancario e assicurativo, sia per gestire i complessi calcoli delle analisi di rischio, sia per prevenire le frodi bancarie, come l’uso illecito di carte di credito e di debito. Si tratta di operazioni complesse che devono essere svolte in tempo praticamente reale per potere essere efficaci nel contrastare il crimine.

Database autonomi e non autonomi sulla stessa architettura Oracle

Una delle principali novità di Exatada X9M è la possibilità di gestire contemporaneamente database autonomi e non autonomi sulla stessa macchina Oracle Exadata Cloud@Customer. Sorge spontanea una domanda: perché farlo?

Lo abbiamo chiesto a Riccardo Romani, Responsabile della prevendita Cloud Systems sud Europa: “Autonomous DB è un database intelligente, che previene problematiche di sicurezza e manutenzione”, spiega Romani. “Tradizionalmente questi ambienti [i DB autonomi, NdR] hanno bisogno di un’infrastruttura dedicata, perché elaborano moltissimi dati e necessitano di parecchia potenza di calcolo per gestirli. Quando Oracle ha lanciato sul mercato le soluzioni Cloud@Customer è stato seguito questo approccio ma col tempo il reparto R&D ha migliorato l’architettura e oggi non servono più due ambienti isolati”. Il vantaggio di questo approccio? “Il time to market e la flessibilità”, sottolinea Romani: avere un ambiente che in pochi clic è in grado di generare in automatico un DB, autonomous o meno, velocizza di molto le operazioni e garantisce maggiore libertà a chi si occupa dello sviluppo. Secondo Romani, è una caratteristica chiave e a oggi Oracle è l’unica realtà a offrirla sul mercato.

Il concetto di fondo è che gli sviluppatori preferiscono adattare lo stile di sviluppo alle specificità del progetto. Chi si occupa di gestire siti di viaggi o di booking, per esempio, trae vantaggio dalle funzionalità tipiche dei database autonomi mentre chi opera in mercati come quello bancario o assicurativo tende a operare in maniera tradizionale.

Ma considerati i vantaggi dei DB autonomi, come mai si sente la necessità di poter eseguire due tipologie di DB contemporaneamente? Secondo Romani, ci sono vari motivi ma i principali sono due: organizzativi e di conformità. “Molte aziende hanno team molto gerarchici, che lavorano tanto in maniera tradizionale. Gli sviluppatori più a ridosso del business, cioè vicini a chi fa marketing e comunicazione, hanno bisogno di un approccio a più alto livello, meno raffinato”. Al contrario, chi deve trattare dati sensibili, a causa dei regolamenti UE è spesso costretto a scegliere DB non autonomi: l’autonomous DB di Oracle prevede che l'algoritmo abbia la possibilità di leggere i dati, fatto che quindi si scontra con le normative Europee che sono più stringenti di altre. E, soprattutto in Italia, i principali utenti di questi sistemi sono quelli che operano nel settore bancario e assicurativo, che devono effettuare complesse analisi sul rischio.

In pratica, poter eseguire due tipologie di DB consente agli sviluppatori di scegliere quale dei due approcci è migliore sulla base delle necessità.

Un altro vantaggio di poter eseguire due tipologie di DB allo stesso tempo su una macchina come X9M è il risparmio economico. La fatturazione è del tipo pay-per-use, quindi si paga solo per le risorse realmente utilizzate, e avere una maggior potenza di elaborazione permette di eseguire i calcoli in meno tempo. Secondo le stime fatte da IDC, il risparmio medio è del 40% circa. Ma ci sono casi, come quelli dei clienti che hanno carichi stagionali o periodici (per esempio le telco) e che quindi non macinano dati 24/7: per loro il risparmio può arrivare anche al 70%.

Abbiamo chiesto a Romani se in futuro Oracle ha intenzione di esplorare nuove architetture hardware, per esempio i nuovi chip M1 di Apple e il dirigente ci ha confermato che la multinazionale li sta valutando. Al momento attuale, non tanto per ripensare l’architettura dei sistemi Cloud@Customer ma per altre soluzioni destinate all’edge computing. Server più compatti e robusti, pensati anche per resistere a condizioni climatiche estreme, per elaborare velocemente e a bassissime latenze i dati lì dove vengono generati, per esempio nelle fabbriche.