Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Optimisation des performances des requêtes

Amazon QLDB est conçu pour répondre aux besoins des charges de travail de traitement des transactions en ligne (OLTP) à hautes performances. Cela signifie que QLDB est optimisé pour un ensemble spécifique de modèles de requêtes, même s'il prend en charge les fonctionnalités de requête de type SQL. Il est essentiel de concevoir des applications et leurs modèles de données pour fonctionner avec ces modèles de requêtes. Dans le cas contraire, au fur et à mesure que vos tables s'agrandissent, vous rencontrerez des problèmes de performances importants, notamment la latence des requêtes, les délais d'expiration des transactions et les conflits de simultanéité.

Cette section décrit les contraintes de requête dans QLDB et fournit des conseils pour écrire des requêtes optimales compte tenu de ces contraintes.

Limite de délai d'expiration des transactions

Dans QLDB, chaque instruction partiQL (y compris SELECT chaque requête) est traitée dans une transaction et est soumise à une limite de délai d'expiration de transaction. Une transaction peut être exécutée pendant 30 secondes au maximum avant d'être validée. Après cette limite, QLDB rejette tout travail effectué sur la transaction et supprime la session qui a exécuté la transaction. Cette limite protège le client du service contre les fuites de sessions en démarrant des transactions et non en les validant ou en les annulant.

Conflits de simultanéité

QLDB implémente le contrôle de simultanéité en utilisant le contrôle de simultanéité optimiste (OCC). Les requêtes sous-optimales peuvent également entraîner davantage de conflits OCC. Pour plus d'informations sur l'OCC, consultezModèle de simultanéité Amazon QLDB.

Modèles de requêtes optimaux

Il est recommandé d'exécuter des instructions avec une clause de WHERE prédicat filtrant en fonction d'un champ indexé ou d'un identifiant de document. QLDB nécessite un opérateur d'égalité = (INou) sur un champ indexé pour rechercher efficacement un document.

Vous trouverez ci-dessous des exemples de modèles de requêtes optimaux dans la vue utilisateur.

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

Toute requête qui ne suit pas ces modèles appelle une analyse complète de la table. L'analyse des tables peut entraîner l'expiration des délais de transaction pour les requêtes portant sur des tables volumineuses ou les requêtes renvoyant de grands ensembles de résultats. Ils peuvent également entraîner des conflits entre l'OCC et des transactions concurrentes.

Indices de cardinalité élevés

Nous recommandons d'indexer les champs contenant des valeurs de cardinalité élevées. Par exemple, les LicensePlateNumber champs VIN et de la VehicleRegistration table sont des champs indexés conçus pour être uniques.

Évitez d'indexer les champs à faible cardinalité tels que les codes de statut, les états ou provinces d'adresse et les codes postaux. Si vous indexez un tel champ, vos requêtes peuvent produire de grands ensembles de résultats susceptibles d'entraîner des délais d'expiration des transactions ou de provoquer des conflits OCC involontaires.

Requêtes d'affichage validées

Les requêtes que vous exécutez dans la vue validée suivent les mêmes directives d'optimisation que les requêtes de vue utilisateur. Les index que vous créez sur une table sont également utilisés pour les requêtes dans la vue validée.

Historique des requêtes relatives aux fonctions

Les requêtes de fonction d'historique n'utilisent pas les index que vous créez sur une table. L'historique QLDB est indexé uniquement par identifiant de document, et vous ne pouvez pas créer d'index d'historique supplémentaires pour le moment.

Il est recommandé de qualifier une requête d'historique à la fois par une plage de dates (heure de début et heure de fin) et par un identifiant de document (metadata.id). Les requêtes d'historique qui incluent une heure de début et une heure de fin bénéficient de la qualification par plage de dates.

Requêtes de jointure internes

Pour les requêtes de jointure interne, utilisez des critères de jointure qui incluent au moins un champ indexé pour la table sur le côté droit de la jointure. Sans index de jointure, une requête de jointure appelle plusieurs scans de table : pour chaque document de la table de gauche de la jointure, la requête scanne entièrement la table de droite. La meilleure pratique consiste à joindre des champs indexés pour chaque table que vous joignez, en plus de spécifier un prédicat d'WHEREégalité pour au moins une table.

Par exemple, la requête suivante joint les Vehicle tables VehicleRegistration et dans leurs VIN champs respectifs, qui sont tous deux indexés. Cette requête possède également un prédicat d'égalité activéVehicleRegistration.VIN.

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

Choisissez des indices de cardinalité élevés pour les critères de jointure et les prédicats d'égalité dans vos requêtes de jointure.

Modèles de requêtes à éviter

Voici quelques exemples d'instructions sous-optimales qui ne s'adaptent pas bien aux grandes tables de QLDB. Nous vous recommandons vivement de ne pas vous fier à ce type de requêtes pour les tables qui s'agrandissent au fil du temps, car vos requêtes finiront par entraîner des délais d'expiration des transactions. Les tables contenant des documents dont la taille varie, il est difficile de définir des limites précises pour les requêtes non indexées.

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

En général, nous ne recommandons pas d'exécuter les types de modèles de requête suivants pour les cas d'utilisation en production dans QLDB :

Nous vous recommandons plutôt de diffuser vos données vers un service de base de données spécialement conçu et optimisé pour les cas d'utilisation analytiques. Par exemple, vous pouvez diffuser des données QLDB vers OpenSearch Amazon Service afin de fournir des fonctionnalités de recherche en texte intégral sur des documents. Pour un exemple d'application illustrant ce cas d'utilisation, consultez le GitHub référentiel amazon-qldb-streaming-amazonaws-samples/ -. opensearch-service-sample-python Pour plus d'informations sur les flux QLDB, consultez. Diffusion en continu de données de journaux depuis Amazon QLDB

Surveillance des performances

Le pilote QLDB fournit des informations de synchronisation et d'utilisation des E/S consommées dans l'objet de résultat d'une instruction. Vous pouvez utiliser ces métriques pour identifier les instructions partiQL inefficaces. Pour en savoir plus, rendez-vous surObtenir les statistiques des instructions PartiQL.

Vous pouvez également utiliser Amazon CloudWatch pour suivre les performances de votre registre en matière d'opérations de données. Surveillez la CommandLatency métrique pour une valeur spécifiée LedgerName etCommandType. Pour de plus amples informations, veuillez consulter Surveillance avec Amazon CloudWatch. Pour savoir comment QLDB utilise les commandes pour gérer les opérations de données, consultez. Gestion des sessions avec le chauffeur