Arsitektur database master-master vs master-slave?

Saya pernah mendengar tentang dua jenis arsitektur database.

• master-master

• tuan-budak

Bukankah master-master lebih cocok untuk web saat ini karena itu seperti Git, setiap unit memiliki seluruh kumpulan data dan jika ada yang mati, itu tidak masalah.

Master-slave mengingatkan saya pada SVN (yang tidak saya sukai) di mana Anda memiliki satu unit pusat yang menangani sesuatu.

Pertanyaan:

1. Apa pro dan kontra dari masing-masing?

2. Jika Anda ingin memiliki database lokal di ponsel Anda seperti iPhone, mana yang lebih sesuai?

3. Apakah pilihan salah satu dari ini merupakan faktor penting untuk dipertimbangkan secara menyeluruh?

Kami memperdagangkan ketersediaan, konsistensi, dan kompleksitas. Untuk menjawab pertanyaan terakhir terlebih dahulu: Apakah ini penting? Ya sangat banyak! Pilihan tentang bagaimana data Anda akan dikelola sangatlah mendasar, dan tidak ada "Praktik Terbaik" yang mengelak dari keputusan. Anda perlu memahami kebutuhan khusus Anda.

Ada ketegangan mendasar:

Satu salinan: konsistensi itu mudah, tetapi jika kebetulan turun semua orang keluar dari air, dan jika orang jauh maka mungkin membayar biaya komunikasi yang mengerikan. Bawa perangkat portabel, yang mungkin perlu dioperasikan secara terputus, ke dalam gambar dan satu salinan tidak akan memotongnya.

Master Slave: konsistensi tidak terlalu sulit karena setiap bagian data memiliki tepat satu master pemilik. Tapi kemudian apa yang Anda lakukan jika Anda tidak dapat melihat master itu, diperlukan semacam pekerjaan yang ditunda.

Master-Master: baik jika Anda bisa membuatnya bekerja maka tampaknya menawarkan segalanya, tidak ada satu titik kegagalan, semua orang bisa bekerja sepanjang waktu. Masalahnya dengan ini adalah sangat sulit untuk menjaga konsistensi absolut. Lihat artikel wikipedia untuk lebih lanjut.

Wikipedia tampaknya memiliki ringkasan yang bagus tentang keuntungan dan kerugian

Keuntungan

• Jika satu master gagal, master lain akan terus memperbarui database.

• Master dapat ditemukan di beberapa situs fisik, misalnya didistribusikan ke seluruh jaringan.

Kekurangan

• Kebanyakan sistem replikasi multi-master hanya konsisten secara longgar, yaitu malas dan asinkron, melanggar properti ACID.

• Sistem replikasi yang bersemangat itu rumit dan memperkenalkan beberapa latensi komunikasi.

• Masalah seperti resolusi konflik bisa menjadi sulit karena jumlah node yang terlibat meningkat dan latensi yang diperlukan berkurang.

Saat meneliti berbagai arsitektur database juga. Saya telah mengumpulkan sedikit informasi bagus yang mungkin relevan dengan penelitian orang lain di masa mendatang. Saya datang

1. Replikasi Master-Slave
2. Replikasi Master-Master
3. Kluster MySQL

Saya telah memutuskan untuk puas menggunakan MySQL Cluster untuk kasus penggunaan saya. Namun silahkan lihat dibawah untuk berbagai pro dan kontra yang telah saya susun

1. Replikasi Master-Slave

Pro

• Aplikasi analitik dapat membaca dari slave tanpa memengaruhi master
• Cadangan seluruh database relatif tidak berdampak pada master
• Budak dapat dibuat offline dan disinkronkan kembali ke master tanpa waktu henti

Kontra

• Dalam contoh kegagalan, seorang budak harus dipromosikan menjadi majikan untuk mengambil alih tempatnya. Tidak ada failover otomatis
• Waktu henti dan kemungkinan kehilangan data saat master gagal
• Semua penulisan juga harus dilakukan kepada master dalam desain master-budak
• Setiap budak tambahan menambahkan beberapa beban ke master karena log biner harus dibaca dan data disalin ke setiap budak
• Aplikasi mungkin harus dimulai ulang

2. Replikasi Master-Master

Pro

• Aplikasi dapat membaca dari kedua master
• Mendistribusikan beban tulis di kedua node master
• Kegagalan sederhana, otomatis, dan cepat

Kontra

• Konsisten secara longgar
• Tidak sesederhana master-slave untuk mengkonfigurasi dan menyebarkan

3. Kluster MySQL

Anak baru di kota berdasarkan desain cluster MySQL. Kluster MySQL dikembangkan dengan mempertimbangkan ketersediaan dan skalabilitas yang tinggi dan merupakan solusi ideal untuk digunakan di lingkungan yang tidak memerlukan waktu henti, ketersediaan tinggi, dan skalabilitas horizontal.

Lihat MySQL Cluster 101 untuk informasi lebih lanjut

Pro

• (Avalabilitas Tinggi) Tidak ada satu titik kegagalan
• Throughput yang sangat tinggi
• 99,99% waktu aktif
• Sharding Otomatis
• Responsivitas Waktu Nyata
• Operasi On-Line (Perubahan skema dll)
• Tulisan terdistribusi

Kontra

• Lihat batasan umum

Anda dapat mengunjungi Blog saya untuk rincian lengkap termasuk diagram arsitektur yang menjelaskan lebih lanjut tentang 3 arsitektur yang disebutkan.