Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Ottimizzazione delle prestazioni delle query

Amazon QLDB è progettato per soddisfare le esigenze dei carichi di lavoro di elaborazione delle transazioni online (OLTP) ad alte prestazioni. Ciò significa che QLDB è ottimizzato per un set specifico di modelli di query, anche se supporta funzionalità di query SQL simili. È fondamentale progettare le applicazioni e i relativi modelli di dati per lavorare con questi modelli di query. Altrimenti, man mano che le tabelle crescono, si verificheranno notevoli problemi di prestazioni, tra cui latenza delle query, timeout delle transazioni e conflitti di concorrenza.

Questa sezione descrive i vincoli di interrogazione QLDB e fornisce indicazioni per scrivere query ottimali in base a tali vincoli.

Limite di timeout delle transazioni

InQLDB, ogni istruzione PartiQL (inclusa ogni SELECT query) viene elaborata in una transazione ed è soggetta a un limite di timeout della transazione. Una transazione può durare 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 client del servizio dalla perdita di sessioni avviando le transazioni e non eseguendole o annullandole.

Conflitti di concorrenza

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

Modelli di interrogazione ottimali

È consigliabile eseguire istruzioni con una clausola di WHERE predicato che filtri in base a un campo indicizzato o a un ID di documento. QLDBrichiede 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 visualizzazione 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 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 con transazioni concorrenti. OCC

Indici ad alta cardinalità

Consigliamo di indicizzare i campi che contengono valori di cardinalità elevata. Ad esempio, i LicensePlateNumber campi VIN e della VehicleRegistration tabella sono campi indicizzati destinati a 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 involontari. OCC

Interrogazioni di visualizzazione impegnate

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

Interrogazioni con funzioni cronologiche

Le query con funzioni cronologiche non utilizzano gli indici creati in una tabella. QLDBla cronologia viene indicizzata solo in base all'ID del documento e al momento non è possibile creare indici cronologici aggiuntivi.

Come procedura consigliata, qualifica una query 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 l'ora di inizio e l'ora di fine ottengono il vantaggio della qualificazione per intervalli di date.

Interrogazioni di giunzione interna

Per le query di inner join, utilizzate 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 tabella: per ogni documento nella tabella sinistra del join, la query analizza completamente la tabella destra. La procedura ottimale consiste nell'unire i campi indicizzati per ogni tabella a cui si sta unendo, oltre a specificare un predicato di uguaglianza per almeno una WHERE tabella.

Ad esempio, la seguente query unisce le Vehicle tabelle VehicleRegistration and VIN nei rispettivi campi, entrambi indicizzati. Questa query ha anche un predicato di uguaglianza su. VehicleRegistration.VIN

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

Scegliete indici ad alta cardinalità sia per i criteri di join che per i predicati di uguaglianza nelle vostre query di join.

Schemi di interrogazione da evitare

Di seguito sono riportati alcuni esempi di istruzioni non ottimali che non si adattano bene a QLDB tabelle di grandi dimensioni. Ti consigliamo vivamente di non fare affidamento su questi tipi di query per tabelle che crescono nel tempo, perché alla fine le query causeranno dei 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 è consigliabile eseguire i seguenti tipi di modelli di query per casi d'uso di produzione in: QLDB

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

Monitoraggio delle prestazioni

Il QLDB driver fornisce informazioni sull'utilizzo e sulla tempistica degli I/O consumati nell'oggetto risultato di un'istruzione. È possibile utilizzare queste metriche per identificare istruzioni PartiQL inefficienti. Per saperne di più, procedi a. Ottenere statistiche sulle istruzioni PartiQL

Puoi anche usare Amazon CloudWatch per monitorare le prestazioni del tuo libro mastro per le operazioni sui dati. Monitora la CommandLatency metrica per un determinato LedgerName e. CommandType Per ulteriori informazioni, consulta Monitoraggio con Amazon CloudWatch. Per informazioni su come QLDB utilizza i comandi per gestire le operazioni sui dati, consultaGestione delle sessioni con il driver.