Arsitektur database master-master vs master-slave?

117

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?

database 
— never_had_a_name
sumber
1
Teorema CAP -> Consistency Availability Partition Tolerance menyatakan bahwa Anda tidak dapat menggabungkan ketiganya. Tergantung pada aplikasinya, Anda dapat memilih salah satunya.
— Pritam Banerjee

Jawaban:

87

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.

— djna
sumber
CouchDB menggunakan MVCC. Apakah ini menangani masalah konsistensi yang dihadapi oleh beberapa master karena ketika satu saya membawa online lagi, sistem versi menangani konsistensi dan master ini akan mendapatkan data yang diperbarui dengan benar.
— never_had_a_name
8
Tetapi apa yang terjadi jika dua pengguna melakukan sesuatu yang kontradiktif - seperti dua pengguna mencoba membeli item terakhir yang ada dalam stok? Bayangkan sebuah skenario di mana kita memiliki dua master dan setiap pengguna mencapai master yang berbeda, lalu kita mendapatkan semacam kesalahan komunikasi - pada akhirnya akan ada kompromi integritas, atau ketersediaan yang berkurang - satu pengguna akan diberi tahu "maaf sobat, Saya benar-benar tidak tahu apa yang terjadi sampai saya berbicara dengan master lain ", atau kami mengalami konflik yang tidak menyenangkan saat komunikasi dipulihkan - dan itu bisa menjadi sangat rumit.
— djna
2
Apa yang digunakan perdagangan keuangan atau pasar saham? Mereka akan menghadapi masalah ini sepanjang waktu?
— CMCDragonkai
3
Di mana Anda membutuhkan satu, memperbarui, "kebenaran" (seperti dalam sistem keuangan) Anda membutuhkan Master / Slave atau memang hanya Master. Di mana Anda dapat menambal kebenaran nanti (pikirkan menggabungkan konflik dalam sistem kontrol revisi seperti Git) maka Anda dapat menggunakan Master / Master.
— djna
Djna membuat pengamatan yang sangat menonjol. Database sekarang harus memiliki semacam logika "tiebreaker". Apa yang terpenting? Data paling "terbaru"? Itu masuk akal jika Anda menulis ulang bidang, tetapi tidak masuk akal jika Anda melakukan "penghitung" dan Anda memerlukan semua proses untuk penambahan (atau pengurangan) sebelum mengembalikan hasil. Terutama agar Anda tidak menjual barang yang stoknya habis. Jika Anda memiliki partisi jaringan, apa yang terjadi ketika partisi tersebut kembali bersama? Semua ini adalah teori CAP. Di sini juga Anda dapat memiliki algoritme seperti Paxos, untuk mengembangkan konsensus di antara mesin yang berbeda.
— Peter Corless
95

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

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

— Skillachie
sumber
2
Bisakah Anda juga menulis sesuatu tentang Galera? Kluster Percona XtraDB?
— Ivanov
"Aplikasi mungkin harus dimulai ulang" sebagai bagian dari kontra. Apa artinya?
— Lily
1
Jika Anda harus mengubah IP dari server DB maka itu perlu dikonfigurasi dalam aplikasi juga untuk membaca dari master baru yang dipilih. Akibatnya, Anda mungkin perlu memulai ulang aplikasi Anda untuk mengambil pengaturan konfigurasi baru. Itu semua tergantung pada pengaturan Anda saat ini. Anda juga bisa menggunakan IP mengambang untuk melewati ini. Sekadar memberi Anda gambaran umum
— Skillachie
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.