it-swarm-tr.com

Tek V / s Çoklu Veritabanları

Çeşitli web siteleri için (şu anda yaklaşık 20 müşteri) bilgi depolayan bu web uygulamasını (php & mysql) geliştirdim.

Mevcut senaryo, müşteri ile ilgili bilgileri bireysel veritabanlarında depolar, 20 müşteri veritabanı ve 1 ana veritabanı vardır.

Buradaki ana avantajlardan biri, her müşteri db'si izole edildiğinde, müşteri artefaktlarının (raporlar, denetimler) vb. Sıralanması; müşterilerimize güvenlik hissi veriyor.

Her DB yaklaşık 15 tablodan oluşur ve bir tablodaki en fazla 2000 sıra vardır. Bunun en fazla 5000 kayıt olması beklenir.

Tek bir db düzeyinde değişiklik yapmak, 20 veritabanını değiştirmek anlamına gelir, ancak nadir bir durumda böyle bir değişiklik yapmam gerekiyorsa, bunu tek bir işlev çağrısında yapan bir komut dosyası kullanırım.

Paylaşılan bir barındırma düzenlemesi içindeyiz ve İSS'imiz bize sınırlı sayıda sağlıyor. Veritabanları; ve bu beni veritabanını merkezileştirme konusunda düşünmeye iten şeydi; böylece TÜM istemci verileri ana veritabanında depolanabilir.

Elbette, ortaya çıkan bazı önemli konular:

a. Artefakt sırasını korumak, (ek bir referans anahtarı yaratılarak ele alınabilir) b. Hız ve performans (bu durumda işleri hızlandırmak için indeksler oluşturabilirim) c. Güvenlik: Bu, müşteri bilgilerini alan her sorgu olarak yönetilecektir. ayrıca client_id adresini de takip edecek

Gelecekte, bir örgütün veri kümelerini diğeriyle karşılaştırmayı düşünmemiz gerekebilir, ancak bunun da merkezi bir db'de elde edilebileceğine inanıyorum. Biraz merkezi bir veritabanına geçmeye (performans ve bakım kolaylığı nedeniyle) meyilliyim.

Merkezi bir veritabanına taşınmanın bizim gibi kalmamdan daha anlamlı olduğunu düşünüyor musunuz (bireysel veritabanlarında)?

Tavsiyen için teşekkürler.

17
Narayan

Her iki sistem için de devralınan riskler ve ödüller vardır. 1 veri tabanında yaklaşık 40 müşteriyi (ulusal banka) destekleyen bir finans firmasında çalıştım. Daha sonra benzer yazılım satan ve müşteri başına 1 veritabanı olan başka bir şirketi satın aldık. Sonunda şirket iflas etti ve tüm kullanıcı verilerini vermek zorunda kaldık. İşte birlikte çalıştığım insanlar ve bulduklarım:

Tek DB Uzmanları:

  1. Yazılım güncellemeleri ve hata düzeltmeleri daha kolaydır.
  2. Tüm müşteri verilerini yönetmek ve raporlamak kolaydır.
  3. Verilerin güncellenmesi daha kolay hale gelir.
  4. 1 istemcinin istediği modüler işlevselliği oluşturmak kolaydır, diğer istemciler için kapalıysa kapatın ve daha sonra istedikleri zaman birisini açın.

Tek DB'nin Con'ları:

  1. Veri bütünlüğü - 1 bankanın kullanıcılarının başka bir bankanın verilerini gördüğü 2 veya 3 vaka vardı. Bu bir kabustu. Özellikle site kullanıcıları sadece banka çalışanları değil, bankanın müşterilerini tutan gerçek hesaplar olduğu için! Bu şimdiye kadar 1 veritabanı ile en büyük konudur
  2. Müşteri verilerini dışa aktarma -Bunun zorunda kaldığımızda genellikle önemli değildi. İçinde tüm müşterilerin bulunduğu 1 masa ile bitirdiniz ve müşterinize özel veriler elde etmek için bu masayı kapatıyorsunuz.

Profesyonellerin Çoklu DB'leri:

  1. Müşteriler arası veri kontaminasyonu veya ihlal endişesi yoktur
  2. Bir müşteri verilerini vermek kolaydır.

Conların Çoklu DB'leri:

  1. Güncellemeler ve hata düzeltmeleri - Bu gerçek kabus oldu. 20 farklı veritabanında 20 müşteriniz olduğunda hızlı bir şekilde, 1 müşterinin bir hatanın düzeltilmesini istediği ve bir başkasının hatanın bir özellik olduğunu düşündüğü veya güncelleme riskini göze almak istemediği bir duruma girersiniz. Dahası, 1 müşterinin oyun değiştirme becerisini geliştirmek istediği ancak diğer müşterilerin istemeyeceği durumlar olacaktır. Bu olduğunda, veritabanları birbirinden ayrılmaya başlayacaktır. Birden müşterilerinizi 1-15, 1 ile 16-19 arasındaki bir betiği, 20'si ise üçüncü ile güncellemeniz gerekecek. Bunun böyle bir sorun olduğunu gördük, bir hata düzeltmesinin bizden daha fazla satın aldığımız şirket için 15 ila 20 kez süreceği, çünkü her müşteri için tüm testleri yapmaları ve her müşteriye özel kodlarla uğraşmaları gerekti. Etkili olarak, her yeni müşteri için yeni bir destek görevlisine ihtiyaç duydukları halde, ana şirketin her 5 ila 10 müşteri için birine ihtiyacı vardı.
  2. DB yönetimi - Tüm veritabanlarını yöneten çok sayıda müşteriye ulaştığınızda gerçek bir güçlük haline gelir. Şüphesiz onları yönetmek için daha fazla DBA zamanına ihtiyacınız olacak.

Sonunda ikisini de görüp yapmış olan önerim "disipline" sahip olmak! Multi-db seçiminin biraz daha iyi olduğunu düşünüyorum çünkü sizi koruyor, ancak müşterilerin yalnızca onlara işlevsellik eklemenize neden olacak bir seçim yapmasına izin veremezsiniz ya da kendinizi başarısızlık yoluna sokacaksınız.

13
Ben Hoffman

Ayrı müşteriler için ayrı bir veritabanına sahip olurdum. Bir müşteri güvenlik nedenlerinden dolayı bunu talep edebilir - yani yalnızca kendi siteleri verilerine erişebilir. Ayrıca, bir müşteri verilerini taşımak istiyorsa o zaman çok yönetimi daha kolay olacak demektir.

Ayrıca, bir müşterinin veritabanında bir sorun varsa, diğerlerini etkilemeyeceği anlamına gelir.

Müşteriler arasında veri karşılaştırmak istiyorsanız, o zaman bunu ayrı ayrı yapmalısınız.

Sahip olabileceğiniz veritabanları tükeniyorsa, belki de Ana Bilgisayar sağlayıcınızı değiştirmeyi düşünmelisiniz.

13
ChrisF

Şimdiye kadar listelenen profesyonellerin/con'ların listesine eklemek için:

Profesyonellerin çoklu veritabanları:

  1. Kilitleme sorunlarından kaçınılır; Müşterilerin bazı tablolarda DDL değişikliklerini tetikleyebilecekleri veritabanlarımız var. Daha büyük tablolar için (> 2m kayıt) bu tabloyu önemli bir süre kilitler. Dezavantajlı olan tek kişi kendi kullanıcılarıdır, bu da kabul edilebilir bir durum.

  2. Esneklik - bazı müşterilerin saklamak istedikleri verilerle ilgili özel istekleri vardır; çoklu veritabanı bize, diğer müşteriler için veri modelini karıştırmadan, özellikle veritabanlarını değiştirme esnekliğini sağladı.

Eksileri:

  1. Majör con: Diğer masalara katılmak çok daha zahmetli. Çoğu meta veri içeren bir ana veri tabanımız var. Müşteriye özgü veritabanı kullanıcıları bu veritabanına erişemez, bu nedenle o veritabanındaki tablolar ile müşteriye özgü olan arasındaki tüm bağlantılar veritabanında değil uygulamada işlenir. Müşteriye özel kullanıcılara ana veritabanına erişim izni vererek bunu çözebilirsiniz, ancak daha sonra uygulama tekrar bilgi sızdırabilir.

Seçiminde iyi şanslar!

0
kander

Zaten bir cevap seçtiğinizi biliyorum, ancak önerilmeyen başka bir çözüm var gibi görünüyor:

Her şeyi bir veritabanına taşıyın, ancak aşağıdaki gibi bir önek kullanarak her müşteri için tablolar oluşturun:

initec_contacts_tbl
initec_accounts_tbl
initec_personel_tbl
...
masterco_contacts_tbl
masterco_accounts_tbl
masterco_personel_tbl

Her iki dünyanın da en iyisi.

  • Mevcut kurulumunuzdan yeni kurulumunuza geçiş yapmak çok kolaydır.
  • Müşteri başına 1 kullanıcı oluşturabilir ve ayrıcalıklarını şirket tablolarıyla sınırlandırabilirsiniz.
  • Gerekirse bir superuser oluşturabilir ve kolayca toplu veri oluşturabilirsiniz.
  • Sadece bir veritabanı kullanın
0
Sylver

Her müşteri için ayrı bir veritabanına sahip olmamamın tek nedeni, 100 veya 1000 müşteri/veritabanına sahip olmanızdır. Bu, veritabanında değişiklik yapmak veya tüm veritabanlarında bir şeyler yapmak dahil olmak üzere, yönetimi gerçekten kıllı olabilir. Çok sayıda veritabanında gerçekleşen eylemler, çok sayıda tabloyu açmanız (ve dolayısıyla kapatmanız) gerektiğinden de yavaş olabilir.

Ancak bu durum dışında, birden fazla veritabanının daha iyi olduğunu düşünüyorum.

Önemli olmasa da faydalı olabilecek bir avantaj, her müşterinin kendi sıralı kimliğini elde etmesidir (başka bir müşteri (ler) kayıt eklediği için bir demet atlamak yerine).

Ayrıca, çoklu veritabanları, alt tabloların (telefon türü gibi), bu tablolarda bir üst kayıt kimliğine ihtiyaç duyulmaksızın müşteri başına kolayca özelleştirilebilmesini sağlar.

0
Darryl Hein

İlk önce yapay sıralama. Bunu sağlamak için tamsayı birincil anahtarlarını kullandığınızı varsayıyorum. Gerçekten, ayrı bir "yapay sayı" sütununa sahip olmalısınız. PK, PK olmalı ve başka bir şey olmamalıdır. İnsanlar "doğal anahtarlar" ve benzerlerinden bahseder ve ben de kenara çekerim. Ne zaman PK'ya bir tanımlayıcı olmaktan daha fazla güveniyorsanız, sizi ısırmaya gelir. Bir şeyin sırasını bilmek istiyorsanız, bir tarih veya sıra numarası saklayın.

Sizin durumunuzda konfigürasyon yönetiminin sizi tek bir veritabanına götüreceğini düşünüyorum. Veritabanlarını korumak ve yükseltmek için size zaman içinde maliyetin ne olduğuna bakın. Yazılımın her sürümüyle ilgili maliyetler nelerdir? Ayrıca, yeni bir müşteri aldığınızda ve bir DB oluşturmanız ve uygulamayı bunun için yapılandırmanız gerektiğinde maliyeti düşünün. Her şey otomatikleştirilebilir, soru şu ki, 100 veritabanınız olduğunda buna değecek mi?

Yolda, tek bir veritabanını ölçeklemek (bölümleme, donanım, paylaşım vb.), Aynı 100 veritabanında yapmaktan daha kolaydır.

Bence diğer afişler bazı mükemmel puanlar almışlardı, ben de bunların üzerinden geçmeyeceğim.

0