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. # Écritures 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 à partir d'une seule série chronologique, and/or des points de données provenant de nombreuses 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 SDKs[AWS CLI](Tools.CLI.md)](getting-started-sdks.md)[AWS Lambda](Lambda.md), ou via [AWS IoT Core](IOT-Core.md)[Service géré Amazon pour Apache Flink](ApacheFlink.md),[Amazon Kinesis](Kinesis.md),[Amazon MSK](MSK.md), et[Telegraf open source](Telegraf.md). **Topics** + [Types de données](#writes.data-types) + [Aucune définition initiale du schéma](#writes.no-upfront-schema) + [Écrire des données (insertions et insertions)](#writes.writing-data-inserts-upserts) + [Cohérence éventuelle pour les lectures](#writes.eventual-consistency) + [Répartition des écritures par lots avec l'API WriteRecords](writes.batching-writes.md) + [Chargement par lots](batch-load-how.md) + [Choix entre le fonctionnement de WriteRecords l'API et le chargement par lots](writes.writes-or-batch-load.md) ## 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 norme IEEE 754 pour l'arithmétique binaire à virgule flottante. 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 `BIGINT``BOOLEAN`,`DOUBLE`,`VARCHAR`, et`TIMESTAMP`. | | TIMESTAMP | Représente une instance dans le temps en utilisant un temps de précision de nanoseconde en UTC, en suivant le temps écoulé depuis l'heure 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 à l'aide des opérations de AWS Management Console l'API Timestream pour Live SDKs Analytics ou Timestream pour Live Analytics. Pour plus d’informations, consultez [Créer une base de données](console_timestream.md#console_timestream.db.using-console) et [Création d’une table](console_timestream.md#console_timestream.table.using-console). 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, consultez [CreateTable](https://docs.aws.amazon.com/timestream/latest/developerguide/API_CreateTable.html), [WriteRecords](https://docs.aws.amazon.com/timestream/latest/developerguide/API_WriteRecords.html) et [PutObject](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html). **É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 à mesures multiples 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. **Topics** + [Enregistrements à mesures multiples](#writes.writing-data-multi-measure) + [Écrire des données avec un horodatage existant dans le passé ou dans le futur](#writes.timestamp-past-future) ### 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 données TIMESTAMP pour stocker plusieurs horodatages dans un enregistrement de série chronologique. Les attributs TIMESTAMP 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 données TIMESTAMP et des enregistrements à mesures multiples. Un enregistrement à mesures multiples peut avoir plusieurs attributs de type de données TIMESTAMP, en plus du champ horaire d'un enregistrement. Les attributs TIMESTAMP, dans un enregistrement multi-mesures, 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 qui s'exécute sur 200 instances EC2. 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 avec compare/contrast les deux approches. Pour chaque approche, nous formulons les hypothèses suivantes. + Chaque instance EC2 émet quatre mesures (video\$1start-up\$1time, rebuffering\$1ratio, video\$1playback\$1failures et average\$1frame\$1rate) et quatre dimensions (device\$1id, device\$1type, os\$1version 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\$1id, device\$1type, os\$1version 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 records = new ArrayList<>(); final long time = System.currentTimeMillis(); List 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\$1id | type\$1d'appareil | os\$1version | region | nom\$1mesure | value\$1mesure : :bigint | valeur\$1mesure : double | | --- | --- | --- | --- | --- | --- | --- | --- | | 2021-09-07 21:48:44.000000000 | 12345678 | iPhone 11 | 14,8 | us-east-1 | video\$1start\$1time | 200 | | | 2021-09-07 21:48:44.000000000 | 12345678 | iPhone 11 | 14,8 | us-east-1 | ratio de rebuffering\$1 | | 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\$1image moyen | | 0,85 | | 2021-09-07 21:53:44.000000000 | 12345678 | iPhone 11 | 14,8 | us-east-1 | video\$1start\$1time | 500 | | | 2021-09-07 21:53:44.000000000 | 12345678 | iPhone 11 | 14,8 | us-east-1 | ratio de rebuffering\$1 | | 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\$1image 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\$1 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\$1id, device\$1type, os\$1version 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 records = new ArrayList<>(); final long time = System.currentTimeMillis(); List 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\$1id | type\$1d'appareil | os\$1version | region | nom\$1mesure | video\$1start\$1time | ratio de rebuffering\$1 | video\$1playback\$1failures | cadre\$1image moyen | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | 2021-09-07 21:48:44.000000000 | 12345678 | iPhone 11 | 14,8 | us-east-1 | video\$1metrics | 200 | 0.5 | 0 | 0,85 | | 2021-09-07 21:53:44.000000000 | 12345678 | iPhone 11 | 14,8 | us-east-1 | video\$1metrics | 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\$1 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. + **Type de données TIMESTAMP pour les mesures** : vous pouvez utiliser le type de données TIMESTAMP pour stocker des données passées, présentes ou futures. Un enregistrement à mesures multiples peut avoir plusieurs attributs de type de données TIMESTAMP, en plus du champ horaire d'un enregistrement. Les attributs TIMESTAMP, dans un enregistrement multi-mesures, 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 données TIMESTAMP n'est pris en charge que pour les enregistrements à mesures multiples. ## Cohérence éventuelle pour les lectures 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. 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. # Répartition des écritures par lots avec l'API WriteRecords Amazon Timestream for Live Analytics vous permet d'écrire des points de données à partir d'une seule série chronologique, des points de données issus de nombreuses and/or séries en une seule demande d'écriture. Le regroupement de plusieurs points de données en une seule opération d'écriture est avantageux du point de vue des performances et des coûts. Consultez [Écritures](metering-and-pricing.writes.md) la section Mesurage et tarification pour plus de détails. **Note** Vos demandes d'écriture adressées à Timestream pour Live Analytics peuvent être limitées à mesure que Timestream for Live Analytics évolue pour s'adapter aux besoins d'ingestion de données de votre application. Si vos applications rencontrent des exceptions de limitation, vous devez continuer à envoyer des données au même débit (ou à un débit supérieur) pour permettre à Timestream for Live Analytics de s'adapter automatiquement aux besoins de votre application. # Chargement par lots Grâce au *chargement par lots* pour Amazon Timestream LiveAnalytics for, vous pouvez ingérer des fichiers CSV stockés dans Amazon S3 dans Timestream par lots. Grâce à cette nouvelle fonctionnalité, vous pouvez accéder à vos données dans Timestream LiveAnalytics sans avoir à utiliser d'autres outils ou à écrire du code personnalisé. Vous pouvez utiliser le chargement par lots pour compléter les données avec des temps d'attente flexibles, telles que les données qui ne sont pas immédiatement requises pour les requêtes ou les analyses. Vous pouvez créer des tâches de chargement par lots à AWS CLI l'aide AWS SDKs des AWS Management Console Pour plus d’informations, consultez [Utilisation du chargement par lots avec la console](batch-load-using-console.md), [En utilisant le chargement par lots avec le AWS CLI](batch-load-using-cli.md) et [En utilisant le chargement par lots avec AWS SDKs](batch-load-using-sdk.md). Pour plus d'informations sur le chargement par lots, consultez[Utilisation du chargement par lots dans Timestream pour LiveAnalytics](batch-load.md). # Choix entre le fonctionnement de WriteRecords l'API et le chargement par lots Grâce au fonctionnement de l' WriteRecords API, vous pouvez écrire les données de vos séries chronologiques de streaming dans Timestream LiveAnalytics telles qu'elles sont générées par votre système. En utilisant WriteRecords, vous pouvez ingérer en continu un seul point de données ou de petits lots de données en temps réel. Timestream for vous LiveAnalytics propose un schéma flexible qui détecte automatiquement les noms de colonnes et les types de données de votre Timestream pour les LiveAnalytics tables, en fonction des noms des dimensions et des types de données des points de données que vous spécifiez lorsque vous appelez des écritures dans la base de données. En revanche, le *chargement par lots* permet l'ingestion robuste de séries chronologiques par lots provenant de fichiers source (fichiers CSV) dans Timestream for LiveAnalytics, à l'aide d'un modèle de données que vous définissez. Voici quelques exemples d'utilisation du chargement par lots avec un fichier source : l'importation de données de séries chronologiques en masse pour l'évaluation de Timestream par le LiveAnalytics biais d'une preuve de concept, l'importation de données de séries chronologiques en masse depuis un appareil IoT resté hors ligne pendant un certain temps et la migration de données de séries chronologiques historiques d'Amazon S3 vers Timestream pour. LiveAnalytics Pour plus d'informations sur le chargement par lots, consultez[Utilisation du chargement par lots dans Timestream pour LiveAnalytics](batch-load.md). Les deux solutions sont sécurisées, fiables et performantes. **À utiliser WriteRecords lorsque :** + Diffusion en continu de plus petites quantités (moins de 10 Mo) de données par demande. + Remplissage de tables existantes. + Ingestion de données à partir d'un flux de log. + Réalisation d'analyses en temps réel. + Nécessitant une latence plus faible. **Utilisez le chargement par lots lorsque :** + Ingestion de volumes plus importants de données provenant d'Amazon S3 dans des fichiers CSV. Pour en savoir plus sur les limites, consultez [QuotasQuotas par défaut](ts-limits.md). + Remplissage de nouvelles tables, par exemple dans le cas d'une migration de données. + Enrichissement des bases de données avec des données historiques (ingestion dans de nouvelles tables). + Vous avez des données sources qui changent lentement ou pas du tout. + Les temps d'attente sont flexibles car une tâche de chargement par lots peut être en attente jusqu'à ce que les ressources soient disponibles, en particulier si vous chargez une très grande quantité de données. Le chargement par lots convient aux données qui n'ont pas besoin d'être facilement accessibles pour les requêtes ou les analyses afin d'apporter plus de clarté.