Modelli di data mining relazionali Dati NoSQL

Suggerimento

Questo contenuto è un estratto di eBook, Architecting Cloud Native .NET Applications for Azure, disponibile in .NET Docs o come PDF scaricabile gratuito che può essere letto offline.

Scarica il PDF

Relazionale e NoSQL sono due tipi di sistemi di database comunemente implementati nelle app native del cloud. Vengono compilati in modo diverso, archiviano i dati in modo diverso e accedono in modo diverso. In questa sezione verranno esaminati entrambi. Più avanti in questo capitolo si esaminerà una tecnologia di database emergente denominata NewSQL.

I database relazionali sono stati una tecnologia prevalente per decenni. Sono maturi, collaudati e ampiamente implementati. Prodotti di database concorrenti, strumenti e competenze in ingresso. I database relazionali forniscono un archivio di tabelle dati correlate. Queste tabelle hanno uno schema fisso, usare SQL (Structured Query Language) per gestire i dati e supportare le garanzie ACID.

I database No-SQL fanno riferimento ad archivi dati non relazionali ad alte prestazioni. Essi eccelleno nelle caratteristiche di facilità d'uso, scalabilità, resilienza e disponibilità. Anziché unire tabelle di dati normalizzati, NoSQL archivia dati non strutturati o semistrutturati, spesso in coppie chiave-valore o documenti JSON. I database No-SQL in genere non forniscono garanzie ACID oltre l'ambito di una singola partizione di database. I servizi con volumi elevati che richiedono un tempo di risposta secondario favoriscono gli archivi dati NoSQL.

L'impatto delle tecnologie NoSQL per i sistemi nativi del cloud distribuiti non può essere superato. La proliferazione di nuove tecnologie di dati in questo spazio ha interrotto le soluzioni che una volta si basavano esclusivamente su database relazionali.

I database NoSQL includono diversi modelli per l'accesso e la gestione dei dati, ognuno dei quali è adatto a casi d'uso specifici. La figura 5-9 presenta quattro modelli comuni.

Figura 5-9: Modelli di dati per database NoSQL

Modello	Caratteristiche
Archivio documenti	I dati e i metadati vengono archiviati gerarchicamente in documenti basati su JSON all'interno del database.
Archivio chiave-valore	Il più semplice dei database NoSQL, i dati sono rappresentati come una raccolta di coppie chiave-valore.
Wide-Column Store	I dati correlati vengono archiviati come set di coppie chiave-valore nidificate all'interno di una singola colonna.
Archivio a grafo	I dati vengono archiviati in una struttura del grafo come proprietà di nodo, bordo e dati.

Teorema CAP

Per comprendere le differenze tra questi tipi di database, considerare il teorema CAP, un set di principi applicati ai sistemi distribuiti che archiviano lo stato. La figura 5-10 mostra le tre proprietà del teorema CAP.

Figura 5-10. Teorema CAP

Il teorema indica che i sistemi dati distribuiti offriranno un compromesso tra coerenza, disponibilità e tolleranza di partizione. Inoltre, qualsiasi database può garantire solo due delle tre proprietà:

• Coerenza. Ogni nodo del cluster risponde con i dati più recenti, anche se il sistema deve bloccare la richiesta fino a quando tutte le repliche non vengono aggiornate. Se si esegue una query su un "sistema coerente" per un elemento attualmente aggiornato, attendere la risposta fino a quando tutte le repliche non vengono aggiornate correttamente. Tuttavia, si riceveranno i dati più aggiornati.

• Disponibilità. Ogni nodo restituisce una risposta immediata, anche se tale risposta non è i dati più recenti. Se si esegue una query su un "sistema disponibile" per un elemento che viene aggiornato, si otterrà la risposta migliore possibile che il servizio possa fornire in quel momento.

• Tolleranza di partizione. Garantisce che il sistema continui a funzionare anche se un nodo dati replicato ha esito negativo o perde la connettività con altri nodi dati replicati.

Il teorema CAP spiega i compromessi associati alla gestione della coerenza e della disponibilità durante una partizione di rete; tuttavia i compromessi rispetto alla coerenza e alle prestazioni esistono anche con l'assenza di una partizione di rete. Il teorema CAP viene spesso esteso ulteriormente a PACELC per spiegare i compromessi in modo più completo.

I database relazionali offrono in genere coerenza e disponibilità, ma non la tolleranza di partizione. In genere viene eseguito il provisioning in un singolo server e viene eseguito il ridimensionamento verticale aggiungendo altre risorse al computer.

Molti sistemi di database relazionali supportano funzionalità di replica predefinite in cui è possibile creare copie del database primario in altre istanze del server secondario. Le operazioni di scrittura vengono eseguite nell'istanza primaria e replicate in ognuna delle repliche secondarie. In caso di errore, l'istanza primaria può eseguire il failover in un database secondario per garantire la disponibilità elevata. Le repliche secondarie possono essere usate anche per distribuire le operazioni di lettura. Mentre le operazioni di scrittura passano sempre alla replica primaria, le operazioni di lettura possono essere instradate a uno dei database secondari per ridurre il carico di sistema.

I dati possono anche essere partizionati orizzontalmente tra più nodi, ad esempio con il partizionamento orizzontale. Tuttavia, il partizionamento orizzontale aumenta notevolmente il sovraccarico operativo tramite lo spitting dei dati tra molte parti che non possono comunicare facilmente. Può essere costoso e dispendioso per la gestione. Le funzionalità relazionali che includono join di tabelle, transazioni e integrità referenziale richiedono sanzioni elevate per le prestazioni nelle distribuzioni partizionate.

È possibile ottimizzare la coerenza della replica e gli obiettivi del punto di ripristino configurando se la replica viene eseguita in modo sincrono o asincrono. Se le repliche dati perdessero la connettività di rete in un cluster di database relazionale "altamente coerente" o sincrono, non sarebbe possibile scrivere nel database. Il sistema rifiuterà l'operazione di scrittura perché non può replicare tale modifica nell'altra replica dati. Ogni replica dati deve essere aggiornata prima che la transazione possa essere completata.

I database NoSQL supportano in genere la disponibilità elevata e la tolleranza di partizione. Aumentano orizzontalmente, spesso tra server di materie prime. Questo approccio offre una disponibilità enorme, sia all'interno che all'interno delle aree geografiche a un costo ridotto. È possibile partizionare e replicare i dati tra questi computer o nodi, fornendo ridondanza e tolleranza di errore. La coerenza viene in genere ottimizzata tramite protocolli di consenso o meccanismi quorum. Forniscono un maggiore controllo durante l'esplorazione dei compromessi tra l'ottimizzazione sincrona e la replica asincrona nei sistemi relazionali.

Se le repliche dati perdessero la connettività in un cluster di database NoSQL a disponibilità elevata, è comunque possibile completare un'operazione di scrittura nel database. Il cluster di database consente l'operazione di scrittura e aggiorna ogni replica dati non appena diventa disponibile. I database NoSQL che supportano più repliche scrivibili possono rafforzare ulteriormente la disponibilità elevata evitando la necessità di failover durante l'ottimizzazione dell'obiettivo del tempo di ripristino.

I database NoSQL moderni implementano in genere funzionalità di partizionamento come funzionalità della progettazione del sistema. La gestione delle partizioni è spesso incorporata nel database e il routing viene ottenuto tramite hint di posizionamento, spesso chiamati chiavi di partizione. Un modello di dati flessibile consente ai database NoSQL di ridurre il carico di lavoro della gestione dello schema e migliorare la disponibilità durante la distribuzione degli aggiornamenti delle applicazioni che richiedono modifiche al modello di dati.

La disponibilità elevata e la scalabilità elevata sono spesso più critiche per l'azienda rispetto ai join di tabelle relazionali e all'integrità referenziale. Gli sviluppatori possono implementare tecniche e modelli come Sagas, CQRS e messaggistica asincrona per adottare la coerenza finale.

Al giorno d'oggi, è necessario prestare attenzione quando si considerano i vincoli del teorema CAP. È emerso un nuovo tipo di database, denominato NewSQL, che estende il motore di database relazionale per supportare sia la scalabilità orizzontale che le prestazioni scalabili dei sistemi NoSQL.

Considerazioni per sistemi relazionali e NoSQL

In base a requisiti di dati specifici, un microservizio basato sul cloud può implementare un archivio dati Relazionale, NoSQL o entrambi.

Prendere in considerazione un archivio dati NoSQL quando:	Si consideri un database relazionale quando:
Sono presenti carichi di lavoro con volumi elevati che richiedono una latenza prevedibile su larga scala (ad esempio la latenza misurata in millisecondi durante l'esecuzione di milioni di transazioni al secondo)	Il volume del carico di lavoro si adatta in genere a migliaia di transazioni al secondo
I dati sono dinamici e cambiano di frequente	I dati sono altamente strutturati e richiedono l'integrità referenziale
Le relazioni possono essere modelli di dati de normalizzati	Le relazioni vengono espresse tramite join di tabella nei modelli di dati normalizzati
Il recupero dei dati è semplice ed espresso senza join di tabella	È possibile usare query e report complessi
I dati vengono in genere replicati tra aree geografiche e richiedono un controllo più corretto sulla coerenza, la disponibilità e le prestazioni	I dati sono in genere centralizzati o possono essere replicati in modo asincrono
L'applicazione verrà distribuita in hardware di base, ad esempio con cloud pubblici	L'applicazione verrà distribuita in hardware di grandi dimensioni e di alto livello

Nelle sezioni successive verranno esaminate le opzioni disponibili nel cloud di Azure per archiviare e gestire i dati nativi del cloud.

Database distribuito come servizio

Per iniziare, è possibile effettuare il provisioning di una macchina virtuale di Azure e installare il database preferito per ogni servizio. Anche se si ha il controllo completo sull'ambiente, si predego molte funzionalità predefinite della piattaforma cloud. Si sarebbe anche responsabile della gestione della macchina virtuale e del database per ogni servizio. Questo approccio potrebbe diventare rapidamente dispendioso e costoso.

Invece, le applicazioni native del cloud favoriscono i servizi dati esposti come database come servizio (DBaaS). Completamente gestito da un fornitore del cloud, questi servizi offrono sicurezza, scalabilità e monitoraggio predefiniti. Invece di possedere il servizio, è sufficiente usarlo come servizio di backup. Il provider gestisce la risorsa su larga scala e ha la responsabilità di prestazioni e manutenzione.

Possono essere configurati tra zone di disponibilità cloud e aree geografiche per ottenere una disponibilità elevata. Supportano tutte la capacità just-in-time e un modello con pagamento in base al consumo. Azure offre diversi tipi di opzioni del servizio dati gestito, ognuna con vantaggi specifici.

Verranno prima esaminati i servizi DBaaS relazionali disponibili in Azure. Si noterà che il database SQL Server principale di Microsoft è disponibile insieme a diverse opzioni open source. Si parlerà quindi dei servizi dati NoSQL in Azure.

Database relazionali di Azure

Per i microservizi nativi del cloud che richiedono dati relazionali, Azure offre quattro offerte di database relazionali gestiti come servizio (DBaaS), illustrate nella figura 5-11.

Figura 5-11. Database relazionali gestiti disponibili in Azure

Nella figura precedente si noti come ognuno si trova su un'infrastruttura DBaaS comune che offre funzionalità chiave senza costi aggiuntivi.

Queste funzionalità sono particolarmente importanti per le organizzazioni che eseguono il provisioning di grandi quantità di database, ma hanno risorse limitate per amministrarle. È possibile effettuare il provisioning di un database di Azure in pochi minuti selezionando la quantità di core di elaborazione, memoria e archiviazione sottostante. È possibile ridimensionare il database al volo e regolare dinamicamente le risorse senza tempi di inattività.

Database SQL di Azure

I team di sviluppo con esperienza in Microsoft SQL Server devono considerare Azure SQL Database. È un database relazionale completamente gestito come servizio (DBaaS) basato sul motore di database di Microsoft SQL Server. Il servizio condivide molte funzionalità disponibili nella versione locale di SQL Server ed esegue la versione stabile più recente del motore di database SQL Server.

Per l'uso con un microservizio nativo del cloud, Azure SQL Database è disponibile con tre opzioni di distribuzione:

• Un database singolo rappresenta un database SQL completamente gestito in esecuzione in un server di database Azure SQL nel cloud di Azure. Il database viene considerato contenuto perché non ha dipendenze di configurazione nel server di database sottostante.

• Un Istanza gestita è un'istanza completamente gestita del motore di database di Microsoft SQL Server che offre compatibilità quasi al 100% con un SQL Server locale. Questa opzione supporta database più grandi, fino a 35 TB e viene inserito in un Rete virtuale di Azure per un migliore isolamento.

• Azure SQL serverless del database è un livello di calcolo per un singolo database che ridimensiona automaticamente in base alla richiesta del carico di lavoro. Fattura solo per la quantità di calcolo usata al secondo. Il servizio è adatto per i carichi di lavoro con modelli di utilizzo intermittenti, imprevedibili, interspersi con periodi di inattività. Il livello di calcolo serverless sospende automaticamente i database durante periodi inattivi in modo che vengano fatturati solo gli addebiti di archiviazione. Viene ripreso automaticamente quando viene restituita l'attività.

Oltre allo stack tradizionale di Microsoft SQL Server, Azure include anche versioni gestite di tre database open source diffusi.

Database open source in Azure

I database relazionali open source sono diventati una scelta popolare per le applicazioni native del cloud. Molte aziende li privilegino sui prodotti di database commerciali, soprattutto per risparmiare sui costi. Molti team di sviluppo godono della flessibilità, dello sviluppo supportato dalla community e dell'ecosistema di strumenti e estensioni. I database open source possono essere distribuiti in più provider di cloud, consentendo di ridurre al minimo la preoccupazione di "blocco fornitore".

Gli sviluppatori possono facilmente ospitare automaticamente qualsiasi database open source in una macchina virtuale di Azure. Fornendo il controllo completo, questo approccio consente di attivare l'hook per la gestione, il monitoraggio e la manutenzione del database e della macchina virtuale.

Microsoft continua tuttavia il suo impegno per mantenere Azure una "piattaforma aperta" offrendo diversi database open source diffusi come servizi DBaaS completamente gestiti .

Database di Azure per MySQL

MySQL è un database relazionale open source e un pilastro per le applicazioni basate sullo stack software LAMP. Ampiamente scelto per leggere carichi di lavoro pesanti , viene usato da molte grandi organizzazioni, tra cui Facebook, Twitter e YouTube. L'edizione community è disponibile gratuitamente, mentre l'edizione enterprise richiede un acquisto di licenza. Originariamente creato nel 1995, il prodotto è stato acquistato da Sun Microsystems nel 2008. Oracle ha acquisito Sun e MySQL nel 2010.

Database di Azure per MySQL è un servizio di database relazionale gestito basato sul motore del server MySQL open source. Usa l'edizione Community di MySQL. Il server Azure MySQL è il punto amministrativo per il servizio. È lo stesso motore del server MySQL usato per le distribuzioni locali. Il motore può creare un singolo database per server o più database per server che condividono le risorse. È possibile continuare a gestire i dati usando gli stessi strumenti open source senza dover imparare nuove competenze o gestire macchine virtuali.

Database di Azure per MariaDB

Mariadb Server è un altro server di database open source popolare. È stato creato come fork di MySQL quando Oracle ha acquistato Sun Microsystems, che possiede MySQL. La finalità era di garantire che MariaDB rimanesse open source. Poiché MariaDB è un fork di MySQL, i dati e le definizioni di tabella sono compatibili e i protocolli client, le strutture e le API, sono a maglia stretta.

MariaDB ha una forte community e viene usata da molte grandi aziende. Mentre Oracle continua a mantenere, migliorare e supportare MySQL, la fondazione MariaDB gestisce MariaDB, consentendo contributi pubblici al prodotto e alla documentazione.

Database di Azure per MariaDB è un database relazionale completamente gestito come servizio nel cloud di Azure. Il servizio si basa sul motore del server mariaDB community edition. Può gestire carichi di lavoro cruciali con prestazioni prevedibili e scalabilità dinamica.

Database di Azure per PostgreSQL

PostgreSQL è un database relazionale open source con oltre 30 anni di sviluppo attivo. PostgreSQL ha una forte reputazione per l'affidabilità e l'integrità dei dati. È una funzionalità avanzata, conforme a SQL e considerata più efficiente di MySQL, soprattutto per i carichi di lavoro con query complesse e scritture pesanti. Molte grandi aziende, tra cui Apple, Red Hat e Fujitsu, hanno costruito prodotti con PostgreSQL.

Database di Azure per PostgreSQL è un servizio di database relazionale completamente gestito, basato sul motore di database Postgres open source. Il servizio supporta molte piattaforme di sviluppo, tra cui C++, Java, Python, Node, C#e PHP. È possibile eseguire la migrazione dei database PostgreSQL usando lo strumento di interfaccia della riga di comando o il servizio Migrazione dati di Azure.

Database di Azure per PostgreSQL è disponibile con due opzioni di distribuzione:

• L'opzione di distribuzione a server singolo è un punto amministrativo centrale per più database a cui è possibile distribuire molti database. I prezzi sono strutturati per server in base ai core e all'archiviazione.

• L'opzione Hyperscale (Citus) è basata sulla tecnologia Citus Data. Consente prestazioni elevate ridimensionando orizzontalmente un singolo database tra centinaia di nodi per offrire prestazioni e scalabilità rapide. Questa opzione consente al motore di adattare più dati in memoria, parallelizzare le query tra centinaia di nodi e indicizzare più velocemente i dati.

Dati NoSQL in Azure

Cosmos DB è un servizio di database NoSQL distribuito a livello globale nel cloud di Azure. È stato adottato da molte grandi aziende in tutto il mondo, tra cui Coca-Cola, Skype, ExxonMobil e Liberty Mutual.

Se i servizi richiedono una risposta rapida da qualsiasi punto del mondo, disponibilità elevata o scalabilità elastica, Cosmos DB è una scelta ottimale. La figura 5-12 mostra Cosmos DB.

Figura 5-12: Panoramica di Azure Cosmos DB

La figura precedente presenta molte delle funzionalità native del cloud predefinite disponibili in Cosmos DB. In questa sezione verranno esaminate più attentamente.

Supporto globale

Le applicazioni native del cloud hanno spesso un pubblico globale e richiedono scalabilità globale.

È possibile distribuire i database Cosmos in aree o in tutto il mondo, inserendo i dati vicini agli utenti, migliorando il tempo di risposta e riducendo la latenza. È possibile aggiungere o rimuovere un database da un'area senza sospendere o ridistribuire i servizi. In background Cosmos DB replica in modo trasparente i dati in ognuna delle aree configurate.

Cosmos DB supporta il clustering attivo/attivo a livello globale, consentendo di configurare una delle aree del database per supportare sia le operazioni di scrittura che di lettura.

Il protocollo di scrittura in più aree è una funzionalità importante di Cosmos DB che abilita le funzionalità seguenti:

• Scalabilità elastica illimitata per la scrittura e la lettura.

• Disponibilità in lettura e scrittura pari al 99,999% in tutto il mondo.

• Letture e scritture gestite in meno di 10 millisecondi nel 99% dei casi.

Con le API multihoming di Cosmos DB, il microservizio riconosce automaticamente l'area di Azure più vicina e invia le richieste. L'area più vicina è identificata da Cosmos DB senza alcuna modifica della configurazione. Se un'area diventa non disponibile, la funzionalità Multi-Homing instrada automaticamente le richieste all'area successiva disponibile più vicina.

Supporto di più modelli

Quando si ripiattano le applicazioni monolitiche in un'architettura nativa del cloud, i team di sviluppo a volte devono eseguire la migrazione di archivi dati NoSQL open source. Cosmos DB consente di mantenere l'investimento in questi archivi dati NoSQL con la piattaforma dati multimodelli . La tabella seguente illustra le API di compatibilità NoSQL supportate.

Provider	Descrizione
API NoSQL	L'API per NoSQL archivia i dati in formato documento
API MongoDB	Supporta le API e i documenti JSON di Mongo DB
API Gremlin	Supporta l'API Gremlin con nodi basati su grafo e rappresentazioni dei dati perimetrali
API Cassandra	Supporta l'API Casandra per le rappresentazioni di dati a colonne estese
API Tabella	Supporta Archiviazione tabelle di Azure con miglioramenti premium
PostgreSQL API	Servizio gestito per l'esecuzione di PostgreSQL su qualsiasi scala

I team di sviluppo possono eseguire la migrazione di database Mongo, Gremlin o Cassandra esistenti in Cosmos DB con modifiche minime ai dati o al codice. Per le nuove app, i team di sviluppo possono scegliere tra opzioni open source o il modello API SQL predefinito.

Internamente, Cosmos archivia i dati in un formato di struct semplice costituito da tipi di dati primitivi. Per ogni richiesta, il motore di database converte i dati primitivi nella rappresentazione del modello selezionata.

Nella tabella precedente prendere nota dell'opzione API Tabella . Questa API è un'evoluzione dell'archiviazione tabelle di Azure. Entrambi condividono lo stesso modello di tabella sottostante, ma l'API Tabella di Cosmos DB aggiunge miglioramenti premium non disponibili nell'API di archiviazione di Azure. Nella tabella seguente sono in contrasto le funzionalità.

Funzionalità	Archiviazione tabelle di Azure	Azure Cosmos DB
Latenza	Veloce	Latenza in millisecondi a cifra singola per letture e scritture ovunque nel mondo
Velocità effettiva	Limite di 20.000 operazioni per tabella	Operazioni illimitate per tabella
Distribuzione globale	Singola area con area di lettura secondaria singola facoltativa	Distribuzioni chiavi in mano a tutte le aree con failover automatico
Indicizzazione	Disponibile solo per le proprietà della chiave di partizione e di riga	Indicizzazione automatica di tutte le proprietà
Prezzi	Ottimizzato per carichi di lavoro ad accesso sporadico (velocità effettiva bassa: rapporto di archiviazione)	Ottimizzato per carichi di lavoro ad accesso frequente (velocità effettiva elevata: rapporto di archiviazione)

I microservizi che usano l'archiviazione tabelle di Azure possono eseguire facilmente la migrazione all'API Tabella di Cosmos DB. Non sono necessarie modifiche al codice.

Coerenza ottimizzabile

In precedenza nella sezione Relazionale e NoSQL è stato illustrato l'oggetto della coerenza dei dati. La coerenza dei dati si riferisce all'integrità dei dati. I servizi nativi del cloud con dati distribuiti si basano sulla replica e devono fare un compromesso fondamentale tra coerenza in lettura, disponibilità e latenza.

La maggior parte dei database distribuiti consente agli sviluppatori di scegliere tra due modelli di coerenza: coerenza assoluta e coerenza finale. La coerenza assoluta è lo standard d'oro della programmabilità dei dati. Garantisce che una query restituisca sempre i dati più recenti, anche se il sistema deve incorrere in una latenza in attesa della replica di un aggiornamento in tutte le copie del database. Anche se un database configurato per la coerenza finale restituirà immediatamente i dati, anche se tali dati non sono la copia più recente. Quest'ultima opzione consente una maggiore disponibilità, una scalabilità maggiore e un miglioramento delle prestazioni.

Azure Cosmos DB offre cinque modelli di coerenza ben definiti illustrati nella figura 5-13.

Figura 5-13: Livelli di coerenza di Cosmos DB

Queste opzioni consentono di effettuare scelte precise e compromessi granulari per coerenza, disponibilità e prestazioni per i dati. I livelli sono presentati nella tabella seguente.

Livello di coerenza	Descrizione
Finale	Nessuna garanzia di ordinamento per le letture. Le repliche convergeranno infine.
Prefisso costante	Le letture sono ancora in corso, ma i dati vengono restituiti nell'ordinamento in cui vengono scritti.
sessione	Garantisce la lettura di tutti i dati scritti durante la sessione corrente. Si tratta del livello di coerenza predefinito.
Decadimento ristretto	Legge le scritture trail in base all'intervallo specificato.
Assoluta	Le letture sono garantite per restituire la versione di cui è stato eseguito il commit più recente di un elemento. Un client non vede mai un'operazione di lettura non commit o parziale.

Nell'articolo Getting Behind the 9-Ball: Cosmos DB Consistency Levels Explained, Microsoft Program Manager Jeremy Likness fornisce una spiegazione eccellente dei cinque modelli.

Partizionamento

Azure Cosmos DB adotta il partizionamento automatico per ridimensionare un database per soddisfare le esigenze di prestazioni dei servizi nativi del cloud.

Per gestire i dati in Cosmos DB, creare database, contenitori ed elementi.

I contenitori si trovano in un database Cosmos DB e rappresentano un raggruppamento indipendente dallo schema di elementi. Gli elementi sono i dati aggiunti al contenitore. Sono rappresentati come documenti, righe, nodi o bordi. Tutti gli elementi aggiunti a un contenitore vengono indicizzati automaticamente.

Per partizionare il contenitore, gli elementi sono divisi in subset distinti denominati partizioni logiche. Le partizioni logiche vengono popolate in base al valore di una chiave di partizione associata a ogni elemento in un contenitore. La figura 5-14 mostra due contenitori ognuno con una partizione logica basata su un valore di chiave di partizione.

Figura 5-14: Meccanismi di partizionamento di Cosmos DB

Si noti nella figura precedente come ogni elemento include una chiave di partizione di 'city' o 'airport'. La chiave determina la partizione logica dell'elemento. Gli elementi con codice città vengono assegnati al contenitore a sinistra e gli elementi con codice aeroporto vengono assegnati al contenitore a destra. La combinazione del valore della chiave di partizione con il valore ID crea l'indice di un elemento, che identifica in modo univoco l'elemento.

Internamente, Cosmos DB gestisce automaticamente il posizionamento delle partizioni logiche nelle partizioni fisiche per soddisfare le esigenze di scalabilità e prestazioni del contenitore. Poiché i requisiti di velocità effettiva e archiviazione dell'applicazione aumentano, Azure Cosmos DB ridistribuisce le partizioni logiche in un numero maggiore di server. Le operazioni di ridistribuzione vengono gestite da Cosmos DB e richiamate senza interruzioni o tempi di inattività.

Database NewSQL

NewSQL è una tecnologia di database emergente che combina la scalabilità distribuita di NoSQL con le garanzie ACID di un database relazionale. I database NewSQL sono importanti per i sistemi aziendali che devono elaborare volumi elevati di dati, in ambienti distribuiti, con supporto transazionale completo e conformità ACID. Anche se un database NoSQL può offrire scalabilità elevata, non garantisce la coerenza dei dati. I problemi intermittenti dai dati incoerenti possono comportare un onere per il team di sviluppo. Gli sviluppatori devono costruire misure di protezione nel codice del microservizio per gestire i problemi causati da dati incoerenti.

Cloud Native Computing Foundation (CNCF) offre diversi progetti di database NewSQL.

Project	Caratteristiche
Db di scarafaggi	Database relazionale conforme a ACID che ridimensiona a livello globale. Aggiungere un nuovo nodo a un cluster e ScarafaggiDB si occupa del bilanciamento dei dati tra istanze e aree geografiche. Crea, gestisce e distribuisce repliche per garantire l'affidabilità. È open source e liberamente disponibile.
TiDB	Un database open source che supporta carichi di lavoro HTAP (Hybrid Transactional and Analytics Processing). È compatibile con MySQL e offre scalabilità orizzontale, coerenza elevata e disponibilità elevata. TiDB funge da server MySQL. È possibile continuare a usare librerie client MySQL esistenti, senza richiedere modifiche estese al codice all'applicazione.
YugabyteDB	Un database SQL distribuito open source, ad alte prestazioni. Supporta la latenza di query bassa, la resilienza contro gli errori e la distribuzione dei dati globali. YugabyteDB è compatibile con PostgreSQL e gestisce carichi di lavoro RDBMS e OLTP su larga scala. Il prodotto supporta anche NoSQL ed è compatibile con Cassandra.
Vitess	Vitess è una soluzione di database per la distribuzione, la scalabilità e la gestione di cluster di grandi dimensioni di istanze di MySQL. Può essere eseguito in un'architettura cloud pubblica o privata. Vitess combina e estende molte funzionalità importanti di MySQL e funzionalità sia di supporto verticale che orizzontale. Originato da YouTube, Vitess ha servito tutto il traffico del database youTube dal 2011.

I progetti open source nella figura precedente sono disponibili dalla Cloud Native Computing Foundation. Tre delle offerte sono prodotti di database completi, che includono il supporto .NET. L'altro, Vitess, è un sistema di clustering di database che ridimensiona orizzontalmente cluster di istanze di MySQL.

Un obiettivo di progettazione chiave per i database NewSQL consiste nel lavorare in modo nativo in Kubernetes, sfruttando la resilienza e la scalabilità della piattaforma.

I database NewSQL sono progettati per crescere in ambienti cloud temporanei in cui le macchine virtuali sottostanti possono essere riavviate o riprogrammate in un momento. I database sono progettati per sopravvivere agli errori del nodo senza perdita di dati né tempi di inattività. ScarafaggiDB, ad esempio, è in grado di sopravvivere a una perdita di computer mantenendo tre repliche coerenti di tutti i dati tra i nodi in un cluster.

Kubernetes usa un costrutto di Servizi per consentire a un client di risolvere un gruppo di database NewSQL identici da una singola voce DNS. Separando le istanze del database dall'indirizzo del servizio a cui è associato, è possibile ridimensionare senza interrompere le istanze dell'applicazione esistenti. L'invio di una richiesta a qualsiasi servizio in un determinato momento restituirà sempre lo stesso risultato.

In questo scenario tutte le istanze del database sono uguali. Non esistono relazioni primarie o secondarie. Le tecniche come la replica di consenso rilevate in ScarafaggiDB consentono a qualsiasi nodo di database di gestire qualsiasi richiesta. Se il nodo che riceve una richiesta con bilanciamento del carico ha i dati necessari in locale, risponde immediatamente. In caso contrario, il nodo diventa un gateway e inoltra la richiesta ai nodi appropriati per ottenere la risposta corretta. Dal punto di vista del client, ogni nodo di database è lo stesso: vengono visualizzati come un singolo database logico con le garanzie di coerenza di un sistema a computer singolo, nonostante la presenza di decine o persino centinaia di nodi che funzionano dietro le quinte.

Per un'analisi dettagliata della meccanica dietro i database NewSQL, vedere l'articolo DASH: Quattro proprietà dei database di Kubernetes-Native .

Migrazione dei dati al cloud

Una delle attività che richiedono più tempo è la migrazione dei dati da una piattaforma dati a un'altra. Il servizio Migrazione dati di Azure può aiutare a velocizzare tali sforzi. Può eseguire la migrazione dei dati da diverse origini di database esterne in piattaforme dati di Azure con tempi di inattività minimi. Le piattaforme di destinazione includono i servizi seguenti:

• database SQL di Azure
• Database di Azure per MySQL
• Database di Azure per MariaDB
• Database di Azure per PostgreSQL
• Azure Cosmos DB

Il servizio fornisce consigli per guidare le modifiche necessarie per eseguire una migrazione, sia di piccole dimensioni che di grandi dimensioni.

IndietroAvanti