Master-master vs master-slave veritabanı mimarisi?


117

İki tür veritabanı mimarisi hakkında duydum.

  • Ana-Master

  • köle başı

Ana-usta bugünün web'i için daha uygun değil mi, çünkü Git gibi, her birim tüm veri setine sahip ve biri çökerse, pek de önemli değil.

Master-slave bana, işleri idare eden bir merkezi birimin olduğu SVN'yi (sevmediğim) hatırlatıyor.

Sorular:

  1. Her birinin artıları ve eksileri nelerdir?

  2. Cep telefonunuzda iPhone gibi yerel bir veri tabanına sahip olmak istiyorsanız hangisi daha uygun?

  3. Bunlardan birinin seçimi, iyice düşünülmesi gereken kritik bir faktör mü?


1
CAP Teoremi -> Tutarlılık Kullanılabilirliği Bölme Toleransı, üçünü birden yapamayacağınızı belirtir. Uygulamaya bağlı olarak herhangi birini seçebilirsiniz.
Pritam Banerjee

Yanıtlar:


87

Kullanılabilirlik, tutarlılık ve karmaşıklıktan vazgeçiyoruz. Önce son soruyu ele almak gerekirse: Bu önemli mi? Evet çok fazla! Verilerinizin nasıl yönetileceğine ilişkin seçimler kesinlikle temeldir ve kararlardan kaçan "En İyi Uygulama" yoktur. Özel gereksinimlerinizi anlamanız gerekir.

Temel bir gerilim var:

Bir kopya: tutarlılık kolaydır, ancak eğer aşağı olursa, herkes sudan çıkar ve insanlar uzaktaysa korkunç iletişim masrafları ödeyebilir. Bağlantısız çalışması gerekebilecek taşınabilir cihazları resme getirin ve bir kopya onu kesmeyecektir.

Ana Bağımlı: tutarlılık çok zor değildir çünkü her veri parçasının tam olarak bir sahip ana bilgisayarı vardır. Ama o ustayı göremezseniz ne yaparsınız, bir tür ertelenmiş çalışma gerekir.

Master-Master: Eğer onu çalıştırabilirseniz, o zaman her şeyi sunuyor gibi görünüyor, tek bir başarısızlık noktası yok, herkes her zaman çalışabilir. Bununla ilgili sorun, mutlak tutarlılığı korumanın çok zor olmasıdır. Daha fazlası için wikipedia makalesine bakın .

Wikipedia'nın avantajları ve dezavantajları hakkında güzel bir özet var gibi görünüyor

Avantajları

  • Bir ana birim başarısız olursa, diğer ana bilgisayarlar veri tabanını güncellemeye devam edecektir.

  • Ana bilgisayarlar birkaç fiziksel yerde bulunabilir, yani ağ üzerinde dağıtılabilir.

Dezavantajları

  • Çok yöneticili çoğaltma sistemlerinin çoğu yalnızca gevşek bir şekilde tutarlıdır, yani tembel ve zaman uyumsuzdur ve ACID özelliklerini ihlal eder.

  • İstekli çoğaltma sistemleri karmaşıktır ve bir miktar iletişim gecikmesine neden olur.

  • Çatışma çözümü gibi sorunlar, dahil olan düğümlerin sayısı arttıkça ve gerekli gecikme azaldıkça çözülemez hale gelebilir.


CouchDB, MVCC kullanır. Bu tür, birden fazla ana bilgisayarda karşılaşılan tutarlılık sorununu ele alıyor mu, çünkü birini tekrar çevrimiçi duruma getirdiğimde, sürüm oluşturma sistemi tutarlılığı ele alıyor ve bu ana bilgisayar doğru güncellenmiş verileri alacak.
never_had_a_name

8
Ancak iki kullanıcı, iki kullanıcının stoktaki son ürünü almaya çalışması gibi çelişkili bir şey yaptığında ne olur? İki ustanızın olduğu ve her kullanıcının farklı bir ustaya vurduğu bir senaryo hayal edin, sonra bir tür iletişim arızası yaşarız - sonunda ya bütünlükten ödün verilir ya da kullanılabilirlik azalır - bir kullanıcıya söylenir "üzgünüm dostum, Diğer efendiyle konuşana kadar neler olduğunu gerçekten bilmiyorum "ya da iletişimler geri geldiğinde kötü bir çatışmamız var - ve bunlar gerçekten karmaşık hale gelebilir.
djna

2
Finansal ticaret veya borsalar ne kullanır? Her zaman bu soruna mı kapılıyorlar?
CMCDragonkai

3
Tek bir güncellemeye, "gerçeğe" (finansal sistemlerde olduğu gibi) ihtiyacınız olduğunda, Master / Slave veya gerçekten sadece Master'a ihtiyacınız vardır. Gerçeği daha sonra düzeltebileceğiniz yerde (Git gibi bir revizyon kontrol sistemindeki çakışmaları birleştirmeyi düşünün), Master / Master'ı kullanabilirsiniz.
djna

djna çok dikkat çekici bir gözlem yapıyor. Veritabanının artık bir tür "eşitliği bozan" mantığı olması gerekir. En önemli olan nedir? En "güncel" veriler? Bu, bir alanı yeniden yazıyorsanız mantıklıdır, ancak bir "sayaç" yapıyorsanız ve bir sonucu döndürmeden önce artırmak (veya azaltmak) için tüm işlemlere ihtiyacınız varsa bu mantıklı değildir. Özellikle de stokta olmayan ürünleri satmazsınız. Bir ağ bölümünüz varsa, tekrar bir araya geldiğinde ne olur? Bunların hepsi CAP theorum işleri. Burası aynı zamanda farklı makineler arasında fikir birliği geliştirmek için Paxos gibi algoritmalara sahip olabileceğiniz yerdir.
Peter Corless

95

Çeşitli veritabanı mimarilerini de araştırırken. Gelecekte araştırma yapacak bir başkasıyla ilgili olabilecek iyi bir bilgi parçası derledim. karşılaştım

  1. Master-Slave Çoğaltma
  2. Ana-Ana Kopyalama
  3. MySQL Kümesi

Kullanım durumum için MySQL Cluster kullanmaya karar verdim. Ancak, derlediğim çeşitli artılar ve eksiler için lütfen aşağıya bakın

1. Master-Slave Çoğaltma

Artıları

  • Analitik uygulamalar, master'ı etkilemeden slave'lerden okuyabilir
  • Ana cihaz üzerinde nispeten etkisi olmayan tüm veritabanının yedekleri
  • Slave'ler çevrimdışına alınabilir ve herhangi bir kesinti olmaksızın ana cihazla senkronize edilebilir

Eksileri

  • Bir başarısızlık durumunda, kölenin onun yerine geçmesi için efendiye terfi etmesi gerekir. Otomatik yük devretme yok
  • Bir ana cihaz arızalandığında kesinti ve muhtemelen veri kaybı
  • Tüm yazılar ayrıca efendiye bir efendi-köle tasarımında yapılmalıdır.
  • İkili günlüğün okunması ve her bir köleye verilerin kopyalanması gerektiğinden, her ek bağımlı birim, ana bilgisayara biraz yük ekler
  • Uygulamanın yeniden başlatılması gerekebilir

2. Ana-Ana Kopyalama

Artıları

  • Uygulamalar her iki ustadan da okuyabilir
  • Yazma yükünü her iki ana düğümde dağıtır
  • Basit, otomatik ve hızlı yük devretme

Eksileri

  • Gevşek tutarlı
  • Yapılandırmak ve dağıtmak için master-slave kadar basit değil

3. MySQL Kümesi

MySQL küme tasarımına dayalı şehirdeki yeni çocuk. MySQL kümesi, yüksek kullanılabilirlik ve ölçeklenebilirlik göz önünde bulundurularak geliştirilmiştir ve kesinti, yüksek kullanılabilirlik ve yatay ölçeklenebilirlik gerektirmeyen ortamlar için kullanılacak ideal çözümdür.

Daha fazla bilgi için MySQL Cluster 101'e bakın

Artıları

  • (Yüksek Olabilirlik) Tek bir hata noktası yok
  • Çok yüksek verim
  • % 99.99 çalışma süresi
  • Otomatik Sharding
  • Gerçek Zamanlı Yanıt Verme
  • Çevrimiçi İşlemler (Şema değişiklikleri vb.)
  • Dağıtılmış yazılar

Eksileri

Benim için ziyaret edebilirsiniz blog 3 bahsedilen mimarileri hakkında daha detaylı bilgi girer mimari şemalar içeren tam dökümü.


2
Galera hakkında da bir şeyler yazabilir misin? Percona XtraDB Kümesi?
Ivanov

Eksilerin bir parçası olarak "uygulamanın yeniden başlatılması gerekebilir". Bu ne demek?
Lily

1
DB sunucusunun IP'sini değiştirmeniz gerekiyorsa, yeni seçilen yöneticiden okumak için de uygulamada yapılandırılması gerekecektir. Sonuç olarak, yeni yapılandırma ayarlarını almak için uygulamanızı yeniden başlatmanız gerekebilir. Her şey mevcut kurulumunuza bağlıdır. Bunu atlamak için kayan bir IP de kullanabilirsiniz. Size genel bir fikir vermek için
Skillachie
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.