AWS MySQL RDS vs AWS DynamoDB [ditutup]

109

Saya telah menggunakan MySQL cukup lama sekarang dan saya merasa nyaman dengan strukturnya & SQL Queries dll.

Saat ini sedang membangun sistem baru di AWS dan saya telah melihat DynamoDB. Saat ini saya hanya tahu sedikit tentang itu.

Apakah yang satu lebih baik dari yang lain?

Apa keuntungan dari DynamoDB?

seperti apa transisi dari kueri MySQL dll ke DB gaya datar ini?

— Adam
sumber

66

Anda dapat membaca penjelasan AWS tentangnya di sini .

Singkatnya, jika Anda terutama memiliki kueri Pencarian (dan bukan kueri Gabung), DynamoDB (dan NoSQL DB lainnya) lebih baik. Jika Anda perlu menangani banyak data , Anda akan dibatasi saat menggunakan MySQL (dan RDBMS lainnya).

Anda tidak dapat menggunakan kembali kueri MySQL atau skema data Anda, tetapi jika Anda berusaha keras untuk mempelajari NoSQL, Anda akan menambahkan alat penting ke kotak alat Anda. Ada banyak kasus di mana DynamoDB memberikan solusi paling sederhana.

— Orang
sumber

262

Sungguh DynamoDB dan MySQL adalah apel dan jeruk. DynamoDB adalah lapisan penyimpanan NoSQL sedangkan MySQL digunakan untuk penyimpanan relasional. Anda harus memilih apa yang akan digunakan berdasarkan kebutuhan sebenarnya dari aplikasi Anda. Faktanya, beberapa aplikasi mungkin terlayani dengan baik dengan menggunakan keduanya.

Jika, misalnya, Anda menyimpan data yang tidak cocok dengan skema relasional (struktur pohon, representasi JSON tanpa skema, dll.) Yang dapat dicari dengan satu kunci atau kombinasi kunci / rentang maka DynamoDB ( atau beberapa toko NoSQL lainnya) kemungkinan akan menjadi taruhan terbaik Anda.

Jika Anda memiliki skema yang terdefinisi dengan baik untuk data Anda yang dapat disesuaikan dengan baik dalam struktur relasional dan Anda memerlukan fleksibilitas untuk melakukan kueri data dalam beberapa cara berbeda (menambahkan indeks seperlunya tentunya), maka RDS mungkin merupakan solusi yang lebih baik .

Manfaat utama menggunakan DynamoDB sebagai penyimpanan NoSQL adalah Anda mendapatkan throughput baca / tulis yang terjamin pada tingkat apa pun yang Anda butuhkan tanpa harus khawatir tentang mengelola penyimpanan data berkerumun. Jadi, jika aplikasi Anda memerlukan 1000 baca / tulis per detik, Anda cukup menyediakan tabel DynamoDB untuk tingkat throughput tersebut dan tidak perlu mengkhawatirkan infrastruktur yang mendasarinya.

RDS memiliki banyak manfaat yang sama dengan tidak perlu mengkhawatirkan infrastruktur itu sendiri, namun jika Anda akhirnya perlu melakukan banyak penulisan ke titik di mana ukuran instans terbesar tidak lagi dapat mengimbangi, Anda agak dibiarkan tanpa opsi (Anda dapat menskalakan secara horizontal untuk membaca menggunakan replika baca).

Catatan yang diperbarui: DynamoDb sekarang mendukung pengindeksan sekunder global, jadi Anda sekarang memiliki kemampuan untuk melakukan pencarian yang dioptimalkan pada bidang data selain hash atau kombinasi kunci hash dan rentang.

— Mike Brant
sumber

10

Jika saya dapat memberikan suara positif untuk jawaban Anda sebesar 100, saya akan melakukannya.

— Salil

Beberapa jenis masalah dalam model informasi cenderung baik untuk implementasi jenis NoSQL. Ketika Anda menemukan masalah seperti itu, tanyakan pada diri Anda pertanyaan apakah masuk akal untuk memiliki NoSQL Db. Beberapa entitas ini adalah: Log, Data deret waktu, Jejaring Sosial, Manajemen Konten, Katalog Produk, dll.

— pengguna398039

150

Kami baru saja memindahkan semua tabel DynamoDB kami ke RDS MySQL.

Meskipun menggunakan DynamoDB untuk tugas tertentu mungkin masuk akal, membangun sistem baru di atas DynamoDB adalah ide yang buruk. Rencana terbaik, dll., Anda selalu membutuhkan fleksibilitas ekstra dari DB Anda.

Berikut adalah alasan kami pindah dari DynamoDB:

Pengindeksan - Mengubah atau menambahkan kunci dengan cepat tidak mungkin dilakukan tanpa membuat tabel baru.
Kueri - Kueri data sangat terbatas. Terutama jika Anda ingin meminta data yang tidak diindeks. Penggabungan tentu saja tidak mungkin sehingga Anda harus mengelola hubungan data yang kompleks pada lapisan kode / cache Anda.
Cadangan - Prosedur pencadangan yang membosankan seperti itu merupakan kejutan yang mengecewakan dibandingkan dengan pencadangan RDS yang apik
GUI - UX buruk, pencarian terbatas, tidak menyenangkan.
Kecepatan - Waktu respons bermasalah dibandingkan dengan RDS. Anda mendapati diri Anda membangun mekanisme cache yang rumit untuk mengimbanginya di tempat yang seharusnya Anda selesaikan untuk cache internal RDS.
Integritas Data - Meskipun konsep struktur data fluida terdengar bagus untuk memulai, beberapa data Anda lebih baik "diatur dalam batu". Pengetikan yang kuat adalah berkah ketika ada bug kecil yang mencoba menghancurkan database Anda. Dengan DynamoDB segala sesuatu mungkin terjadi dan memang segala sesuatu yang salah bisa terjadi.

Kami sekarang menggunakan DynamoDB sebagai cadangan untuk beberapa sistem dan saya yakin kami akan menggunakannya di masa mendatang untuk tugas-tugas tertentu yang ditentukan dengan baik. Ini bukan DB yang buruk, itu bukan DB yang melayani 100% sistem inti Anda.

Sejauh keuntungan pergi, saya akan mengatakan Skalabilitas dan Daya Tahan. Ini berskala luar biasa dan transparan dan (semacam) selalu naik. Ini adalah fitur yang sangat bagus, tetapi mereka tidak mengimbangi dengan cara apa pun untuk aspek negatifnya.

— Yami Glick
sumber

11

Pro / kontra yang sangat spesifik. Jawaban bagus

— stevendesu

10

Beberapa di antaranya sudah usang. Misalnya, 1 tidak lagi benar.

— mbroshi

2

Jawaban yang terdokumentasi dengan sangat baik. Namun, beberapa kekhawatiran ini mungkin khusus untuk kasus penggunaan yang jarang terjadi. Nomor 2 - "Tentu saja tidak mungkin bergabung" - Struktur data DynamoDB seharusnya tidak memiliki hubungan - titik. Tabel harus benar-benar dinormalisasi. Itu berarti beberapa atribut diduplikasi. Untuk kasus seperti itu, gunakan pemicu dinamo atau penulisan bersyarat. Jika pengguna tidak dapat menangani latensi untuk penulisan bersyarat, letakkan antrean SQS antara aplikasi dan dinamo. Selanjutnya, poin nomor 6 adalah misnamed ke titik yang menimbulkan keraguan pada "integritas" DynamoDB ini - yang mungkin tidak niat ...

— doles

1

Dynamo masih kekurangan fleksibilitas saat membuat kueri. Meskipun GSI sangat membantu, tetapi kami tetap dapat membuat model data kami lebih baik dengan skema RDBMS.

— Pavan

1

Saya akan menambahkan bahwa kemampuan kueri dalam DynamoDB memiliki beberapa "gotcha". Misalnya, jika kunci utama Anda hanya terdiri dari hash, kueri Dynamo hanya dapat mengembalikan 1 entri, Anda tidak dapat memberikan rentang ke kunci khusus hash pada waktu kueri, Anda juga tidak dapat membuat kueri tanpa mengetahui hash spesifik dari item yang Anda cari. BatchGet hanya menerima 100 permintaan dalam permintaan, ukuran respons total 1MB atau ukuran kueri total 1MB, mana saja yang lebih dulu. Pemindaian memberi Anda pencarian yang fleksibel, tetapi sangat tidak efisien dan mahal, mengembalikan seluruh tabel sebelum memfilter.

— Brooks

12

Saat menggunakan DynamoDB, Anda juga harus mengetahui bahwa item / catatan di DynamoDB dibatasi hingga 400KB (Lihat Batas DynamoDB ). Untuk banyak kasus penggunaan, ini tidak akan berhasil. Jadi DynamoDB akan bagus untuk beberapa hal, tetapi tidak semua. Hal yang sama berlaku untuk banyak database NoSQL lainnya.

— Ali
sumber