Pour des fonctionnalités similaires à celles d'Amazon Timestream pour, pensez à Amazon Timestream LiveAnalytics pour InfluxDB. Il permet une ingestion simplifiée des données et des temps de réponse aux requêtes à un chiffre en millisecondes pour des analyses en temps réel. Pour en savoir plus, [cliquez ici](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html).

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.

# Utilisation des informations relatives aux requêtes pour optimiser les requêtes dans Amazon Timestream
<a name="using-query-insights"></a>

Query Insights est une fonctionnalité d'optimisation des performances qui vous permet d'optimiser vos requêtes, d'améliorer leurs performances et de réduire les coûts. Grâce à Query Insights, vous pouvez évaluer l'efficacité de l'élagage basé sur les clés de partition temporelles, temporelles et spatiales de vos requêtes. À l'aide des informations sur les requêtes, vous pouvez également identifier les domaines à améliorer afin d'améliorer les performances des requêtes. En outre, grâce aux informations sur les requêtes, vous pouvez évaluer l'efficacité avec laquelle vos requêtes utilisent l'indexation basée sur le temps et sur les clés de partition pour optimiser la récupération des données. Pour optimiser les performances des requêtes, il est essentiel d'affiner les paramètres temporels et spatiaux qui régissent l'exécution des requêtes.

**Topics**
+ [Avantages des informations sur les requêtes](#query-insights-benefits)
+ [Optimisation de l'accès aux données dans Amazon Timestream](query-insights-optimize-data-access-pattern.md)
+ [Activation de l'analyse des requêtes dans Amazon Timestream](enable-query-insights.md)
+ [Optimisation des requêtes à l'aide des informations sur les requêtes et](optimize-query-using-query-insights.md)

## Avantages des informations sur les requêtes
<a name="query-insights-benefits"></a>

Les principaux avantages de l'utilisation de Query Insights sont les suivants : 
+ **Identification des requêtes inefficaces** : Query Insights fournit des informations sur l'élagage basé sur le temps et les attributs des tables auxquelles la requête accède. Ces informations vous aident à identifier les tables auxquelles l'accès n'est pas optimal.
+ **Optimisation de votre modèle de données et de partitionnement** : vous pouvez utiliser les informations issues des requêtes pour accéder à votre modèle de données et à votre stratégie de partitionnement et les affiner.
+ **Optimisation des requêtes** : Query Insights met en évidence les possibilités d'utiliser les index de manière plus efficace.

# Optimisation de l'accès aux données dans Amazon Timestream
<a name="query-insights-optimize-data-access-pattern"></a>

Vous pouvez optimiser les modèles d'accès aux données dans Amazon Timestream à l'aide du schéma de partitionnement Timestream ou des techniques d'organisation des données.

**Topics**
+ [Schéma de partitionnement Timestream](#query-insights-optimize-data-access-partitioning-scheme)
+ [organisation des données](#query-insights-optimize-data-access-data-org)

## Schéma de partitionnement Timestream
<a name="query-insights-optimize-data-access-partitioning-scheme"></a>

Amazon Timestream utilise un schéma de partitionnement hautement évolutif dans lequel chaque table Timestream peut contenir des centaines, des milliers, voire des millions de partitions indépendantes. Un service de suivi et d'indexation des partitions à haute disponibilité gère le partitionnement, minimisant ainsi l'impact des défaillances et renforçant la résilience du système.

![\[Schéma de partitionnement Timestream\]](http://docs.aws.amazon.com/fr_fr/timestream/latest/developerguide/images/QueryInsights/ts-partitioning-scheme.png)


## organisation des données
<a name="query-insights-optimize-data-access-data-org"></a>

Timestream stocke chaque point de données ingéré dans une seule partition. Lorsque vous ingérez des données dans une table Timestream, Timestream crée automatiquement des partitions en fonction des horodatages, de la clé de partition et d'autres attributs contextuels contenus dans les données. En plus de partitionner les données dans le temps (partitionnement temporel), Timestream partitionne également les données en fonction de la clé de partitionnement sélectionnée et d'autres dimensions (partitionnement spatial). Cette approche est conçue pour répartir le trafic d'écriture et permettre un élagage efficace des données pour les requêtes.

La fonction d'analyse des requêtes fournit des informations précieuses sur l'efficacité de l'élagage de la requête, notamment la couverture spatiale et la couverture temporelle des requêtes.

**Topics**
+ [QuerySpatialCoverage](#query-insights-data-org-query-spatial-cvg)
+ [QueryTemporalCoverage](#query-insights-data-org-query-temporal-cvg)

### QuerySpatialCoverage
<a name="query-insights-data-org-query-spatial-cvg"></a>

La [QuerySpatialCoverage](https://docs.aws.amazon.com/timestream/latest/developerguide/API_query_QuerySpatialCoverage.html)métrique fournit des informations sur la couverture spatiale de la requête exécutée et de la table présentant l'élagage spatial le plus inefficace. Ces informations peuvent vous aider à identifier les points à améliorer dans la stratégie de partitionnement afin d'améliorer l'élagage spatial. La valeur de la `QuerySpatialCoverage` métrique est comprise entre 0 et 1. Plus la valeur de la métrique est faible, plus l'élagage des requêtes sur l'axe spatial est optimal. Par exemple, une valeur de 0,1 indique que la requête scanne 10 % de l'axe spatial. La valeur 1 indique que la requête scanne 100 % de l'axe spatial.

**Example Utilisation des informations issues des requêtes pour analyser la couverture spatiale d'une requête**  
Supposons que vous disposiez d'une base de données Timestream qui stocke des données météorologiques. Supposons que la température soit enregistrée toutes les heures par des stations météorologiques situées dans différents États des États-Unis d'Amérique. Imaginez que vous choisissiez `State` comme [clé de partitionnement définie par le client](customer-defined-partition-keys.md) (CDPK) pour partitionner les données par état.  
Supposons que vous exécutiez une requête pour récupérer la température moyenne de toutes les stations météorologiques de Californie entre 14 h et 16 h un jour donné. L'exemple suivant montre la requête pour ce scénario.  

```
SELECT AVG(temperature) 
FROM "weather_data"."hourly_weather"
WHERE time >= '2024-10-01 14:00:00' AND time < '2024-10-01 16:00:00' 
  AND state = 'CA';
```
À l'aide de la fonctionnalité Query Insights, vous pouvez analyser la couverture spatiale de la requête. Imaginez que la `QuerySpatialCoverage` métrique renvoie une valeur de 0,02. Cela signifie que la requête n'a scanné que 2 % de l'axe spatial, ce qui est efficace. Dans ce cas, la requête a pu affiner efficacement la plage spatiale, en ne récupérant que les données de Californie et en ignorant les données d'autres États.  
Au contraire, si la `QuerySpatialCoverage` métrique renvoie une valeur de 0,8, cela indique que la requête a scanné 80 % de l'axe spatial, ce qui est moins efficace. Cela peut suggérer que la stratégie de partitionnement doit être affinée pour améliorer l'élagage spatial. Par exemple, vous pouvez sélectionner la clé de partition comme ville ou région plutôt que comme État. En analysant la `QuerySpatialCoverage` métrique, vous pouvez identifier les opportunités d'optimiser votre stratégie de partitionnement et d'améliorer les performances de vos requêtes.

L'image suivante montre un élagage spatial médiocre.

![\[Résultat fourni par la QuerySpatialCoverage métrique qui indique un faible élagage spatial.\]](http://docs.aws.amazon.com/fr_fr/timestream/latest/developerguide/images/QueryInsights/QuerySpatialCoverageMetricResult.png)


Pour améliorer l'efficacité de l'élagage spatial, vous pouvez effectuer l'une des opérations suivantes ou les deux :
+ Ajoutez `measure_name` la clé de partitionnement par défaut ou utilisez les prédicats CDPK dans votre requête.
+ Si vous avez déjà ajouté les attributs mentionnés au point précédent, supprimez les fonctions associées à ces attributs ou clauses, telles que`LIKE`.

### QueryTemporalCoverage
<a name="query-insights-data-org-query-temporal-cvg"></a>

La `QueryTemporalCoverage` métrique fournit des informations sur la plage temporelle analysée par la requête exécutée, y compris la table contenant la plus grande plage temporelle scannée. La valeur de la `QueryTemporalCoverage` métrique est la plage de temps représentée en nanosecondes. Plus la valeur de cette métrique est faible, plus l'élagage des requêtes sur la plage temporelle est optimal. Par exemple, une requête analysant les données des dernières minutes est plus performante qu'une requête analysant l'ensemble de la plage temporelle de la table.

**Example**  
Supposons que vous disposiez d'une base de données Timestream qui stocke les données des capteurs IoT, avec des mesures prises chaque minute à partir d'appareils situés dans une usine de fabrication. Supposons que vous avez partitionné vos données par`device_ID`.  
Supposons que vous exécutiez une requête pour récupérer le relevé moyen du capteur pour un appareil spécifique au cours des 30 dernières minutes. L'exemple suivant montre la requête pour ce scénario.  

```
SELECT AVG(sensor_reading) 
FROM "sensor_data"."factory_1"
WHERE device_id = 'DEV_123' 
  AND time >= NOW() - INTERVAL 30 MINUTE and time < NOW();
```
À l'aide de la fonctionnalité Query Insights, vous pouvez analyser la plage temporelle analysée par la requête. Imaginez que la `QueryTemporalCoverage` métrique renvoie une valeur de 1800000000000 nanosecondes (30 minutes). Cela signifie que la requête n'a scanné que les 30 dernières minutes de données, ce qui représente une plage temporelle relativement étroite. C'est un bon signe car cela indique que la requête a réussi à affiner efficacement le partitionnement temporel et à récupérer uniquement les données demandées.  
Au contraire, si la `QueryTemporalCoverage` métrique renvoie une valeur de 1 an en nanosecondes, cela indique que la requête a scanné une période d'un an dans le tableau, ce qui est moins efficace. Cela peut indiquer que la requête n'est pas optimisée pour l'élagage temporel, et vous pouvez l'améliorer en ajoutant des filtres temporels.

L'image suivante montre un élagage temporel médiocre.

![\[Résultat fourni par la QueryTemporalCoverage métrique qui montre un faible élagage temporel.\]](http://docs.aws.amazon.com/fr_fr/timestream/latest/developerguide/images/QueryInsights/QueryTemporalCoverageMetricResult.png)


Pour améliorer l'élagage temporel, nous vous recommandons d'effectuer l'une ou l'ensemble des opérations suivantes :
+ Ajoutez les prédicats temporels manquants dans la requête et assurez-vous qu'ils élaguent la fenêtre temporelle souhaitée.
+ Supprimez les fonctions`MAX()`, telles que celles relatives aux prédicats temporels.
+ Ajoutez des prédicats temporels à toutes les sous-requêtes. Cela est important si vos sous-requêtes joignent de grandes tables ou exécutent des opérations complexes.

# Activation de l'analyse des requêtes dans Amazon Timestream
<a name="enable-query-insights"></a>

Vous pouvez activer les informations relatives aux requêtes pour vos requêtes grâce à des informations fournies directement par le biais de la réponse à la requête. L'activation des informations sur les requêtes ne nécessite aucune infrastructure supplémentaire ni n'entraîne de coûts supplémentaires. Lorsque vous activez Query Insights, les champs de métadonnées liés aux performances des requêtes sont renvoyés en plus des résultats des requêtes dans le cadre de la réponse à votre requête. Vous pouvez utiliser ces informations pour ajuster vos requêtes afin d'améliorer les performances des requêtes et de réduire le coût des requêtes.

Pour plus d'informations sur l'activation des informations sur les requêtes, consultez[Exécuter une requête](console_timestream.md#console_timestream.queries.using-console).

Pour consulter des exemples de réponses renvoyées en activant les informations sur les requêtes, voir [Exemples de requêtes planifiées](https://docs.aws.amazon.com/timestream/latest/developerguide/API_query_ExecuteScheduledQuery.html#API_query_ExecuteScheduledQuery_Examples).

**Note**  
Lorsque vous activez les informations sur les requêtes, le débit limite la requête à une requête par seconde (QPS). Pour éviter tout impact sur les performances, nous vous recommandons vivement d'activer les informations sur les requêtes uniquement pendant la phase d'évaluation de vos requêtes, avant de les déployer en production.
Les informations fournies dans les informations des requêtes sont finalement cohérentes, ce qui signifie qu'elles peuvent changer à mesure que de nouvelles données sont continuellement ingérées dans les tables.

# Optimisation des requêtes à l'aide des informations sur les requêtes et
<a name="optimize-query-using-query-insights"></a>

Supposons que vous utilisiez Amazon Timestream LiveAnalytics pour surveiller la consommation d'énergie sur différents sites. Imaginez que votre base de données comporte deux tables nommées `raw-metrics` et`aggregate-metrics`.

Le `raw-metrics` tableau contient des données énergétiques détaillées au niveau de l'appareil et contient les colonnes suivantes :
+ Horodatage
+ État, par exemple, Washington
+ ID de l'appareil
+ Consommation d'énergie

Les données de ce tableau sont collectées et stockées selon une minute-by-minute granularité. La table est utilisée `State` comme CDPK.

Le `aggregate-metrics` tableau enregistre le résultat d'une requête planifiée pour agréger les données de consommation d'énergie de tous les appareils toutes les heures. Ce tableau contient les colonnes suivantes :
+ Horodatage
+ État, par exemple, Washington
+ Consommation totale d'énergie

La `aggregate-metrics` table stocke ces données selon une granularité horaire. La table est utilisée `State` comme CDPK.

**Topics**
+ [Consultation de la consommation d'énergie des dernières 24 heures](#query-energy-consumption-data)
+ [Optimisation de la requête pour la plage temporelle](#optimize-query-temporal-range)
+ [Optimisation de la requête pour la couverture spatiale](#optimize-query-spatial-coverage)
+ [Performances de requête améliorées](#improved-query-performance)

## Consultation de la consommation d'énergie des dernières 24 heures
<a name="query-energy-consumption-data"></a>

Supposons que vous souhaitiez extraire l'énergie totale consommée à Washington au cours des dernières 24 heures. Pour trouver ces données, vous pouvez tirer parti des points forts des deux tableaux : `raw-metrics` et`aggregate-metrics`. Le `aggregate-metrics` tableau fournit des données de consommation d'énergie horaire pour les 23 dernières heures, tandis que le `raw-metrics` tableau fournit des données détaillées par minute pour la dernière heure. En consultant les deux tableaux, vous pouvez obtenir une image complète et précise de la consommation d'énergie à Washington au cours des dernières 24 heures.

```
SELECT am.time, am.state, am.total_energy_consumption, 
rm.time, rm.state, rm.device_id, rm.energy_consumption
FROM 
 "metrics"."aggregate-metrics" am
 LEFT JOIN "metrics"."raw-metrics" rm ON am.state = rm.state
WHERE rm.time >= ago(1h) and rm.time < now()
```

Cet exemple de requête est fourni à titre indicatif uniquement et risque de ne pas fonctionner tel quel. Il est destiné à illustrer le concept, mais vous devrez peut-être le modifier pour l'adapter à votre cas d'utilisation ou à votre environnement spécifique.

Après avoir exécuté cette requête, vous remarquerez peut-être que le temps de réponse à la requête est plus lent que prévu. Pour identifier la cause première de ce problème de performance, vous pouvez utiliser la fonctionnalité Query Insights pour analyser les performances de la requête et optimiser son exécution.

L'exemple suivant montre la réponse de Query Insights.

```
queryInsightsResponse={
                QuerySpatialCoverage: {
                    Max: {
                        Value: 1.0,
                        TableArn: arn:aws:timestream:us-east-1:123456789012:database/metrics/table/raw-metrics,
                        PartitionKey: [State]
                    }
                },
                QueryTemporalRange: {
                    Max: {
                        Value:31540000000000000 //365 days,
                        TableArn: arn:aws:timestream:us-east-1:123456789012:database/metrics/table/aggregate-metrics
                    }
                },
                QueryTableCount: 2,
                OutputRows: 83,
                OutputBytes: 590
```

La réponse Query Insights fournit les informations suivantes :
+ **Plage temporelle** : la requête a scanné une plage temporelle excessive de 365 jours pour la `aggregate-metrics` table. Cela indique une utilisation inefficace du filtrage temporel.
+ **Couverture spatiale** : La requête a scanné l'ensemble de la plage spatiale (100 %) de la `raw-metrics` table. Cela suggère que le filtrage spatial n'est pas utilisé efficacement.

Si votre requête accède à plusieurs tables, query insights fournit les indicateurs de la table dont le modèle d'accès est le moins optimal.

## Optimisation de la requête pour la plage temporelle
<a name="optimize-query-temporal-range"></a>

Sur la base de la réponse de la requête Insights, vous pouvez optimiser la requête en fonction de la plage temporelle, comme indiqué dans l'exemple suivant.

```
SELECT am.time, am.state, am.total_energy_consumption, 
rm.time, rm.state, rm.device_id, rm.energy_consumption
FROM 
  "metrics"."aggregate-metrics" am
  LEFT JOIN "metrics"."raw-metrics" rm ON am.state = rm.state
WHERE 
  am.time >=  ago(23h) and am.time < now()
  AND rm.time >=  ago(1h) and rm.time < now()
  AND rm.state = 'Washington'
```

Si vous réexécutez la `QueryInsights` commande, elle renvoie la réponse suivante.

```
queryInsightsResponse={
                QuerySpatialCoverage: {
                    Max: {
                        Value: 1.0,
                        TableArn: arn:aws:timestream:us-east-1:123456789012:database/metrics/table/aggregate-metrics,
                        PartitionKey: [State]
                    }
                },
                QueryTemporalRange: {
                    Max: {
                        Value: 82800000000000 //23 hours,
                        TableArn: arn:aws:timestream:us-east-1:123456789012:database/metrics/table/aggregate-metrics
                    }
                },
                QueryTableCount: 2,
                OutputRows: 83,
                OutputBytes: 590
```

Cette réponse montre que la couverture spatiale de la `aggregate-metrics` table est toujours de 100 %, ce qui est inefficace. La section suivante montre comment optimiser la requête pour la couverture spatiale.

## Optimisation de la requête pour la couverture spatiale
<a name="optimize-query-spatial-coverage"></a>

Sur la base de la réponse à la requête Insights, vous pouvez optimiser la requête pour la couverture spatiale, comme indiqué dans l'exemple suivant.

```
SELECT am.time, am.state, am.total_energy_consumption, 
rm.time, rm.state, rm.device_id, rm.energy_consumption
FROM 
  "metrics"."aggregate-metrics" am
  LEFT JOIN "metrics"."raw-metrics" rm ON am.state = rm.state
WHERE 
  am.time >=  ago(23h) and am.time < now()
  AND am.state ='Washington'
  AND rm.time >=  ago(1h) and rm.time < now()
  AND rm.state = 'Washington'
```

Si vous réexécutez la `QueryInsights` commande, elle renvoie la réponse suivante.

```
queryInsightsResponse={
                QuerySpatialCoverage: {
                    Max: {
                        Value: 0.02,
                        TableArn: arn:aws:timestream:us-east-1:123456789012:database/metrics/table/aggregate-metrics,
                        PartitionKey: [State]
                    }
                },
                QueryTemporalRange: {
                    Max: {
                        Value: 82800000000000 //23 hours,
                        TableArn: arn:aws:timestream:us-east-1:123456789012:database/metrics/table/aggregate-metrics
                    }
                },
                QueryTableCount: 2,
                OutputRows: 83,
                OutputBytes: 590
```

## Performances de requête améliorées
<a name="improved-query-performance"></a>

Une fois la requête optimisée, Query Insights fournit les informations suivantes :
+ L'élagage temporel de la `aggregate-metrics` table est de 23 heures. Cela indique que seules 23 heures de la plage temporelle sont scannées.
+ L'élagage spatial de la `aggregate-metrics` table est de 0,02. Cela indique que seulement 2 % des données de plage spatiale de la table sont numérisées. La requête analyse une très petite partie des tables, ce qui améliore les performances et réduit l'utilisation des ressources. L'efficacité améliorée de l'élagage indique que la requête est désormais optimisée en termes de performances.