Bir Büyük Veritabanı ve Birkaç Küçük Kişi

(A) tablo örneklerini kullanarak bir uygulama örneğini bir MySQL veritabanına dağıtabiliriz veya (B) uygulamanın her örneği için farklı MySQL veritabanları kullanabiliriz, örneğin,

Kurulum "A":

central_database
  app1_table1
  app1_table2
  app1_tablen
...
  appn_table1
  appn_table2
  appn_tablen

Sonuç birçok tablo ile büyük bir db oldu.

Kurulum "B":

app1_db
  table1
  table2
  tablen

...

appn_db
  table1
  table2
  tablen

Sonuçta bazı tablolar ile birçok veritabanı olur.

Her şey eşittir (örneğin, veri miktarı, uygulama örneği sayısı vb.), Her iki yaklaşımla da gitmenin avantajları ve dezavantajları nelerdir? Veritabanı performansı ve bakımına ne zarar verebilir? Uygulama PHP 5 tabanlı, Apache 2.x üzerinde çalışıyor ve MySQL 5.x kullanıyoruz.

Zaman ve düşünceleriniz için çok teşekkürler!

Bin veritabanının en iyi parçası olan ve birden çok sunucuya yayılmış bir sistem çalıştırdım. Hepsi aynı yapıdaydı ve her bir makinede bulunan bir şablon veritabanı ile senkronize edildi.

Bu bana bir aşırı aşırı yükleniyor olsaydı veritabanlarını bir db'den diğerine geçirme olanağı sağladı ve istemci karışımı değiştikçe, sunucular arasında denge yüklemek için farklı sunucularda yeni veritabanları oluşturabilirim. Bu, sistemden aldığım en büyük avantajdı, çünkü ayrı sunucularda aynı anda birden fazla karmaşık sorgu gerçekleştiren çok sayıda büyük kalay topluluğum vardı.

Bunun en güzel yanı, yapılandırmaya kendi hızınızda sunucu ekleyebilmenizdir, çünkü her sunucu aşırı yüklenmeye başlar, karışıma başka bir tane ekler, yeni sunucuya bazı dbs'yi geçirir ve güzel bir şekilde sonlanır yük dengeli sunucu seti. Gerektiğinde ve gerektiğinde sisteme ölçek eklemek için gerçekten güzel ve basit bir yol!

Tek bir büyük veritabanı yaklaşımı yerine bu yaklaşımla gitmemizin nedeni, yaratılacak potansiyel veritabanının büyüklüğüdür ... 1000 veritabanının her birinin 200 tablosu ve her birinin içindeki tabloların çoğu veritabanları yüz milyonlarca veri satırından oluşuyordu !

Tek bir veritabanı yapılandırmasında belirli tabloların (yaklaşık 8 tanesi) çoklu milyarlarca veri satırına sahip olması gerekirdi ve toplam db boyutu 10 TB'ın üzerinde olurdu. Her birinde çok sayıda veritabanı bulunan 5 TB RAID 10 depolama alanına sahip birden fazla sunucuya sahip olduk.

Ben de öyle yapardım! Umarım karar vermenize yardımcı olur ... :)

Oluşturduğunuz uygulama bir SaaS uygulaması mı? Eğer öyleyse, üçüncü bir yaklaşımı düşünmenizi öneririm - tek bir farkla tüm uygulama örnekleri için ortak bir yapıya sahip bir DB'ye sahip olmak - tüm tablolara bir userid / applicationid sütunu ekleyin. Bu, uygulama geliştirme / bakım maliyetlerinizi büyük ölçüde azaltacaktır. Deneyimlerime göre bu, çok kiracılı verileri depolamak için en iyi yaklaşımlardan biridir.

Ayrıca Microsoft tarafından çok kiracılı veri mimarisi hakkındaki bu büyük beyaz makaleye bakın

Ayrıca, bahsettiğiniz yaklaşımların avantajlarını / dezavantajlarını da vurgular.

B Ayarı'nın yönetimi çok daha kolay

Her biri tablenfarklı bir klasörde bulunur. İşletim sistemi sınırlarını test etmek istemiyorsanız bu çok yararlı olabilir .

Örneğin, işverenim bir CRM araç bayiliği sistemi için MySQL'e ev sahipliği yapıyor. Müşterinin 800 bayisi vardır. Her bayi veri tabanında 160 tablo bulunmaktadır. Bu 128.000 tablo.

• Kurulum A altında, 128.000 tablonun tümü tek bir veritabanı altında oturur.
• Kurulum B altında, her 160 tablo kümesi / var / lib / mysql altındaki bir alt klasörde bulunur.

İşletim sistemi ve klasör başına maksimum sayıda dosyaya sahip olan i-düğümleri (veya Windows için FAT tablolarını) işleme yeteneği açısından:

• Kurulum A altında, tek bir klasör altında yaklaşık 128.000 dosya için endişelenirsiniz. İşletim sisteminiz tek bir klasör altında bu kadar çok dosyayı destekleyebilir mi?
• Kurulum B altında böyle bir endişe yok.

Tablo yapılarını ALTER TABLEveya başka bir DDL kullanarak tweek etmek zorunda kaldıysanız :

• A Kurulumu altında, gerekli DDL'yi PHP'ye (veya özel MySQL komut dosyalarını) kullanarak tabloya ve ilgili sorgulara erişmeden ve değişiklik yapmadan önce komut dosyası yazmanız gerekir.
• Kurulum B altında, Sağ veritabanına bağlan, ardından her seferinde aynı adlı tabloya erişin. Erişim paradigması her zaman temiz olacaktır:
  • Özel Veritabanı
  • Altında Belirli Klasör /var/lib/mysql
  • Belirli Tablo Adı.

Farklı disklere farklı veritabanları koymak istiyorsanız:

• Kurulum A altında, ayrı bir diske taşınan her tablo için semboller yalnızca "klasördeki inode sayısı" sorununu daha da kötüleştirecektir. Disk G / Ç ve genel tablo erişimi daha fazla karmaşıklaşır ve .frmdosyalara art arda erişildiğinden toplam sunucu yükünü artırır .
• Kurulum B altında, tüm veritabanı klasörünü ayrı bir veri yuvasına taşıyın. Disk G / Ç isteğe bağlı olarak dağıtılabilir.
• CAVEAT: InnoDB için kesinlikle önerilmez

Mecazi olarak konuşmak ister misiniz?

• bir yatak odası, bir banyo ve bir mutfaktan oluşan devasa bir daire (SetupA)
• her biri kendi yatak odası, banyo ve mutfağı olan birden fazla daire (SetupB)

Bir dairede bir radyatör sabitlemeye gelince:

• Kurulum A ile, her kiracı rahatsız edici olabilir ve dahil edilmelidir, çünkü etkilenen kiracılar ile herkesin önünde olduğu gibi herkesin önünde konuşmak zorundasınız
• B Ayarı ile, duvara veya borulara çarpma sesi duymak dışında kiracılar özel hayatlarına devam edebilir
• Bu liste ve metaforları uzayıp gidebilir

IHMO Bütçeler tasarım / altyapı kararları için itici bir güç olsa da, müşteri başına veritabanlarını ayırmaktan kolayca yararlanabilirim.

Ayrıca bir SaaS ürünüm var ve Dave Rix ile aynı kurulumu kullanıyorum.

Her müşterinin kendi veritabanı vardır

Birkaç öneride bulunacağım:

• Veritabanı konumunu (ip), veritabanı adını ve müşteri adını depolayan bir veritabanı "denetleyici" yük dengeli (master-master) olmalıdır. Bu denetleyici, uygulamanızın her müşteri veritabanının nerede olduğunu bildiği yerdir.

• Başvurunuz istediğiniz her yerde olabilir - dünyadaki birçok veri merkezi için veritabanına sahip olabilirsiniz.

• Uygulamanız istediğiniz kadar büyüyebilir. Bu bir Web SaaS ise, müşteri girişinde olduğu gibi her veritabanına işaret eden yük dengeli bir web sunucusu grubu oluşturabilirsiniz.

• Bazı müşteriler için başkalarını etkilemeden özelleştirilmiş GÖRÜNÜM / Veritabanı oluşturabilirsiniz. İşletmenizin bir parçası olarak özelleştirme sunmaya çalışırsanız bu önemlidir.

• İki web grubu + veritabanı grubu oluşturabilirsiniz: biri "EDGE" diğeri "STABLE" sürümleri için. Ardından, tüm müşterilerinize başvurmadan önce, bir şeyleri test etmek ve her şeyin beklendiği gibi çalıştığını (başka bir deyişle, kalite güvencesi [KG]) doğrulamak isteyen küçük bir müşteri grubuna sahip olmanız gerekir.

• Günde en az bir kez veritabanı başına otomatik bir yedekleme işiniz olmalıdır.

• Çoğaltma yapmak için başka bir sunucunuz olmalıdır. Aynı miktarda "ana" ve "bağımlı" ana sunucu göze alamazsanız, aynı ana bilgisayar birçok veritabanını çoğaltabilir (aynı ana bilgisayardaki her sunucu için farklı bağlantı noktaları kullanın).

  Örneğin, 5 ana sunucu + farklı veritabanlarında çalışan 5 veritabanına sahip 1 bağımlı sunucu - bunu yapmak için yeterli RAM'e sahip olmanız yeterlidir.

• Bir veritabanını istediğiniz zaman başka bir sunucuya taşımak için bir "taşıma" aracı kullanmalısınız.

• Gelirinizi korumak için VIP müşterileri daha güvenli / kullanılabilir veritabanı sunucusuna taşımalısınız. Unutmayın, müşterilerin% 20'si gelirinizin% 80'ini temsil eder. Özel müşterilerle ilgilenin.

• "Son yedekleme" yapmak ve müşteri şirketinizden ayrıldığında veritabanını silmek için yedek silme "çöp" toplayıcısına sahip olmalısınız.

• Yeni hesaplar için dışa aktardığınız ve kullandığınız bir veritabanı resminizin olması gerekir.

• Mevcut hesaplara yeni düzeltme ekleri uygulamak için bir veritabanı düzeltme aracına sahip olmanız gerekir.

• Subversion veya git gibi bir sürümleme aracını kullanarak tüm SQL yamalarınızın sürümlerini saklayın ve kendi numaralandırmanızı da oluşturun. xxx-4.3.0.sql - bazen yama yanlış gidiyor ve yama görevini nasıl kurtaracağınızı / tamamlayacağınızı bilmelisiniz.

Peki, şirketimde her biri yaklaşık 600 tablo içeren yaklaşık 5k veritabanına sahip bir ürünle yaptığım tek şey bu.