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 requêtes
<a name="query-optimize"></a>

## Filtres de métadonnées
<a name="metadata-filters"></a>

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

**Example 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
<a name="raw-data-filters"></a>

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

**Exemples de filtres** :
+  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. 
+  Lorsque vous interrogez des données brutes, les fonctions d'horodatage peuvent également être utilisées dans la `WHERE` clause pour filtrer la quantité de données numérisées. Par exemple, la requête suivante analyse uniquement les 30 dernières minutes de données de la table **raw\_time\_series** : 

  ```
  SELECT r.event_timestamp, r.double_value
  FROM raw_time_series r
  WHERE r.event_timestamp > TIMESTAMP_SUB(MINUTE, 30, NOW())
  ```

**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
<a name="join-optimization"></a>

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
<a name="large-queries"></a>

Pour les requêtes qui produisent plus de lignes que la valeur par défaut, définissez la taille de page de l'[ExecuteQuery](https://docs.aws.amazon.com/iot-sitewise/latest/APIReference/API_ExecuteQuery.html)API 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 de la table (`GROUP BY``ORDER 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.