バッチロードのベストプラクティス - Amazon Timestream

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

バッチロードのベストプラクティス

バッチロードは、次の条件と推奨事項に従う場合に最適です (高スループット)。

  1. 並列処理と取り込み速度を向上させるために、取り込み用に送信されるCSVファイルは小さく、特にファイルサイズは 100MB~1 GB です。

  2. バッチロードの進行中に同じテーブルに同時にデータを取り込まないでください (API WriteRecords オペレーションやスケジュールされたクエリを使用するなど)。これによりスロットリングが発生し、バッチロードタスクが失敗する可能性があります。

  3. バッチロードタスクの実行中に、バッチロードで使用される S3 バケットからファイルを追加、変更、または削除しないでください。

  4. テーブルまたはソースからアクセス許可を削除または取り消したり、バッチロードタスクがスケジュールされているか進行中の S3 バケットをレポートしたりしないでください。

  5. カーディナリティの高いディメンション値のセットを持つデータを取り込む場合は、「」のガイダンスに従ってください複数メジャーレコードのパーティション化に関する推奨事項

  6. 小さなファイルを送信して、データの正確性をテストしてください。バッチロードに送信されたデータについては、正確性に関係なく課金されます。料金の詳細については、「Amazon Timestream の料金」を参照してください。

  7. ActiveMagneticStorePartitions が 250 未満でない限り、バッチロードタスクを再開しないでください。ジョブがスロットリングされて失敗する可能性があります。同じデータベースに対して複数のジョブを同時に送信すると、その数は減ります。

コンソールのベストプラクティスは次のとおりです。

  1. ビルダーは、複数メジャーレコードにメジャー名を 1 つだけ使用する、より単純なデータモデリングにのみ使用します。

  2. より複雑なデータモデリングには、JSON を使用します。例えば、複数メジャーレコードを使用するときに複数のメジャー名を使用する場合は、JSON を使用します。

Timestream for LiveAnalytics のその他のベストプラクティスについては、「」を参照してくださいベストプラクティス