Optimieren der Abfrageleistung

Amazon QLDB ist darauf ausgelegt, die Anforderungen von Hochleistungs-Workloads bei der Online-Transaktionsverarbeitung (OLTP) zu erfüllen. Das bedeutet, dass QLDB für einen bestimmten Satz von Abfragemustern optimiert ist, obwohl es SQL-ähnliche Abfragefunktionen unterstützt. Es ist wichtig, Anwendungen und ihre Datenmodelle so zu entwerfen, dass sie mit diesen Abfragemustern arbeiten. Andernfalls treten beim Wachstum Ihrer Tabellen erhebliche Leistungsprobleme auf, darunter Abfragelatenz, Transaktions-Timeouts und Parallelitätskonflikte.

In diesem Abschnitt werden Abfragebeschränkungen in QLDB beschrieben und Anleitungen zum Schreiben optimaler Abfragen unter Berücksichtigung dieser Einschränkungen gegeben.

Transaktions-Timeout-Limit

In QLDB wird jede PartiQL-Anweisung (einschließlich jederSELECT Abfrage) in einer Transaktion verarbeitet und unterliegt einem Transaktions-Timeout-Limit. Eine Transaktion kann bis zu 30 Sekunden lang laufen, bevor sie bestätigt wird. Nach diesem Limit lehnt QLDB alle an der Transaktion geleisteten Arbeiten ab und verwirft die Sitzung, die die Transaktion ausgeführt hat. Dieses Limit schützt den Kunden des Dienstes vor Sitzungsverlusten, indem Transaktionen gestartet werden, ohne sie zu bestätigen oder zu stornieren.

Nebenläufigkeit

QLDB implementiert die Parallelitätssteuerung mithilfe der optimistischen Parallelitätssteuerung (OCC). Suboptimale Abfragen können auch zu mehr OCC-Konflikten führen. Informationen zu OCC finden Sie unterAmazon QLDB-Nebenläufigkeit von Amazon QLDB-Nebenläufigkeit.

Optimale Abfragemuster

Es hat sich bewährt, Anweisungen mit einerWHERE Prädikatklausel auszuführen, die nach einem indizierten Feld oder einer Dokument-ID filtert. QLDB benötigt einen Gleichheitsoperator (=oderIN) für ein indiziertes Feld, um ein Dokument effizient nachschlagen zu können.

Im Folgenden finden Sie Beispiele für optimale Abfragemuster in der Benutzeransicht.

--Indexed field (VIN) lookup using the = operator
SELECT * FROM VehicleRegistration
WHERE VIN = '1N4AL11D75C109151'

--Indexed field (VIN) AND non-indexed field (City) lookup
SELECT * FROM VehicleRegistration
WHERE VIN = '1N4AL11D75C109151' AND City = 'Seattle'

--Indexed field (VIN) lookup using the IN operator
SELECT * FROM VehicleRegistration
WHERE VIN IN ('1N4AL11D75C109151', 'KM8SRDHF6EU074761')

--Document ID (r_id) lookup using the BY clause
SELECT * FROM VehicleRegistration BY r_id
WHERE r_id = '3Qv67yjXEwB9SjmvkuG6Cp'

Jede Abfrage, die diesen Mustern nicht folgt, ruft einen vollständigen Tabellenscan auf. Tabellenscans können zu Transaktions-Timeouts für Abfragen in großen Tabellen oder Abfragen, die große Ergebnismengen zurückgeben, führen. Sie können auch zu OCC-Konflikten mit konkurrierenden Transaktionen führen.

Indizes mit hoher Kardinalität

Wir empfehlen, Felder zu indizieren, die Werte mit hoher Kardinalität enthalten. Beispielsweise sind dieLicensePlateNumber FelderVIN und in derVehicleRegistration Tabelle indizierte Felder, die eindeutig sein sollen.

Vermeiden Sie es, Felder mit niedriger Kardinalität wie Statuscodes, Adressstaaten oder Provinzen und Postleitzahlen zu indexieren. Wenn Sie ein solches Feld indexieren, können Ihre Abfragen zu großen Ergebnismengen führen, die mit größerer Wahrscheinlichkeit zu Transaktions-Timeouts oder unbeabsichtigten OCC-Konflikten führen.

Engagierte View-Abfragen

Abfragen, die Sie in der Committe-Ansicht ausführen, folgen denselben Optimierungsrichtlinien wie Abfragen in der Benutzeransicht. Indizes, die Sie für eine Tabelle erstellen, werden auch für Abfragen in der Committed-Ansicht verwendet.

Abfragen von Verlaufsfunktionen

Abfragen von Verlaufsfunktionen verwenden nicht die Indizes, die Sie für eine Tabelle erstellen. Der QLDB-Verlauf wird nur nach der Dokument-ID indexiert, und Sie können derzeit keine zusätzlichen Verlaufsindizes erstellen.

Es hat sich bewährt, eine Verlaufsabfrage sowohl mit einem Datumsbereich (Startzeit und Endzeit) als auch mit einer Dokument-ID (metadata.id) zu qualifizieren. Verlaufsabfragen, die eine Start- und Endzeit enthalten, profitieren von der Qualifizierung des Datumsbereichs.

Interne Join-Abfragen

Verwenden Sie für interne Join-Abfragen Verknüpfungskriterien, die mindestens ein indiziertes Feld für die Tabelle auf der rechten Seite der Verknüpfung enthalten. Ohne einen Join-Index ruft eine Join-Abfrage mehrere Tabellenscans auf — für jedes Dokument in der linken Tabelle der Verknüpfung scannt die Abfrage die rechte Tabelle vollständig. Die bewährte Methode besteht darin, Felder zu verknüpfen, die für jede Tabelle, die Sie verknüpfen, indexiert sind, und zusätzlich einWHERE Gleichheitsprädikat für mindestens eine Tabelle anzugeben.

Die folgende Abfrage verknüpft beispielsweise dieVehicle TabellenVehicleRegistration und in ihren jeweiligenVIN Feldern, die beide indexiert sind. Diese Abfrage hat auch ein Gleichheitsprädikat fürVehicleRegistration.VIN.

SELECT * FROM VehicleRegistration AS r INNER JOIN Vehicle AS v
ON r.VIN = v.VIN
WHERE r.VIN IN ('1N4AL11D75C109151', 'KM8SRDHF6EU074761')

Wählen Sie Indizes mit hoher Kardinalität sowohl für die Verknüpfungskriterien als auch für die Gleichheitsprädikate in Ihren Join-Abfragen.

Abfragemuster, die Sie vermeiden sollten

Im Folgenden finden Sie einige Beispiele für suboptimale Anweisungen, die sich für größere Tabellen in QLDB nicht gut skalieren lassen. Wir empfehlen Ihnen dringend, sich bei Tabellen, die im Laufe der Zeit wachsen, nicht auf diese Art von Abfragen zu verlassen, da Ihre Abfragen letztendlich zu Transaktions-Timeouts führen. Da Tabellen Dokumente mit unterschiedlicher Größe enthalten, ist es schwierig, genaue Grenzwerte für nicht indizierte Abfragen zu definieren.

--No predicate clause
SELECT * FROM Vehicle

--COUNT() is not an optimized function
SELECT COUNT(*) FROM Vehicle

--Low-cardinality predicate
SELECT * FROM Vehicle WHERE Color = 'Silver'

--Inequality (>) does not qualify for indexed lookup
SELECT * FROM Vehicle WHERE "Year" > 2019

--Inequality (LIKE)
SELECT * FROM Vehicle WHERE VIN LIKE '1N4AL%'

--Inequality (BETWEEN)
SELECT SUM(PendingPenaltyTicketAmount) FROM VehicleRegistration
WHERE ValidToDate BETWEEN `2020-01-01T` AND `2020-07-01T`

--No predicate clause
DELETE FROM Vehicle

--No document id, and no date range for the history() function
SELECT * FROM history(Vehicle)

Im Allgemeinen empfehlen wir nicht, die folgenden Arten von Abfragemustern für produktive Anwendungsfälle in QLDB auszuführen:

• Abfragen zur analytischen Online-Verarbeitung (OLAP)

• Explorative Abfragen ohne Prädikatklausel

• Anfragen melden

• Textsuche

Stattdessen empfehlen wir, Ihre Daten an einen speziell entwickelten Datenbankdienst zu streamen, der für analytische Anwendungsfälle optimiert ist. Sie können beispielsweise QLDB-Daten an Amazon OpenSearch Service streamen, um Volltextsuchfunktionen für Dokumente bereitzustellen. Eine Beispielanwendung, die diesen Anwendungsfall demonstriert, finden Sie im GitHub Repository aws-samples/amazon-qldb-streaming-amazon -opensearch-service-sample-python. Hinweise zu QLDB-Streams finden Sie unterJournaldaten von Amazon QLDB streamen.

Überwachung der Leistung

Der QLDB-Treiber stellt Informationen zur verbrauchten I/O-Nutzung und zum Timing im Ergebnisobjekt einer Anweisung bereit. Sie können diese Metriken verwenden, um ineffiziente PartiQL-Anweisungen zu identifizieren. Um mehr zu erfahren, fahren Sie mit fortAbrufen von PartiQL-Anweisungsstatistiken.

Sie können Amazon auch verwenden CloudWatch , um die Leistung Ihres Ledgers für Datenoperationen zu verfolgen. Überwachen Sie dieCommandLatency Metrik für ein bestimmtesLedgerName undCommandType. Weitere Informationen finden Sie unter Überwachung mit Amazon CloudWatch. Informationen dazu, wie QLDB Befehle zur Verwaltung von Datenoperationen verwendet, finden Sie unterSitzungsmanagement mit dem Fahrer.