Cara memodelkan data Anda agar berfungsi dengan DynamoDB berbasis NoSQL Amazon Web Services.
Mengapa NoSQL?
Saat ini, penyimpanan murah dan daya komputasi mahal. NoSQL memanfaatkan fakta ini dan mengorbankan sejumlah ruang penyimpanan untuk memungkinkan kueri yang lebih mudah secara komputasi. Intinya, saat mendesain model data NoSQL, Anda harus selalu memikirkan cara untuk menyederhanakan kueri ke database Anda. Jika digunakan dengan benar, NoSQL bisa menjadi solusi yang jauh lebih hemat biaya dibandingkan database relasional.
Mengapa DynamoDB?
Amazon DynamoDB adalah database nilai kunci dan dokumen yang dikelola sepenuhnya, multi-wilayah, dan penskalaan otomatis sehingga Anda tidak perlu mengkhawatirkan infrastruktur atau pusat data. DynamoDB juga menawarkan model penetapan harga “Kapasitas Sesuai Permintaan”. Hal ini membuatnya sangat mudah bagi aplikasi ukuran apa pun untuk memulai secara instan tanpa harus khawatir tentang penyediaan kapasitas atau harus melakukan upgrade di kemudian hari.
Memahami Dasar-dasarnya
Tidak seperti database relasional seperti MySQL, NoSQL mengharuskan Anda untuk terus-menerus mengajukan pertanyaan tentang bagaimana data akan ditanyakan. Mengajukan pertanyaan-pertanyaan ini akan membawa Anda ke jalur pengorganisasian item dan cara membagi item dengan cara yang kondusif untuk pertanyaan cepat. Langkah pertama adalah membuat kunci utama untuk item Anda yang terdiri dari kunci partisi dan kunci pengurutan.
Catatan: Anda hanya dapat menggunakan kunci partisi sebagai kunci utama, namun untuk sebagian besar kasus, Anda juga ingin memanfaatkan kunci pengurutan.
Kunci Partisi
Tabel DynamoDB dibagi menjadi beberapa partisi. DynamoDB menggunakan kunci partisi sebagai masukan ke fungsi hash internal yang hasilnya menentukan di partisi mana item akan disimpan.
Partisi Panas
Penting untuk memastikan bahwa kunci partisi Anda membagi item Anda sehingga beban kerja Anda didistribusikan secara merata di antara partisi untuk menghindari masalah partisi “panas”.
Misalnya, tabel Anda dibagi menjadi 3 partisi dan Anda telah menyediakan 3 RCU (unit Kapasitas Baca) ke tabel Anda. Artinya setiap partisi akan memiliki akses ke 1 RCU. Jika 1 partisi terkena lebih sering dibandingkan 2 partisi lainnya, Anda berisiko mengalami pembatasan karena Anda mungkin menggunakan seluruh 1 RCU tersebut; sementara itu, Anda masih membayar untuk 3 RCU.
Anda dapat mengetahui lebih lanjut tentang ini di dokumen resmi AWS: Merancang Kunci Partisi untuk Mendistribusikan Beban Kerja Anda Secara Merata.
Kunci Sortir
Semua item dengan kunci partisi yang sama disimpan bersama dan diurutkan berdasarkan kunci pengurutan. Dengan mengikuti pola ini, Anda dapat melakukan kueri beberapa item dengan sangat efisien hanya dengan menggunakan kunci partisi.
Contoh Pemodelan Data
Katakanlah Anda sedang merancang sebuah aplikasi di mana Anda perlu menyimpan informasi tentang turnamen olahraga. Bisa dibilang setiap turnamen memiliki tim, pemain, dan pertandingan. Turnamen juga memiliki beberapa informasi dasar seperti lokasi, tanggal, permainan, dan hadiah.
Pendekatan yang sangat umum untuk memodelkan data di NoSQL adalah berpikir dalam kerangka hierarki. Jadi apa yang ada di puncak hierarki kita? Bayangkan saja seperti ini: tanpa turnamen, kita tidak akan memiliki tim, pemain, atau pertandingan. Turnamen ini memberikan konteks yang menghubungkan semua item lainnya bersama-sama. Jadi, untuk setiap turnamen, kami ingin mengelompokkan semua item secara berdampingan sehingga kami dapat mengambil semua data turnamen secara efisien dalam satu kueri.
Kami harus mempartisi setiap turnamen kami berdasarkan pengenal yang unik namun terdistribusi secara seragam. Untuk ini, saya akan merekomendasikan penggunaan UUIDv4 untuk menghasilkan id turnamen unik. Jadi mari kita lihat seperti apa tampilannya di Tabel DynamoDB. Id turnamen UUIDv4 kami bertindak sebagai kunci partisi kami.
Seperti yang Anda lihat, kami memiliki 4 item individual, semuanya dengan kunci partisi yang sama dan diurutkan berdasarkan kunci pengurutan. Anda juga akan melihat bahwa setiap item diawali dengan deskripsi atau hanya nilai hardcode. Saya akan menjelaskan lebih lanjut mengapa kami melakukan ini nanti. Selain itu, masing-masing item ini memiliki kumpulan atribut uniknya sendiri, dan semuanya dapat diambil dengan melakukan satu panggilan kueri sederhana ke DynamoDB.
{
"TableName": "tournaments",
"KeyConditionExpression": "partitionKey = :tournamentId",
"ExpressionAttributeValues": {
":tournamentId": "983d39a3-bdd6-4b61-88d5-58595d555b81"
}
}
Bagaimana jika Anda hanya menginginkan tim untuk ID turnamen tertentu?
Di sinilah awalan team- berguna. Karena kita mengawali semua kunci pengurutan item tim dengan team-, kita dapat menjalankan fungsi khusus di KeyConditionExpression — begins_with. Panggilan kueri ini akan mengambil semua tim untuk id turnamen tertentu (kunci partisi).
{
"TableName": "tournaments",
"KeyConditionExpression": "partitionKey = :tournamentId and begins_with(sortKey, :teamPrefix)",
"ExpressionAttributeValues": {
":teamPrefix": "team-",
":tournamentId": "983d39a3-bdd6-4b61-88d5-58595d555b81"
}
}
Bagaimana jika Anda hanya menginginkan detail dasar saja?
Kita cukup melakukan panggilan get item DynamoDB karena kita mengetahui kunci partisi dan kunci pengurutan.
{
"TableName": "tournaments",
"Key": {
"partitionKey": "983d39a3-bdd6-4b61-88d5-58595d555b81",
"sortKey": "tournament-details"
}
}
Membungkus
Saya harap ini membantu Anda dalam perjalanan Anda memodelkan data untuk database NoSQL seperti DynamoDB. Tentu saja saya membutuhkan waktu cukup lama untuk memahami beberapa pola dan teknik yang telah saya coba uraikan di sini. Oleh karena itu, saya ingin berbagi pengetahuan yang saya peroleh dengan harapan dapat memberi Anda langkah awal dalam memodelkan data Anda.
Jika Anda tertarik untuk mempelajari lebih lanjut tentang layanan AWS
Terima kasih telah membaca dan semoga sukses dengan proyek Anda! Tinggalkan komentar atau kirim pesan kepada saya jika Anda memiliki pertanyaan.
