Priorità delle query - Amazon Redshift

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Priorità delle query

Non tutte le query hanno la stessa importanza; spesso le prestazioni di un carico di lavoro o di un set di utenti possono essere più importanti. Se hai abilitato l'opzione automatica WLM, puoi definire l'importanza relativa delle query in un carico di lavoro impostando un valore di priorità. La priorità viene specificata per una coda e la ereditano tutte le query associate alla coda. Le query vengono associate a una coda mappando gruppi di utenti e gruppi di query alla coda. Puoi impostare le seguenti priorità (elencate da quella più alta a quella più bassa):

  1. HIGHEST

  2. HIGH

  3. NORMAL

  4. LOW

  5. LOWEST

Gli amministratori utilizzano queste priorità per illustrare l'importanza relativa dei carichi di lavoro quando query con priorità diverse si contendono le stesse risorse. Amazon Redshift utilizza la priorità quando lascia query nel sistema e per determinare la quantità di risorse allocate a una query. Per impostazione predefinita, le query vengono eseguite con priorità impostata su NORMAL.

Una priorità aggiuntiva, CRITICAL, superiore a HIGHEST, è disponibile per gli utenti con privilegi avanzati. Per impostare questa priorità, puoi utilizzare le funzioni CHANGE_QUERY_PRIORITY, CHANGE_SESSION_PRIORITY e CHANGE_USER_PRIORITY. Per concedere a un utente di database l'autorizzazione per l'uso di queste funzioni, puoi creare una procedura archiviata e concedere l'autorizzazione a un utente. Per un esempio, consultare CHANGE_SESSION_PRIORITY.

Nota

Si può eseguire solo una query CRITICAL alla volta.

Facciamo un esempio in cui la priorità di un carico di lavoro extract, transform, load (ETL) è superiore alla priorità del carico di lavoro di analisi. Il ETL carico di lavoro viene eseguito ogni sei ore e il carico di lavoro di analisi viene eseguito nell'arco della giornata. Quando solo il carico di lavoro analitico è in esecuzione sul cluster, attira tutte le risorse su di sé, ottenendo un elevato throughput e un utilizzo ottimale del sistema. Tuttavia, quando il ETL carico di lavoro inizia, prende il sopravvento perché ha una priorità più alta. Le interrogazioni eseguite come parte del ETL carico di lavoro hanno la priorità durante l'ammissione e anche l'allocazione preferenziale delle risorse dopo l'ammissione. Di conseguenza, il ETL carico di lavoro funziona in modo prevedibile indipendentemente da cos'altro potrebbe essere in esecuzione sul sistema. Pertanto, offre prestazioni prevedibili e la possibilità per gli amministratori di fornire accordi sui livelli di servizio (SLAs) per i propri utenti aziendali.

All'interno di un determinato cluster, le prestazioni prevedibili di un carico di lavoro con priorità superiori vanno a scapito di altri carichi di lavoro con priorità minori. L'esecuzione dei carichi di lavoro con priorità inferiori può durare più a lungo perché le loro query attendono il completamento di query più importanti. O perché ricevono una frazione più piccola di risorse quando vengono eseguite simultaneamente a query con priorità maggiore. Le query con priorità minore non soffrono un uso eccessivo delle risorse, ma progrediscono a un ritmo più lento.

Nell'esempio precedente, l'amministratore può abilitare il dimensionamento della simultaneità per il carico di lavoro analitico. In questo modo il carico di lavoro può mantenere la velocità effettiva, anche se il ETL carico di lavoro viene eseguito con priorità elevata.

Configurazione della priorità di coda

Se hai abilitato la modalità automaticaWLM, ogni coda ha un valore di priorità. Le query vengono instradata in base ai gruppi di utenti e ai gruppi di query. Iniziare con una priorità della coda impostata su NORMAL. Imposta la priorità come maggiore o minore in base al carico di lavoro associato ai gruppi di utenti e ai gruppi di query della coda.

È possibile modificare la priorità di una coda nella console Amazon Redshift. Nella console Amazon Redshift, la pagina Gestione del carico di lavoro visualizza le code e permette la modifica delle proprietà come Priorità. Per impostare la priorità utilizzando le API operazioni CLI o, utilizzate il wlm_json_configuration parametro. Per informazioni, consulta Configurazione della gestione del carico di lavoro nella Guida alla gestione di Amazon Redshift.

Il seguente esempio wlm_json_configuration definisce tre gruppi di utenti (ingest, reporting e analytics). Le query inviate dagli utenti di uno di questi gruppi vengono eseguite rispettivamente con priorità highest, normal e low.

[ { "user_group": [ "ingest" ], "priority": "highest", "queue_type": "auto" }, { "user_group": [ "reporting" ], "priority": "normal", "queue_type": "auto" }, { "user_group": [ "analytics" ], "priority": "low", "queue_type": "auto", "auto_wlm": true } ]

Modifica della priorità delle query con le regole di monitoraggio delle query

Le regole di monitoraggio delle query (QMR) consentono di modificare la priorità di una query in base al suo comportamento durante l'esecuzione. A tale scopo, oltre a un'azione, è necessario specificare l'attributo priority in un QMR predicato. Per ulteriori informazioni, consulta WLMregole di monitoraggio delle interrogazioni.

Ad esempio, puoi definire una regola per annullare tutte le query classificate con priorità high che vengono eseguite per più di 10 minuti.

"rules" :[ { "rule_name":"rule_abort", "predicate":[ { "metric_name":"query_cpu_time", "operator":">", "value":600 }, { "metric_name":"query_priority", "operator":"=", "value":"high" } ], "action":"abort" } ]

Un altro esempio è quello di definite una regola che modifica la priorità in lowest per tutte le query con priorità attuale normal che riversano su disco più di 1 TB.

"rules":[ { "rule_name":"rule_change_priority", "predicate":[ { "metric_name":"query_temp_blocks_to_disk", "operator":">", "value":1000000 }, { "metric_name":"query_priority", "operator":"=", "value":"normal" } ], "action":"change_query_priority", "value":"lowest" } ]

Monitoraggio della priorità delle query

Per visualizzare la priorità delle query in esecuzione e in attesa, osserva la colonna query_priority nella tabella di sistema stv_wlm_query_state.

query | service_cl | wlm_start_time | state | queue_time | query_priority ---------+------------+----------------------------+------------------+------------+---------------- 2673299 | 102 | 2019-06-24 17:35:38.866356 | QueuedWaiting | 265116 | Highest 2673236 | 101 | 2019-06-24 17:35:33.313854 | Running | 0 | Highest 2673265 | 102 | 2019-06-24 17:35:33.523332 | Running | 0 | High 2673284 | 102 | 2019-06-24 17:35:38.477366 | Running | 0 | Highest 2673288 | 102 | 2019-06-24 17:35:38.621819 | Running | 0 | Highest 2673310 | 103 | 2019-06-24 17:35:39.068513 | QueuedWaiting | 62970 | High 2673303 | 102 | 2019-06-24 17:35:38.968921 | QueuedWaiting | 162560 | Normal 2673306 | 104 | 2019-06-24 17:35:39.002733 | QueuedWaiting | 128691 | Lowest

Per un elenco della priorità delle query completate, visualizza la colonna query_priority nella tabella di sistema stl_wlm_query.

select query, service_class as svclass, service_class_start_time as starttime, query_priority from stl_wlm_query order by 3 desc limit 10;
query | svclass | starttime | query_priority ---------+---------+----------------------------+---------------------- 2723254 | 100 | 2019-06-24 18:14:50.780094 | Normal 2723251 | 102 | 2019-06-24 18:14:50.749961 | Highest 2723246 | 102 | 2019-06-24 18:14:50.725275 | Highest 2723244 | 103 | 2019-06-24 18:14:50.719241 | High 2723243 | 101 | 2019-06-24 18:14:50.699325 | Low 2723242 | 102 | 2019-06-24 18:14:50.692573 | Highest 2723239 | 101 | 2019-06-24 18:14:50.668535 | Low 2723237 | 102 | 2019-06-24 18:14:50.661918 | Highest 2723236 | 102 | 2019-06-24 18:14:50.643636 | Highest

Per ottimizzare la velocità effettiva del carico di lavoro, Amazon Redshift potrebbe modificare la priorità delle query inviate dall'utente. Amazon Redshift utilizza algoritmi avanzati di machine learning per determinare quando questa ottimizzazione avvantaggia il carico di lavoro e la applica automaticamente quando vengono soddisfatte tutte le seguenti condizioni.

  • L'opzione Automatica WLM è abilitata.

  • È definita una sola WLM coda.

  • Non sono state definite regole di monitoraggio delle interrogazioni (QMRs) che impostino la priorità delle interrogazioni. Tali regole includono la QMR metrica query_priority o l'QMRazionechange_query_priority. Per ulteriori informazioni, consulta WLMregole di monitoraggio delle interrogazioni.