Untuk kemampuan serupa dengan Amazon Timestream LiveAnalytics, pertimbangkan Amazon Timestream untuk InfluxDB. Ini menawarkan konsumsi data yang disederhanakan dan waktu respons kueri milidetik satu digit untuk analitik waktu nyata. Pelajari lebih lanjut [di sini](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html). Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Menulis Anda dapat mengumpulkan data deret waktu dari perangkat yang terhubung, sistem TI, dan peralatan industri, dan menuliskannya ke Timestream untuk Live Analytics. Timestream untuk Live Analytics memungkinkan Anda menulis titik data dari satu titik and/or data deret waktu dari banyak seri dalam satu permintaan tulis ketika deret waktu termasuk dalam tabel yang sama. Demi kenyamanan Anda, Timestream for Live Analytics menawarkan skema fleksibel yang secara otomatis mendeteksi nama kolom dan tipe data untuk tabel Timestream untuk Live Analytics Anda berdasarkan nama dimensi dan tipe data dari nilai ukuran yang Anda tentukan saat menjalankan penulisan ke dalam database. Anda juga dapat menulis kumpulan data ke Timestream untuk Live Analytics. **catatan** Timestream untuk Live Analytics mendukung semantik konsistensi akhir untuk pembacaan. Ini berarti bahwa ketika Anda melakukan kueri data segera setelah menulis kumpulan data ke Timestream for Live Analytics, hasil kueri mungkin tidak mencerminkan hasil operasi penulisan yang baru saja selesai. Hasilnya mungkin juga mencakup beberapa data basi. Demikian pula, saat menulis data deret waktu dengan satu atau lebih dimensi baru, kueri dapat mengembalikan sebagian bagian kolom untuk waktu yang singkat. Jika Anda mengulangi permintaan kueri ini setelah waktu yang singkat, hasilnya akan mengembalikan data terbaru. Anda dapat menulis data menggunakan [AWS SDKs](getting-started-sdks.md),, [AWS CLI](Tools.CLI.md), atau melalui [AWS Lambda](Lambda.md)[AWS IoT Core](IOT-Core.md),[Layanan Terkelola Amazon untuk Apache Flink](ApacheFlink.md),[Amazon Kinesis](Kinesis.md),[Amazon MSK](MSK.md), dan[Telegraf sumber terbuka](Telegraf.md). **Topics** + [Jenis Data](#writes.data-types) + [Tidak ada definisi skema di muka](#writes.no-upfront-schema) + [Menulis data (sisipan dan upserts)](#writes.writing-data-inserts-upserts) + [Konsistensi akhir untuk membaca](#writes.eventual-consistency) + [Batching menulis dengan API WriteRecords](writes.batching-writes.md) + [Beban batch](batch-load-how.md) + [Memilih antara operasi WriteRecords API dan pemuatan batch](writes.writes-or-batch-load.md) ## Jenis Data Timestream untuk Live Analytics mendukung tipe data berikut untuk penulisan. | Jenis data | Deskripsi | | --- | --- | | BIGINT | Merupakan integer bertanda 64-bit. | | BOOLEAN | Merupakan dua nilai kebenaran logika, yaitu benar, dan salah. | | DOUBLE | Presisi variabel 64-bit mengimplementasikan IEEE Standard 754 untuk Binary Floating-Point Arithmetic. Ada fungsi bahasa query untuk `Infinity` dan nilai `NaN` ganda yang dapat digunakan dalam query. Tetapi Anda tidak dapat menulis nilai-nilai itu ke Timestream. | | VARCHAR | Data karakter panjang variabel dengan panjang maksimum opsional. Batas maksimum adalah 2 KB. | | MULTI | Tipe data untuk catatan multi-ukuran. Tipe data ini mencakup satu atau lebih ukuran tipe`BIGINT`,`BOOLEAN`,`DOUBLE`,`VARCHAR`, dan`TIMESTAMP`. | | TIMESTAMP | Merupakan instance dalam waktu menggunakan waktu presisi nanodetik di UTC, melacak waktu sejak waktu Unix. Tipe data ini saat ini hanya didukung untuk catatan multi-ukuran (yaitu dalam nilai ukuran tipe`MULTI`). `YYYY-MM-DD hh:mm:ss.sssssssss` Menulis stempel waktu dukungan dalam kisaran `1970-01-01 00:00:00.000000000` ke. `2262-04-11 23:47:16.854775807` | ## Tidak ada definisi skema di muka Sebelum mengirim data ke Amazon Timestream untuk Live Analytics, Anda harus membuat database dan tabel menggunakan Konsol Manajemen AWS, Timestream untuk Live Analytics SDKs, atau Timestream untuk operasi API Live Analytics. Untuk informasi selengkapnya, lihat [Buat database](console_timestream.md#console_timestream.db.using-console) dan [Membuat tabel](console_timestream.md#console_timestream.table.using-console). Saat membuat tabel, Anda tidak perlu mendefinisikan skema di depan. Amazon Timestream for Live Analytics secara otomatis mendeteksi skema berdasarkan ukuran dan dimensi titik data yang dikirim, sehingga Anda tidak perlu lagi mengubah skema secara offline untuk menyesuaikannya dengan data deret waktu yang berubah dengan cepat. ## Menulis data (sisipan dan upserts) Operasi tulis di Amazon Timestream untuk Live Analytics memungkinkan Anda memasukkan dan *meningkatkan* data. Secara default, menulis di Amazon Timestream untuk Live Analytics mengikuti *penulis pertama memenangkan* semantik, di mana data disimpan sebagai append saja dan catatan duplikat ditolak. Sementara penulis pertama memenangkan semantik memenuhi persyaratan banyak aplikasi deret waktu, ada skenario di mana aplikasi perlu memperbarui catatan yang ada dengan cara yang idempoten dan/atau menulis data dengan penulis terakhir memenangkan semantik, di mana catatan dengan versi tertinggi disimpan dalam layanan. Untuk mengatasi skenario ini, Amazon Timestream untuk Live Analytics menyediakan kemampuan untuk meningkatkan data. Upsert adalah operasi yang menyisipkan catatan ke dalam sistem ketika catatan tidak ada, atau memperbarui catatan ketika ada. Ketika catatan diperbarui, itu diperbarui dengan cara yang idempoten. Tidak ada operasi tingkat catatan untuk penghapusan. Tetapi tabel dan database dapat dihapus. **Menulis data ke dalam penyimpanan memori dan penyimpanan magnetik** Amazon Timestream untuk Live Analytics menawarkan kemampuan untuk langsung menulis data ke penyimpanan memori dan penyimpanan magnetik. Penyimpanan memori dioptimalkan untuk penulisan data throughput tinggi dan penyimpanan magnetik dioptimalkan untuk penulisan throughput yang lebih rendah dari data kedatangan terlambat. Data yang datang terlambat adalah data dengan stempel waktu lebih awal dari waktu saat ini dan di luar periode penyimpanan penyimpanan memori. Anda harus secara eksplisit mengaktifkan kemampuan untuk menulis data yang datang terlambat ke dalam penyimpanan magnetik dengan mengaktifkan penulisan penyimpanan magnetik untuk tabel. Juga, `MagneticStoreRejectedDataLocation` didefinisikan ketika tabel dibuat. Untuk menulis ke penyimpanan magnetik, penelepon `WriteRecords` harus memiliki `S3:PutObject` izin ke bucket S3 yang ditentukan `MagneticStoreRejectedDataLocation` selama pembuatan tabel. Lihat informasi selengkapnya di [CreateTable](https://docs.aws.amazon.com/timestream/latest/developerguide/API_CreateTable.html), [WriteRecords](https://docs.aws.amazon.com/timestream/latest/developerguide/API_WriteRecords.html), dan [PutObject](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html). **Menulis data dengan catatan ukuran tunggal dan catatan multi-ukuran** Amazon Timestream for Live Analytics menawarkan kemampuan untuk menulis data menggunakan dua jenis catatan, yaitu rekaman ukuran tunggal dan catatan multi-ukuran. **Catatan ukuran tunggal** Catatan ukuran tunggal memungkinkan Anda mengirim satu ukuran per catatan. Saat data dikirim ke Timestream untuk Live Analytics menggunakan format ini, Timestream untuk Live Analytics membuat satu baris tabel per rekaman. Ini berarti bahwa jika perangkat memancarkan 4 metrik dan setiap metrik dikirim sebagai catatan ukuran tunggal, Timestream untuk Live Analytics akan membuat 4 baris dalam tabel untuk menyimpan data ini, dan atribut perangkat akan diulang untuk setiap baris. Format ini direkomendasikan jika Anda ingin memantau satu metrik dari aplikasi atau saat aplikasi Anda tidak memancarkan beberapa metrik secara bersamaan. **Catatan multi-ukuran** Dengan catatan multi-ukuran, Anda dapat menyimpan beberapa ukuran dalam satu baris tabel, alih-alih menyimpan satu ukuran per baris tabel. Oleh karena itu, catatan multi-ukuran memungkinkan Anda untuk memigrasikan data yang ada dari database relasional ke Amazon Timestream untuk Live Analytics dengan sedikit perubahan. Anda juga dapat mengumpulkan lebih banyak data dalam satu permintaan penulisan daripada catatan ukuran tunggal. Ini meningkatkan throughput dan kinerja penulisan data, dan juga mengurangi biaya penulisan data. Ini karena mengumpulkan lebih banyak data dalam permintaan tulis memungkinkan Amazon TimeStream untuk Live Analytics mengidentifikasi lebih banyak data yang dapat diulang dalam satu permintaan tulis (jika berlaku), dan hanya mengenakan biaya sekali untuk data berulang. **Topics** + [Catatan multi-ukuran](#writes.writing-data-multi-measure) + [Menulis data dengan stempel waktu yang ada di masa lalu atau di masa depan](#writes.timestamp-past-future) ### Catatan multi-ukuran Dengan catatan multi-ukuran, Anda dapat menyimpan data deret waktu Anda dalam format yang lebih ringkas di memori dan penyimpanan magnetik, yang membantu menurunkan biaya penyimpanan data. Selain itu, penyimpanan data ringkas cocok untuk menulis kueri yang lebih sederhana untuk pengambilan data, meningkatkan kinerja kueri, dan menurunkan biaya kueri. Selain itu, catatan multi-ukuran juga mendukung tipe data TIMESTAMP untuk menyimpan lebih dari satu stempel waktu dalam catatan deret waktu. Atribut TIMESTAMP dalam catatan multi-ukuran mendukung stempel waktu di masa depan atau masa lalu. Oleh karena itu, catatan multi-ukuran membantu meningkatkan kinerja, biaya, dan kesederhanaan kueri—dan menawarkan lebih banyak fleksibilitas untuk menyimpan berbagai jenis ukuran yang berkorelasi. **Manfaat** Berikut ini adalah manfaat menggunakan catatan multi-ukuran. + **Kinerja dan biaya** - Catatan multi-ukuran memungkinkan Anda menulis beberapa ukuran deret waktu dalam satu permintaan tulis. Ini meningkatkan throughput penulisan dan juga mengurangi biaya penulisan. Dengan catatan multi-ukuran, Anda dapat menyimpan data dengan cara yang lebih ringkas, yang membantu menurunkan biaya penyimpanan data. Penyimpanan data ringkas dari catatan multi-ukuran menghasilkan lebih sedikit data yang diproses oleh kueri. Ini dirancang untuk meningkatkan kinerja kueri secara keseluruhan dan membantu menurunkan biaya kueri. + **Kesederhanaan kueri** — Dengan catatan multi-ukuran, Anda tidak perlu menulis ekspresi tabel umum yang kompleks (CTEs) dalam kueri untuk membaca beberapa ukuran dengan stempel waktu yang sama. Ini karena ukuran disimpan sebagai kolom dalam satu baris tabel. Oleh karena itu, catatan multi-ukuran memungkinkan penulisan kueri yang lebih sederhana. + **Fleksibilitas pemodelan data** — Anda dapat menulis stempel waktu masa depan ke Timestream for Live Analytics dengan menggunakan tipe data TIMESTAMP dan catatan multi-ukuran. Rekaman multi-ukuran dapat memiliki beberapa atribut tipe data TIMESTAMP, selain bidang waktu dalam catatan. Atribut TIMESTAMP, dalam catatan multi-ukuran, dapat memiliki stempel waktu di masa depan atau masa lalu dan berperilaku seperti bidang waktu kecuali TimeStream untuk Live Analytics tidak mengindeks nilai tipe TIMESTAMP dalam catatan multi-ukuran. **Kasus penggunaan** Anda dapat menggunakan catatan multi-ukuran untuk aplikasi deret waktu apa pun yang menghasilkan lebih dari satu pengukuran dari perangkat yang sama pada waktu tertentu. Berikut ini adalah beberapa contoh aplikasi. + Platform streaming video yang menghasilkan ratusan metrik pada waktu tertentu. + Perangkat medis yang menghasilkan pengukuran seperti kadar oksigen darah, detak jantung, dan denyut nadi. + Peralatan industri seperti rig minyak yang menghasilkan metrik, suhu, dan sensor cuaca. + Aplikasi lain yang dirancang dengan satu atau lebih layanan mikro. #### Contoh: Memantau kinerja dan kesehatan aplikasi streaming video Pertimbangkan aplikasi streaming video yang berjalan pada 200 instans EC2. Anda ingin menggunakan Amazon Timestream for Live Analytics untuk menyimpan dan menganalisis metrik yang dipancarkan dari aplikasi, sehingga Anda dapat memahami kinerja dan kesehatan aplikasi Anda, mengidentifikasi anomali dengan cepat, menyelesaikan masalah, dan menemukan peluang pengoptimalan. Kami akan memodelkan skenario ini dengan catatan ukuran tunggal dan catatan multi-ukuran, dan kemudian compare/contrast kedua pendekatan. Untuk setiap pendekatan, kami membuat asumsi berikut. + Setiap instans EC2 memancarkan empat ukuran (video\$1startup\$1time, rebuffering\$1ratio, video\$1playback\$1failure, dan average\$1frame\$1rate) dan empat dimensi (device\$1id, device\$1type, os\$1version, dan region) per detik. + Anda ingin menyimpan 6 jam data di penyimpanan memori dan 6 bulan data di penyimpanan magnetik. + Untuk mengidentifikasi anomali, Anda telah menyiapkan 10 kueri yang berjalan setiap menit untuk mengidentifikasi aktivitas yang tidak biasa selama beberapa menit terakhir. Anda juga telah membangun dasbor dengan delapan widget yang menampilkan data 6 jam terakhir, sehingga Anda dapat memantau aplikasi Anda secara efektif. Dasbor ini diakses oleh lima pengguna pada waktu tertentu dan disegarkan secara otomatis setiap jam. ##### Menggunakan catatan ukuran tunggal **Pemodelan data**: Dengan catatan ukuran tunggal, kami akan membuat satu catatan untuk masing-masing dari empat ukuran (waktu startup video, rasio rebuffering, kegagalan pemutaran video, dan kecepatan bingkai rata-rata). Setiap record akan memiliki empat dimensi (device\$1id, device\$1type, os\$1version, dan region) dan stempel waktu. **Menulis**: Saat Anda menulis data ke Amazon Timestream untuk Live Analytics, catatan dibuat sebagai berikut. ``` 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); } } ``` Saat Anda menyimpan catatan ukuran tunggal, data secara logis direpresentasikan sebagai berikut. | Waktu | device\$1id | device\$1type | os\$1versi | region | ukuran\$1nama | ukuran\$1nilai: :bigint | ukuran\$1nilai: :ganda | | --- | --- | --- | --- | --- | --- | --- | --- | | 2021-09-07 21:48:44 .000000000 | 12345678 | iPhone 11 | 14.8 | us-east-1 | video\$1startup\$1waktu | 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\$1failure | 0 | | | 2021-09-07 21:48:44 .000000000 | 12345678 | iPhone 11 | 14.8 | us-east-1 | rata-rata\$1frame\$1rate | | 0,85 | | 2021-09-07 21:53:44 .000000000 | 12345678 | iPhone 11 | 14.8 | us-east-1 | video\$1startup\$1waktu | 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\$1failure | 10 | | | 2021-09-07 21:53:44 .000000000 | 12345678 | iPhone 11 | 14.8 | us-east-1 | rata-rata\$1frame\$1rate | | 0,2 | **Kueri**: Anda dapat menulis kueri yang mengambil semua titik data dengan stempel waktu yang sama yang diterima selama 15 menit terakhir sebagai berikut. ``` 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 ``` **Biaya beban kerja**: Biaya beban kerja ini diperkirakan \$1373,23 per bulan dengan catatan ukuran tunggal ##### Menggunakan catatan multi-ukuran **Pemodelan data**: Dengan catatan multi-ukuran, kami akan membuat satu catatan yang berisi keempat ukuran (waktu startup video, rasio rebuffering, kegagalan pemutaran video, dan kecepatan bingkai rata-rata), keempat dimensi (device\$1id, device\$1type, os\$1version, dan region), dan stempel waktu. **Menulis**: Saat Anda menulis data ke Amazon Timestream untuk Live Analytics, catatan dibuat sebagai berikut. ``` 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); } } ``` Saat Anda menyimpan catatan multi-ukuran, data secara logis direpresentasikan sebagai berikut. | Waktu | device\$1id | device\$1type | os\$1versi | region | ukuran\$1nama | video\$1startup\$1waktu | rebuffering\$1ratio | video\$1 pemutaran\$1kegagalan | rata-rata\$1frame\$1rate | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | 2021-09-07 21:48:44 .000000000 | 12345678 | iPhone 11 | 14.8 | us-east-1 | video\$1metrik | 200 | 0,5 | 0 | 0,85 | | 2021-09-07 21:53:44 .000000000 | 12345678 | iPhone 11 | 14.8 | us-east-1 | video\$1metrik | 500 | 1.5 | 10 | 0,2 | **Kueri**: Anda dapat menulis kueri yang mengambil semua titik data dengan stempel waktu yang sama yang diterima selama 15 menit terakhir sebagai berikut. ``` 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) ``` **Biaya beban kerja**: Biaya beban kerja diperkirakan \$1127,43 dengan catatan multi-ukuran. **catatan** Dalam hal ini, menggunakan catatan multi-ukuran mengurangi perkiraan pengeluaran bulanan keseluruhan sebesar 2,5x, dengan biaya penulisan data berkurang 3,3x, biaya penyimpanan berkurang 3,3x, dan biaya kueri berkurang 1,2x. ### Menulis data dengan stempel waktu yang ada di masa lalu atau di masa depan Timestream for Live Analytics menawarkan kemampuan untuk menulis data dengan stempel waktu yang berada di luar jendela penyimpanan penyimpanan memori melalui beberapa mekanisme berbeda. + **Menulis toko magnetik** — Anda dapat menulis data yang datang terlambat langsung ke toko magnetik melalui penulisan penyimpanan magnetik. Untuk menggunakan penulisan penyimpanan magnetik, Anda harus terlebih dahulu mengaktifkan penulisan penyimpanan magnetik untuk sebuah tabel. Anda kemudian dapat menelan data ke dalam tabel menggunakan mekanisme yang sama yang digunakan untuk menulis data ke dalam penyimpanan memori. Amazon Timestream untuk Live Analytics akan secara otomatis menulis data ke penyimpanan magnetik berdasarkan stempel waktunya. **catatan** write-to-readLatensi untuk penyimpanan magnetik bisa sampai 6 jam, tidak seperti menulis data ke penyimpanan memori, di mana write-to-read latensi berada dalam kisaran sub-detik. + **Tipe data TIMESTAMP untuk pengukuran** - Anda dapat menggunakan tipe data TIMESTAMP untuk menyimpan data dari masa lalu, sekarang, atau masa depan. Rekaman multi-ukuran dapat memiliki beberapa atribut tipe data TIMESTAMP, selain bidang waktu dalam catatan. Atribut TIMESTAMP, dalam catatan multi-ukuran, dapat memiliki stempel waktu di masa depan atau masa lalu dan berperilaku seperti bidang waktu kecuali TimeStream untuk Live Analytics tidak mengindeks nilai tipe TIMESTAMP dalam catatan multi-ukuran. **catatan** Tipe data TIMESTAMP hanya didukung untuk catatan multi-ukuran. ## Konsistensi akhir untuk membaca Timestream untuk Live Analytics mendukung semantik konsistensi akhir untuk pembacaan. Ini berarti bahwa ketika Anda melakukan kueri data segera setelah menulis kumpulan data ke Timestream for Live Analytics, hasil kueri mungkin tidak mencerminkan hasil operasi penulisan yang baru saja selesai. Jika Anda mengulangi permintaan kueri ini setelah waktu yang singkat, hasilnya akan mengembalikan data terbaru. # Batching menulis dengan API WriteRecords Amazon Timestream untuk Live Analytics memungkinkan Anda menulis titik data dari satu titik and/or data deret waktu dari banyak seri dalam satu permintaan tulis. Mengelompokkan beberapa titik data dalam satu operasi penulisan bermanfaat dari perspektif kinerja dan biaya. Lihat [Menulis](metering-and-pricing.writes.md) di bagian Pengukuran dan Harga untuk detail selengkapnya. **catatan** Permintaan tulis Anda ke Timestream untuk Live Analytics dapat dibatasi karena Timestream untuk Live Analytics skala untuk beradaptasi dengan kebutuhan konsumsi data aplikasi Anda. Jika aplikasi Anda mengalami pengecualian pembatasan, Anda harus terus mengirim data pada throughput yang sama (atau lebih tinggi) agar Timestream for Live Analytics dapat secara otomatis menskalakan kebutuhan aplikasi Anda. # Beban batch Dengan *pemuatan batch* untuk Amazon Timestream LiveAnalytics, Anda dapat menelan file CSV yang disimpan di Amazon S3 ke Timestream dalam batch. Dengan fungsi baru ini, Anda dapat memiliki data Anda di Timestream LiveAnalytics tanpa harus bergantung pada alat lain atau menulis kode khusus. Anda dapat menggunakan pemuatan batch untuk mengisi ulang data dengan waktu tunggu yang fleksibel, seperti data yang tidak segera diperlukan untuk kueri atau analisis. Anda dapat membuat tugas pemuatan batch dengan menggunakan Konsol Manajemen AWS, AWS CLI, dan file AWS SDKs. Lihat informasi selengkapnya di [Menggunakan pemuatan batch dengan konsol](batch-load-using-console.md), [Menggunakan beban batch dengan AWS CLI](batch-load-using-cli.md), dan [Menggunakan beban batch dengan AWS SDKs](batch-load-using-sdk.md). Untuk informasi selengkapnya tentang pemuatan batch, lihat[Menggunakan pemuatan batch di Timestream untuk LiveAnalytics](batch-load.md). # Memilih antara operasi WriteRecords API dan pemuatan batch Dengan operasi WriteRecords API, Anda dapat menulis data deret waktu streaming Anda ke Timestream LiveAnalytics karena dihasilkan oleh sistem Anda. Dengan menggunakan WriteRecords, Anda dapat terus menelan satu titik data atau kumpulan data yang lebih kecil secara real time. Timestream for LiveAnalytics menawarkan skema fleksibel yang secara otomatis mendeteksi nama kolom dan tipe data untuk Timestream Anda untuk LiveAnalytics tabel, berdasarkan nama dimensi dan tipe data dari titik data yang Anda tentukan saat menjalankan penulisan ke dalam database. Sebaliknya, *pemuatan batch* memungkinkan penyerapan data deret waktu batch yang kuat dari file sumber (file CSV) ke Timestream untuk LiveAnalytics, menggunakan model data yang Anda tentukan. Beberapa contoh kapan menggunakan pemuatan batch dengan file sumber adalah mengimpor data deret waktu secara massal untuk evaluasi Timestream LiveAnalytics melalui bukti konsep, mengimpor data deret waktu secara massal dari perangkat IoT yang offline selama beberapa waktu, dan memigrasi data deret waktu historis dari Amazon S3 ke Timestream untuk. LiveAnalytics Untuk informasi tentang pemuatan batch, lihat[Menggunakan pemuatan batch di Timestream untuk LiveAnalytics](batch-load.md). Kedua solusi tersebut aman, andal, dan berkinerja baik. **Gunakan WriteRecords saat:** + Streaming data dalam jumlah yang lebih kecil (kurang dari 10 MB) per permintaan. + Mengisi tabel yang ada. + Menelan data dari aliran log. + Melakukan analitik waktu nyata. + Membutuhkan latensi yang lebih rendah. **Gunakan pemuatan batch saat:** + Menelan beban data yang lebih besar yang berasal dari Amazon S3 dalam file CSV. Untuk informasi selengkapnya tentang batasn, lihat [KuotaKuota default](ts-limits.md). + Mengisi tabel baru, seperti dalam kasus migrasi data. + Memperkaya database dengan data historis (konsumsi ke dalam tabel baru). + Anda memiliki sumber data yang berubah perlahan atau tidak sama sekali. + Anda memiliki waktu tunggu yang fleksibel karena tugas pemuatan batch mungkin dalam status tertunda hingga sumber daya tersedia, terutama jika Anda memuat data dalam jumlah yang sangat besar. Batch load cocok untuk data yang tidak perlu tersedia untuk query atau analisis untuk menambah kejelasan.