Lütfen dikkat: Bir SQL Server perspektifinden cevap veriyorum, bu yüzden SQL Server'a özgü bazı kavramlardan bahsediyorum, ancak tüm bu kavramların benzer avantajları ve sınırlamaları olan diğer büyük RDBMS platformlarında eşdeğerleri olduğuna inanıyorum.
Diğer potansiyel artıları / eksileri düşündüğümde muhtemelen bu cevabı düzenlemeye devam edeceğim.
Peki, gerçekten şema, hacim vb. 50.000 kedi veya 50.000 ürün veya 50.000 kanat kuruyemiş hakkında veri depolamaktan farkı nedir?
50.000 farklı müşteriye ait verileri tek bir veritabanında depolamak istememenizin birkaç nedeni olabilir (gerçekten de veriler müşteri tarafından tamamen ayrılabilirse (posta kodları gibi arama tabloları dahil değil) tek bir merkezi veritabanına girebilecek uygulamaya özgü tablolar):
bir müşteri uygulamasını outgrows istiyorsan, durma ve benzeri bir şey üzerine bölme planı sürece, dışarı ölçekli sadece kendi veri ayıklamak ve vb başka örneği, sunucu taşımak için kolay bir yolu yoktur CustomerIDve konum (50.000 dosya gruplarını var sınırlı yine de 15.000 bölüme veya SQL Server'ın eski bir sürümündeyken 1.000'e ve çok fazla dosya grubuna sahip olmak felaket olabilir ). Ayrıca bölümlemenin Enterprise Edition gerektirdiğini unutmayın.
tüm müşterilerinizin bu örnek için çok büyük olduğu ortaya çıkarsa, ölçeklendirme yeni donanım almak ve tüm veritabanını oraya taşımak (ve muhtemelen bunu tekrar yolda yapmak) anlamına gelir.
çok büyük tablolardan satırların bazılarını silmek zorunda kalacağınız için, bir müşteriyi silmek aynı derecede acı verici olabilir ve bu ucuz olmayacaktır.
büyük olasılıkla müşteri verilerinin geniş bir dağılımına sahip olacaksınız (bir müşteri milyar satır, diğer müşteri 5.000 müşteri). Bu, parametre koklama ve kardinalite ve plan kalitesini içeren zararlı performans gibi şeylere yol açabilir (çünkü aynı planları çok farklı veri kümelerine karşı aynı planları tekrar kullanacağınız için).
tüm müşterileriniz aynı SLA ve HA / DR planlarına tabidir. Tüm veritabanına n-günlük günlük yedeklemeleri ile tam kurtarma modunda sahipsiniz ya da basit ve tam + diff yedeklerine güveniyorsunuz. Bir müşteri hatası nedeniyle geri dönmeniz veya veritabanını belirli bir zamanda kurtarmanız gerekiyorsa, bu her bir müşteriyi etkiler.
veri almada hata olasılığı vardır - örneğin, cümlelerin bir müşterinin başka bir müşterinin verilerini veya diğer tüm müşterilerin verilerini görmesine yol açabileceği hatalar .
yasal sonuçlar olabilir (bazı şirketlerin verilerini başka bir şirketle ve özellikle de rakipleriyle aynı veritabanına yerleştirmemeniz için katı gereksinimleri olacaktır).
herhangi bir müşterinin verilerinin güvenliği önemliyse, bunu elde etmek, veritabanı ayırmayı kullanarak tablodaki ayırmadan çok daha kolaydır.
Her bir müşterinin ayrı bir veritabanına sahip olmasının (veya en azından her biri bir grup müşteri için birden fazla veritabanına sahip olmanın) bazı avantajları:
- boyut açısından, diskte yaklaşık aynı boyutta olacaktır.
- bir veritabanını (veya birçoğunu) farklı bir sunucuya taşıyabildiğiniz için ölçeklendirme daha kolaydır.
- bir müşterinin ve tüm verilerinin silinmesi kabaca eşittir
DROP DATABASE.
- planlar için daha fazla bellek kullanıyorsunuz (veya müşteri başına önbellekte daha az planınız varsa), ancak en azından bu planlar ilgili veritabanlarındaki verilerle ilgilidir ve istatistik / parametre koklama sorunlarına daha az eğilimlidir.
- kolayca farklı SLA'lar ve DR planlarına sahip olabilir, bazı veritabanlarını tam ve diğerlerini basitleştirebilirsiniz. Ayrıca zaman içinde bir noktaya geri dönme veya geri yükleme yalnızca bu müşteriyi etkiler.
- daha hızlı G / Ç'ye farklı veritabanlarını (örneğin, yüksek öncelikli müşterileriniz) kolayca yerleştirebilirsiniz. Bunu dosya grupları ile tek bir veritabanında yapabilirsiniz, ancak bu yönetilmesi çok daha zordur (en azından IMHO).
Bazı dezavantajlar:
- bir kenara, muhtemelen tek bir SQL Server örneğinde 50.000 veritabanına sahip olmak istemezsiniz, bu muhtemelen birden fazla sunucuya ölçeklendirme yapmak anlamına gelir.
- başlangıç zamanı artar çünkü her veritabanının başlatılmasında bazı genel yükler vardır.
- Uygulamanın biraz daha akıllı olması gerekir; burada yalnızca buradaki CustomerID'ye sahip olmak yerine, CustomerID'nin veritabanına dinamik olarak bağlanması gerekir. Bu uygun bir orta kademe ile zor değil ama bir değişiklik.
- evet, aynı tabloların ve prosedürlerin birçok kopyası var, ancak veritabanları arasında kod ve şema aynı, sadece veriler farklı. Kod / şema değişikliklerini dağıtmak artık tek bir yürütme yerine sadece bir döngüdür.
- 50.000 veritabanını yönetirken bakım biraz farklıdır - yine toplam boyut kabaca aynıdır, ancak işlemin değişmesi gerekir - aynı anda 50.000 veritabanının tümünü birleştiremez / yeniden birleştiremez / yedekleyemezsiniz. Daha önceki işimde 500-1.000 özdeş veritabanına sahip örnekleri yönettim ve 3 özdeş veritabanını ve 750 özdeş veritabanını yönetme arasındaki fark basitçe gereken zamandır.