Livello di servizio Hyperscale

Si applica a: database SQL di Azure

Il Database SQL di Azure si basa sull'architettura del motore di database di SQL Server che viene regolata per l'ambiente cloud per garantire alta disponibilità anche in caso di errori dell'infrastruttura. Esistono tre opzioni di livello di servizio nel modello di acquisto vCore per database SQL di Azure:

• Utilizzo generico
• Business Critical
• Hyperscale

Il livello di servizio Hyperscale è adatto a tutti i tipi di carico di lavoro. L'architettura nativa del cloud offre risorse di calcolo e archiviazione scalabili in modo indipendente per supportare la più ampia gamma di applicazioni tradizionali e moderne. Le risorse di calcolo e archiviazione in Hyperscale superano sostanzialmente le risorse disponibili nei livelli Per utilizzo generico e Business Critical.

Per informazioni dettagliate sui livelli di servizio Utilizzo generico e Business critical nel modello di acquisto basato su vCore, vedere i livelli di servizio Utilizzo generico e Business critical. Per un confronto tra il modello di acquisto basato su vCore e il modello di acquisto basato su vCore, vedi Confrontare i modelli di acquisto basati su vCore e DTU del database SQL di Azure.

Il livello di servizio Hyperscale è attualmente disponibile per il database SQL di Azure, ma non per Istanza gestita di SQL di Azure.

Funzionalità del livello di servizio Hyperscale

Il livello di servizio Hyperscale nel database SQL di Azure offre le seguenti funzionalità aggiuntive:

• Rapida scalabilità verticale: in un tempo costante è possibile aumentare le risorse di calcolo per supportare ingenti carichi di lavoro in base alle esigenze e quindi ridurle nuovamente quando non sono necessarie.
• Scale-out rapidoe: è possibile effettuare il provisioning di una o più repliche di sola lettura per l'offload del carico di lavoro di lettura e per l'uso come hot standby.
• Scalabilità verticale e orizzontale e fatturazione automatiche per il calcolo in base all'utilizzo con elaborazione serverless.
• Prezzo/prestazioni ottimizzato per un gruppo di database Hyperscale con esigenze di risorse variabili con pool elastici (in anteprima).
• Archiviazione con scalabilità automatica con supporto per un massimo di 100 TB di dimensioni del database o del pool elastico.
• Prestazioni complessive più elevate grazie alla maggiore velocità effettiva dei log e ai tempi di commit delle transazioni più veloci, indipendentemente dai volumi di dati.
• Backup dei database rapidi (basati su snapshot di file) indipendentemente dalle dimensioni senza alcun impatto delle operazioni di I/O sulle risorse di calcolo.
• Ripristino database o copie (basati su snapshot di file) in pochi minuti anziché in ore o giorni.

Il livello di servizio Hyperscale elimina molti dei limiti pratici che generalmente caratterizzano i database cloud. Se la maggior parte dei database sono limitati dalle risorse disponibili in un singolo nodo, i database nel livello di servizio Hyperscale non presentano limiti di questo tipo. Grazie all'architettura di archiviazione flessibile, lo spazio di archiviazione aumenta in base alle esigenze. I database Hyperscale, infatti, non vengono creati con una dimensione massima definita. Un database Hyperscale può espandersi in base alle esigenze e la fatturazione viene applicata solo in base alla capacità di archiviazione assegnata. Per i carichi di lavoro con intense attività di lettura, il livello di servizio Hyperscale consente un rapido scale-out effettuando il provisioning di repliche in lettura aggiuntive in base alle necessità per l'offload dei carichi di lavoro di lettura.

Inoltre, il tempo necessario per creare i backup dei database oppure aumentare o diminuire le prestazioni non è più associato al volume dei dati presenti nel database. Il backup dei database Hyperscale viene eseguito in maniera praticamente istantanea. È anche possibile dimensionare un database in decine di terabyte verso l'alto o verso il basso entro pochi minuti nel livello di calcolo di cui è stato effettuato il provisioning o usare serverless per dimensionare automaticamente il calcolo. Questa funzionalità consente di non essere vincolati alle scelte di configurazione iniziali.

Per altre informazioni sulle dimensioni di calcolo per il livello di servizio Hyperscale, vedere Caratteristiche del livello di servizio.

Destinazione d'uso del livello di servizio Hyperscale

Il livello di servizio Hyperscale è destinato a tutti i clienti che richiedono prestazioni e disponibilità più elevate, backup e ripristino rapidi e/o scalabilità di calcolo e archiviazione veloci. Sono inclusi i clienti che stanno passando al cloud per modernizzare le loro applicazioni e i clienti che usano già altri livelli di servizio nel database SQL di Azure. Il livello di servizio Hyperscale supporta un'ampia gamma di carichi di lavoro di database, da OLTP pulito ad analisi pulita. È ottimizzato per carichi di lavoro OLTP e di elaborazione analitica e transazioni ibride (HTAP).

Nota

Attualmente i pool elastici per Hyperscale sono disponibili in anteprima.

Modello di prezzi del livello di servizio Hyperscale

Nota

Sono arrivati i prezzi semplificati per Hyperscale di database SQL di Azure! Leggi l'annuncio del nuovo piano tariffario per Hyperscale di database SQL di Azure, mentre per informazioni dettagliate sulle modifiche ai prezzi, vedi Azure SQL Database Hyperscale – lower, simplified pricing!.

Il livello di servizio Hyperscale è disponibile solo nel modello vCore. Per allinearsi alla nuova architettura, il modello di prezzi è leggermente diverso da quello del livello di servizio Utilizzo generico o Business critical:

• Calcolo con provisioning:

  Il prezzo dell'unità di calcolo del livello di servizio Hyperscale è per replica. Gli utenti possono modificare da 0 a 4 il numero totale di repliche secondarie con disponibilità elevata a seconda dei requisiti di disponibilità e scalabilità e creare fino a 30 repliche denominate per supportare vari carichi di lavoro con aumento delle istanze in lettura.

• Calcolo serverless:

  La fatturazione delle risorse di elaborazione serverless si basa sull'utilizzo. Per ulteriori informazioni, vedi Livello di calcolo serverless per il database SQL di Azure.

• Archiviazione:

  Non è necessario specificare le dimensioni massime dei dati durante la configurazione di un database Hyperscale. Nel livello Hyperscale viene addebitato il costo dell'archiviazione per il database in base all'allocazione effettiva. L'archiviazione viene assegnata automaticamente tra 10 GB e 100 TB, in incrementi di 10 GB quando necessario.

Per altre informazioni sui prezzi di Hyperscale, si veda Prezzi di Database SQL di Azure.

Confrontare i limiti delle risorse

I livelli di servizio basati su vCore si distinguono per tipo di disponibilità e di archiviazione, prestazioni e dimensioni di archiviazione massime. Le differenze sono descritte nella tabella seguente:

ㅤ	Utilizzo generico	Business Critical	Hyperscale
Ideale per	Offre opzioni di calcolo e archiviazione bilanciate a prezzi convenienti.	Applicazioni OLTP con frequenza di transazioni elevata e bassi livelli di latenza di I/O. Offre grande resilienza agli errori e failover rapidi tramite più repliche hot standby.	La più ampia gamma di carichi di lavoro. Scalabilità automatica delle dimensioni di archiviazione fino a 100 TB, ridimensionamento rapido verticale e orizzontale dell'ambiente di calcolo, ripristino rapido del database.
Dimensioni di calcolo	Da 2 a 128 vCore	Da 2 a 128 vCore	Da 2 a 128 vCore 1
Tipo di archiviazione	Archiviazione remota Premium (per istanza)	Archiviazione SSD locale estremamente veloce (per istanza)	Archiviazione disaccoppiata con cache SSD locale (per replica di calcolo)
Dimensioni di archiviazione 1	Da 1 GB a 4 TB	Da 1 GB a 4 TB	Da 10 GB a 100 TB
IOPS	320 operazioni di I/O al secondo per vCore fino a un massimo di 16.000	4.000 operazioni di I/O al secondo per vCore fino a un massimo di 327.680	327.680 operazioni di I/O al secondo con SSD locale massimo Hyperscale è un'architettura multilivello con memorizzazione nella cache a più livelli. Le operazioni di I/O al secondo effettive dipendono dal carico di lavoro.
Memoria e vCore	5,1 GB	5,1 GB	5.1 GB o 10.2 GB
Disponibilità	Una replica, nessuna per scalabilità in lettura, disponibilità elevata con ridondanza della zona	Tre repliche, una per scalabilità in lettura, disponibilità elevata con ridondanza della zona	Più repliche, fino a quattro con scalabilità in lettura, disponibilità elevata con ridondanza della zona
Backup	Scelta tra archiviazione con ridondanza locale (LRS), con ridondanza della zona (ZRS) o con ridondanza geografica (GRS) Conservazione di 1-35 giorni (sette giorni per impostazione predefinita), con un massimo di 10 anni di conservazione a lungo termine disponibile	Scelta tra archiviazione con ridondanza locale (LRS), con ridondanza della zona (ZRS) o con ridondanza geografica (GRS) Conservazione di 1-35 giorni (sette giorni per impostazione predefinita), con un massimo di 10 anni di conservazione a lungo termine disponibile	Scelta tra archiviazione con ridondanza locale (LRS), con ridondanza della zona (ZRS) o con ridondanza geografica (GRS) Conservazione di 1-35 giorni (sette giorni per impostazione predefinita), con un massimo di 10 anni di conservazione a lungo termine disponibile
Prezzi e fatturazione	Vengono addebitati i costi per vCore, spazio di archiviazione e archivio di backup. Le operazioni di I/O al secondo non vengono addebitate.	Vengono addebitati i costi per vCore, spazio di archiviazione e archivio di backup. Le operazioni di I/O al secondo non vengono addebitate.	Vengono addebitati i costi vCore per ogni replica, archiviazione dei dati assegnata e archivio di backup. Le operazioni di I/O al secondo non vengono addebitate.
Modelli di sconto2	Istanze riservate Vantaggio Azure Hybrid3 Sottoscrizioni di sviluppo/test enterprise e con pagamento in base al consumo	Istanze riservate Vantaggio Azure Hybrid3 Sottoscrizioni di sviluppo/test enterprise e con pagamento in base al consumo	Istanze riservate Vantaggio Azure Hybrid3 Sottoscrizioni di sviluppo/test enterprise e con pagamento in base al consumo

¹ Le Informazioni generali sui pool elastici Hyperscale in database SQL di Azure sono attualmente in anteprima.

² A dicembre 2023 sono arrivati i prezzi semplificati per Hyperscale di database SQL. Per informazioni dettagliate, vedere il blog sui prezzi di Hyperscale.

³ A partire da dicembre 2023, il vantaggio di Azure Hybrid non è disponibile per i nuovi database Hyperscale o nelle sottoscrizioni di sviluppo/test. I database singoli Hyperscale esistenti con calcolo con provisioning possono continuare a usare Vantaggio Azure Hybrid per risparmiare sui costi di calcolo fino a dicembre 2026. Per ulteriori informazioni, vedi il blog sui prezzi di Hyperscale.

Risorse di calcolo

Configurazione hardware	CPU	Memoria
Serie standard (Gen5)	Calcolo con provisioning - Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake)1, Intel® 8272CL (Cascade Lake) 2,5 GHz1, Intel® Xeon® Platinum 8370C (Ice Lake)1, processori AMD EPYC 7763v (Milan) - Provisioning di un massimo di 80 vCore (con hyperthreading) Calcolo serverless - Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake)1, Intel® 8272CL (Cascade Lake) 2,5 GHz1, Intel® Xeon® Platinum 8370C (Ice Lake)1, processori AMD EPYC 7763v (Milan) - Scalabilità automatica fino a 80 vCore (con hyperthreading) - Il rapporto da memoria a vCore si adatta dinamicamente all'utilizzo della memoria e della CPU in base alla domanda del carico di lavoro e può essere pari a 24 GB per vCore. Ad esempio, in un determinato momento, un carico di lavoro può usare ed essere fatturato per 240 GB di memoria e solo 10 vCore.	Calcolo con provisioning - 5,1 GB per vCore - Provisioning di un massimo di 625 GB Calcolo serverless - Scalabilità automatica fino a 24 GB per vCore - Scalabilità automatica fino a 240 GB
Serie Premium	- Processori Intel® Xeon® Platinum 8370C (Ice Lake), AMD EPYC 7763v (Milan) - Provisioning di un massimo di 128 vCore (con hyperthreading)	- 5,1 GB per vCore
Serie Premium ottimizzata per la memoria	- Processori Intel® Xeon® Platinum 8370C (Ice Lake), AMD EPYC 7763v (Milan) - Provisioning di un massimo di 80 vCore (con hyperthreading)	- 10,2 GB per vCore

¹ Nella DMV sys.dm_user_db_resource_governance , la generazione hardware per i database che usano processori Intel® SP-8160 (Skylake) viene visualizzata come Gen6, la generazione hardware per i database che usano Intel® 8272CL (Cascade Lake) viene visualizzata come Gen7 e la generazione hardware per i database che usano Intel® Xeon® Platinum 8370C (Ice Lake) o AMD® EPYC® 7763v (Milano) viene visualizzata come Gen8. Per una determinata configurazione hardware e determinate dimensioni di calcolo, i limiti delle risorse sono uguali indipendentemente dal tipo di CPU. Per ulteriori informazioni, vedere i limiti delle risorse per database singoli e pool elastici.

Serverless è supportato solo nell'hardware della serie Standard (Gen5).

Architettura con funzioni distribuite

Hyperscale separa il motore di elaborazione delle query dai componenti che forniscono archiviazione e durabilità a lungo termine per i dati. Questa architettura consente di dimensionare in modo uniforme la capacità di archiviazione per quanto necessario (l'obiettivo iniziale è 100 TB) e di dimensionare rapidamente le risorse di calcolo.

Il diagramma seguente illustra l'architettura funzionale di Hyperscale:

Ulteriori informazioni sull'architettura funzionale distribuita di Hyperscale.

Vantaggi di scalabilità e prestazioni

Con la possibilità di accelerare/diminuore la velocità dei nodi di calcolo di sola lettura aggiuntivi, l'architettura Hyperscale offre significative funzionalità di scalabilità di lettura e consente inoltre di liberare il nodo di calcolo primario per la gestione di più richieste di scrittura. Inoltre, i nodi di calcolo possono essere aumentati o diminuiti rapidamente grazie all'architettura di archiviazione condivisa dell'architettura Hyperscale. I nodi di calcolo di sola lettura in Hyperscale sono disponibili anche nel livello di elaborazione serverless, che dimensiona automaticamente le risorse di calcolo in base alla domanda del carico di lavoro.

Creare e gestire database Hyperscale

È possibile creare e gestire database Hyperscale con il portale di Azure, Transact-SQL, PowerShell e l'interfaccia della riga di comando di Azure. Per ulteriori informazioni, vedi Guida introduttiva: Creare un database Hyperscale.

Operazione	Dettagli	Ulteriori informazioni
Creare un database Hyperscale	I database Hyperscale sono disponibili solo con il modello di acquisto basato su vCore.	Trova esempi per creare un database Hyperscale in Guida introduttiva: Creare un database Hyperscale in database SQL di Azure.
Aggiornare un database esistente a Hyperscale	La migrazione di un database esistente in database SQL di Azure al livello Hyperscale è una dimensione delle operazioni dei dati.	Informazioni su come eseguire la migrazione di un database esistente a Hyperscale.
Invertire la migrazione di un database Hyperscale al livello di servizio Per utilizzo generico	Se in precedenza è stata eseguita la migrazione di un database SQL di Azure esistente al livello di servizio Hyperscale, è possibile invertire la migrazione del database al livello di servizio Per utilizzo generico entro 45 giorni dalla migrazione originale a Hyperscale. Se si vuole eseguire la migrazione del database a un altro livello di servizio, ad esempio Business Critical, bisogna prima invertire la migrazione al livello di servizioPper utilizzo generico e poi modificare il livello di servizio.	Informazioni su come invertire la migrazione da Hyperscale e limitazioni per l'inversione della migrazione.

Disponibilità elevata del database in Hyperscale

Come in tutti gli altri livelli di servizio, Hyperscale garantisce la durabilità dei dati per le transazioni di cui è stato eseguito il commit indipendentemente dalla disponibilità della replica di calcolo. L'entità del tempo inattivo dovuto alla mancata disponibilità della replica primaria dipende dal tipo di failover (pianificato o non pianificato), dall'eventuale configurazione della ridondanza della zona e dalla presenza di almeno una replica a disponibilità elevata. In un failover pianificato (ad esempio, un evento di manutenzione), il sistema crea la nuova replica primaria prima di avviare un failover oppure usa una replica a disponibilità elevata esistente come destinazione di failover. In un failover non pianificato (ad esempio un errore hardware nella replica primaria), il sistema usa una replica a disponibilità elevata come destinazione di failover, se presente, o crea una nuova replica primaria dal pool di capacità di calcolo disponibile. In quest'ultimo caso, la durata del tempo inattivo è maggiore a causa di passaggi aggiuntivi necessari per creare la nuova replica primaria.

È possibile scegliere una finestra di manutenzione che consente di rendere prevedibili e meno problematici gli eventi di manutenzione con impatto sul carico di lavoro.

Per il contratto di servizio Hyperscale, vedi Contratto di servizio per database SQL di Azure.

Backup e ripristino

Le operazioni di backup e ripristino per i database Hyperscale sono basate su snapshot di file. In questo modo, queste operazioni possono essere quasi istantanee. Poiché l'architettura Hyperscale usa il livello di archiviazione per backup e ripristino, il carico di elaborazione e l'impatto sulle prestazioni per le repliche di calcolo sono ridotti. Ulteriori informazioni sono disponibili in Backup Hyperscale e ridondanza dell'archiviazione.

Ripristino di emergenza per i database Hyperscale

Se devi ripristinare un database Hyperscale in database SQL di Azure in un'area diversa da quella attualmente ospitata in, come parte di un'operazione di ripristino di emergenza o di drill-down, una rilocazione o qualsiasi altro motivo, il metodo primario consiste nell'eseguire un ripristino geografico del database. Il ripristino geografico è disponibile solo quando viene scelta l'archiviazione con ridondanza geografica (RA-GRS) per la ridondanza dell'archiviazione.

Ulteriori informazioni sul ripristino di un database Hyperscale in un'area diversa.

Compatta

Le operazioni di compattazione di database e file sono attualmente in anteprima per database SQL di Azure Hyperscale. Per altre informazioni sull’anteprima, vedere Compattazione per Database SQL di Azure Hyperscale.

Limitazioni note

Queste sono le limitazioni correnti del livello di servizio Hyperscale. Stiamo lavorando attivamente per rimuovere il maggior numero possibile di queste limitazioni.

Problema	Descrizione
La compattazione viene bloccata quando TDE è disabilitato	Attualmente, le operazioni di compattazione di database e file non sono supportate quando Transparent Data Encryption (TDE) è disabilitato in database SQL di Azure Hyperscale.
Ripristinare il database da altri livelli di servizio	Non è possibile ripristinare un database non Hyperscale come database Hyperscale né un database Hyperscale come database non Hyperscale. Per i database migrati a Hyperscale da altri livelli di servizio database SQL di Azure, i backup di pre-migrazione vengono mantenuti per la durata del periodo di conservazione dei backup del database di origine, inclusi i criteri di conservazione a lungo termine. Il ripristino di un backup di pre-migrazione entro il periodo di conservazione dei backup del database è supportato tramite la riga di comando. È possibile ripristinare questi backup in qualsiasi livello di servizio non Hyperscale.
Migrazione di database con oggetti OLTP in memoria	Hyperscale supporta un sottoinsieme di oggetti OLTP in memoria, inclusi i tipi di tabella ottimizzata per la memoria, le variabili di tabella e i moduli compilati in modo nativo. Tuttavia, quando tutti gli oggetti OLTP in memoria sono presenti nel database di cui viene eseguita la migrazione, la migrazione dai livelli di servizio Premium e Business Critical a Hyperscale non è supportata. Per eseguire la migrazione di tale database a Hyperscale, è necessario eliminare tutti gli oggetti OLTP in memoria e le relative dipendenze. Dopo la migrazione del database, questi oggetti possono essere ricreati. Le tabelle ottimizzate per la memoria durevoli e non durevoli non sono attualmente supportate in Hyperscale e devono essere modificate in tabelle del disco.
Controllo integrità del database	DBCC CHECKDB non è attualmente supportato per i database Hyperscale. È possibile usare DBCC CHECKTABLE ('TableName') WITH TABLOCK e DBCC CHECKFILEGROUP WITH TABLOCK come soluzione alternativa. Per ulteriori informazioni sulla gestione dell'integrità dei dati nel database SQL di Azure, vedi Data Integrity in Azure SQL Database (Integrità dei dati nel database SQL di Azure).
Processi elastici	L'uso di un database Hyperscale come database di lavoro non è supportato. Tuttavia, i lavori elastici possono avere come destinazione i database Hyperscale come qualsiasi altro database SQL di Azure.
Sincronizzazione dei dati	L'uso di un database Hyperscale come database dei metadati di sincronizzazione o dell'hub non è supportato. Tuttavia, un database Hyperscale può essere un database membro in una topologia di sincronizzazione dati.
Hardware della serie Premium del livello di servizio Hyperscale	L'hardware della serie Premium e della serie Premium ottimizzata per la memoria attualmente non supporta il livello di elaborazione serverless.
Disponibilità a livello di area	L'hardware ottimizzato per la memoria e la serie Premium del livello di servizio Hyperscale sono disponibili in aree di Azure limitate. Per un elenco, vedi Disponibilità della serie Premium Hyperscale.

Contenuto correlato

• Domande frequenti su Hyperscale
• Confrontare i modelli di acquisto basati su vCore e DTU di Azure SQL Database
• Gestione di risorse nel database SQL di Azure
• Limiti di risorse per i database singoli usando il modello di acquisto vCore
• Confronto tra funzionalità: database SQL di Azure e Istanza gestita di SQL di Azure
• Architettura delle funzioni distribuite Hyperscale
• Come gestire un database Hyperscale