Ottimizzazione delle prestazioni delle query

Amazon QLDB ha lo scopo di soddisfare le esigenze di carichi di lavoro OLTP (OLTP) di elaborazione di transazioni online (OLTP). Ciò significa che QLDB è ottimizzato per un set specifico di modelli di query, anche se supporta funzionalità di query di tipo SQL. È fondamentale progettare le applicazioni e i relativi modelli di dati in modo che funzionino con questi modelli di interrogazione. Altrimenti, man mano che le tabelle crescono, si verificheranno problemi di prestazioni significativi, tra cui latenza delle query, timeout delle transazioni e conflitti di concorrenza.

Questa sezione descrive i vincoli delle query in QLDB e fornisce una guida per scrivere interrogazioni ottimali in base a questi vincoli.

Limite di timeout della transazione

In QLDB, ogni istruzione PartiQL (inclusa ogniSELECT query) viene elaborata in una transazione ed è soggetta a un limite di timeout della transazione. Una transazione può essere eseguita fino a 30 secondi prima di essere confermata. Dopo questo limite, QLDB rifiuta qualsiasi lavoro svolto sulla transazione e scarta la sessione che ha eseguito la transazione. Questo limite protegge il cliente del servizio dalla perdita di sessioni avviando transazioni e non eseguendole o annullandole.

Conflitti di concorrenza

QLDB implementa il controllo della concorrenza utilizzando il controllo ottimistico della concorrenza (OCC). Le interrogazioni non ottimali possono anche portare a ulteriori conflitti OCC. Per informazioni su OCC, vedereModello di concorrenza Amazon QLDB.

Schemi di query ottimali

Come procedura consigliata, è consigliabile eseguire istruzioni con una clausolaWHERE predicativa che filtra in base a un campo indicizzato o all'ID di un documento. QLDB richiede un operatore di uguaglianza (=oIN) su un campo indicizzato per cercare in modo efficiente un documento.

Di seguito sono riportati alcuni esempi di modelli di interrogazione ottimali nella vista utente.

--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'

Qualsiasi query che non segue questi schemi richiama una scansione completa della tabella. Le scansioni delle tabelle possono causare il timeout delle transazioni per le query su tabelle di grandi dimensioni o per le query che restituiscono set di risultati di grandi dimensioni. Possono anche portare a conflitti OCC con transazioni concorrenti.

Indici ad alta cardinalità

Consigliamo di indicizzare i campi che contengono valori di cardinalità elevati. Ad esempio, iLicensePlateNumber campiVIN e nellaVehicleRegistration tabella sono campi indicizzati che devono essere univoci.

Evita di indicizzare campi a bassa cardinalità come codici di stato, stati o province degli indirizzi e codici postali. Se indicizzi un campo di questo tipo, le tue query possono produrre set di risultati di grandi dimensioni che hanno maggiori probabilità di causare timeout delle transazioni o conflitti OCC involontari.

Query di visualizzazione confermate

Le query eseguite nella visualizzazione commit seguono le stesse linee guida di ottimizzazione delle query di visualizzazione utente. Gli indici creati su una tabella vengono utilizzati anche per le interrogazioni nella vista confermata.

Interrogazioni sulle funzioni di cronologia

Le interrogazioni sulle funzioni di cronologia non utilizzano gli indici creati su una tabella. La cronologia QLDB è indicizzata solo in base all'ID del documento e al momento non è possibile creare indici di cronologia aggiuntivi.

Come procedura consigliata, qualifica un'interrogazione cronologica con un intervallo di date (ora di inizio e ora di fine) e un ID del documento (metadata.id). Le interrogazioni cronologiche che includono un'ora di inizio e un'ora di fine ottengono il vantaggio della qualificazione dell'intervallo di date.

Interrogazioni interne

Per le query di join interne, utilizza criteri di join che includano almeno un campo indicizzato per la tabella sul lato destro del join. Senza un indice di join, una query di join richiama più scansioni di tabelle: per ogni documento nella tabella sinistra del join, la query esegue la scansione completa della tabella destra. La procedura migliore consiste nell'unire i campi indicizzati per ogni tabella a cui si sta unendo, oltre a specificare un predicato diWHERE uguaglianza per almeno una tabella.

Ad esempio, la seguente query unisce leVehicle tabelleVehicleRegistration eVIN nei rispettivi campi, che sono entrambi indicizzati. Questa interrogazione ha anche un predicato di uguaglianza suVehicleRegistration.VIN.

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

Scegli indici ad alta cardinalità sia per i criteri di unione che per i predicati di uguaglianza nelle tue query di partecipazione.

Schemi di query da evitare

Di seguito sono riportati alcuni esempi di istruzioni non ottimali che non si adattano bene alle tabelle più grandi in QLDB. Ti consigliamo vivamente di non fare affidamento su questi tipi di query per le tabelle che crescono nel tempo, perché alla fine le query comporteranno il timeout delle transazioni. Poiché le tabelle contengono documenti di dimensioni variabili, è difficile definire limiti precisi per le query non indicizzate.

--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)

In generale, non consigliamo di eseguire i seguenti tipi di pattern di query per i casi d'uso di produzione in QLDB:

• Interrogazioni di elaborazione analitica online (OLAP)

• Interrogazioni esplorative senza una clausola predicativa

• Richieste di segnalazione

• Ricerca testuale

Consigliamo invece lo streaming dei dati su un servizio di database appositamente creato e ottimizzato per casi d'uso analitici. Ad esempio, puoi trasmettere dati QLDB ad Amazon OpenSearch Service per fornire funzionalità di ricerca di testo completo sui documenti. Per un'applicazione di esempio che dimostri questo caso d'uso, consulta il GitHub repository aws-samples/amazon-qldb-streaming-amazon -opensearch-service-sample-python. Per informazioni sugli stream QLDB, consultaStreaming dei dati del diario da Amazon QLDB.

Monitoraggio delle prestazioni

Il driver QLDB fornisce informazioni sull'utilizzo degli I/O e sulla tempistica nell'oggetto risultato di un'istruzione. Puoi utilizzare questi parametri per identificare le istruzioni PartiQL inefficienti. Per saperne di più, procedi aOttenere le statistiche delle dichiarazioni PartiQL.

Puoi anche utilizzare Amazon CloudWatch per monitorare le prestazioni del tuo libro contabile per le operazioni sui dati. Monitora laCommandLatency metrica per un determinatoLedgerName eCommandType. Per ulteriori informazioni, consulta Monitoraggio con Amazon CloudWatch. Per scoprire come QLDB utilizza i comandi per gestire le operazioni sui dati, vedereGestione delle sessioni con il conducente.