Types de données Aucune définition initiale du schéma Écrire des données (insertions et insertions)Cohérence éventuelle pour les lectures

écrit

Vous pouvez collecter des séries chronologiques à partir d'appareils connectés, de systèmes informatiques et d'équipements industriels, et les écrire dans Timestream pour Live Analytics. Timestream for Live Analytics vous permet d'écrire des points de données d'une seule série chronologique et/ou des points de données de plusieurs séries dans une seule demande d'écriture lorsque les séries temporelles appartiennent à la même table. Pour vous faciliter la tâche, Timestream for Live Analytics propose un schéma flexible qui détecte automatiquement les noms de colonnes et les types de données de vos tables Timestream for Live Analytics en fonction des noms des dimensions et des types de données des valeurs de mesure que vous spécifiez lorsque vous appelez des écritures dans la base de données. Vous pouvez également écrire des lots de données dans Timestream pour Live Analytics.

Note

Timestream for Live Analytics prend en charge la sémantique de cohérence éventuelle pour les lectures. Cela signifie que lorsque vous interrogez des données immédiatement après avoir écrit un lot de données dans Timestream for Live Analytics, les résultats de la requête peuvent ne pas refléter les résultats d'une opération d'écriture récemment terminée. Les résultats peuvent également inclure des données périmées. De même, lors de l'écriture de données de séries chronologiques avec une ou plusieurs nouvelles dimensions, une requête peut renvoyer un sous-ensemble partiel de colonnes pendant une courte période. Si vous répétez ces requêtes après un court laps de temps, les résultats devraient renvoyer les données les plus récentes.

Vous pouvez écrire des données en utilisant le AWS SDKsAWS CLI, ou via AWS Lambda AWS IoT Core,Service géré Amazon pour Apache Flink,Amazon Kinesis,Amazon MSK, etTelegraf open source.

Rubriques

Types de données

Timestream for Live Analytics prend en charge les types de données suivants pour les écritures.

Type de données	Description
BIGINT	Représente un entier signé de 64 bits.
BOOLEAN	Représente les deux valeurs de vérité de la logique, à savoir vrai et faux.
DOUBLE	64 bits à précision variable implémentant la IEEE norme 754 pour l'arithmétique binaire à virgule flottante. Note Il existe des fonctions de langage de requête `Infinity` et des valeurs `NaN` doubles qui peuvent être utilisées dans les requêtes. Mais vous ne pouvez pas écrire ces valeurs dans Timestream.
VARCHAR	Données de caractères de longueur variable avec une longueur maximale facultative. La limite maximale est de 2 Ko.
MULTI	Type de données pour les enregistrements à mesures multiples. Ce type de données inclut une ou plusieurs mesures de type `BIGINTBOOLEAN`,`DOUBLE`,`VARCHAR`, et`TIMESTAMP`.
TIMESTAMP	Représente une instance dans le temps en utilisant une précision de nanosecondeUTC, en suivant le temps écoulé depuis l'époque d'Unix. Ce type de données n'est actuellement pris en charge que pour les enregistrements multi-mesures (c'est-à-dire dans les limites des valeurs de mesure du type`MULTI`). `YYYY-MM-DD hh:mm:ss.sssssssss` Écrit les horodatages de support compris entre`1970-01-01 00:00:00.000000000`. `2262-04-11 23:47:16.854775807`

Aucune définition initiale du schéma

Avant d'envoyer des données vers Amazon Timestream pour Live Analytics, vous devez créer une base de données et une table à AWS Management Console l'aide des opérations Timestream pour Live SDKs Analytics ou Timestream pour Live Analytics. API Pour plus d’informations, consultez Créer une base de données et Créer une table . Lors de la création de la table, il n'est pas nécessaire de définir le schéma dès le départ. Amazon Timestream for Live Analytics détecte automatiquement le schéma en fonction des mesures et des dimensions des points de données envoyés. Vous n'avez donc plus besoin de modifier votre schéma hors ligne pour l'adapter à l'évolution rapide de vos données de séries chronologiques.

Écrire des données (insertions et insertions)

L'opération d'écriture dans Amazon Timestream for Live Analytics vous permet d'insérer et de modifier des données. Par défaut, les écritures dans Amazon Timestream pour Live Analytics suivent la sémantique du premier auteur, selon laquelle les données sont stockées sous forme d'ajout uniquement et les enregistrements dupliqués sont rejetés. Alors que la sémantique du premier rédacteur gagne répond aux exigences de nombreuses applications de séries chronologiques, il existe des scénarios dans lesquels les applications doivent mettre à jour les enregistrements existants de manière idempotente et/ou écrire des données selon la sémantique du dernier rédacteur gagnant, dans lesquels l'enregistrement contenant la version la plus récente est stocké dans le service. Pour répondre à ces scénarios, Amazon Timestream for Live Analytics permet de modifier les données. Upsert est une opération qui insère un enregistrement dans le système lorsqu'il n'existe pas ou met à jour l'enregistrement lorsqu'il en existe un. Lorsque l'enregistrement est mis à jour, il est mis à jour de manière idempotente.

Il n'existe aucune opération de suppression au niveau de l'enregistrement. Mais les tables et les bases de données peuvent être supprimées.

Écrire des données dans la mémoire et dans la mémoire magnétique

Amazon Timestream for Live Analytics permet d'écrire des données directement dans la mémoire et dans la mémoire magnétique. La mémoire est optimisée pour les écritures de données à haut débit et la mémoire magnétique est optimisée pour les écritures à faible débit de données d'arrivée tardive.

Les données arrivées tardivement sont des données dont l'horodatage est antérieur à l'heure actuelle et en dehors de la période de conservation de la mémoire. Vous devez explicitement activer la possibilité d'écrire des données arrivées tardivement dans la mémoire magnétique en activant les écritures dans la mémoire magnétique pour la table. Est également défini lors de la création d'une table. MagneticStoreRejectedDataLocation Pour écrire dans le magasin magnétique, les appelants WriteRecords doivent disposer des S3:PutObject autorisations d'accès au compartiment S3 spécifié MagneticStoreRejectedDataLocation lors de la création de la table. Pour plus d'informations, reportez-vous aux WriteRecordssections CreateTable, et PutObject.

Écrire des données avec des enregistrements à mesure unique et des enregistrements à mesures multiples

Amazon Timestream for Live Analytics permet d'écrire des données à l'aide de deux types d'enregistrements, à savoir les enregistrements à mesure unique et les enregistrements à mesures multiples.

Enregistrements à mesure unique

Les enregistrements à mesure unique vous permettent d'envoyer une seule mesure par enregistrement. Lorsque des données sont envoyées à Timestream pour Live Analytics à l'aide de ce format, Timestream for Live Analytics crée une ligne de tableau par enregistrement. Cela signifie que si un appareil émet 4 mesures et que chaque métrique est envoyée sous la forme d'un enregistrement de mesure unique, Timestream for Live Analytics créera 4 lignes dans le tableau pour stocker ces données, et les attributs de l'appareil seront répétés pour chaque ligne. Ce format est recommandé lorsque vous souhaitez surveiller une seule métrique à partir d'une application ou lorsque votre application n'émet pas plusieurs métriques en même temps.

Enregistrements à mesures multiples

Avec les enregistrements à mesures multiples, vous pouvez stocker plusieurs mesures dans une seule ligne de tableau, au lieu de stocker une mesure par ligne de tableau. Les enregistrements multi-mesures vous permettent donc de migrer vos données existantes depuis des bases de données relationnelles vers Amazon Timestream for Live Analytics avec un minimum de modifications.

Vous pouvez également regrouper plus de données dans une seule demande d'écriture que dans des enregistrements à mesure unique. Cela augmente le débit et les performances d'écriture des données, tout en réduisant le coût des écritures de données. En effet, le fait de regrouper davantage de données dans une demande d'écriture permet à Amazon Timestream for Live Analytics d'identifier davantage de données reproductibles dans une seule demande d'écriture (le cas échéant) et de ne facturer qu'une seule fois pour les données répétées.

Rubriques

Enregistrements à mesures multiples
Écrire des données avec un horodatage existant dans le passé ou dans le futur

Enregistrements à mesures multiples

Avec les enregistrements à mesures multiples, vous pouvez stocker vos données de séries chronologiques dans un format plus compact dans la mémoire et le stockage magnétique, ce qui permet de réduire les coûts de stockage des données. En outre, le stockage de données compact permet d'écrire des requêtes plus simples pour la récupération de données, d'améliorer les performances des requêtes et de réduire le coût des requêtes.

En outre, les enregistrements à mesures multiples prennent également en charge le type de TIMESTAMP données permettant de stocker plusieurs horodatages dans un enregistrement de série chronologique. TIMESTAMPles attributs d'un enregistrement multi-mesures prennent en charge les horodatages futurs ou passés. Les enregistrements à mesures multiples contribuent donc à améliorer les performances, les coûts et la simplicité des requêtes, tout en offrant une plus grande flexibilité pour le stockage de différents types de mesures corrélées.

Avantages

Les avantages de l'utilisation d'enregistrements à mesures multiples sont les suivants.

Performances et coûts — Les enregistrements à mesures multiples vous permettent d'écrire plusieurs mesures de séries chronologiques en une seule demande d'écriture. Cela augmente le débit d'écriture et réduit également le coût des écritures. Avec les enregistrements à mesures multiples, vous pouvez stocker les données de manière plus compacte, ce qui permet de réduire les coûts de stockage des données. Le stockage compact des données des enregistrements à mesures multiples permet de réduire le nombre de données traitées par les requêtes. Ceci est conçu pour améliorer les performances globales des requêtes et contribuer à réduire le coût des requêtes.
Simplicité des requêtes : avec les enregistrements à mesures multiples, il n'est pas nécessaire d'écrire des expressions de table communes complexes (CTEs) dans une requête pour lire plusieurs mesures avec le même horodatage. Cela est dû au fait que les mesures sont stockées sous forme de colonnes dans une seule ligne de tableau. Les enregistrements multi-mesures permettent donc d'écrire des requêtes plus simples.
Flexibilité de modélisation des données — Vous pouvez écrire les futurs horodatages dans Timestream pour Live Analytics en utilisant le type de TIMESTAMP données et des enregistrements à mesures multiples. Un enregistrement à mesures multiples peut avoir plusieurs attributs de type de TIMESTAMP données, en plus du champ horaire d'un enregistrement. TIMESTAMPdans un enregistrement multi-mesures, les attributs peuvent être horodatés dans le futur ou dans le passé et se comporter comme le champ horaire, sauf que Timestream for Live Analytics n'indexe pas les valeurs de type TIMESTAMP dans un enregistrement multi-mesures.

Cas d’utilisation

Vous pouvez utiliser des enregistrements de mesures multiples pour toute application de séries chronologiques qui génère plusieurs mesures à partir du même appareil à un moment donné. Voici quelques exemples d'applications.

Une plateforme de streaming vidéo qui génère des centaines de métriques à un moment donné.
Dispositifs médicaux qui génèrent des mesures telles que le taux d'oxygène dans le sang, la fréquence cardiaque et le pouls.
Des équipements industriels tels que les plates-formes pétrolières qui génèrent des métriques, des capteurs de température et des capteurs météorologiques.
Autres applications conçues avec un ou plusieurs microservices.

Exemple : surveillance des performances et de l'état d'une application de streaming vidéo

Prenons l'exemple d'une application de streaming vidéo exécutée sur 200 EC2 instances. Vous souhaitez utiliser Amazon Timestream for Live Analytics pour stocker et analyser les métriques émises par l'application, afin de comprendre les performances et l'état de votre application, d'identifier rapidement les anomalies, de résoudre les problèmes et de découvrir des opportunités d'optimisation.

Nous modéliserons ce scénario avec des enregistrements à mesure unique et des enregistrements à mesures multiples, puis comparer/contraster les deux approches. Pour chaque approche, nous formulons les hypothèses suivantes.

Chaque EC2 instance émet quatre mesures (video_start-up_time, rebuffering_ratio, video_playback_failures et average_frame_rate) et quatre dimensions (device_id, device_type, os_version et region) par seconde.
Vous souhaitez stocker 6 heures de données dans la mémoire et 6 mois de données dans la mémoire magnétique.
Pour identifier les anomalies, vous avez configuré 10 requêtes exécutées toutes les minutes afin d'identifier toute activité inhabituelle au cours des dernières minutes. Vous avez également créé un tableau de bord avec huit widgets qui affichent les 6 dernières heures de données, afin que vous puissiez surveiller efficacement votre application. Ce tableau de bord est accessible à cinq utilisateurs à tout moment et est actualisé automatiquement toutes les heures.

Utilisation d'enregistrements de mesures uniques

Modélisation des données : avec des enregistrements à mesure unique, nous allons créer un enregistrement pour chacune des quatre mesures (temps de démarrage de la vidéo, taux de rebufférisation, échecs de lecture vidéo et fréquence d'images moyenne). Chaque enregistrement comportera les quatre dimensions (device_id, device_type, os_version et region) et un horodatage.

Écritures : lorsque vous écrivez des données dans Amazon Timestream pour Live Analytics, les enregistrements sont construits comme suit.


public void writeRecords() {
    System.out.println("Writing records");
    // Specify repeated values for all records
    List<Record> records = new ArrayList<>();
    final long time = System.currentTimeMillis();
 
    List<Dimension> dimensions = new ArrayList<>();
    
    final Dimension device_id = new Dimension().withName("device_id").withValue("12345678");
    final Dimension device_type = new Dimension().withName("device_type").withValue("iPhone 11");
    final Dimension os_version = new Dimension().withName("os_version").withValue("14.8");
    final Dimension region = new Dimension().withName("region").withValue("us-east-1");
 
    dimensions.add(device_id);
    dimensions.add(device_type);
    dimensions.add(os_version);
    dimensions.add(region);
 
    Record videoStartupTime = new Record()
        .withDimensions(dimensions)
        .withMeasureName("video_startup_time")
        .withMeasureValue("200")
        .withMeasureValueType(MeasureValueType.BIGINT)
        .withTime(String.valueOf(time));
    Record rebufferingRatio = new Record()
        .withDimensions(dimensions)
        .withMeasureName("rebuffering_ratio")
        .withMeasureValue("0.5")
        .withMeasureValueType(MeasureValueType.DOUBLE)
        .withTime(String.valueOf(time));
    Record videoPlaybackFailures = new Record()
        .withDimensions(dimensions)
        .withMeasureName("video_playback_failures")
        .withMeasureValue("0")
        .withMeasureValueType(MeasureValueType.BIGINT)
        .withTime(String.valueOf(time));
    Record averageFrameRate = new Record()
        .withDimensions(dimensions)
        .withMeasureName("average_frame_rate")
        .withMeasureValue("0.5")
        .withMeasureValueType(MeasureValueType.DOUBLE)
        .withTime(String.valueOf(time));

    records.add(videoStartupTime);
    records.add(rebufferingRatio); 
    records.add(videoPlaybackFailures);
    records.add(averageFrameRate);
 
    WriteRecordsRequest writeRecordsRequest = new WriteRecordsRequest()
        .withDatabaseName(DATABASE_NAME)
        .withTableName(TABLE_NAME)
        .withRecords(records);
 
    try {
      WriteRecordsResult writeRecordsResult = amazonTimestreamWrite.writeRecords(writeRecordsRequest);
      System.out.println("WriteRecords Status: " + writeRecordsResult.getSdkHttpMetadata().getHttpStatusCode());
    } catch (RejectedRecordsException e) {
      System.out.println("RejectedRecords: " + e);
      for (RejectedRecord rejectedRecord : e.getRejectedRecords()) {
        System.out.println("Rejected Index " + rejectedRecord.getRecordIndex() + ": "
            + rejectedRecord.getReason());
      }
      System.out.println("Other records were written successfully. ");
    } catch (Exception e) {
      System.out.println("Error: " + e);
    }
  }

Lorsque vous stockez des enregistrements à mesure unique, les données sont représentées logiquement comme suit.

Heure	device_id	type_d'appareil	os_version	region	nom_mesure	value_mesure : :bigint	valeur_mesure : double
2021-09-07 21:48:44.000000000	12345678	iPhone 11	14,8	us-east-1	video_start_time	200
2021-09-07 21:48:44.000000000	12345678	iPhone 11	14,8	us-east-1	ratio de rebuffering_		0.5
2021-09-07 21:48:44.000000000	12345678	iPhone 11	14,8	us-east-1	échecs de lecture vidéo	0
2021-09-07 21:48:44.000000000	12345678	iPhone 11	14,8	us-east-1	cadre_image moyen		0,85
2021-09-07 21:53:44.000000000	12345678	iPhone 11	14,8	us-east-1	video_start_time	500
2021-09-07 21:53:44.000000000	12345678	iPhone 11	14,8	us-east-1	ratio de rebuffering_		1.5
2021-09-07 21:53:44.000000000	12345678	iPhone 11	14,8	us-east-1	échecs de lecture vidéo	10
2021-09-07 21:53:44.000000000	12345678	iPhone 11	14,8	us-east-1	cadre_image moyen		0.2

Requêtes : vous pouvez écrire une requête qui récupère tous les points de données portant le même horodatage reçus au cours des 15 dernières minutes comme suit.


with cte_video_startup_time as ( SELECT time, device_id, device_type, os_version, region, measure_value::bigint as video_startup_time FROM table where time >= ago(15m) and measure_name=”video_startup_time”),
cte_rebuffering_ratio as ( SELECT time, device_id, device_type, os_version, region, measure_value::double as rebuffering_ratio FROM table where time >= ago(15m) and measure_name=”rebuffering_ratio”),
cte_video_playback_failures as ( SELECT time, device_id, device_type, os_version, region, measure_value::bigint as video_playback_failures FROM table where time >= ago(15m) and measure_name=”video_playback_failures”),
cte_average_frame_rate as ( SELECT time, device_id, device_type, os_version, region, measure_value::double as average_frame_rate FROM table where time >= ago(15m) and measure_name=”average_frame_rate”)
SELECT a.time, a.device_id, a.os_version, a.region, a.video_startup_time, b.rebuffering_ratio, c.video_playback_failures, d.average_frame_rate FROM cte_video_startup_time a, cte_buffering_ratio b, cte_video_playback_failures c, cte_average_frame_rate d WHERE
a.time = b.time AND a.device_id = b.device_id AND a.os_version = b.os_version AND a.region=b.region AND
a.time = c.time AND a.device_id = c.device_id AND a.os_version = c.os_version AND a.region=c.region AND
a.time = d.time AND a.device_id = d.device_id AND a.os_version = d.os_version AND a.region=d.region

Coût de la charge de travail : Le coût de cette charge de travail est estimé à 373,23$ par mois avec des enregistrements à mesure unique

Utilisation d'enregistrements à mesures multiples

Modélisation des données : avec les enregistrements à mesures multiples, nous allons créer un enregistrement contenant les quatre mesures (heure de démarrage de la vidéo, taux de rebufférisation, échecs de lecture vidéo et fréquence d'images moyenne), les quatre dimensions (device_id, device_type, os_version et region) et un horodatage.

Écritures : lorsque vous écrivez des données dans Amazon Timestream pour Live Analytics, les enregistrements sont construits comme suit.


public void writeRecords() {
    System.out.println("Writing records");
    // Specify repeated values for all records
    List<Record> records = new ArrayList<>();
    final long time = System.currentTimeMillis();
 
    List<Dimension> dimensions = new ArrayList<>();
    
    final Dimension device_id = new Dimension().withName("device_id").withValue("12345678");
    final Dimension device_type = new Dimension().withName("device_type").withValue("iPhone 11");
    final Dimension os_version = new Dimension().withName("os_version").withValue("14.8");
    final Dimension region = new Dimension().withName("region").withValue("us-east-1");
 
    dimensions.add(device_id);
    dimensions.add(device_type);
    dimensions.add(os_version);
    dimensions.add(region);
 
    Record videoMetrics = new Record()
        .withDimensions(dimensions)
        .withMeasureName("video_metrics")
        .withTime(String.valueOf(time));
        .withMeasureValueType(MeasureValueType.MULTI)
        .withMeasureValues(
          new MeasureValue()
        	.withName("video_startup_time")
        	.withValue("0")
        	.withValueType(MeasureValueType.BIGINT),
        	new MeasureValue()
		.withName("rebuffering_ratio")
        	.withValue("0.5")
        	.withType(MeasureValueType.DOUBLE),
          new MeasureValue()
        	.withName("video_playback_failures")
        	.withValue("0")
        	.withValueType(MeasureValueType.BIGINT),
		 new MeasureValue()
         	.withName("average_frame_rate")
        	.withValue("0.5")
        	.withValueType(MeasureValueType.DOUBLE))
 
    records.add(videoMetrics);
 
    WriteRecordsRequest writeRecordsRequest = new WriteRecordsRequest()
        .withDatabaseName(DATABASE_NAME)
        .withTableName(TABLE_NAME)
        .withRecords(records);
 
    try {
      WriteRecordsResult writeRecordsResult = amazonTimestreamWrite.writeRecords(writeRecordsRequest);
      System.out.println("WriteRecords Status: " + writeRecordsResult.getSdkHttpMetadata().getHttpStatusCode());
    } catch (RejectedRecordsException e) {
      System.out.println("RejectedRecords: " + e);
      for (RejectedRecord rejectedRecord : e.getRejectedRecords()) {
        System.out.println("Rejected Index " + rejectedRecord.getRecordIndex() + ": "
            + rejectedRecord.getReason());
      }
      System.out.println("Other records were written successfully. ");
    } catch (Exception e) {
      System.out.println("Error: " + e);
    }
  }

Lorsque vous stockez des enregistrements à mesures multiples, les données sont représentées logiquement comme suit.

Heure	device_id	type_d'appareil	os_version	region	nom_mesure	video_start_time	ratio de rebuffering_	video_playback_failures	cadre_image moyen
2021-09-07 21:48:44.000000000	12345678	iPhone 11	14,8	us-east-1	video_metrics	200	0.5	0	0,85
2021-09-07 21:53:44.000000000	12345678	iPhone 11	14,8	us-east-1	video_metrics	500	1.5	10	0.2

Requêtes : vous pouvez écrire une requête qui récupère tous les points de données portant le même horodatage reçus au cours des 15 dernières minutes comme suit.


SELECT time, device_id, device_type, os_version, region, video_startup_time, rebuffering_ratio, video_playback_failures, average_frame_rate FROM table where time >= ago(15m)

Coût de la charge de travail : Le coût de la charge de travail est estimé à 127,43$ avec des enregistrements à mesures multiples.

Note

Dans ce cas, l'utilisation d'enregistrements à mesures multiples réduit les dépenses mensuelles totales estimées de 2,5 fois, le coût d'écriture des données étant réduit de 3,3 fois, le coût de stockage réduit de 3,3 fois et le coût des requêtes réduit de 1,2 fois.

Écrire des données avec un horodatage existant dans le passé ou dans le futur

Timestream for Live Analytics permet d'écrire des données avec un horodatage situé en dehors de la fenêtre de rétention de la mémoire par le biais de différents mécanismes.

Écritures sur mémoire magnétique : vous pouvez écrire les données arrivées en retard directement dans la mémoire magnétique par le biais d'écritures sur mémoire magnétique. Pour utiliser les écritures en mémoire magnétique, vous devez d'abord activer les écritures en mémoire magnétique pour une table. Vous pouvez ensuite ingérer des données dans la table en utilisant le même mécanisme que celui utilisé pour écrire des données dans la mémoire. Amazon Timestream for Live Analytics inscrira automatiquement les données dans le magasin magnétique en fonction de son horodatage.

Note
La write-to-read latence de la mémoire magnétique peut atteindre 6 heures, contrairement à l'écriture de données dans la mémoire, où la write-to-read latence est inférieure à la seconde.
TIMESTAMPtype de données pour les mesures : vous pouvez utiliser le type de TIMESTAMP données pour stocker des données du passé, du présent ou du futur. Un enregistrement à mesures multiples peut avoir plusieurs attributs de type de TIMESTAMP données, en plus du champ horaire d'un enregistrement. TIMESTAMPdans un enregistrement multi-mesures, les attributs peuvent être horodatés dans le futur ou dans le passé et se comporter comme le champ horaire, sauf que Timestream for Live Analytics n'indexe pas les valeurs de type TIMESTAMP dans un enregistrement multi-mesures.

Note
Le type de TIMESTAMP données n'est pris en charge que pour les enregistrements à mesures multiples.

Cohérence éventuelle pour les lectures

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Architecture

Rédactions par lots