Optimisation des requêtes

Filtres de métadonnées

Lorsque vous interrogez des métadonnées ou des données brutes, utilisez la WHERE clause pour filtrer par champs de métadonnées afin de réduire la quantité de données numérisées. Utilisez les opérateurs suivants pour limiter l'analyse des métadonnées :

• Est égal à (=)

• N'est pas égal à (! =)

• LIKE

• IN

• AND

• OU

Pour les propriétés des attributs, utilisez les champs suivants pour filtrer les résultats. :

• double_attribute_value

• int_attribute_value

• boolean_attribute_value

• string_attribute_value

Ces champs offrent de meilleures performances que la table latest_value_time_series pour les propriétés des actifs de type attribut.

Note

Utilisez des littéraux sur le côté droit des opérateurs pour limiter correctement l'analyse des données. Par exemple, la requête suivante est moins performante que l'utilisation d'une chaîne littérale stricte :

SELECT property_id FROM asset_property WHERE property_name = CONCAT('my', 'property')

Exemple pour les filtres de métadonnées :

SELECT p.property_name FROM asset_property p
WHERE p.property_type = 'attribute' AND p.string_attribute_value LIKE 'my-property-%'    

Filtres de données brutes

Toutes les tables de données brutes (raw_time_series, latest_value_time_series, precomputed_aggregates) ont des horodatages associés à leurs lignes. Outre les filtres de métadonnées, utilisez des filtres de WHERE clauses sur le event_timestamp terrain pour réduire la quantité de données numérisées. Utilisez les opérations suivantes pour limiter l'analyse des données brutes :

• Est égal à (=)

• supérieure à (>)

• Inférieur à (<)

• Supérieur ou égal à (>=)

• Inférieur ou égal à (<=)

• BETWEEN

• AND

Lorsque vous interrogez la table precomputed_aggregates, spécifiez toujours un filtre de qualité dans la clause. WHERE Cela réduit la quantité de données que la requête analyse, en particulier si vous recherchez BAD des UNCERTAIN données. Nous vous recommandons également vivement d'utiliser un filtre de résolution (1 m, 15 m, 1 h ou 1d) lorsque vous interrogez la table precomputed_aggregates. Si vous ne spécifiez pas de filtre de résolution, le tableau AWS IoT SiteWise sera analysé par défaut dans son intégralité pour toutes les résolutions, ce qui est inefficace.

Note

Ce n'est pas égal (!=) et OR les opérateurs n'appliquent généralement pas de filtres significatifs à l'analyse des données brutes. Les filtres sur les valeurs des données brutes (string_value, double_value, etc.) ne limitent pas non plus l'analyse des données brutes.

Optimisation JOIN

AWS IoT SiteWise SQL prend en charge le JOIN mot clé permettant de fusionner deux tables. Seuls JOIN les filtres actifs sur un champ (à l'aide du ON mot clé) sont pris en charge. Les jointures cartésiennes complètes sont interdites.

AWS IoT SiteWise prend également en charge les JOIN s implicites sans utiliser le JOIN mot clé. Elles sont autorisées entre différentes tables de métadonnées et entre une table de métadonnées et une table brute. Par exemple, cette requête :

SELECT a.asset_name, p.property_name FROM asset a, asset_property p

Fonctionne mieux que cette requête équivalente :

SELECT a.asset_name, p.property_name FROM asset a
JOIN asset_property p ON a.asset_id = p.asset_id

Les jointures implicites suivantes sont autorisées (O est autorisé, X est interdit) :

	asset	propriété_actif	dernière_value_time_series	Série Raw_Time	agrégats_précalculés	sous-requête
asset	X	O	O	O	O	X
propriété_actif	O	X	O	O	O	X
dernière_value_time_series	O	O	X	X	X	X
Série Raw_Time	O	O	X	X	X	X
agrégats_précalculés	O	O	X	X	X	X
sous-requête	X	X	X	X	X	X

Utilisez des JOIN s implicites dans la mesure du possible. Si vous devez utiliser le JOIN mot clé, appliquez des filtres sur les différentes tables JOIN rouges afin de minimiser les données numérisées. Par exemple, au lieu de cette requête :

SELECT level1.asset_id, level2.asset_id, level3.asset_id
FROM asset AS level1
JOIN asset AS level2 ON level2.parent_asset_id = level1.asset_id
JOIN asset AS level3 ON level3.parent_asset_id = level2.asset_id
WHERE level1.asset_name LIKE 'level1%'
AND level2.asset_name LIKE 'level2%'
AND level3.asset_name LIKE 'level3%'

Utilisez cette requête plus efficace :

SELECT level1.asset_id, level2.asset_id, level3.asset_id
FROM asset AS level1
JOIN (SELECT asset_id, parent_asset_id FROM asset WHERE asset_name LIKE 'level2%') AS level2 ON level2.parent_asset_id = level1.asset_id
JOIN (SELECT asset_id, parent_asset_id FROM asset WHERE asset_name LIKE 'level3%') AS level3 ON level3.parent_asset_id = level2.asset_id
WHERE level1.asset_name LIKE 'level1%'

En insérant des filtres de métadonnées dans les sous-requêtes, vous vous assurez que les tables individuelles du JOIN s sont filtrées pendant le processus de numérisation. Vous pouvez également utiliser le LIMIT mot clé dans les sous-requêtes pour obtenir le même effet.

Requêtes volumineuses

Pour les requêtes qui produisent plus de lignes que la valeur par défaut, définissez la taille de page de l'ExecuteQueryAPI sur la valeur maximale de 20 000. Cela améliore les performances globales des requêtes.

Utilisez la LIMIT clause pour réduire la quantité de données numérisées pour certaines requêtes. Notez que les fonctions d'agrégation et certaines clauses à l'échelle du tableau (GROUP BYORDER BY,,JOIN) nécessitent une analyse complète avant d'appliquer la LIMIT clause.

Note

AWS IoT SiteWise peut scanner un minimum de données même si la LIMIT clause est appliquée, en particulier pour les requêtes de données brutes qui analysent plusieurs propriétés.