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

Mit Amazon Redshift können Sie die Priorisierung von Abfragen und die Ressourcenzuweisung für gleichzeitige Abfragen und Workloads mithilfe von Workload Management (WM) verwalten. In den folgenden Abschnitten wird beschrieben, wie Sie WM-Abfragewarteschlangen konfigurieren, Warteschlangeneigenschaften wie Speicherzuweisung und Parallelitätsskalierung definieren und Prioritätsregeln implementieren, die auf Ihre Workload-Anforderungen zugeschnitten sind.

Nicht alle Abfragen sind gleich wichtig und häufig ist die Leistung eines bestimmten Workloads oder Benutzersatzes von höherer Wichtigkeit. Wenn Sie „Automatisch“ aktiviert habenWLM, können Sie die relative Bedeutung von 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):

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.

Nehmen wir ein Beispiel, bei dem die Priorität eines Workloads zum Extrahieren, Transformieren, Laden (ETL) höher ist als die Priorität des Analyse-Workloads. Der ETL Workload wird alle sechs Stunden ausgeführt, und der Analytics-Workload läuft den ganzen Tag. 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 der ETL Workload jedoch gestartet wird, wird ihm der Weg gewiesen, da er eine höhere Priorität hat. Abfragen, die im Rahmen der ETL Arbeitslast ausgeführt werden, erhalten bei der Zulassung Vorfahrt und erhalten nach der Zulassung auch bevorzugte Ressourcenzuweisungen. Das hat zur Folge, dass der ETL Workload vorhersehbar ausgeführt wird, unabhängig davon, was sonst noch auf dem System ausgeführt wird. Somit bietet es vorhersehbare Leistung und bietet Administratoren die Möglichkeit, Service Level Agreements (SLAs) für ihre Geschäftsanwender bereitzustellen.

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. Auf diese Weise kann der Workload seinen Durchsatz aufrechterhalten, obwohl der ETL Workload mit hoher Priorität ausgeführt wird.

Konfigurieren der Warteschlangenpriorität

Wenn Sie „Automatisch“ aktiviert habenWLM, hat 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. Verwenden Sie den wlm_json_configuration Parameter, um die Priorität mithilfe der API Operationen CLI oder festzulegen. 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

Mit Regeln zur Abfrageüberwachung (QMR) können Sie die Priorität einer Abfrage auf der Grundlage ihres Verhaltens während der Ausführung ändern. Dazu geben Sie zusätzlich zu einer Aktion das Prioritätsattribut in einem QMR Prädikat an. Weitere Informationen finden Sie unter WLMRegeln für die Abfrageüberwachung.

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.