Blok bangunan pemodelan data di DynamoDB

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Bagian ini membahas lapisan blok bangunan yang dapat Anda gunakan dalam pola deasin untuk aplikasi Anda.

Blok bangunan kunci urutan komposit

Ketika orang berpikir tentang TidakSQL, mereka mungkin juga menganggapnya sebagai non-relasional. Pada akhirnya, tidak ada hal yang menghalangi relasi untuk ditempatkan ke dalam skema DynamoDB, meski tampilannya berbeda dari basis data relasional dan kunci asingnya. Salah satu pola paling kritis yang dapat kita gunakan untuk mengembangkan hierarki logis data kita di DynamoDB adalah kunci urutan komposit. Gaya yang paling umum untuk merancangnya adalah dengan memisahkan setiap lapisan hierarki (layer induk > lapisan turunan > lapisan cucu) dengan tagar. Misalnya, PARENT#CHILD#GRANDCHILD#ETC.

Sementara kunci partisi di DynamoDB selalu membutuhkan nilai yang tepat untuk kueri data, kita dapat menerapkan kondisi parsial ke kunci urutan dari kiri ke kanan, mirip dengan melintasi pohon biner.

Dalam contoh di atas, ada toko e-Commerce dengan Keranjang Belanja yang perlu dipertahankan di seluruh sesi pengguna. Setiap kali pengguna masuk, mereka mungkin ingin melihat seluruh Keranjang Belanja, termasuk item yang disimpan untuk nanti. Namun ketika mereka memasuki halaman checkout, hanya item di keranjang aktif yang harus dimuat untuk dibeli. Karena keduanya KeyConditions secara eksplisit meminta kunci CART pengurutan, data daftar keinginan tambahan diabaikan begitu saja oleh DynamoDB pada waktu baca. Meskipun item yang disimpan dan aktif adalah bagian dari keranjang yang sama, kita perlu memperlakukannya secara berbeda di berbagai bagian aplikasi, jadi menerapkan KeyCondition ke prefiks kunci urutan adalah cara yang paling optimal untuk hanya mengambil data yang diperlukan untuk setiap bagian aplikasi.

Fitur utama dari blok bangunan ini

Blok bangunan multi-penghunian

Banyak pelanggan menggunakan DynamoDB sebagai host data untuk aplikasi multi-penghuni mereka. Untuk skenario ini, kami ingin merancang skema dengan cara yang menyimpan semua data dari penghuni tunggal di partisi logisnya sendiri dari tabel. Hal ini memanfaatkan konsep Koleksi Item, yang merupakan istilah untuk semua item dalam tabel DynamoDB dengan kunci partisi yang sama. Untuk informasi selengkapnya tentang cara pendekatan DynamoDB terhadap multi-penghuni, lihat Multi-penghuni di DynamoDB.

Untuk contoh ini, kami menjalankan situs hosting foto dengan potensi ribuan pengguna. Setiap pengguna hanya akan mengunggah foto ke profil mereka sendiri pada awalnya, tetapi secara default kami tidak akan mengizinkan pengguna untuk melihat foto pengguna lain. Tingkat isolasi tambahan idealnya akan ditambahkan ke otorisasi panggilan setiap pengguna ke Anda API untuk memastikan mereka hanya meminta data dari partisi mereka sendiri, tetapi pada tingkat skema, kunci partisi unik sudah memadai.

Fitur utama dari blok bangunan ini

Blok bangunan indeks jarang

Terkadang pola akses memerlukan pencarian item yang cocok dengan item langka atau item yang menerima status (yang memerlukan respons yang dieskalasikan). Daripada secara teratur melakukan kueri di seluruh kumpulan data untuk item ini, kami dapat memanfaatkan fakta bahwa indeks sekunder global (GSI) jarang dimuat dengan data. Ini berarti bahwa hanya item dalam tabel dasar yang memiliki atribut yang ditentukan dalam indeks yang akan direplikasi ke indeks.

Dalam contoh ini, kita melihat kasus IOT penggunaan di mana setiap perangkat di lapangan melaporkan kembali status secara teratur. Untuk sebagian besar laporan, kita berharap perangkat melaporkan semuanya baik-baik saja, tetapi kadang-kadang kesalahan bisa saja muncul, dan hal itu harus dieskalasikan ke teknisi perbaikan. Untuk laporan dengan eskalasi, atribut EscalatedTo ditambahkan item, tetapi malah tidak muncul. GSIDalam contoh ini dipartisi oleh EscalatedTo dan karena GSI membawa kunci dari tabel dasar kita masih dapat melihat deviceId mana yang melaporkan kesalahan dan pada jam berapa.

Meskipun pembacaan lebih murah daripada penulisan di DynamoDB, indeks jarang adalah alat yang sangat efektif untuk kasus penggunaan di mana instans jenis item tertentu jarang terjadi tetapi pembacaan untuk menemukannya merupakan hal biasa.

Fitur utama dari blok bangunan ini

Blok bangunan waktu untuk tayang

Sebagian besar data memiliki beberapa durasi waktu yang dapat dianggap layak disimpan dalam penyimpanan data primer. Untuk memfasilitasi penuaan data dari DynamoDB, ia memiliki fitur yang disebut time to live (). TTL TTLFitur ini memungkinkan Anda untuk menentukan atribut tertentu pada tingkat tabel yang memerlukan pemantauan untuk item dengan stempel waktu epoch (itu di masa lalu). Hal ini memungkinkan Anda untuk menghapus catatan kedaluwarsa dari tabel secara gratis.

Dalam contoh ini, kami memiliki aplikasi yang dirancang untuk memungkinkan pengguna membuat pesan berumur pendek. Ketika pesan dibuat di DynamoDB, TTL atribut diatur ke tanggal tujuh hari di masa depan oleh kode aplikasi. Dalam kira-kira tujuh hari, DynamoDB akan melihat bahwa stempel jangka waktu item ini sudah ada di masa lalu kemudian menghapusnya.

Karena penghapusan yang dilakukan oleh TTL gratis, sangat disarankan untuk menggunakan fitur ini untuk menghapus data historis dari tabel. Ini akan mengurangi tagihan penyimpanan keseluruhan setiap bulan dan kemungkinan akan mengurangi biaya pembacaan pengguna karena data yang akan diambil oleh kueri mereka menjadi lebih sedikit. Sementara TTL diaktifkan di tingkat tabel, terserah Anda item atau entitas mana yang akan membuat TTL atribut dan seberapa jauh ke future untuk mengatur stempel waktu epoch.

Fitur utama dari blok bangunan ini

Blok bangunan pengarsipan waktu untuk tayang

Meskipun TTL merupakan alat yang efektif untuk menghapus data lama dari DynamoDB, banyak kasus penggunaan memerlukan arsip data disimpan untuk jangka waktu yang lebih lama daripada datastore primer. Dalam hal ini, kita dapat memanfaatkan TTL penghapusan catatan berjangka waktu untuk mendorong catatan kedaluwarsa ke dalam datastore jangka panjang.

Ketika TTL penghapusan dilakukan oleh DynamoDB, itu masih didorong ke DynamoDB Stream sebagai acara. Delete Ketika TTL DynamoDB adalah orang yang melakukan penghapusan, ada atribut pada catatan aliran. principal:dynamodb Menggunakan pelanggan Lambda ke Aliran DynamoDB, kita dapat menerapkan filter peristiwa hanya untuk atribut pengguna utama DynamoDB dan mengetahui bahwa catatan apa pun yang cocok dengan filter tersebut akan didorong ke penyimpanan arsip seperti S3 Glacier.

Fitur utama dari blok bangunan ini

Blok bangunan partisi vertikal

Pengguna yang akrab dengan database model dokumen akan terbiasa dengan gagasan menyimpan semua data terkait dalam satu JSON dokumen. Meskipun DynamoDB JSON mendukung tipe data, DynamoDB tidak mendukung KeyConditions eksekusi pada bersarang. JSON Karena itulah KeyConditions yang menentukan berapa banyak data yang dibaca dari disk dan secara efektif berapa banyak kueri RCUs yang dikonsumsi, ini dapat mengakibatkan inefisiensi pada skala. Untuk mengoptimalkan penulisan dan pembacaan DynamoDB dengan lebih baik, kami sarankan untuk memecah entitas individual dokumen menjadi item DynamoDB individual, yang juga disebut sebagai partisi vertikal.

Partisi vertikal, seperti yang ditunjukkan di atas, adalah contoh kunci desain tabel tunggal dalam kenyataannya, tetapi juga dapat diimplementasikan di beberapa tabel jika diinginkan. Karena tagihan DynamoDB menulis dalam kelipatan 1 KB, Anda idealnya harus mempartisi dokumen dengan cara yang menghasilkan item di bawah 1 KB.

Fitur utama dari blok bangunan ini

Blok bangunan sharding penulisan

Salah satu dari sedikit batasan keras yang dimiliki DynamoDB adalah pembatasan jumlah throughput yang dapat dipertahankan oleh satu partisi fisik per detik (tidak harus satu kunci partisi). Batasan ini untuk saat ini:

Jika permintaan terhadap tabel melebihi salah satu dari batas ini, kesalahan dikirim kembali ke klien SDKThroughputExceededException, lebih sering disebut sebagai throttling. Kasus penggunaan yang memerlukan operasi baca di luar batas itu sebagian besar akan dilayani paling baik dengan menempatkan cache baca di depan DynamoDB, tetapi operasi penulisan memerlukan desain tingkat skema yang dikenal sebagai sharding penulisan.

Untuk mengatasi masalah ini, kita akan menambahkan bilangan bulat acak ke akhir kunci partisi untuk setiap kontestan dalam kode UpdateItem aplikasi. Rentang generator bilangan bulat acak harus memiliki pencocokan batas atas atau melebihi jumlah penulisan per detik yang diharapkan untuk kontestan tertentu dibagi 1000. Untuk mendukung 20.000 suara per detik, hal ini akan terlihat seperti rand(0,19). Setelah data disimpan di bawah partisi logis yang terpisah, data harus digabungkan bersama kembali pada waktu baca. Karena total suara tidak perlu real time, fungsi Lambda yang dijadwalkan untuk membaca semua partisi suara setiap X menit dapat melakukan agregasi sesekali untuk setiap kontestan dan menuliskannya kembali ke catatan total suara tunggal untuk pembacaan langsung.

Fitur utama dari blok bangunan ini