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. # Exemples de requêtes Cette section inclut des exemples de cas d'utilisation du langage de requête LiveAnalytics de Timestream for. **Topics** + [Requêtes simples](sample-queries.basic-scenarios.md) + [Requêtes avec fonctions de séries chronologiques](sample-queries.devops-scenarios.md) + [Requêtes avec fonctions d'agrégation](sample-queries.iot-scenarios.md) # Requêtes simples Ce qui suit permet d'obtenir les 10 derniers points de données ajoutés à une table. ``` SELECT * FROM . ORDER BY time DESC LIMIT 10 ``` Ce qui suit permet d'obtenir les 5 points de données les plus anciens pour une mesure spécifique. ``` SELECT * FROM . WHERE measure_name = '' ORDER BY time ASC LIMIT 5 ``` Ce qui suit fonctionne avec des horodatages à granularité nanoseconde. ``` SELECT now() AS time_now , now() - (INTERVAL '12' HOUR) AS twelve_hour_earlier -- Compatibility with ANSI SQL , now() - 12h AS also_twelve_hour_earlier -- Convenient time interval literals , ago(12h) AS twelve_hours_ago -- More convenience with time functionality , bin(now(), 10m) AS time_binned -- Convenient time binning support , ago(50ns) AS fifty_ns_ago -- Nanosecond support , now() + (1h + 50ns) AS hour_fifty_ns_future ``` Les valeurs de mesure pour les enregistrements à mesures multiples sont identifiées par le nom de colonne. Les valeurs de mesure pour les enregistrements à mesure unique sont identifiées par`measure_value::`, où se `` trouve l'un des `double` `bigint``boolean`, ou `varchar` comme décrit dans[Types de données pris en charge](supported-data-types.md). Pour plus d'informations sur la façon dont les valeurs de mesure sont modélisées, voir [Table unique ou tables multiples](https://docs.aws.amazon.com/timestream/latest/developerguide/data-modeling.html#data-modeling-multiVsinglerecords). Ce qui suit récupère les valeurs d'une mesure appelée `speed` à partir d'enregistrements de plusieurs mesures avec un `measure_name` de. `IoTMulti-stats` ``` SELECT speed FROM . where measure_name = 'IoTMulti-stats' ``` Ce qui suit récupère `double` les valeurs des enregistrements à mesure unique avec un `measure_name` de. `load` ``` SELECT measure_value::double FROM . WHERE measure_name = 'load' ``` # Requêtes avec fonctions de séries chronologiques **Topics** + [Exemple de jeu de données et de requêtes](#sample-queries.devops-scenarios.example) ## Exemple de jeu de données et de requêtes Vous pouvez utiliser Timestream LiveAnalytics pour comprendre et améliorer les performances et la disponibilité de vos services et applications. Vous trouverez ci-dessous un exemple de table et des exemples de requêtes exécutées sur cette table. La table `ec2_metrics` stocke les données de télémétrie, telles que l'utilisation du processeur et d'autres mesures provenant d'instances EC2. Vous pouvez consulter le tableau ci-dessous. | Heure | region | az | Hostname | nom\$1mesure | valeur\$1mesure : double | value\$1mesure : :bigint | | --- | --- | --- | --- | --- | --- | --- | | 2019-12-04 19:00:00.000 000000 | us-east-1 | us-east-1a | frontend 01 | utilisation du processeur | 35,1 | null | | 2019-12-04 19:00:00.000 000000 | us-east-1 | us-east-1a | frontend 01 | memory\$1utilization | 55,3 | null | | 2019-12-04 19:00:00.000 000000 | us-east-1 | us-east-1a | frontend 01 | network\$1bytes\$1in | null | 1 500 | | 2019-12-04 19:00:00.000 000000 | us-east-1 | us-east-1a | frontend 01 | octets\$1out du réseau | null | 6 700 | | 2019-12-04 19:00:00.000 000000 | us-east-1 | us-east-1b | frontend 02 | utilisation du processeur | 38,5 | null | | 2019-12-04 19:00:00.000 000000 | us-east-1 | us-east-1b | frontend 02 | memory\$1utilization | 58,4 | null | | 2019-12-04 19:00:00.000 000000 | us-east-1 | us-east-1b | frontend 02 | network\$1bytes\$1in | null | 23 000 | | 2019-12-04 19:00:00.000 000000 | us-east-1 | us-east-1b | frontend 02 | octets\$1out du réseau | null | 12 000 | | 2019-12-04 19:00:00.000 000000 | us-east-1 | us-east-1c | frontend 03 | utilisation du processeur | 45.0 | null | | 2019-12-04 19:00:00.000 000000 | us-east-1 | us-east-1c | frontend 03 | memory\$1utilization | 65,8 | null | | 2019-12-04 19:00:00.000 000000 | us-east-1 | us-east-1c | frontend 03 | network\$1bytes\$1in | null | 15 000 | | 2019-12-04 19:00:00.000 000000 | us-east-1 | us-east-1c | frontend 03 | octets\$1out du réseau | null | 836 000 | | 2019-12-04 19:00:05 000 000000 | us-east-1 | us-east-1a | frontend 01 | utilisation du processeur | 55,2 | null | | 2019-12-04 19:00:05 000 000000 | us-east-1 | us-east-1a | frontend 01 | memory\$1utilization | 75.0 | null | | 2019-12-04 19:00:05 000 000000 | us-east-1 | us-east-1a | frontend 01 | network\$1bytes\$1in | null | 1 245 | | 2019-12-04 19:00:05 000 000000 | us-east-1 | us-east-1a | frontend 01 | octets\$1out du réseau | null | 68 432 | | 2019-12-04 19:00:08 000 000000 | us-east-1 | us-east-1b | frontend 02 | utilisation du processeur | 65,6 | null | | 2019-12-04 19:00:08 000 000000 | us-east-1 | us-east-1b | frontend 02 | memory\$1utilization | 85,3 | null | | 2019-12-04 19:00:08 000 000000 | us-east-1 | us-east-1b | frontend 02 | network\$1bytes\$1in | null | 1 245 | | 2019-12-04 19:00:08 000 000000 | us-east-1 | us-east-1b | frontend 02 | octets\$1out du réseau | null | 68 432 | | 2019-12-04 19:00:20 000 000000 | us-east-1 | us-east-1c | frontend 03 | utilisation du processeur | 12.1 | null | | 2019-12-04 19:00:20 000 000000 | us-east-1 | us-east-1c | frontend 03 | memory\$1utilization | 32,0 | null | | 2019-12-04 19:00:20 000 000000 | us-east-1 | us-east-1c | frontend 03 | network\$1bytes\$1in | null | 1 400 | | 2019-12-04 19:00:20 000 000000 | us-east-1 | us-east-1c | frontend 03 | octets\$1out du réseau | null | 345 | | 2019-12-04 19:00:10 000 000000 | us-east-1 | us-east-1a | frontend 01 | utilisation du processeur | 15,3 | null | | 2019-12-04 19:00:10 000 000000 | us-east-1 | us-east-1a | frontend 01 | memory\$1utilization | 35,4 | null | | 2019-12-04 19:00:10 000 000000 | us-east-1 | us-east-1a | frontend 01 | network\$1bytes\$1in | null | 23 | | 2019-12-04 19:00:10 000 000000 | us-east-1 | us-east-1a | frontend 01 | octets\$1out du réseau | null | 0 | | 2019-12-04 19:00:16 000 000000 | us-east-1 | us-east-1b | frontend 02 | utilisation du processeur | 44.0 | null | | 2019-12-04 19:00:16 000 000000 | us-east-1 | us-east-1b | frontend 02 | memory\$1utilization | 64,2 | null | | 2019-12-04 19:00:16 000 000000 | us-east-1 | us-east-1b | frontend 02 | network\$1bytes\$1in | null | 1 450 | | 2019-12-04 19:00:16 000 000000 | us-east-1 | us-east-1b | frontend 02 | octets\$1out du réseau | null | 200 | | 2019-12-04 19:00:40.000 000000 | us-east-1 | us-east-1c | frontend 03 | utilisation du processeur | 66,4 | null | | 2019-12-04 19:00:40.000 000000 | us-east-1 | us-east-1c | frontend 03 | memory\$1utilization | 86,3 | null | | 2019-12-04 19:00:40.000 000000 | us-east-1 | us-east-1c | frontend 03 | network\$1bytes\$1in | null | 300 | | 2019-12-04 19:00:40.000 000000 | us-east-1 | us-east-1c | frontend 03 | octets\$1out du réseau | null | 423 | Trouvez l'utilisation moyenne du processeur, p90, p95 et p99 pour un hôte EC2 spécifique au cours des 2 dernières heures : ``` SELECT region, az, hostname, BIN(time, 15s) AS binned_timestamp, ROUND(AVG(measure_value::double), 2) AS avg_cpu_utilization, ROUND(APPROX_PERCENTILE(measure_value::double, 0.9), 2) AS p90_cpu_utilization, ROUND(APPROX_PERCENTILE(measure_value::double, 0.95), 2) AS p95_cpu_utilization, ROUND(APPROX_PERCENTILE(measure_value::double, 0.99), 2) AS p99_cpu_utilization FROM "sampleDB".DevOps WHERE measure_name = 'cpu_utilization' AND hostname = 'host-Hovjv' AND time > ago(2h) GROUP BY region, hostname, az, BIN(time, 15s) ORDER BY binned_timestamp ASC ``` Identifiez les hôtes EC2 dont l'utilisation du processeur est supérieure de 10 % ou plus à l'utilisation moyenne du processeur de l'ensemble du parc au cours des 2 dernières heures : ``` WITH avg_fleet_utilization AS ( SELECT COUNT(DISTINCT hostname) AS total_host_count, AVG(measure_value::double) AS fleet_avg_cpu_utilization FROM "sampleDB".DevOps WHERE measure_name = 'cpu_utilization' AND time > ago(2h) ), avg_per_host_cpu AS ( SELECT region, az, hostname, AVG(measure_value::double) AS avg_cpu_utilization FROM "sampleDB".DevOps WHERE measure_name = 'cpu_utilization' AND time > ago(2h) GROUP BY region, az, hostname ) SELECT region, az, hostname, avg_cpu_utilization, fleet_avg_cpu_utilization FROM avg_fleet_utilization, avg_per_host_cpu WHERE avg_cpu_utilization > 1.1 * fleet_avg_cpu_utilization ORDER BY avg_cpu_utilization DESC ``` Trouvez l'utilisation moyenne du processeur regroupée à intervalles de 30 secondes pour un hôte EC2 spécifique au cours des 2 dernières heures : ``` SELECT BIN(time, 30s) AS binned_timestamp, ROUND(AVG(measure_value::double), 2) AS avg_cpu_utilization FROM "sampleDB".DevOps WHERE measure_name = 'cpu_utilization' AND hostname = 'host-Hovjv' AND time > ago(2h) GROUP BY hostname, BIN(time, 30s) ORDER BY binned_timestamp ASC ``` Trouvez l'utilisation moyenne du processeur regroupée à intervalles de 30 secondes pour un hôte EC2 spécifique au cours des 2 dernières heures, en remplissant les valeurs manquantes à l'aide d'une interpolation linéaire : ``` WITH binned_timeseries AS ( SELECT hostname, BIN(time, 30s) AS binned_timestamp, ROUND(AVG(measure_value::double), 2) AS avg_cpu_utilization FROM "sampleDB".DevOps WHERE measure_name = 'cpu_utilization' AND hostname = 'host-Hovjv' AND time > ago(2h) GROUP BY hostname, BIN(time, 30s) ), interpolated_timeseries AS ( SELECT hostname, INTERPOLATE_LINEAR( CREATE_TIME_SERIES(binned_timestamp, avg_cpu_utilization), SEQUENCE(min(binned_timestamp), max(binned_timestamp), 15s)) AS interpolated_avg_cpu_utilization FROM binned_timeseries GROUP BY hostname ) SELECT time, ROUND(value, 2) AS interpolated_cpu FROM interpolated_timeseries CROSS JOIN UNNEST(interpolated_avg_cpu_utilization) ``` Trouvez l'utilisation moyenne du processeur regroupée à intervalles de 30 secondes pour un hôte EC2 spécifique au cours des 2 dernières heures, en remplissant les valeurs manquantes à l'aide d'une interpolation basée sur la dernière observation reportée : ``` WITH binned_timeseries AS ( SELECT hostname, BIN(time, 30s) AS binned_timestamp, ROUND(AVG(measure_value::double), 2) AS avg_cpu_utilization FROM "sampleDB".DevOps WHERE measure_name = 'cpu_utilization' AND hostname = 'host-Hovjv' AND time > ago(2h) GROUP BY hostname, BIN(time, 30s) ), interpolated_timeseries AS ( SELECT hostname, INTERPOLATE_LOCF( CREATE_TIME_SERIES(binned_timestamp, avg_cpu_utilization), SEQUENCE(min(binned_timestamp), max(binned_timestamp), 15s)) AS interpolated_avg_cpu_utilization FROM binned_timeseries GROUP BY hostname ) SELECT time, ROUND(value, 2) AS interpolated_cpu FROM interpolated_timeseries CROSS JOIN UNNEST(interpolated_avg_cpu_utilization) ``` # Requêtes avec fonctions d'agrégation Vous trouverez ci-dessous un exemple de jeu de données pour un scénario IoT illustrant des requêtes avec des fonctions agrégées. **Topics** + [Exemple de données](#sample-queries.iot-scenarios.example-data) + [Exemples de requêtes](#sample-queries.iot-scenarios.example-queries) ## Exemple de données Timestream vous permet de stocker et d'analyser les données des capteurs IoT telles que l'emplacement, la consommation de carburant, la vitesse et la capacité de charge d'une ou de plusieurs flottes de camions afin de permettre une gestion efficace de la flotte. Vous trouverez ci-dessous le schéma et certaines des données d'une table iot\$1trucks qui stocke des données télémétriques telles que l'emplacement, la consommation de carburant, la vitesse et la capacité de charge des camions. | Heure | truck\$1id | Marque | Modèle | Flotte | capacité\$1carburant | capacité\$1charge | nom\$1mesure | valeur\$1mesure : double | valeur\$1mesure : varchar | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | 2019-12-04 19:00:00.000 000000 | 123456781 | GMC | Astro | Alpha | 100 | 500 | lecture de carburant | 65,2 | null | | 2019-12-04 19:00:00.000 000000 | 123456781 | GMC | Astro | Alpha | 100 | 500 | charge | 400,0 | null | | 2019-12-04 19:00:00.000 000000 | 123456781 | GMC | Astro | Alpha | 100 | 500 | speed | 90,2 | null | | 2019-12-04 19:00:00.000 000000 | 123456781 | GMC | Astro | Alpha | 100 | 500 | location | null | 47,6062 M, 122,3321 W | | 2019-12-04 19:00:00.000 000000 | 123456782 | Kenworth | W900 | Alpha | 150 | 1 000 | lecture de carburant | 10.1 | null | | 2019-12-04 19:00:00.000 000000 | 123456782 | Kenworth | W900 | Alpha | 150 | 1 000 | charge | 950,3 | null | | 2019-12-04 19:00:00.000 000000 | 123456782 | Kenworth | W900 | Alpha | 150 | 1 000 | speed | 50,8 | null | | 2019-12-04 19:00:00.000 000000 | 123456782 | Kenworth | W900 | Alpha | 150 | 1 000 | location | null | 40,7128 degrés N, 74,0060 degrés W | ## Exemples de requêtes Obtenez une liste de tous les attributs et valeurs des capteurs surveillés pour chaque camion de la flotte. ``` SELECT truck_id, fleet, fuel_capacity, model, load_capacity, make, measure_name FROM "sampleDB".IoT GROUP BY truck_id, fleet, fuel_capacity, model, load_capacity, make, measure_name ``` Obtenez le dernier relevé de consommation de carburant de chaque camion de la flotte au cours des dernières 24 heures. ``` WITH latest_recorded_time AS ( SELECT truck_id, max(time) as latest_time FROM "sampleDB".IoT WHERE measure_name = 'fuel-reading' AND time >= ago(24h) GROUP BY truck_id ) SELECT b.truck_id, b.fleet, b.make, b.model, b.time, b.measure_value::double as last_reported_fuel_reading FROM latest_recorded_time a INNER JOIN "sampleDB".IoT b ON a.truck_id = b.truck_id AND b.time = a.latest_time WHERE b.measure_name = 'fuel-reading' AND b.time > ago(24h) ORDER BY b.truck_id ``` Identifiez les camions qui ont consommé peu de carburant (moins de 10 %) au cours des dernières 48 heures : ``` WITH low_fuel_trucks AS ( SELECT time, truck_id, fleet, make, model, (measure_value::double/cast(fuel_capacity as double)*100) AS fuel_pct FROM "sampleDB".IoT WHERE time >= ago(48h) AND (measure_value::double/cast(fuel_capacity as double)*100) < 10 AND measure_name = 'fuel-reading' ), other_trucks AS ( SELECT time, truck_id, (measure_value::double/cast(fuel_capacity as double)*100) as remaining_fuel FROM "sampleDB".IoT WHERE time >= ago(48h) AND truck_id IN (SELECT truck_id FROM low_fuel_trucks) AND (measure_value::double/cast(fuel_capacity as double)*100) >= 10 AND measure_name = 'fuel-reading' ), trucks_that_refuelled AS ( SELECT a.truck_id FROM low_fuel_trucks a JOIN other_trucks b ON a.truck_id = b.truck_id AND b.time >= a.time ) SELECT DISTINCT truck_id, fleet, make, model, fuel_pct FROM low_fuel_trucks WHERE truck_id NOT IN ( SELECT truck_id FROM trucks_that_refuelled ) ``` Trouvez la charge moyenne et la vitesse maximale de chaque camion au cours de la semaine écoulée : ``` SELECT bin(time, 1d) as binned_time, fleet, truck_id, make, model, AVG( CASE WHEN measure_name = 'load' THEN measure_value::double ELSE NULL END ) AS avg_load_tons, MAX( CASE WHEN measure_name = 'speed' THEN measure_value::double ELSE NULL END ) AS max_speed_mph FROM "sampleDB".IoT WHERE time >= ago(7d) AND measure_name IN ('load', 'speed') GROUP BY fleet, truck_id, make, model, bin(time, 1d) ORDER BY truck_id ``` Découvrez l'efficacité de chargement de chaque camion au cours de la semaine écoulée : ``` WITH average_load_per_truck AS ( SELECT truck_id, avg(measure_value::double) AS avg_load FROM "sampleDB".IoT WHERE measure_name = 'load' AND time >= ago(7d) GROUP BY truck_id, fleet, load_capacity, make, model ), truck_load_efficiency AS ( SELECT a.truck_id, fleet, load_capacity, make, model, avg_load, measure_value::double, time, (measure_value::double*100)/avg_load as load_efficiency -- , approx_percentile(avg_load_pct, DOUBLE '0.9') FROM "sampleDB".IoT a JOIN average_load_per_truck b ON a.truck_id = b.truck_id WHERE a.measure_name = 'load' ) SELECT truck_id, time, load_efficiency FROM truck_load_efficiency ORDER BY truck_id, time ```