Tidak ada SQL desain untuk DynamoDB

Tidak ada sistem SQL database seperti Amazon DynamoDB yang menggunakan model alternatif untuk manajemen data, seperti pasangan nilai kunci atau penyimpanan dokumen. Ketika Anda beralih dari sistem manajemen database relasional ke sistem SQL basis data No seperti DynamoDB, penting untuk memahami perbedaan utama dan pendekatan desain tertentu.

Perbedaan antara desain data relasional dan No SQL

Sistem basis data relasional (RDBMS) dan Tidak ada SQL database yang memiliki kekuatan dan kelemahan yang berbeda:

• DalamRDBMS, data dapat ditanyakan secara fleksibel, tetapi kueri relatif mahal dan tidak berskala baik dalam situasi lalu lintas tinggi (lihat). Langkah pertama untuk memodelkan data relasional di DynamoDB

• Dalam SQL database No seperti DynamoDB, data dapat ditanyakan secara efisien dalam sejumlah cara, di luar mana kueri bisa mahal dan lambat.

Perbedaan ini membuat desain basis data menjadi berbeda di antara kedua sistem:

• DiRDBMS, Anda mendesain untuk fleksibilitas tanpa mengkhawatirkan detail implementasi atau kinerja. 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 kunci untuk Tidak ada SQL desain

Tidak ada SQL desain yang membutuhkan pola pikir yang berbeda dari RDBMS desain. Untuk ituRDBMS, 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.

Bagaimana Tidak ada SQL desain yang berbeda

• 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 Tidak ada SQL desain

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 RDBMS sistem), SQL database No mengatur data sehingga bentuknya dalam database sesuai dengan apa yang akan ditanyakan. 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 di SQL sistem No, 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 No SQL design 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.

Tidak ada SQL Workbench untuk DynamoDB

Tidak ada SQL Workbench untuk DynamoDBadalah GUI aplikasi cross-platform, sisi klien yang dapat Anda gunakan untuk pengembangan dan operasi database modern. Ini tersedia untuk Windows, macOS, dan Linux. No SQL Workbench adalah alat pengembangan visual yang menyediakan pemodelan data, visualisasi data, pembuatan data sampel, dan fitur pengembangan kueri untuk membantu Anda merancang, membuat, membuat kueri, dan mengelola tabel DynamoDB. Dengan No SQL Workbench for DynamoDB, Anda dapat membuat model data baru dari, atau mendesain model berdasarkan, model data yang 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.