SQL server'a karşı dosyalara hizmet etme - Dosya sistemi vs. S3 vb.
Uygulamamın (klasik asp yay!) 25 GB’da yaklaşık 2.1 milyon imgesi var ve bu yalnızca 90 günlük verileri temsil ediyor ve en azından 365 kez gitmek istiyorum. Bunları kontrol altına almam gerekiyor ve tüm seçenekleri düşünüyorum. Aşağıdaki uygulamaların avantaj ve dezavantajları hakkındaki düşünceleriniz nelerdir:
- SQL Server Artıları: Yedeklemesi kolay Eksileri: Performans?
- Dosya Sistemi Artıları: Hız Eksileri: Artıklık, Yedekleme yavaş (şu anda bunu daha iyi hale getirebilecek yerine Sentetik tam yedeklemeler yapmayı araştırıyor)
- S3 ve Benzeri Artıları: Bant genişliği veri merkezimden Amazon'a kayıyor, neredeyse sınırsız depolama alanı. Eksileri: Maliyet, Maliyet Analizi yanıltıcı (bant genişliğimin% 80'ini yatırım getirisi amaçlı görüntüler olarak tahmin ediyor), Zorunlu/Maliyetli servis sağlayıcıları için gerekli olması gerektiğinde
Milyonlarca insan imajıyla mücadele eden başka biri var mı ve bunu nasıl ele aldınız?
Milyonlarca görüntüümüz yok, ancak yüz binlerce kişi var ve hibrid yaklaşımı kullanıyoruz - meta veri için mysql, yerel diskte depolanan görüntüler ve kullanıcılara servis edildiği Amazon s3'e bastırılıyor. Amazon ve müsaitlik konusunda hiç sorun yaşamadık. Cloudfront'a geçmek planlarımızda, sadece zamanı bulmanız gerekiyor.
Bu tartışma kararınızda size yardımcı olabilir:
http://ask.metafilter.com/59635/Millions-of-images
SQL sunucusunda meta veri ve dosya sistemindeki (veya s3 veya cloudfront) dosyalar ile giderdim. Ancak en iyi cevap diğer bazı kullanım şekillerine bağlıdır:
- görüntüler sık sık değişiyor mu
- görüntüleri doğrudan dosya sisteminden (yani,
img src="...") sunabilir misiniz ya da erişimin kontrol altında tutulması gerekiyor mu? İkincisi, o zaman bir veritabanı çözümü en iyisidir - çoğu zaman az sayıda görüntü sunuyorsunuz (en son% 10) veya dağıtım nispeten yaygın.
Milyonlarca görüntü için yedeklemeler, onları nasıl düzenlediğiniz önemli değil, karmaşık olacak - bu sadece çok fazla veri. Bu çözüme karar vermeden önce, SQL server'da BLOB'ların yedeklenmesi üzerine iyi bir vaka çalışması bulmak isterdim. (İşte faydalı olabilecek bir makale: http://www.databasejournal.com/features/mssql/article.php/3738276/Storing-Images-and-BLOB-files-in-SQL-Server-Part -4.htm )
" Görüntüleri/ikili verileri veritabanında saklamayın " deyince, cevaplarını eski bilgilere dayandırın. Verilerin bir VarBinary tipi sütuna kaydedilmesi). Görüntüleri depolamak için SQL Server kullanma performansı artık SQL Server 2008'deki FILESTREAM veri türü kullanılarak azaltılabilir. Temel olarak, FILESTREAM veri türü, veri saklama kolaylığını birleştirmenizi sağlar NTFS dosya deposundan dosya sunarken elde ettiğiniz performansa sahip veritabanı.
Alıntı yapmak SQL Mag :
"SQL Server 2008’in yeni FILESTREAM desteği, LOB’lere doğrudan NTFS dosya sisteminden erişmenin yararını referans bütünlüğü ve SQL Server ilişkisel veritabanı motoru tarafından sunulan erişim kolaylığı ile birleştiriyor."
Daha fazla bilgi için okuyun bu blog MSDN'de S.Maniam tarafından yazılmıştır .
Bunları dosya sistemine kaydetmeye karar verirseniz, bazılarının ve yapmadıklarının bu ServerFault sorusunu okumak isteyebilirsiniz: Bir milyon görüntüyü dosya sisteminde saklamak .
Milyonlarca imaj zorluğuyla uğraşmasam da, Amazon CloudFront'u kullanırdım. Tüm dosyalar bir S3 kovasında saklanır, ancak Amazon'un içerik dağıtım sistemiyle sunucudur. S3'ü yalnız kullanmam.
İkinci tercihim dosya sistemi olurdu. Basit ve kolay, tek sorun, tüm bu dosyaların bir dizinde kalması durumunda her şey çökecek, zor.
Bana göre SQL, böyle bir sistem için bir seçenek olmazdı. Sadece bant genişliği aktarımı için ücret almakla kalmazsınız aynı zamanda sorgunun işlenmesi için de ücretlendirilirsiniz - bu oldukça barındırmaya bağlıdır, ancak tahsis edilmiş bir sunucu veya en azından ücretlendirilecek bir vps kullandığınızı varsayıyorum döngüleri için. Ardından, görüntü sunucusuyla aynı veritabanını kullanıyorsa sitenizi yavaşlatacaktır. Değilse, iki veritabanı bağlantısını yönetmek zorunda kalmanın tüm bu karmaşıklığını ekleyin.
Veritabanları işlemsel veri/tutarlılık ve güvenlik için tasarlanmıştır.
Medya dosyaları (görüntüler, ses, video) yaratılma ve belki de silinme eğilimindedir, ancak çok nadiren güncellenir. Bu yüzden genellikle bunları diğer verilerle işlemsel olarak tutarlı tutmaya gerek yoktur ve bir veritabanı size orada gerçek bir fayda sağlamaz. Metin içeriği belki farklı bir konu.
Dosyanın URL'sine sahipse, dosyanızı doğrudan çeken birinin kavramıyla ilgili herhangi bir sorun yaşamadığınız sürece, o zaman bir dosya sistemi iyidir. İnsanlar dosyayı indirmeden önce şarj etmeyi beklediğiniz bir fotoğraf kütüphanesi gibi bir şey çalıştırıyorsanız, bu muhtemelen farklı bir konudur. Diğer bir deyişle, bir kullanıcı ödeme yaptıktan sonra, bu kullanıcıya özel veya kısa bir süre için geçerli olan bir URL alabilir ve uygulama aynı görüntüye işaret eden birden fazla veya geçici URL’yi işler. Bu hala uygulama ve bir dosya sistemi tarafından idare edilebiliyor, ancak düz bir dosya indirme yerine medyaya uygulama yoluyla hizmet veriyorsunuz (bu, çoğunlukla S3'ün yararlarını ekarte eder) ve DB ile dosya sistemi arasında daha az fark var .