İçinde çok fazla dosya (BLOB) olan bir SQL Server DB işlemek için strateji?

Senaryo:
ASP.NET uygulamasına hizmet veren SQL Server 2005 veritabanı (ayrı bir web sunucusunda).

Veritabanı:
DB içinde yaklaşık 5GB "normal" veri ve yaklaşık 15GB "dosya" vardır (örneğin: resim olarak depolanan 200k PDF (BLOB), bu tür bir şey). Kullanıcılar tarafından daha fazla dosya yüklenmekte ve hızla daha fazla disk alanı tüketmektedir (DB önümüzdeki birkaç ay içinde 50GB'a kadar büyüyebilir, çoğunlukla dosyalar).

Endişeler:
DB'de bu kadar çok dosya depolamak zaten sorunlara neden oluyor (örneğin: Veritabanının toplam boyutu, zaman zaman tüm DB yedeklemelerini ve dağıtımlarını zorlaştırıyor.).

Ve daha fazla sorun olacağından endişeliyiz . (örneğin: performans sorunları - belki de tüm DB'yi RAM'de tutamama nedeniyle olabilir?)

Soru:
Bu soruna hangi teknik çözümü önerirsiniz? Dosyalar dosya sisteminde depolansın mı? Veritabanını ikiye bölün ve dosyalar için daha büyük, daha yavaş olanı var mı?

İhtiyaç Varsa Daha Fazla Ayrıntı:
Bu dosyalar çok önemli değildir ve çok hızlı erişim sürelerine ihtiyaç duymaz - birkaç saniye iyi olur ve şu anda saatte en fazla bir düzine seçim olabilir. DB'deki diğer "normal" veriler, saniyede birçok kez gereken bilgileri içerir.

Çok benzer bir veritabanına bakıyorum, şu anda 3 TB ve günde 5GB büyüyor.

• Filestream (2008+) yedekleme / geri yükleme sorununu çözmez.
• Paul Randal'ın testi , Filestream'in 1MB'den büyük dosyalar için LOB depolamadan daha iyi performans gösterdiğini söylüyor . İş yükü 256KB-1MB'ye bağımlı ve genellikle <256KB'de daha kötü.
• Bazı ortamlarda Filestream için büyük bir artı, arabellek havuzunu atlaması ve bunun yerine Windows sistem önbelleğini kullanmasıdır.
• Dosyaları bir dosya sistemine koyarsanız, veritabanı kaydıyla işlem tutarlılığını kaybedersiniz. Milyonlarca ayrı dosyayı yedeklemenin ek yükünü de eklediniz, bu da zahmetli olabilir.

Profesyoneller ve aleyhte olanlar Filestream için tartın ve durumunuza uygun olup olmadığını görün. Bizim durumumuzda, farklı bir rota izledik ve veritabanını bölümlere ayırmayı seçtik, böylece kısmi kullanılabilirlik / parça parça geri yüklemeden faydalanabiliyoruz .

Sahip olabileceğiniz, bizim için mevcut olmayan bir seçenek, eski / arşiv dosya gruplarını salt okunur olarak işaretlemektir. Daha sonra salt okunur dosya grupları nadiren yedeklenebilir.

2005 Standardında (bölümleme bir Enterprise sürümü özelliğiyse) takılı kalırsanız ve tarih için salt okunur seçeneğiniz varsa, bunu eski moda bir şekilde çözebilirsiniz.

• Masanızı ayırın. Etkin / geçmiş rotasını veya tarihe dayalı olarak örneğin aylık tabloyu düşünebilirsiniz.
• Geçmiş verileri salt okunur bir dosya grubuna koyun ve yalnızca daha fazla veri arşivlediğinizde yedekleyin. Kullanıcılarınızın bunun yalnızca yedekleme süresini kısalttığını anladığından emin olun. Kısmi kullanılabilirlik özelliğine sahip olmadığınızda geri yükleme biraz zaman alabilir.
• Tablolar üzerinde bölümlenmiş bir görünüm oluşturun .

Son bir seçenek (3 TB'lık blobberimiz için düşündüğümüz), dosya verilerini bir belge veritabanına veya bulut depolama alanına (örn. AmazonS3 , Azure BLOB Depolama Alanı ) taşımaktır . Bu, daha önce bahsettiğim işlem tutarlılığı sorununu tanıtıyor ancak yükü bu çok pahalı SQL Server'lardan uzaklaştırıyor.

SQL Server'daki FILESTREAM özelliğini deneyin ,

FILESTREAM, varbinary (max) ikili büyük nesne (BLOB) verilerini dosya sistemindeki dosyalar olarak depolayarak SQL Server Veritabanı Altyapısını bir NTFS dosya sistemiyle tümleştirir

onun hakkında güzel makaleler

1. SQL Server FileStream'e Giriş
2. BLOB'a veya BLOB'a: Bir Veritabanında veya Dosya Sisteminde Büyük Nesne Depolama
3. SQL Server 2008'de FILESTREAM Depolama