Perbedaan utama dan prinsip desain Tanpa SQL desain - Amazon Keyspaces (untuk Apache Cassandra)

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

Perbedaan utama dan prinsip desain Tanpa SQL desain

Tidak ada sistem SQL database seperti Amazon Keyspaces yang menggunakan model alternatif untuk manajemen data, seperti pasangan nilai kunci atau penyimpanan dokumen. Saat Anda beralih dari sistem manajemen basis data relasional ke sistem Tanpa SQL basis data seperti Amazon Keyspaces, 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). Praktik terbaik pemodelan data: rekomendasi untuk merancang model data

  • Dalam SQL database No seperti Amazon Keyspaces, 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 Amazon Keyspaces, Anda mendesain skema Anda secara khusus untuk membuat kueri yang paling umum dan penting secepat dan semurah 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 mendesain skema Anda untuk Amazon Keyspaces sampai Anda mengetahui pertanyaan yang perlu dijawab. Memahami masalah bisnis dan kasus penggunaan aplikasi di awal sangat penting.

  • Anda harus memelihara tabel sesedikit mungkin dalam aplikasi Amazon Keyspaces. Memiliki lebih sedikit tabel membuat hal-hal lebih skalabel, memerlukan lebih sedikit manajemen izin, dan mengurangi biaya overhead untuk aplikasi Amazon Keyspaces Anda. Hal ini juga dapat membantu menjaga biaya pencadangan tetap rendah secara keseluruhan.

Mendekati Tidak ada SQL desain

Langkah pertama dalam merancang aplikasi Amazon Keyspaces Anda adalah mengidentifikasi pola kueri spesifik yang harus dipenuhi oleh sistem.

Secara khusus, penting untuk memahami tiga properti dasar dari pola akses aplikasi Anda sebelum memulai:

  • Ukuran data: Mengetahui berapa banyak data yang akan disimpan dan diminta sekaligus 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: Amazon Keyspaces menskalakan dengan meningkatkan jumlah partisi fisik yang tersedia untuk memproses kueri, dan dengan mendistribusikan data secara efisien di 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 tentang optimasi tabel perutean 20 tahun yang lalu menemukan bahwa "lokalitas referensi" adalah satu-satunya faktor terpenting dalam mempercepat waktu respons: menyimpan data terkait di satu tempat. Hal ini juga berlaku dalam SQL sistem No saat ini, di mana menyimpan data terkait dalam jarak dekat memiliki dampak besar pada biaya dan kinerja. Alih-alih mendistribusikan item data terkait di beberapa tabel, Anda harus menyimpan item terkait di SQL sistem No Anda sedekat mungkin.

    Sebagai aturan umum, Anda harus memelihara tabel sesedikit mungkin dalam aplikasi Amazon Keyspaces.

    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 agar kueri dalam jumlah besar tidak terfokus pada satu bagian basis data, yang dapat melebihi kapasitas I/O. Sebagai gantinya, Anda harus mendesain kunci data untuk mendistribusikan lalu lintas secara merata di seluruh partisi sebanyak mungkin, menghindari "hot spot".

Prinsip-prinsip umum ini diterjemahkan ke dalam beberapa pola desain umum yang dapat Anda gunakan untuk memodelkan data secara efisien di Amazon Keyspaces.