Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Memantau pembaruan status perangkat di DynamoDB
Kasus penggunaan ini membahas tentang penggunaan DynamoDB untuk memantau pembaruan status perangkat (atau perubahan status perangkat) di DynamoDB.
## Kasus penggunaan
Dalam kasus penggunaan IoT (pabrik pintar misalnya), banyak perangkat yang perlu dipantau oleh operator dan perangkat tersebut secara berkala mengirim status atau log ke sistem pemantauan. Ketika ada masalah dengan sebuah perangkat, status perangkat tersebut berubah dari *normal* menjadi *peringatan*. Ada tingkat log atau status yang berbeda tergantung tingkat keparahan dan jenis perilaku abnormal pada perangkat. Sistem kemudian menugaskan operator untuk memeriksa perangkat dan mereka dapat mengeskalasikan masalah kepada supervisor jika diperlukan.
Beberapa pola akses tipikal untuk sistem ini meliputi:
+ Membuat entri log untuk sebuah perangkat
+ Mendapatkan semua log untuk status perangkat tertentu yang menampilkan log terbaru terlebih dahulu
+ Mendapatkan semua log untuk operator tertentu di antara dua tanggal
+ Mendapatkan semua log yang dieskalasi untuk supervisor tertentu
+ Mendapatkan semua log yang dieskalasi dengan status perangkat tertentu untuk supervisor tertentu
+ Mendapatkan semua log yang dieskalasi dengan status perangkat tertentu untuk supervisor tertentu pada tanggal tertentu
## Diagram hubungan entitas
Ini adalah diagram hubungan entitas (ERD) yang akan kita gunakan untuk memantau pembaruan status perangkat.
![\[ERD pembaruan status perangkat. Ini menunjukkan entitas: Perangkat dan Operator.\]](http://docs.aws.amazon.com/id_id/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-1-ERD.jpg)
## Pola akses
Ini adalah pola akses yang akan kita pertimbangkan untuk memantau pembaruan status perangkat.
1. `createLogEntryForSpecificDevice`
1. `getLogsForSpecificDevice`
1. `getWarningLogsForSpecificDevice`
1. `getLogsForOperatorBetweenTwoDates`
1. `getEscalatedLogsForSupervisor`
1. `getEscalatedLogsWithSpecificStatusForSupervisor`
1. `getEscalatedLogsWithSpecificStatusForSupervisorForDate`
## Evolusi desain skema
**Langkah 1: Atasi pola akses 1 (`createLogEntryForSpecificDevice`) dan 2 (`getLogsForSpecificDevice`)**
Unit penskalaan untuk sistem pelacakan perangkat adalah perangkat individual. Dalam sistem ini, `deviceID` mengidentifikasi perangkat secara unik. Ini menjadikan `deviceID` kandidat yang baik untuk kunci partisi. Setiap perangkat mengirim informasi ke sistem pelacakan secara berkala (misalnya, setiap lima menit atau lebih). Pengurutan ini menjadikan tanggal sebagai kriteria pengurutan logis dan oleh karena itu, menjadi kunci urutan. Data sampel dalam kasus ini akan terlihat seperti ini:
![\[Tabel untuk menyimpan status beberapa perangkat. DeviceID adalah kunci utama dan pembaruan status Tanggal adalah kunci pengurutan.\]](http://docs.aws.amazon.com/id_id/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-2-Step1.png)
Untuk mengambil entri log perangkat tertentu, kita dapat melakukan operasi [kueri](Query.md) dengan kunci partisi `DeviceID="d#12345"`.
**Langkah 2: Atasi pola akses 3 (`getWarningLogsForSpecificDevice`)**
Karena `State` merupakan atribut non-kunci, mengatasi pola akses 3 dengan skema saat ini akan memerlukan [ekspresi filter](Query.FilterExpression.md). Di DynamoDB, ekspresi filter diterapkan setelah data dibaca menggunakan ekspresi kondisi kunci. Misalnya, jika kita mengambil log peringatan untuk`d#12345`, operasi kueri dengan kunci partisi `DeviceID="d#12345"` akan membaca empat item dari tabel di atas dan kemudian menyaring satu item tanpa status *peringatan*. Pendekatan ini tidak efisien dalam skala besar. Ekspresi filter dapat menjadi cara yang baik untuk mengecualikan item dalam kueri jika rasio item yang dikecualikan rendah atau kueri jarang dilakukan. Namun, untuk kasus dengan banyak item diambil dari tabel dan sebagian besar item disaring, kita dapat terus mengembangkan desain tabel agar berjalan lebih efisien.
Mari kita ubah cara menangani pola akses ini menggunakan [kunci urutan komposit](data-modeling-blocks.md#data-modeling-blocks-composite). Anda dapat mengimpor data sampel dari [DeviceStateLog\$13.json](https://github.com/aws-samples/amazon-dynamodb-design-patterns/blob/master/examples/device-state-log/json/DeviceStateLog_3.json) di mana kunci pengurutan diubah menjadi. `State#Date` Kunci urutan ini adalah komposisi atribut `State`, `#`, dan `Date`. Dalam contoh ini, `#` digunakan sebagai pembatas. Data sekarang terlihat seperti ini:
![\[Data pembaruan status untuk perangkat, d #12345, diambil menggunakan kunci sortir komposit Status #Date.\]](http://docs.aws.amazon.com/id_id/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-3-Step2.png)
Untuk mengambil log peringatan untuk perangkat saja, kueri menjadi lebih tertarget dengan skema ini. Kondisi kunci untuk kueri menggunakan kunci partisi `DeviceID="d#12345"` dan kunci urutan `State#Date begins_with “WARNING”`. Kueri ini hanya akan membaca tiga item yang relevan dengan status *peringatan*.
**Langkah 3: Atasi pola akses 4 (`getLogsForOperatorBetweenTwoDates`)**
Anda dapat mengimpor [DeviceStateLog\$14.json](https://github.com/aws-samples/amazon-dynamodb-design-patterns/blob/master/examples/device-state-log/json/DeviceStateLog_4.json) D di mana `Operator` atribut ditambahkan ke `DeviceStateLog` tabel dengan contoh data.
![\[DeviceStateLog desain tabel dengan atribut Operator untuk mendapatkan log operator antara tanggal tertentu.\]](http://docs.aws.amazon.com/id_id/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-4-Step3.png)
Karena `Operator` bukan kunci partisi, tidak ada cara untuk melakukan pencarian nilai kunci langsung pada tabel ini berdasarkan `OperatorID`. Kita perlu membuat [koleksi item](WorkingWithItemCollections.md) baru dengan indeks sekunder global aktif pada `OperatorID`. Pola akses memerlukan pencarian berdasarkan tanggal, sehingga Tanggal adalah atribut kunci urutan untuk [indeks sekunder global (GSI)](GSI.md). Tampilan GSI sekarang menjadi:
![\[Desain GSI dengan OperatorId dan Date sebagai kunci partisi dan kunci sortir untuk mendapatkan log untuk operator tertentu.\]](http://docs.aws.amazon.com/id_id/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-5-Step3.png)
Untuk pola akses 4 (`getLogsForOperatorBetweenTwoDates`), Anda dapat mengueri GSI ini dengan kunci partisi `OperatorID=Liz` dan kunci urutan `Date` antara `2020-04-11T05:58:00` dan `2020-04-24T14:50:00`.
![\[Query pada GSI menggunakan OperatorId dan Date untuk mendapatkan log untuk operator antara dua tanggal.\]](http://docs.aws.amazon.com/id_id/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-6-GSI1_1.png)
**Langkah 4: Tangani pola akses 5 (`getEscalatedLogsForSupervisor`), 6 (`getEscalatedLogsWithSpecificStatusForSupervisor`), dan 7 (`getEscalatedLogsWithSpecificStatusForSupervisorForDate`)**
Kami akan menggunakan [indeks jarang](data-modeling-blocks.md#data-modeling-blocks-sparse-index) untuk mengatasi pola akses ini.
Indeks sekunder global secara default bersifat jarang, jadi hanya item dalam tabel dasar yang berisi atribut kunci primer indeks yang benar-benar akan muncul di indeks. Ini adalah cara lain untuk mengecualikan item yang tidak relevan untuk pola akses yang dimodelkan.
Anda dapat mengimpor [DeviceStateLog\$16.json](https://github.com/aws-samples/amazon-dynamodb-design-patterns/blob/master/examples/device-state-log/json/DeviceStateLog_6.json) di mana `EscalatedTo` atribut ditambahkan ke `DeviceStateLog` tabel dengan contoh data. Seperti disebutkan sebelumnya, tidak semua log akan dieskalasikan ke supervisor.
![\[Desain GSI dengan EscalatedTo atribut untuk mendapatkan semua log yang ditingkatkan untuk supervisor.\]](http://docs.aws.amazon.com/id_id/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-7-Step4.png)
Anda sekarang dapat membuat GSI baru di mana `EscalatedTo` adalah kunci partisi dan `State#Date` adalah kunci urutan. Perhatikan bahwa hanya item yang memiliki atribut `EscalatedTo` dan `State#Date` yang muncul dalam indeks.
![\[Desain GSI untuk mendapatkan semua item dengan atribut EscalatedTo dan State #Date.\]](http://docs.aws.amazon.com/id_id/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-8-Step4.png)
Pola akses lainnya dirangkum sebagai berikut:
Untuk pola akses 5 (getEscalatedLogsForSupervisor), Anda dapat melakukan kueri pada eskalasi GSI dengan kunci partisi EscalatedTo ="Sara” Untuk pola akses 6 (getEscalatedLogsWithSpecificStatusForSupervisor), Anda dapat melakukan kueri pada eskalasi GSI dengan kunci partisi EscalatedTo ="Sara” dan mengurutkan kunci Status \$1Date begins\$1with “WARNING” Untuk pola akses 7 (getEscalatedLogsWithSpecificStatusForSupervisorForDate), Anda dapat melakukan kueri pada eskalasi GSI dengan kunci partisi EscalatedTo ="Sara” dan mengurutkan kunci Status \$1Date begins\$1with “\$12020 -04-27” WARNING4
Semua pola akses dan bagaimana desain skema mengatasinya dirangkum dalam tabel di bawah ini:
| Pola akses | Basis table/GSI/LSI | Operasi | Nilai kunci partisi | Nilai kunci urutan | Kondisi/filter lainnya |
| --- | --- | --- | --- | --- | --- |
| createLogEntryForSpecificDevice | Tabel dasar | PutItem | DeviceID=deviceId | State\$1Date=state\$1date | |
| getLogsForSpecificDevice | Tabel dasar | Kueri | DeviceID=deviceId | State\$1Date begins\$1with "state1\$1" | ScanIndexForward = Salah |
| getWarningLogsForSpecificDevice | Tabel dasar | Kueri | DeviceID=deviceId | State\$1Date begins\$1with "WARNING" | |
| getLogsForOperatorBetweenTwoDates | GSI-1 | Kueri | Operator=operatorName | Tanggal antara date1 dan date2 | |
| getEscalatedLogsForSupervisor | GSI-2 | Kueri | EscalatedTo=Nama pengawas | | |
| getEscalatedLogsWithSpecificStatusForSupervisor | GSI-2 | Kueri | EscalatedTo=Nama pengawas | State\$1Date begins\$1with "state1\$1" | |
| getEscalatedLogsWithSpecificStatusForSupervisorForDate | GSI-2 | Kueri | EscalatedTo=Nama pengawas | State\$1Date begins\$1with "state1\$1date1" | |
## Skema akhir
Berikut adalah desain skema akhir. [Untuk mengunduh desain skema ini sebagai file JSON, lihat Contoh DynamoDB di.](https://github.com/aws-samples/aws-dynamodb-examples/tree/master/schema_design/SchemaExamples) GitHub
**Tabel dasar**
![\[Desain tabel dasar dengan metadata status perangkat, seperti ID Perangkat, Status, dan Tanggal.\]](http://docs.aws.amazon.com/id_id/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-9-Table.png)
**GSI-1**
![\[Desain GSI-1. Ini menunjukkan kunci utama dan atribut: deviceId, State #Date, dan State.\]](http://docs.aws.amazon.com/id_id/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-10-GSI1.png)
**GSI-2**
![\[Desain GSI-2. Ini menunjukkan kunci utama dan atribut: DeviceId, Operator, Date, dan State.\]](http://docs.aws.amazon.com/id_id/amazondynamodb/latest/developerguide/images/DataModeling/DeviceStatus-11-GSI2.png)
## Menggunakan NoSQL Workbench dengan desain skema ini
Anda dapat mengimpor skema akhir ini ke [NoSQL Workbench](workbench.md), sebuah alat visual yang menyediakan fitur pemodelan data, visualisasi data, dan pengembangan kueri untuk DynamoDB, guna mengeksplorasi dan mengedit proyek baru Anda lebih lanjut. Ikuti langkah-langkah berikut untuk memulai:
1. Unduh NoSQL Workbench. Untuk informasi selengkapnya, lihat [Unduh NoSQL Workbench untuk DynamoDB](workbench.settingup.md).
1. Unduh file skema JSON yang tercantum di atas, yang sudah dalam format model NoSQL Workbench.
1. Impor file skema JSON ke NoSQL Workbench. Untuk informasi selengkapnya, lihat [Mengimpor model data yang ada](workbench.Modeler.ImportExisting.md).
1. Setelah mengimpor model data ke NoSQL Workbench, Anda dapat mengeditnya. Lihat informasi yang lebih lengkap di [Mengedit model data yang ada](workbench.Modeler.Edit.md).