Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Sistem basis data NoSQL seperti Amazon DynamoDB menggunakan model alternatif untuk manajemen data, seperti pasangan nilai kunci atau penyimpanan dokumen. Saat Anda beralih dari sistem manajemen basis data relasional ke sistem basis data NoSQL seperti DynamoDB, penting untuk memahami perbedaan utama dan pendekatan desain tertentu.
Topik
Perbedaan antara desain data relasional dan NoSQL
Sistem basis data relasional (RDBMS) dan basis data NoSQL memiliki keunggulan dan kelemahan yang berbeda:
-
Di RDBMS, data dapat dikueri secara fleksibel, tetapi kueri relaitf mahal dan tidak dapat diskalakan dengan baik dalam situasi lalu lintas tinggi (lihat Langkah pertama untuk memodelkan data relasional di DynamoDB).
-
Dalam basis data NoSQL seperti DynamoDB, data dapat dikueri secara efisien dalam sejumlah cara terbatas, di luar itu kueri bisa jadi mahal dan lambat.
Perbedaan ini membuat desain basis data menjadi berbeda di antara kedua sistem:
-
Di RDBMS, Anda mendesain untuk fleksibilitas tanpa perlu mengkhawatirkan detail penerapan atau performa. Optimasi kueri umumnya tidak memengaruhi desain skema, tetapi normalisasi itu penting.
-
Di DynamoDB, Anda mendesain skema secara spesifik untuk membuat kueri yang paling umum dan penting seefisien dan seterjangkau mungkin. Struktur data Anda disesuaikan dengan kebutuhan spesifik kasus penggunaan bisnis Anda.
Dua konsep utama untuk desain NoSQL
Desain NoSQL membutuhkan pola pikir yang berbeda dari desain RDBMS. Untuk RDBMS, Anda dapat melanjutkan dan membuat model data yang dinormalisasi tanpa memikirkan pola akses. Anda kemudian dapat memperluasnya nanti ketika ada pertanyaan dan persyaratan kueri baru. Anda dapat mengatur setiap jenis data ke dalam tabelnya sendiri.
Perbedaan desain NoSQL
-
Sebaliknya, Anda tidak boleh mulai merancang skema untuk DynamoDB sampai Anda mengetahui pertanyaan yang perlu dijawab. Memahami masalah bisnis dan kasus penggunaan aplikasi di awal sangat penting.
-
Anda harus mempertahankan tabel sesedikit mungkin dalam aplikasi DynamoDB. Memiliki lebih sedikit tabel membuat segala sesuatunya lebih terukur, memerlukan lebih sedikit manajemen izin, dan mengurangi overhead untuk aplikasi DynamoDB Anda. Hal ini juga dapat membantu menjaga biaya pencadangan tetap rendah secara keseluruhan.
Mendekati desain NoSQL
Langkah pertama dalam mendesain aplikasi DynamoDB adalah mengidentifikasi pola kueri tertentu yang harus dipenuhi oleh sistem.
Secara khusus, penting untuk memahami tiga properti dasar dari pola akses aplikasi Anda sebelum memulai:
-
Ukuran data: Mengetahui jumlah data yang akan disimpan dan diminta pada satu waktu akan membantu menentukan cara paling efektif untuk mempartisi data.
-
Bentuk data: Alih-alih membentuk kembali data saat kueri diproses (seperti yang dilakukan sistem RDBMS), basis data NoSQL mengatur data sehingga bentuknya dalam basis data tersebut sesuai dengan apa yang akan dikueri. Ini adalah faktor kunci dalam meningkatkan kecepatan dan skalabilitas.
-
Kecepatan data: DynamoDB menskalakan dengan meningkatkan jumlah partisi fisik yang tersedia untuk memproses kueri, dan dengan mendistribusikan data secara efisien ke seluruh partisi tersebut. Mengetahui berapa beban kueri puncak di awal mungkin akan membantu menentukan cara mempartisi data agar dapat menggunakan kapasitas I/O dengan sebaik-baiknya.
Setelah mengidentifikasi persyaratan kueri tertentu, Anda bisa mengatur data menurut prinsip umum yang mengatur performa:
-
Menyimpan data terkait bersama-sama. Penelitian telah menunjukkan bahwa prinsip 'lokalitas referensi', menjaga data terkait bersama-sama di satu tempat, merupakan faktor kunci dalam meningkatkan kinerja dan waktu respons dalam sistem NoSQL, seperti yang ditemukan penting untuk mengoptimalkan tabel perutean bertahun-tahun yang lalu.
Aturan umumnya, Anda harus mempertahankan tabel sesedikit mungkin dalam aplikasi DynamoDB.
Pengecualian adalah kasus yang melibatkan data deret waktu bervolume tinggi, atau set data yang memiliki pola akses yang sangat berbeda. Tabel tunggal dengan indeks terbalik biasanya dapat mengaktifkan kueri sederhana untuk membuat dan mengambil struktur data hierarki kompleks yang diperlukan oleh aplikasi Anda.
-
Menggunakan urutan. Item terkait dapat dikelompokkan bersama dan dikueri secara efisien jika desain utamanya menyebabkan item tersebut disortir bersama. Ini adalah strategi desain NoSQL yang penting.
-
Mendistribusikan kueri. Penting juga bahwa volume kueri yang tinggi tidak difokuskan pada satu bagian dari database, di mana mereka dapat melebihi kapasitas I/O. Sebagai gantinya, Anda harus merancang kunci data untuk mendistribusikan lalu lintas secara merata di seluruh partisi sebanyak mungkin, menghindari hot spot.
-
Menggunakan indeks sekunder global. Dengan membuat indeks sekunder global tertentu, Anda dapat mengaktifkan kueri yang berbeda dari yang dapat didukung oleh tabel utama Anda, dan itu masih cepat dan relatif murah.
Prinsip-prinsip umum ini diterjemahkan ke dalam beberapa pola desain umum yang dapat Anda gunakan untuk memodelkan data secara efisien di DynamoDB.
NoSQL Workbench untuk DynamoDB
Tidak ada SQL Workbench untuk DynamoDB adalah aplikasi GUI sisi klien lintas platform yang dapat Anda gunakan untuk pengembangan dan operasi basis data modern. Ini tersedia untuk Windows, macOS, dan Linux. NoSQL Workbench adalah alat pengembangan visual yang menyediakan fitur pemodelan data, visualisasi data, pembuatan data sampel, dan pengembangan kueri untuk membantu Anda mendesain, membuat, mengkueri, dan mengelola tabel DynamoDB. Dengan NoSQL Workbench untuk DynamoDB, Anda dapat membuat model data baru dari, atau mendesain model berdasarkan, model data yang sudah ada yang memenuhi pola akses data aplikasi Anda. Anda juga dapat mengimpor dan mengekspor model data yang didesain pada akhir proses. Untuk informasi selengkapnya, lihat Membangun model data tanpa SQL meja kerja.
