Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Langkah pertama untuk memodelkan data relasional di DynamoDB
catatan
Desain NoSQL membutuhkan pola pikir yang berbeda dari desain RDBMS. Untuk RDBMS, Anda dapat membuat model data yang dinormalisasi tanpa memikirkan pola akses. Anda kemudian dapat memperluasnya nanti ketika ada pertanyaan dan persyaratan kueri baru. Sebaliknya, di Amazon DynamoDB, Anda tidak boleh mulai merancang skema sampai Anda mengetahui pertanyaan-pertanyaan yang perlu dijawab. Memahami masalah bisnis dan kasus penggunaan aplikasi di awal sangatlah penting.
Untuk mulai merancang tabel DynamoDB yang akan menskalakan secara efisien, Anda harus melakukan beberapa langkah pertama untuk mengidentifikasi pola akses yang diperlukan oleh operasi dan sistem dukungan bisnis (OSS/BSS) yang memerlukan dukungan:
Untuk aplikasi baru, tinjau cerita pengguna tentang aktivitas dan sasaran. Dokumentasikan berbagai kasus penggunaan yang Anda identifikasi, dan analisis pola akses yang mereka butuhkan.
Untuk aplikasi yang sudah ada, analisis log kueri untuk mengetahui bagaimana orang-orang saat ini menggunakan sistem tersebut dan apa pola akses utamanya.
Setelah menyelesaikan proses ini, Anda akan mendapatkan daftar seperti berikut.
| Pola # | Deskripsi Pola Akses |
|---|---|
| 1 | Cari Detail Karyawan berdasarkan ID Karyawan |
| 2 | Kueri Detail Karyawan berdasarkan Nama Karyawan |
| 3 | Temukan Nomor Telepon Karyawan |
| 4 | Temukan Nomor Telepon Pelanggan |
| 5 | Dapatkan Pesanan untuk Pelanggan dalam Rentang Tanggal |
| 6 | Tampilkan semua Pesanan Terbuka dalam Rentang Tanggal |
| 7 | Lihat semua Karyawan yang dipekerjakan baru-baru ini |
| 8 | Temukan Semua Karyawan di Gudang |
| 9 | Dapatkan semua Item sesuai Pesanan untuk Produk |
| 10 | Dapatkan Inventaris Produk di Semua Gudang |
| 11 | Dapatkan Pelanggan dengan Perwakilan Akun |
| 12 | Dapatkan Pesanan berdasarkan Akun Rep |
| 13 | Dapatkan Karyawan dengan Job Title |
| 14 | Dapatkan Inventaris berdasarkan Produk dan Gudang |
| 15 | Dapatkan Total Inventaris Produk |
Dalam aplikasi yang sebenarnya, daftar Anda mungkin lebih panjang. Namun, kumpulan ini menunjukkan berbagai kompleksitas pola kueri yang mungkin Anda temukan di lingkungan produksi.
Pendekatan modern untuk desain skema DynamoDB menggunakan prinsip berorientasi agregat, mengelompokkan data berdasarkan pola akses daripada batas entitas yang kaku. Pendekatan ini mempertimbangkan beberapa pola desain:
Desain Tabel Tunggal - Menggunakan kunci pengurutan komposit, indeks sekunder global yang kelebihan beban, dan pola daftar kedekatan untuk menyimpan beberapa jenis entitas dalam satu tabel
Desain Multi-Tabel - Menggunakan tabel terpisah untuk entitas dengan karakteristik operasional independen dan korelasi akses rendah, dengan strategis GSIs untuk kueri lintas entitas
Desain Agregat - Menyematkan data terkait saat selalu diakses bersama (Pesanan + OrderItems) atau menggunakan koleksi item untuk mengidentifikasi hubungan (Product + Inventory)
Pilihan antara pendekatan ini tergantung pada pola akses spesifik Anda, karakteristik data, dan persyaratan operasional. Anda dapat menggunakan elemen-elemen ini untuk mengatur data sehingga aplikasi dapat mengambil apa pun yang dibutuhkannya untuk pola akses tertentu menggunakan satu kueri pada tabel atau indeks.
catatan
Pilihan antara desain single-table dan multi-table tergantung pada kebutuhan spesifik Anda. Desain meja tunggal bekerja dengan baik ketika entitas memiliki korelasi akses tinggi dan karakteristik operasional yang serupa. Desain multi-tabel lebih disukai ketika entitas memiliki persyaratan operasional independen, pola akses yang berbeda, atau ketika Anda membutuhkan batasan operasional yang jelas. Contoh dalam panduan ini menunjukkan pendekatan multi-tabel dengan agregasi strategis dan denormalisasi.
Untuk menggunakan NoSQL Workbench untuk DynamoDB guna membantu memvisualisasikan desain kunci partisi Anda, lihat Membangun Model Data dengan NoSQL Workbench.