

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.

# CloudTrail Lake-Abfragen optimieren
<a name="lake-queries-optimization"></a>

Diese Seite enthält Anleitungen zur Optimierung von CloudTrail Lake-Abfragen, um Leistung und Zuverlässigkeit zu verbessern. Es behandelt spezifische Optimierungstechniken sowie Problemumgehungen für häufig auftretende Abfragefehler.

**Topics**
+ [Empfehlungen zur Optimierung von Abfragen](#lake-queries-tuning)
+ [Behelfslösungen für Abfragefehler](#lake-queries-troubleshooting)

## Empfehlungen zur Optimierung von Abfragen
<a name="lake-queries-tuning"></a>

Folgen Sie den Empfehlungen in diesem Abschnitt, um Ihre Abfragen zu optimieren.

**Topics**
+ [Aggregationen optimieren](#query-optimization-aggregation)
+ [Verwenden Sie Näherungstechniken](#query-optimization-approximation)
+ [Beschränken Sie die Abfrageergebnisse](#query-optimization-limit)
+ [Optimieren Sie LIKE-Abfragen](#query-optimization-like)
+ [Verwenden Sie `UNION ALL` anstelle von `UNION`.](#query-optimization-union)
+ [Nur die erforderlichen Spalten einschließen](#query-optimization-reqcolumns)
+ [Reduzieren Sie den Funktionsumfang von Fenstern](#query-optimization-windows)

### Aggregationen optimieren
<a name="query-optimization-aggregation"></a>

Das Ausschließen redundanter Spalten in `GROUP BY` Klauseln kann die Leistung verbessern, da weniger Spalten weniger Speicher benötigen. In der folgenden Abfrage können wir die `arbitrary` Funktion beispielsweise für eine redundante Spalte verwenden, um die Leistung `eventType` zu verbessern. Die `arbitrary` Funktion on `eventType` wird verwendet, um den Feldwert nach dem Zufallsprinzip aus der Gruppe auszuwählen, da der Wert derselbe ist und nicht in der `GROUP BY` Klausel enthalten sein muss.

```
SELECT eventName, eventSource, arbitrary(eventType), count(*) 
FROM $EDS_ID 
GROUP BY eventName, eventSource
```

Es ist möglich, die Leistung der `GROUP BY` Funktion zu verbessern, indem die Liste der Felder innerhalb der Felder `GROUP BY` in absteigender Reihenfolge ihrer Einzelwertanzahl (Kardinalität) angeordnet wird. Wenn beispielsweise die Anzahl der Ereignisse eines Typs in jedem Objekt ermittelt wird AWS-Region, kann die Leistung verbessert werden`eventName`, indem die `awsRegion` Reihenfolge in der `GROUP BY` Funktion anstelle von verwendet wird`awsRegion`, `eventName` da es mehr Einzelwerte von `eventName` als von gibt. `awsRegion`

```
SELECT eventName, awsRegion, count(*) 
FROM $EDS_ID 
GROUP BY eventName, awsRegion
```

### Verwenden Sie Näherungstechniken
<a name="query-optimization-approximation"></a>

Wenn exakte Werte nicht benötigt werden, um unterschiedliche Werte zu zählen, verwenden Sie [ungefähre Aggregatfunktionen](https://trino.io/docs/current/functions/aggregate.html#approximate-aggregate-functions), um die häufigsten Werte zu ermitteln. [https://trino.io/docs/current/functions/aggregate.html#approx_distinct](https://trino.io/docs/current/functions/aggregate.html#approx_distinct)Verwendet beispielsweise viel weniger Speicher und läuft schneller als der `COUNT(DISTINCT fieldName)` Vorgang.

### Beschränken Sie die Abfrageergebnisse
<a name="query-optimization-limit"></a>

Wenn für eine Abfrage nur eine Beispielantwort benötigt wird, beschränken Sie die Ergebnisse mithilfe der `LIMIT` Bedingung auf eine kleine Anzahl von Zeilen. Andernfalls gibt die Abfrage umfangreiche Ergebnisse zurück und die Ausführung der Abfrage nimmt mehr Zeit in Anspruch.

Durch die Verwendung von `LIMIT` along with `ORDER BY` können Ergebnisse für die obersten oder untersten N Datensätze schneller bereitgestellt werden, da dadurch der benötigte Speicherplatz und die für die Sortierung benötigte Zeit reduziert werden.

```
SELECT * FROM $EDS_ID
ORDER BY eventTime 
LIMIT 100;
```

### Optimieren Sie LIKE-Abfragen
<a name="query-optimization-like"></a>

Sie können `LIKE` es verwenden, um passende Zeichenketten zu finden, aber bei langen Zeichenketten ist das rechenintensiv. Die [https://trino.io/docs/current/functions/regexp.html#regexp_like](https://trino.io/docs/current/functions/regexp.html#regexp_like)Funktion ist in den meisten Fällen eine schnellere Alternative.

Oft können Sie eine Suche optimieren, indem Sie die gesuchte Teilzeichenfolge verankern. Wenn Sie beispielsweise nach einem Präfix suchen, ist es besser, '%' statt '`substr``substr`%' mit dem `LIKE` Operator und '^' mit der Funktion zu verwenden. `substr` `regexp_like`

### Verwenden Sie `UNION ALL` anstelle von `UNION`.
<a name="query-optimization-union"></a>

`UNION ALL`und `UNION` sind zwei Möglichkeiten, die Ergebnisse von zwei Abfragen zu einem Ergebnis zu kombinieren, dabei aber Duplikate zu entfernen. `UNION` `UNION`muss alle Datensätze verarbeiten und die Duplikate finden, was speicher- und rechenintensiv ist, aber ein relativ schneller Vorgang `UNION ALL` ist. Sofern Sie Datensätze nicht deduplizieren müssen, verwenden Sie `UNION ALL`, um die beste Leistung zu erzielen.

### Nur die erforderlichen Spalten einschließen
<a name="query-optimization-reqcolumns"></a>

Wenn Sie eine Spalte nicht benötigen, nehmen Sie sie nicht in Ihre Abfrage auf. Je weniger Daten eine Abfrage verarbeiten muss, desto schneller wird sie ausgeführt. Wenn Sie Abfragen haben, die `SELECT *` in der äußersten Abfrage vorkommen, sollten Sie `*` die in eine Liste der benötigten Spalten ändern.

Die `ORDER BY`-Klausel gibt die Ergebnisse einer Abfrage in sortierter Reihenfolge zurück. Wenn beim Sortieren größerer Datenmengen der benötigte Speicher nicht verfügbar ist, werden sortierte Zwischenergebnisse auf die Festplatte geschrieben, was die Abfrageausführung verlangsamen kann. Wenn Sie nicht unbedingt möchten, dass Ihr Ergebnis sortiert wird, vermeiden Sie das Hinzufügen einer `ORDER BY`-Klausel. Vermeiden Sie außerdem `ORDER BY` das Hinzufügen zu internen Abfragen, wenn dies nicht unbedingt erforderlich ist. 

### Reduzieren Sie den Funktionsumfang von Fenstern
<a name="query-optimization-windows"></a>

[Fensterfunktionen](https://trino.io/docs/current/functions/window.html) behalten alle Datensätze, mit denen sie arbeiten, im Speicher, um ihr Ergebnis zu berechnen. Wenn das Fenster sehr groß ist, kann der Speicherplatz der Fensterfunktion knapp werden. Um sicherzustellen, dass Abfragen innerhalb der verfügbaren Speichergrenzen ausgeführt werden, reduzieren Sie die Größe der Fenster, in denen Ihre Fensterfunktionen arbeiten, indem Sie eine `PARTITION BY` Klausel hinzufügen.

Manchmal können Abfragen mit Fensterfunktionen ohne Fensterfunktionen neu geschrieben werden. Anstatt `row_number` oder `rank` zu verwenden, können Sie beispielsweise Aggregatfunktionen wie [https://trino.io/docs/current/functions/aggregate.html#max_by](https://trino.io/docs/current/functions/aggregate.html#max_by)oder verwenden [https://trino.io/docs/current/functions/aggregate.html#min_by](https://trino.io/docs/current/functions/aggregate.html#min_by).

Die folgende Abfrage findet den Alias, der den einzelnen KMS-Schlüsseln zuletzt zugewiesen wurde`max_by`.

```
SELECT element_at(requestParameters, 'targetKeyId') as keyId, 
max_by(element_at(requestParameters, 'aliasName'), eventTime) as mostRecentAlias 
FROM $EDS_ID 
WHERE eventsource = 'kms.amazonaws.com' 
AND eventName in ('CreateAlias', 'UpdateAlias') 
AND eventTime > DATE_ADD('week', -1, CURRENT_TIMESTAMP) 
GROUP BY element_at(requestParameters, 'targetKeyId')
```

In diesem Fall gibt die `max_by` Funktion den Alias für den Datensatz mit der letzten Ereigniszeit innerhalb der Gruppe zurück. Diese Abfrage wird schneller ausgeführt und benötigt weniger Speicher als eine entsprechende Abfrage mit einer Fensterfunktion.

## Behelfslösungen für Abfragefehler
<a name="lake-queries-troubleshooting"></a>

In diesem Abschnitt finden Sie Lösungen für häufig auftretende Abfragefehler.

**Topics**
+ [Die Abfrage schlägt fehl, weil die Antwort zu groß ist](#large-responses)
+ [Die Abfrage schlägt aufgrund erschöpfter Ressourcen fehl](#exhausted-resources)

### Die Abfrage schlägt fehl, weil die Antwort zu groß ist
<a name="large-responses"></a>

Eine Abfrage kann fehlschlagen, wenn die Antwort zu umfangreich ist, was zu der Nachricht führt`Query response is too large`. In diesem Fall können Sie den Aggregationsbereich reduzieren.

Aggregationsfunktionen wie `array_agg` können dazu führen, dass mindestens eine Zeile in der Abfrageantwort sehr groß ist, sodass die Abfrage fehlschlägt. Wenn Sie beispielsweise `array_agg(eventName)` anstelle von verwenden, `array_agg(DISTINCT eventName)` wird die Antwortgröße aufgrund doppelter Ereignisnamen aus den ausgewählten CloudTrail Ereignissen erheblich erhöht.

### Die Abfrage schlägt aufgrund erschöpfter Ressourcen fehl
<a name="exhausted-resources"></a>

Wenn während der Ausführung von speicherintensiven Vorgängen wie Verknüpfungen, Aggregationen und Fensterfunktionen nicht genügend Speicher verfügbar ist, werden Zwischenergebnisse auf die Festplatte übertragen, aber ein Datenverlust verlangsamt die Abfrageausführung und kann nicht ausreichen, um zu verhindern, dass die Abfrage fehlschlägt. `Query exhausted resources at this scale factor` Dies kann behoben werden, indem Sie die Abfrage erneut versuchen.

Wenn die oben genannten Fehler auch nach der Optimierung der Abfrage weiterhin bestehen, können Sie den Umfang der Abfrage anhand `eventTime` der Ereignisse einschränken und die Abfrage mehrmals in kleineren Intervallen des ursprünglichen Abfragezeitraums ausführen.