Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Abfragepriorität
Nicht alle Abfragen sind gleich wichtig und häufig ist die Leistung eines bestimmten Workloads oder Benutzersatzes von höherer Wichtigkeit. Wenn Sie automatisches WLM aktiviert haben, können Sie die relative Wichtigkeit der Abfragen in einem Workload definieren, indem Sie einen Prioritätswert festlegen. Die Priorität wird für eine Warteschlange angegeben und von allen Abfragen geerbt, die mit der Warteschlange verknüpft sind. Sie verknüpfen Abfragen mit einer Warteschlange, indem Sie der Warteschlange Benutzer- und Abfragegruppen zuordnen. Sie können die folgenden Prioritäten festlegen (von höchster zu niedrigster Priorität):
HIGHESTHIGHNORMALLOWLOWEST
Administratoren verwenden diese Prioritäten, um die relative Wichtigkeit von Workloads anzugeben, wenn es Abfragen mit unterschiedlicher Priorität gibt, die dieselben Ressourcen benötigen. Amazon Redshift verwendet die Priorität bei der Annahme von Abfragen für das System und zur Festlegung der Menge der Ressourcen, die einer Abfrage zugeordnet werden. Standardmäßig wird die Priorität von Abfragen auf festgelegt NORMAL.
Für Superuser ist zusätzlich die Priorität CRITICAL verfügbar. Diese Priorität hat einen höheren Rang als HIGHEST. Um diese Priorität festzulegen, können Sie die Funktionen CHANGE_QUERY_PRIORITY, CHANGE_SESSION_PRIORITY und CHANGE_USER_PRIORITY verwenden. Um einem Datenbankbenutzer die Berechtigung zur Nutzung dieser Funktionen zu erteilen, können Sie eine gespeicherte Prozedur erstellen und diesem Benutzer die entsprechende Berechtigung erteilen. Ein Beispiel finden Sie unter CHANGE_SESSION_PRIORITY.
Anmerkung
Es kann jeweils nur eine Abfrage mit der Priorität CRITICAL ausgeführt werden.
Betrachten wir ein Beispiel, in dem ein Workload zum Extrahieren, Transformieren und Laden (Extract, Transform, Load; ETL) eine höhere Priorität als der Analytics-Workload hat. Der ETL-Workload wird alle sechs Stunden ausgeführt. Der Analytics-Workload wird während des gesamten Tages ausgeführt. Wenn nur der Analytics-Workload für das Cluster ausgeführt wird, kann er das gesamte System nutzen und einen hohen Durchsatz bei optimaler Systemnutzung erzielen. Wenn jedoch der ETL-Workload gestartet wird, erhält dieser Priorität, da er eine höhere Priorität hat. Abfragen, die als Teil des ETL-Workloads ausgeführt werden, erhalten Priorität bei der Annahme. Nach der Annahme werden ihnen die Ressourcen bevorzugt zugeteilt. Daher wird der ETL-Workload planbar ausgeführt, unabhängig davon, welche weiteren Aufgaben im System ausgeführt werden. Auf diese Weise wird eine planbare Leistung bereitgestellt und die Administratoren können geschäftlichen Benutzern Service Level Agreements (SLAs) bereitstellen.
Innerhalb des jeweiligen Clusters geht die planbare Leistung eines Workloads mit hoher Priorität zu Lasten anderer Workloads mit einer niedrigeren Priorität. Workloads mit einer niedrigeren Priorität benötigen für die Ausführung möglicherweise mehr Zeit, da ihre Abfragen warten, bis wichtigere Abfragen abgeschlossen sind. Ein anderer Grund für die längere Ausführungszeit kann darin bestehen, dass sie einen kleineren Anteil an den Ressourcen erhalten, wenn sie gleichzeitig mit Abfragen höherer Priorität ausgeführt werden. Abfragen mit einer niedrigeren Priorität werden jedoch nicht angehalten, sondern lediglich langsamer ausgeführt.
Im vorherigen Beispiel kann der Administrator für den Analytics-Workload die Nebenläufigkeitsskalierung aktivieren. Hierdurch kann dieser Workload seinen Durchsatz bewahren, auch wenn der ETL-Workload mit höherer Priorität ausgeführt wird.
Konfigurieren der Warteschlangenpriorität
Wenn Sie automatisches WLM aktiviert haben, besitzt jede Warteschlange einen Prioritätswert. Abfragen werden auf der Grundlage von Benutzer- und Abfragegruppen an Warteschlangen geleitet. Beginnen Sie mit der Warteschlangenpriorität NORMAL. Sie können eine höhere oder niedrigere Priorität festlegen, abhängig von dem Workload, der mit den Benutzer- und Abfragegruppen des Workloads verknüpft ist.
Sie können die Priorität einer Warteschlange in der Amazon-Redshift-Konsole ändern. Sie können in der Amazon-Redshift-Konsole auf der Seite Workload Management (Workload-Verwaltung) die Warteschlangen anzeigen und Warteschlangeneigenschaften wie Priority (Priorität) bearbeiten. Um die Priorität über die CLI oder API-Operationen festzulegen, verwenden Sie den Parameter wlm_json_configuration. Weitere Informationen finden Sie unter Workload-Management-Konfiguration im Amazon-Redshift-Verwaltungshandbuch.
Im folgenden wlm_json_configuration-Beispiel werden drei Benutzergruppen definiert (ingest, reporting und analytics). Die Abfragen, die von den Benutzern dieser Gruppen übermittelt werden, werden jeweils mit den Prioritäten highest, normal und low ausgeführt.
[ { "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 } ]
Ändern der Abfragepriorität mittels Abfrageüberwachungsregeln
Abfrageüberwachungsregeln (Query Monitoring Rules, QMR) ermöglichen Ihnen die Änderung der Priorität einer Abfrage basierend auf ihrem Verhalten während der Ausführung. Hierzu geben Sie zusätzlich zu einer Aktion das Prioritätsattribut in einem QMR-Prädikat an. Weitere Informationen finden Sie unter WLM-Abfrageüberwachungsregeln.
Sie können beispielsweise eine Regel definieren, nach der Abfragen mit der Priorität high abgebrochen werden, wenn sie länger als 10 Minuten ausgeführt werden.
"rules" :[ { "rule_name":"rule_abort", "predicate":[ { "metric_name":"query_cpu_time", "operator":">", "value":600 }, { "metric_name":"query_priority", "operator":"=", "value":"high" } ], "action":"abort" } ]
Sie können auch eine Regel definieren, nach der die Priorität aller Abfragen mit der Priorität lowest in normal geändert wird, wenn sie mehr als 1 TB auf der Festplatte belegen.
"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" } ]
Konfigurieren der Abfragepriorität
Um die Priorität für wartende und ausgeführte Abfragen anzuzeigen, zeigen Sie die Spalte query_priority in der Systemtabelle „stv_wlm_query_state“ an.
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
Um die Abfragepriorität abgeschlossener Abfragen anzuzeigen, zeigen Sie die Spalte query_priority in der Systemtabelle „stl_wlm_query“ an.
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
Um den Durchsatz Ihres Workloads zu optimieren, kann Amazon Redshift die Priorität der von Benutzern übermittelten Abfragen ändern. Amazon Redshift verwendet fortschrittliche Machine-Learning-Algorithmen, um zu ermitteln, wann diese Optimierung Ihrem Workload zugutekommt, und wendet sie automatisch an, wenn alle folgenden Bedingungen erfüllt sind.
Automatisches WLM ist aktiviert.
Es ist nur eine WLM-Warteschlange definiert.
Sie haben keine Abfrageüberwachungsregeln (Query Monitoring Rules, QMRS) definiert, die die Abfragepriorität festlegen. Dazu gehören zum Beispiel die QMR-Metrik
query_priorityoder die QMR-Aktionchange_query_priority. Weitere Informationen finden Sie unter WLM-Abfrageüberwachungsregeln.
