Amazon Timestream for LiveAnalytics に類似した機能をご希望の場合は Amazon Timestream for InfluxDB をご検討ください。リアルタイム分析に適した、シンプルなデータインジェストと 1 桁ミリ秒のクエリ応答時間を特徴としています。詳細については、[こちら](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html)を参照してください。 翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # writes 接続されたデバイス、IT システム、産業機器から時系列データを収集し、Timestream for LiveAnalytics に書き込むことができます。Timestream for LiveAnalytics では、時系列が同じテーブルに属している場合、単一の時系列からのデータポイントや、単一の書き込みリクエスト内にある多数の系列からのデータポイントを書き込むことができます。Timestream for LiveAnalytics には、データベースへの書き込みを呼び出すときに指定したメジャー値のディメンション名とデータ型に基づいて、Timestream for LiveAnalytics テーブルの列名とデータ型を自動検出する柔軟なスキーマが用意されています。また、データのバッチを Timestream for LiveAnalytics に書き込むこともできます。 **注記** Timestream for LiveAnalytics は、読み取りの結果整合性セマンティクスをサポートします。つまり、データのバッチを Timestream for LiveAnalytics に書き込んだ直後にデータをクエリする場合、クエリ結果は最近完了した書き込みオペレーションの結果を反映していない可能性があります。また、結果に古いデータが含まれている可能性もあります。同様に、1 つ以上の新しいディメンションを持つ時系列データを書き込むときに、クエリは列の一部のサブセットを短時間返すことができます。少し時間が経ってからこれらのクエリリクエストを繰り返すと、結果で最新のデータが返されます。 [AWS SDK](getting-started-sdks.md)、[AWS CLI](Tools.CLI.md)、または [AWS Lambda](Lambda.md)、[AWS IoT Core](IOT-Core.md)、[Amazon Managed Service for Apache Flink](ApacheFlink.md)、[Amazon Kinesis](Kinesis.md)、[Amazon MSK](MSK.md)、[オープンソース Telegraf](Telegraf.md) を使用してデータを書き込むことができます。 **Topics** + [データ型](#writes.data-types) + [事前スキーマ定義なし](#writes.no-upfront-schema) + [データの書き込み (挿入とアップサート)](#writes.writing-data-inserts-upserts) + [読み取りの結果整合性](#writes.eventual-consistency) + [WriteRecords API を使用した書き込みのバッチ処理](writes.batching-writes.md) + [バッチロード](batch-load-how.md) + [WriteRecords API オペレーションかバッチロードかの選択](writes.writes-or-batch-load.md) ## データ型 Timestream for LiveAnalytics は、書き込みに対して次のデータ型をサポートしています。 | データ型 | 説明 | | --- | --- | | BIGINT | 64 ビットの符号付き整数カウンターを表します。 | | BOOLEAN | ロジックの 2 つの真理値、つまり true と false を表します。 | | DOUBLE | 2 進浮動小数点演算規格 IEEE 標準 754 を実装する 64 ビット可変精度。 クエリで使用できる `Infinity` と `NaN` の倍精度浮動小数点数値向けのクエリ言語関数があります。ただし、これらの値を Timestream に書き込むことはできません。 | | VARCHAR | オプションの最大長が設定された可変長文字データ。最大は 2 KB です。 | | MULTI | マルチメジャーレコードのデータ型。このデータ型には、`BIGINT`、`BOOLEAN`、`DOUBLE`、`VARCHAR`、`TIMESTAMP` 型の 1 つ以上のメジャーが含まれます。 | | TIMESTAMP | UTC のナノ秒精度の時間を使用してインスタンスを時間で表し、Unix 時間を追跡します。このデータ型は現在、マルチメジャーレコード (`MULTI` 型のメジャー値内) でのみサポートされています。 `YYYY-MM-DD hh:mm:ss.sssssssss` `1970-01-01 00:00:00.000000000`～`2262-04-11 23:47:16.854775807` の範囲のサポートタイムスタンプを書き込みます。 | ## 事前スキーマ定義なし Amazon Timestream for Live Analytics にデータを送信する前に、 AWS マネジメントコンソール、Timestream for Live Analytics SDKsまたは Timestream for Live Analytics API オペレーションを使用してデータベースとテーブルを作成する必要があります。詳細については、「[データベースを作成する](console_timestream.md#console_timestream.db.using-console)」および「[テーブルを作成する](console_timestream.md#console_timestream.table.using-console)」を参照してください。テーブルの作成中に、スキーマを事前に定義する必要はありません。Amazon Timestream for LiveAnalytics は、送信されるデータポイントのメジャーとディメンションに基づいてスキーマを自動的に検出するため、急速に変化する時系列データに合わせてスキーマをオフラインで変更する必要がなくなりました。 ## データの書き込み (挿入とアップサート) Amazon Timestream for LiveAnalytics の書き込みオペレーションを使用すると、データを挿入および*アップサート*できます。デフォルトでは、Amazon Timestream for LiveAnalytics での書き込みは、*first writer wins* セマンティクスに従います。このセマンティクスでは、データは追加としてのみ保存され、重複したレコードは拒否されます。first writer wins セマンティクスは、多くの時系列アプリケーションの要件を満たしますが、アプリケーションがべき等性を持つ方法で既存のレコードを更新したり、last writer wins セマンティクスでデータを書き込んだりする必要があるシナリオでは、最も新しいバージョンのレコードがサービスに保存されます。これらのシナリオに対応するため、Amazon Timestream for LiveAnalytics はデータをアップサートする機能を提供します。アップサートは、レコードが存在しない場合はシステムにレコードを挿入し、存在する場合はレコードを更新するオペレーションです。レコードが更新されると、べき等性を持つ方法で更新されます。 削除するためのレコードレベルのオペレーションはありません。ただし、テーブルとデータベースは削除できます。 **メモリストアとマグネティックストアへのデータの書き込み** Amazon Timestream for LiveAnalytics では、データをメモリストアとマグネティックストアに直接書き込むことができます。メモリストアは高スループットのデータ書き込みに最適化され、マグネティックストアは遅延到着データの低スループット書き込みに最適化されています。 遅延受信データは、タイムスタンプが現在の時刻より前で、メモリストアの保持期間外のデータです。テーブルのマグネティックストア書き込みを有効にすることで、遅延到着データをマグネティックストアに書き込む機能を明示的に有効にする必要があります。また、`MagneticStoreRejectedDataLocation` はテーブルの作成時に定義されます。マグネティックストアに書き込むには、`WriteRecords` の呼び出し元に、テーブルの作成時に `MagneticStoreRejectedDataLocation` で指定された S3 バケットへの `S3:PutObject` アクセス許可が必要です。詳細については、「[CreateTable](https://docs.aws.amazon.com/timestream/latest/developerguide/API_CreateTable.html)」「[WriteRecords](https://docs.aws.amazon.com/timestream/latest/developerguide/API_WriteRecords.html)」「[PutObject](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html)」を参照してください。 **単一メジャーレコードとマルチメジャーレコードを使用したデータの書き込み** Amazon Timestream for LiveAnalytics では、単一メジャーレコードとマルチメジャーレコードの 2 種類のレコードを使用してデータを書き込むことができます。 **単一メジャーレコード** 単一メジャーレコードを使用すると、レコードごとに 1 つのメジャーを送信できます。この形式を使用してデータを Timestream for LiveAnalytics に送信すると、Timestream for LiveAnalytics はレコードごとに単一のテーブル行を作成します。つまり、デバイスが 4 つのメトリクスを出力し、各メトリクスが単一メジャーレコードとして送信されると、Timestream for LiveAnalytics はテーブルに 4 行を作成してこのデータを保存し、デバイス属性を行ごとに繰り返します。この形式は、アプリケーションの単一のメトリクスをモニタリングする場合や、アプリケーションが同時に複数のメトリクスを出力しない場合に推奨されます。 **マルチメジャーレコード** マルチメジャーレコードを使用すると、テーブル行ごとに単一のメジャーを保存するのではなく、複数のメジャーを単一のテーブル行に保存できます。したがって、マルチメジャーレコードを使用すると、最小限の変更で既存のデータをリレーショナルデータベースから Amazon Timestream for LiveAnalytics に移行できます。 単一メジャーレコードよりも多くのデータを 1 回の書き込みリクエストでバッチ処理することもできます。これにより、データ書き込みスループットとパフォーマンスが向上し、データ書き込みのコストも削減されます。なぜなら、書き込みリクエストでより多くのデータをバッチ処理することで、Amazon Timestream for LiveAnalytics は 1 回の書き込みリクエスト (該当する場合) でより多くの繰り返し可能なデータを識別し、繰り返しデータに対して 1 回だけ課金するためです。 **Topics** + [マルチメジャーレコード](#writes.writing-data-multi-measure) + [過去または将来に存在するタイムスタンプ付きのデータの書き込み](#writes.timestamp-past-future) ### マルチメジャーレコード マルチメジャーレコードを使用すると、時系列データをよりコンパクトな形式でメモリとマグネティックストアに保存できるため、データストレージコストを削減できます。また、コンパクトなデータストレージは、データ取得のためのより簡単なクエリの書き込みに役立ち、クエリのパフォーマンスを向上させ、クエリのコストを削減します。 さらに、マルチメジャーレコードは、時系列レコードに複数のタイムスタンプを保存するための TIMESTAMP データ型もサポートしています。マルチメジャーレコードの TIMESTAMP 属性は、将来または過去のタイムスタンプをサポートします。したがって、マルチメジャーレコードは、パフォーマンス、コスト、クエリのシンプルさの向上に役立ち、さまざまなタイプの相関メジャーをより柔軟に格納できます。 **利点** マルチメジャーレコードを使用する利点は次のとおりです。 + **パフォーマンスとコスト** – マルチメジャーレコードを使用すると、1 回の書き込みリクエストで複数の時系列メジャーを書き込むことができます。これにより、書き込みスループットが向上し、書き込みのコストも削減されます。マルチメジャーレコードを使用すると、データをよりコンパクトな方法で保存できるため、データストレージコストを削減できます。マルチメジャーレコードのコンパクトなデータストレージにより、クエリによって処理されるデータが少なくなります。これは、全体的なクエリパフォーマンスを向上させ、クエリコストを削減するように設計されています。 + **クエリのシンプルさ** – マルチメジャーレコードでは、同じタイムスタンプで複数のメジャーを読み取るために、クエリに複雑な共通テーブル式 (CTE) を記述する必要はありません。これは、メジャーが 1 つのテーブル行に列として保存されるためです。したがって、マルチメジャーレコードを使用すると、より簡単なクエリを記述できます。 + **データモデリングの柔軟性** – TIMESTAMP データ型とマルチメジャーレコードを使用して、将来のタイムスタンプを Timestream for LiveAnalytics に書き込むことができます。マルチメジャーレコードには、レコードの時間フィールドに加えて、TIMESTAMP データ型の複数の属性を含めることができます。マルチメジャーレコードの TIMESTAMP 属性は、将来または過去のタイムスタンプを持つことができ、Timestream for LiveAnalytics がマルチメジャーレコードの TIMESTAMP タイプの値に対してインデックスを作成しない点を除いて、時間フィールドのように動作します。 **ユースケース** マルチメジャーレコードは、同じデバイスから一度に複数の測定値を生成する任意の時系列アプリケーションに使用できます。以下は、いくつかのアプリケーションの例です。 + 一度に数百のメトリクスを生成する動画ストリーミングプラットフォーム。 + 血圧、心拍数、脈拍などの測定値を生成する医療デバイス。 + メトリクスを生成する石油リグなどの産業機器、温度、気象センサー。 + 1 つ以上のマイクロサービスで設計されているその他のアプリケーション。 #### 例: 動画ストリーミングアプリケーションのパフォーマンスと状態のモニタリング 200 個の EC2 インスタンスで実行されている動画ストリーミングアプリケーションを考えてみましょう。Amazon Timestream for LiveAnalytics を使用してアプリケーションから出力されるメトリクスを保存および分析すると、アプリケーションのパフォーマンスと状態を把握し、異常をすばやく特定して問題を解決し、最適化の機会を発見できます。 このシナリオを単一メジャーレコードとマルチメジャーレコードでモデリングし、両方のアプローチを比較/対照します。アプローチごとに、以下の前提があります。 + 各 EC2 インスタンスは、毎秒 4 つのメジャー (video\$1startup\$1time、rebuffering\$1ratio、video\$1playback\$1failures、average\$1frame\$1rate) と 4 つのディメンション (device\$1id、device\$1type、os\$1version、region) を出力します。 + 6 時間のデータをメモリストアに保存し、6 か月のデータをマグネティックストアに保存します。 + 異常を特定するため、毎分実行される 10 個のクエリを設定して、過去数分間の異常なアクティビティを特定します。また、過去 6 時間のデータを表示する 8 つのウィジェットを含むダッシュボードを構築して、アプリケーションを効果的にモニタリングできるようにしました。このダッシュボードには、いつでも 5 人のユーザーがアクセスし、1 時間ごとに自動更新されます。 ##### 単一メジャーレコードの使用 **データモデリング**: 単一メジャーレコードでは、4 つのメジャー (動画の起動時間、再バッファリング率、動画再生失敗、平均フレームレート) ごとに 1 つのレコードを作成します。各レコードには、4 つのディメンション (device\$1id、device\$1type、os\$1version、region) とタイムスタンプがあります。 **書き込み**: Amazon Timestream for LiveAnalytics にデータを書き込むと、レコードは次のように構築されます。 ``` 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); } } ``` 単一メジャーレコードを保存すると、データは次のように論理的に表されます。 | Time | device\$1id | device\$1type | os\$1version | リージョン | measure\$1name | measure\$1value::bigint | measure\$1value::double | | --- | --- | --- | --- | --- | --- | --- | --- | | 2021-09-07 21:48:44 .000000000 | 12345678 | iPhone 11 | 14.8 | us–east–1 | video\$1startup\$1time | 200 | | | 2021-09-07 21:48:44 .000000000 | 12345678 | iPhone 11 | 14.8 | us–east–1 | rebuffering\$1ratio | | 0.5 | | 2021-09-07 21:48:44 .000000000 | 12345678 | iPhone 11 | 14.8 | us–east–1 | video\$1playback\$1failures | 0 | | | 2021-09-07 21:48:44 .000000000 | 12345678 | iPhone 11 | 14.8 | us–east–1 | average\$1frame\$1rate | | 0.85 | | 2021-09-07 21:53:44 .000000000 | 12345678 | iPhone 11 | 14.8 | us–east–1 | video\$1startup\$1time | 500 | | | 2021-09-07 21:53:44 .000000000 | 12345678 | iPhone 11 | 14.8 | us–east–1 | rebuffering\$1ratio | | 1.5 | | 2021-09-07 21:53:44 .000000000 | 12345678 | iPhone 11 | 14.8 | us–east–1 | video\$1playback\$1failures | 10 | | | 2021-09-07 21:53:44 .000000000 | 12345678 | iPhone 11 | 14.8 | us–east–1 | average\$1frame\$1rate | | 0.2 | **クエリ**: 次のように、過去 15 分間に受信したのと同じタイムスタンプを持つすべてのデータポイントを取得するクエリを記述できます。 ``` 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 ``` **ワークロードコスト**: このワークロードのコストは、単一メジャーレコードでは月あたり 373.23 USD と推定されます。 ##### マルチメジャーレコードの使用 **データモデリング**: マルチメジャーレコードでは、4 つのメジャーすべて (動画の起動時間、再バッファリング率、動画再生失敗、平均フレームレート)、4 つのディメンションすべて (device\$1id、device\$1type、os\$1version、region)、タイムスタンプを含む単一のレコードを作成します。 **書き込み**: Amazon Timestream for LiveAnalytics にデータを書き込むと、レコードは次のように構築されます。 ``` 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); } } ``` マルチメジャーレコードを保存すると、データは次のように論理的に表されます。 | Time | device\$1id | device\$1type | os\$1version | リージョン | measure\$1name | video\$1startup\$1time | rebuffering\$1ratio | video\$1 playback\$1failures | average\$1frame\$1rate | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | 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 | **クエリ**: 次のように、過去 15 分間に受信したのと同じタイムスタンプを持つすべてのデータポイントを取得するクエリを記述できます。 ``` 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) ``` **ワークロードコスト**: ワークロードのコストは、マルチメジャーレコードでは 127.43 USD と推定されます。 **注記** この場合、マルチメジャーレコードを使用すると、全体的な推定月額支出が 1/2.5 に削減され、データ書き込みコストが 1/3.3、ストレージコストが 1/3.3、クエリコストが 1/1.2 に削減されます。 ### 過去または将来に存在するタイムスタンプ付きのデータの書き込み Timestream for LiveAnalytics では、いくつかの異なるメカニズムを使用して、メモリストアの保持期間外にあるタイムスタンプでデータを書き込むことができます。 + **マグネティックストアの書き込み** – マグネティックストアの書き込みを通じて、遅延到着データをマグネティックストアに直接書き込むことができます。マグネティックストア書き込みを使用するには、まずテーブルのマグネティックストア書き込みを有効にする必要があります。その後、メモリストアにデータを書き込むのと同じメカニズムを使用して、テーブルにデータを取り込むことができます。Amazon Timestream for LiveAnalytics は、タイムスタンプに基づいてデータを自動的にマグネティックストアに書き込みます。 **注記** マグネティックストアの書き込みから読み取りまでのレイテンシーは最大 6 時間で、書き込みから読み取りのレイテンシーが 1 秒未満のメモリストアへのデータ書き込みとは異なります。 + **メジャーの TIMESTAMP データ型** – TIMESTAMP データ型を使用して、過去、現在、または将来のデータを保存できます。マルチメジャーレコードには、レコードの時間フィールドに加えて、TIMESTAMP データ型の複数の属性を含めることができます。マルチメジャーレコードの TIMESTAMP 属性は、将来または過去のタイムスタンプを持つことができ、Timestream for LiveAnalytics がマルチメジャーレコードの TIMESTAMP タイプの値に対してインデックスを作成しない点を除いて、時間フィールドのように動作します。 **注記** TIMESTAMP データ型は、マルチメジャーレコードでのみサポートされています。 ## 読み取りの結果整合性 Timestream for LiveAnalytics は、読み取りの結果整合性セマンティクスをサポートします。つまり、データのバッチを Timestream for LiveAnalytics に書き込んだ直後にデータをクエリする場合、クエリ結果は最近完了した書き込みオペレーションの結果を反映していない可能性があります。少し時間が経ってからこれらのクエリリクエストを繰り返すと、結果で最新のデータが返されます。 # WriteRecords API を使用した書き込みのバッチ処理 Amazon Timestream for LiveAnalytics を使用すると、単一の時系列のデータポイントや、単一の書き込みリクエストで多数の系列のデータポイントを書き込むことができます。単一の書き込みオペレーションで複数のデータポイントをバッチ処理することは、パフォーマンスとコストの観点から有益です。詳細については、「メータリングとコスト最適化」セクションの「[writes](metering-and-pricing.writes.md)」を参照してください。 **注記** Timestream for LiveAnalytics への書き込みリクエストは、Timestream for LiveAnalytics がアプリケーションのデータインジェストニーズに適応するようにスケールするとスロットリングされる場合があります。アプリケーションでスロットリング例外が発生した場合は、引き続き同じ (またはそれ以上の) スループットでデータを送信して、Timestream for LiveAnalytics がアプリケーションのニーズに自動的にスケールできるようにする必要があります。 # バッチロード Amazon Timestream for LiveAnalytics の*バッチロード*を使用すると、Amazon S3 に保存されている CSV ファイルをバッチで Timestream に取り込むことができます。この新機能により、他のツールに頼ったり、カスタムコードを記述したりすることなく、Timestream for LiveAnalytics でデータを取得できます。バッチロードを使用して、クエリや分析にすぐに必要ではないデータなどを、柔軟な待機時間でバックフィルできます。 バッチロードタスクは AWS マネジメントコンソール、、 AWS CLI、 AWS SDKs を使用して作成できます。詳細については[コンソールでのバッチロードの使用](batch-load-using-console.md)、[でのバッチロードの使用 AWS CLI](batch-load-using-cli.md)、および[AWS SDKs](batch-load-using-sdk.md)を参照してください。 バッチロードの詳細については、「[Timestream for LiveAnalytics でのバッチロードの使用](batch-load.md)」を参照してください。 # WriteRecords API オペレーションかバッチロードかの選択 WriteRecords API オペレーションを使用すると、システムによって生成されたストリーミング時系列データを Timestream for LiveAnalytics に書き込むことができます。WriteRecords を使用すると、単一のデータポイントまたは小さなデータバッチをリアルタイムで継続的に取り込むことができます。Timestream for LiveAnalytics には、データベースへの書き込みを呼び出すときに指定したデータポイントのディメンション名とデータ型に基づいて、Timestream for LiveAnalytics テーブルの列名とデータ型を自動検出する柔軟なスキーマが用意されています。 対照的に、*バッチロード*を使用すると、定義したデータモデルを使用して、バッチ処理された時系列データをソースファイル (CSV ファイル) から Timestream for LiveAnalytics に堅牢に取り込むことができます。ソースファイルでバッチロードを使用する場合の例として、概念実証を通じて Timestream for LiveAnalytics を評価するために時系列データを一括でインポートする、しばらくオフラインだった IoT デバイスから時系列データを一括でインポートする、Amazon S3 から Timestream for LiveAnalytics に履歴時系列データを移行するなどがあります。バッチロードの情報については、「[Timestream for LiveAnalytics でのバッチロードの使用](batch-load.md)」を参照してください。 どちらのソリューションも安全で信頼性が高く、パフォーマンスに優れています。 **WriteRecords を使用すべき場合:** + リクエストごとの少量 (10 MB 未満) のデータストリーミング。 + 既存のテーブルの入力。 + ログストリームからのデータインジェスト。 + リアルタイム分析の実行。 + 低レイテンシーが必要。 **バッチロードを使用すべき場合:** + CSV ファイルで Amazon S3 から送信される大量のデータのインジェスト。制限事項の詳細については、「[クォータデフォルトのクォータ](ts-limits.md)」を参照してください。 + データ移行などにおける新しいテーブルの入力。 + 履歴データによるデータベースのエンリッチメント (新しいテーブルへのインジェスト)。 + ソースデータの変更が遅い、またはまったくない。 + バッチロードタスクは、特に大量のデータをロードする場合、リソースが利用可能になるまで保留状態になることがあるため、待機時間が柔軟です。バッチロードは、より明確にするためにクエリや分析にすぐに利用できる必要がないデータに適しています。