Tek bir veritabanı kullanarak birden çok veritabanı kullanmanın artıları / eksileri

Performans, kararlılık, optimizasyonun daha kolay uygulanabileceğini savunan 7 veritabanı kullanma gereksinimi olan yeni bir proje üzerinde çalışıyordum.

Kabul etmeme rağmen, tek bir veritabanı (tabloları mantıksal alanlara bölme) kullanmak için iyi argümanlar toplamada sorun yaşıyorum.

Şimdiye kadar sahip olduğum bir argüman veri bütünlüğüdür (veritabanları arasında yabancı anahtar kullanamıyorum).

Tek veya çoklu veritabanlarını kullanmak için iyi avantajlar / dezavantajlar nelerdir?

[şimdiye kadar özet]

Birden çok veritabanına karşı argümanlar:

• Veri bütünlüğünü kaybetme (veritabanlarında yabancı anahtarlar kullanılamaz)

• Geri yükleme bütünlüğünü kaybetme

• Karmaşıklık kazanmak (db kullanıcıları / rolleri)

• Küçük olasılıklı sunucu / veritabanı azalacak

Çözümler:

• Etki alanlarını ayırmak için şemalar kullanın.

• POC: 7/1 db'nin yürütme planlarındaki noktayı kanıtlamak için kukla verileri kullanın

Hiçbir performans, kararlılık, optimizasyon doğru değildir. Bunların neden doğru olacağına dair sağlam bir argüman veya referans makalesi var mı?

Kaynaklar bir veritabanına tahsis değildir: o yapar böylece SQL Server örneği kaynaklarını dengeler fark

Kaybettin:

• veri bütünlüğü
• bütünlüğü geri yükle (DB7'deki veriler daha sonra DB1 olacaktır)

Karmaşıklık kazanırsınız:

• güvenlik (kullanıcılar, roller vb.) tüm veritabanlarında olmalıdır
• 1 veritabanına sığmayan bazı verileriniz olacak

Seçenekler:

• bir veritabanını ayrı disklere bölmek dosya grupları ile yapılabilir
• verileri mantıksal olarak ayırmak için şemalar kullanın (diğer cevaba göre)

Verileri mantıksal etki alanına böldükten sonra SQL2008 içinde şemalar kullanmaya her zaman bakabilirsiniz (varsayılan dbo'dan uzağa gidiyor), ancak bu acı verici ve OR / Ms ile olmayan bir - standart şema.

Birden fazla veritabanından veri harmanlama pozisyonunda bulundum ve acı verici ve yüksek performanstan uzak. Verileri önbelleğe almanız veya en azından hızı korumak için püf noktaları kullanmanız gerekir.

Test olarak 7 yapay veri tabanı oluşturun. Tüm 7'den aynı anda veya en azından çok sayıda veri gerektiren bir sorgu oluşturun.

Sonra yürütme planlarını karşılaştırın! Sanırım vakanı orada kazanacaksın.

Ayrı veritabanları oluşturmak için iyi nedenler, farklı kullanılabilirlik gereksinimlerini desteklemek veya yönetimi basitleştirmek olacaktır. Örneğin, veritabanlarınız çok farklı yedekleme zamanlamaları veya farklı kurtarma modelleri gerektiriyorsa. Başka bir neden, bunları farklı örneklerde çalıştırmak isteyebilmeniz olabilir.

Tek bir veritabanıyla elde edemeyeceğiniz birden çok veritabanında performans optimizasyonu yoktur. "Performans, kararlılık, optimizasyon" ile ne demek istediğiniz hakkında daha fazla bilgi verebilir misiniz?

Düşünce deneyi: Veritabanınızı yedi parçaya bölmek yerine 7.000 parçaya bölün. Donanım arızasının uygulamanızı etkileme olasılığı nedir? Belirli bir günde belirli bir sunucunun ölme olasılığı% 0.1 ise, bağımlı olduğunuz makine sayısını artırırken bir donanım arızasından etkilenme şansınız daha iyi veya daha kötü mü?

Ben "veritabanı" kavramını iki parçaya bölmek önemli olduğunu düşünüyorum: şema ve veri vs veri hizmet için kullanılan donanım.

Veritabanını birden çok makinede kırmak, bu konudaki diğer cevapların açıkladığı birçok nedenden dolayı iyi olmaz.

Güvenilirlik ve gelişmiş performans için birden fazla makine kullanacaksanız, belki de bunları, sorguları dağıtmak için de kullanılabilecek birden çok sıcak / sıcak bekleme makinesine sahip bir ana sunucunuz olacak şekilde yapılandırabilirsiniz. Bu şekilde, herhangi bir makine bir hata ile karşılaşırsa, veri kaybetmezsiniz ve en kötüsü bir sorguyu yeniden başlatmanız gerekir. Tabii ki, bundan daha karmaşık, ancak temeller geçerlidir.

Bir DB ile hem de dosya ve şema seçeneklerini kullanarak hemfikirim.

Birden fazla parçaya bölünmenin mantıklı olduğu uç durumlar vardır.

FTP sunucuları, dışa aktarma dosya yolları vb. Gibi uygulama ortamı (dev, test, prod) yapılandırması, sunucu başına saklamak istediğiniz ve geri yüklemede üzerine yazılmayan şeyler.

Ayrıca istemciye özgü yordam değişikliklerini yalıtmak için bir yol olarak.

Ancak bunlar performans değil, destek.