Condividi tramite

Ottimizzare la concorrenza elevata con Azure Esplora dati

  • Articolo

Le applicazioni altamente simultanee sono necessarie in scenari con una grande base utente, in cui l'applicazione gestisce simultaneamente molte richieste con bassa latenza e velocità effettiva elevata.

I casi d'uso includono dashboard di monitoraggio e avvisi su larga scala. Alcuni esempi includono prodotti e servizi Microsoft, ad esempio Monitoraggio di Azure, Azure Time Series Insights e Playfab. Tutti questi servizi usano Azure Esplora dati per la gestione di carichi di lavoro di concorrenza elevata. Azure Esplora dati è un servizio di analisi Big Data veloce e completamente gestito per l'analisi in tempo reale su grandi volumi di streaming di dati da applicazioni, siti Web, dispositivi IoT e altro ancora.

Nota

Il numero effettivo di query che possono essere eseguite simultaneamente in un cluster dipende da fattori come SKU del cluster, volumi di dati, complessità di query e modelli di utilizzo.

Per configurare le applicazioni con concorrenza elevata, progettare l'architettura back-end come indicato di seguito:

Questo articolo presenta raccomandazioni per ognuno dei soggetti precedenti che è possibile implementare per ottenere una concorrenza elevata in modo ottimale e conveniente. Queste funzionalità possono essere usate da soli o in combinazione.

Ottimizzare i dati

Per una concorrenza elevata, le query devono utilizzare la quantità minima possibile di risorse CPU. È possibile usare uno o tutti i metodi seguenti:

Usare le procedure consigliate per la progettazione dello schema di tabella

Usare i suggerimenti di progettazione dello schema di tabella seguenti per ridurre al minimo le risorse della CPU usate:

  • Le colonne ID devono essere definite come tipi di dati stringa indipendentemente dal fatto che i valori siano numerici. L'indicizzazione per le colonne di stringa è più sofisticata rispetto alle colonne numeriche e offre prestazioni di filtro migliori.
  • Corrisponde al tipo di dati della colonna in modo ottimale ai dati effettivi archiviati in queste colonne. Ad esempio, non archiviare i valori datetime in una colonna stringa.
  • Evitare una tabella sparse di grandi dimensioni con molte colonne e usare colonne dinamiche per archiviare le proprietà sparse.
  • Archiviare le proprietà usate di frequente nella propria colonna con un tipo di dati non dinamico.
  • Denormalizzare i dati per evitare join che richiedono risorse CPU relativamente grandi.

Dati di partizione

I dati vengono archiviati sotto forma di extent (partizioni di dati) e vengono partizionati in base al tempo di inserimento per impostazione predefinita. È possibile usare i criteri di partizionamento per suddividere gli extent in base a una singola colonna stringa o a una singola colonna datetime in un processo in background. Il partizionamento può offrire miglioramenti significativi delle prestazioni quando la maggior parte delle query usa chiavi di partizione per filtrare, aggregare o entrambi.

Nota

Il processo di partizionamento stesso usa le risorse della CPU. Tuttavia, la riduzione della CPU durante il tempo di query deve superare la CPU usata per il partizionamento.

Pre-aggregare i dati con viste materializzate

Pre-aggregare i dati per ridurre significativamente le risorse della CPU durante il tempo di query. Gli scenari di esempio includono il riepilogo dei punti dati su un numero ridotto di contenitori di tempo, mantenendo il record più recente di un determinato record o deduplicando il set di dati. Usare viste materializzate per una visualizzazione aggregata facile da configurare nelle tabelle di origine. Questa funzionalità semplifica lo sforzo di creazione e gestione di queste visualizzazioni aggregate.

Nota

Il processo di aggregazione in background usa le risorse della CPU. Tuttavia, la riduzione della CPU durante il tempo di query deve superare il consumo di CPU per l'aggregazione.

Configurare i criteri di memorizzazione nella cache

Configurare i criteri di memorizzazione nella cache in modo che le query vengano eseguite sui dati archiviati nell'archiviazione ad accesso frequente, nota anche come cache del disco. Vengono eseguiti solo scenari limitati e progettati attentamente nelle tabelle di archiviazione a freddo o esterne.

Impostare un modello di architettura leader-follower

Il database follower è una funzionalità che segue un database o un set di tabelle in un database da un altro cluster che si trova nella stessa area. Questa funzionalità viene esposta tramite Azure Condivisione dati, LE API di Azure Resource Manager e un set di comandi del cluster.

Usare il modello leader-follower per impostare le risorse di calcolo per carichi di lavoro diversi. Ad esempio, configurare un cluster per l'inserimento, un cluster per eseguire query o gestire dashboard o applicazioni e un cluster che gestisce i carichi di lavoro di data science. Ogni carico di lavoro in questo caso avrà risorse di calcolo dedicate che possono essere ridimensionate in modo indipendente e configurazioni di memorizzazione nella cache e sicurezza diverse. Tutti i cluster usano gli stessi dati, con il leader che scrive i dati e i follower che lo usano in modalità di sola lettura.

Nota

I database di follower hanno un ritardo dal leader, in genere di pochi secondi. Se la soluzione richiede i dati più recenti senza latenza, questa soluzione potrebbe essere utile. Usare una vista sul cluster di follower che unione i dati del leader e del follower e esegue query sui dati più recenti del leader e sul resto dei dati del follower.

Per migliorare le prestazioni delle query nel cluster follower, è possibile abilitare la configurazione degli extent di prefetch. Usare attentamente questa configurazione, perché potrebbe influire sulla freschezza dei dati nel database follower.

Ottimizzare le query

Usare i metodi seguenti per ottimizzare le query per una concorrenza elevata.

Seguire le procedure consigliate per le query in modo che le query siano più efficienti possibile.

Usare una cache dei risultati della query

Quando più utenti caricano lo stesso dashboard in un momento simile, il dashboard al secondo e gli utenti seguenti possono essere serviti dalla cache. Questa configurazione offre prestazioni elevate con quasi nessun utilizzo della CPU. Usare la funzionalità cache dei risultati della query e inviare la configurazione della cache dei risultati delle query con la query usando l'istruzione set .

Grafana contiene un'impostazione di configurazione per la cache dei risultati della query a livello di origine dati, quindi tutti i dashboard usano questa impostazione per impostazione predefinita e non devono modificare la query.

Configurare la coerenza delle query

La modalità di coerenza della query predefinita è complessa. In questa modalità, un nodo amministratore gestisce i metadati e l'inserimento per il cluster, nonché la pianificazione delle query e delega l'esecuzione ad altri nodi.

Nelle applicazioni ad alta concorrenza, la gestione delle query può causare un utilizzo elevato della CPU del nodo di amministrazione , mentre altri nodi sono meno occupati. Ciò può causare un collo di bottiglia in cui il numero di query simultanee non può aumentare. Tuttavia, questo potrebbe non essere evidente nel report della CPU del cluster (portale di Azure {your_cluster > } > Metrics CPU Metrics>, che mostra l'uso medio della CPU per il cluster.

Per questo scenario è consigliabile usare la modalità coerenza debole . In questa modalità, più nodi sono in grado di gestire le query, che consente di ridimensionare orizzontalmente il numero di query simultanee. I nodi in questa modalità aggiornano periodicamente la copia dei metadati e i dati appena inseriti, che comportano una latenza di in genere inferiore a un minuto quando i dati vengono sincronizzati. Tuttavia, questa breve latenza è preferibile alla situazione del collo di bottiglia che può verificarsi quando si usa una modalità di coerenza elevata .

È possibile impostare la modalità coerenza in un criterio di coerenza del gruppo di carico di lavoro, nelle proprietà della richiesta client o nella configurazione dell'origine dati Grafana.

Impostare i criteri del cluster

Il numero di richieste simultanee viene limitato per impostazione predefinita e controllato dai criteri di limite di frequenza richiesta in modo che il cluster non venga sottoposto a overload. È possibile modificare questo criterio per situazioni di concorrenza elevata. Questo criterio deve essere modificato solo dopo un test rigoroso, preferibilmente su modelli di utilizzo e set di dati di produzione. Il test garantisce che il cluster possa sostenere il valore modificato. Questo limite può essere configurato in base alle esigenze dell'applicazione.

Monitorare i cluster di Azure Esplora dati

Il monitoraggio dell'integrità delle risorse del cluster consente di creare un piano di ottimizzazione usando le funzionalità suggerite nelle sezioni precedenti. Monitoraggio di Azure per Azure Esplora dati offre una panoramica completa delle prestazioni, delle operazioni, delle operazioni, dell'utilizzo e degli errori del cluster. Ottenere informazioni dettagliate sulle prestazioni delle query, query simultanee, query limitate e varie altre metriche selezionando la scheda Insights (anteprima) nella sezione Monitoraggio del cluster di Azure Esplora dati nel portale di Azure.

Per informazioni sui cluster di monitoraggio, vedere Monitoraggio di Azure per Azure Esplora dati. Per informazioni sulle singole metriche, vedere Metriche di Azure Esplora dati.