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:

Diagram hubungan entitas

Ini adalah diagram hubungan entitas (ERD) yang akan kita gunakan untuk memantau pembaruan status perangkat.

Pola akses

Ini adalah pola akses yang akan kita pertimbangkan untuk memantau pembaruan status perangkat.

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:

Untuk mengambil entri log perangkat tertentu, kita dapat melakukan operasi kueri 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. 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 lalu menyaring satu item dengan 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. Anda dapat mengimpor data sampel dari 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:

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_4.json D di mana Operator atribut ditambahkan ke DeviceStateLog tabel dengan contoh data.

Karena Operator bukan kunci partisi, tidak ada cara untuk melakukan pencarian nilai kunci langsung pada tabel ini berdasarkan OperatorID. Kita perlu membuat koleksi item baru dengan indeks sekunder global aktif pada OperatorID. Pola akses memerlukan pencarian berdasarkan tanggal sehingga Tanggal adalah atribut kunci sortir untuk indeks sekunder global (GSI). Seperti inilah yang GSI sekarang terlihat:

Untuk pola akses 4 (getLogsForOperatorBetweenTwoDates), Anda dapat menanyakan ini GSI dengan kunci partisi OperatorID=Liz dan kunci pengurutan Date antara 2020-04-11T05:58:00 dan2020-04-24T14:50:00.

Langkah 4: Tangani pola akses 5 (getEscalatedLogsForSupervisor), 6 (getEscalatedLogsWithSpecificStatusForSupervisor), dan 7 (getEscalatedLogsWithSpecificStatusForSupervisorForDate)

Kami akan menggunakan indeks jarang 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_6.json di mana EscalatedTo atribut ditambahkan ke DeviceStateLog tabel dengan contoh data. Seperti disebutkan sebelumnya, tidak semua log akan dieskalasikan ke supervisor.

Anda sekarang dapat membuat yang baru GSI di mana EscalatedTo adalah kunci partisi dan State#Date merupakan kunci sortir. Perhatikan bahwa hanya item yang memiliki atribut EscalatedTo dan State#Date yang muncul dalam indeks.

Pola akses lainnya dirangkum sebagai berikut:

Semua pola akses dan bagaimana desain skema mengatasinya dirangkum dalam tabel di bawah ini:

Skema akhir

Berikut adalah desain skema akhir. Untuk mengunduh desain skema ini sebagai JSON file, lihat Contoh DynamoDB di. GitHub

Tabel dasar

GSI-1

GSI-2

Menggunakan No SQL Workbench dengan desain skema ini

Anda dapat mengimpor skema akhir ini ke No SQL Workbench, alat visual yang menyediakan pemodelan data, visualisasi data, dan fitur pengembangan kueri untuk DynamoDB, untuk mengeksplorasi lebih lanjut dan mengedit proyek baru Anda. Ikuti langkah-langkah berikut untuk memulai: