Büyük dosyaları (10 MB) bir veritabanında saklamak kötü bir uygulama mıdır?

Şu anda kullanıcıların 1 MB - 10 MB boyutunda dosyaları depolamasını ve paylaşmasını sağlayan bir web uygulaması oluşturuyorum.

Bana öyle geliyor ki, dosyaları bir veritabanında saklamak veritabanı erişimini önemli ölçüde yavaşlatır.

Bu geçerli bir endişe mi? Dosyaları dosya sisteminde depolamak ve dosya adını ve yolunu veritabanına kaydetmek daha iyi olur mu? Veritabanında çalışırken dosya depolamakla ilgili en iyi yöntemler var mı?

Bu proje için PHP ve MySQL'de çalışıyorum, ancak çoğu ortam ( Ruby on Rails , PHP , .NET ) ve veritabanları (MySQL, PostgreSQL ) için de aynı sorun var .

Veritabanında dosya saklamanın lehine nedenler:

1. Dosyalar veritabanının dışında depolandığında karmaşık olan bir güncellemenin geri alınmasını içeren ACID tutarlılığı. Bu hafifçe parlatılmaz. Dosyaların ve veritabanların senkronize olması ve işlemlere katılabilmesi çok yararlı olabilir.
2. Dosyalar veritabanına girer ve bundan kurtarılamaz.
3. Yedeklemeler otomatik olarak dosya ikili dosyalarını içerir.

Veritabanında dosya depolanmasına karşı sebep:

1. Bir ikili dosyanın boyutu veritabanları arasında farklılık gösterir. SQL Server'da, FILESTREAM nesnesini kullanmadığınızda, örneğin, 2 GB'dir. Kullanıcıların dosyaları daha büyük saklaması gerekiyorsa (örneğin bir film gibi), sihrin gerçekleşmesi için çemberin içinden atlamanız gerekir.
2. Veritabanının boyutunu arttırır. Kalbe almanız gereken genel bir kavram: Veritabanını korumak için gereken bilgi düzeyi, veri tabanı boyutuyla orantılı olarak artar.Yani, büyük veritabanları küçük veritabanlarından ziyade bakımı daha karmaşıktır. Dosyaları veritabanında depolamak, veritabanını çok daha büyük hale getirebilir. Günlük bir tam yedeklemenin yeterli olacağını söylese bile, daha büyük bir veritabanı boyutuyla, bunu artık yapamayabilirsiniz. Dosyaları farklı bir dosya grubuna koymayı düşünmeniz gerekebilir (eğer veritabanı destekliyorsa), verilerin yedeğini dosyaların yedeğinden vs. ayırmak için yedekleri ince ayar yapın. Bunların hiçbiri öğrenmek imkansız değildir. bakıma maliyet getirmesi, işletmeye maliyet getirmesi demektir Daha büyük veritabanları ayrıca, belleğe mümkün olduğunca çok veri doldurmaya çalıştıkça daha fazla bellek tüketir.
3. Taşınabilirlik, SQL Server'ın FILESTREAMnesnesi gibi sisteme özgü özellikler kullanıyorsanız ve farklı bir veritabanı sistemine geçmeniz gerekiyorsa endişe verici olabilir .
4. Dosyaları veritabanına yazan kod bir sorun olabilir. Bir ay önce o kadar çok istişarede bulunmadığım bir şirket, bir noktada bir Microsoft Access önyüzünü kendi veritabanı sunucularına bağladı ve Ole Object kontrolünü kullanarak Access'i "herhangi bir şey" yükleme yeteneğini kullandı. Daha sonra Ole'ya bağlı farklı bir kontrol kullanmaya başladılar. Çok sonraları birisi ham ikiliyi saklamak için arayüzü değiştirdi. Bu Ole Object'in çıkarılması yeni bir cehennem seviyesi idi. Dosyaları dosya sisteminde sakladığınızda, kaynak dosyayı sarmak / ayarlamak / değiştirmek için ek bir katman yoktur.
5. Dosyaları bir web sitesine sunmak daha karmaşıktır. İkili sütunlarla yapmak için, dosyayı ikili dosyadan akışa aktarmak için bir işleyici yazmanız gerekir. Eğer dosya yollarını saklamak ama yoksa da hatta bunu yapabilirsiniz sahip bunu yapmak. Yine bir işleyici eklemek imkansız değildir, karmaşıklık ekler ve başka bir başarısızlık noktasıdır.
6. Bulut depolamasından yararlanamazsınız. Bir gün dosyalarınızı Amazon S3 kovasında saklamak istediğinizi varsayalım. Veritabanında sakladığınız şey dosya yolları ise, bunları S3'teki yollara değiştirme kabiliyetine sahip olursunuz. Bildiğim kadarıyla, herhangi bir DBMS ile herhangi bir senaryoda bu mümkün değildir.

IMO, dosyaların veritabanında depolandığını veya "kötü" olmadığını kabul ederek, koşullar ve gereksinimler hakkında daha fazla bilgi gerektirir. Boyut ve / veya dosya sayısı her zaman küçük mü olacak? Bulut depolamayı kullanmak için bir plan yok mu? Dosyalar bir web sitesinde mi yoksa Windows uygulaması gibi bir ikili dosyada mı yayınlanacak?

Genel olarak, benim deneyimim, ACID eksikliği ve yetimlerin varlığını hesaba katan yolların depolanmanın işletme için daha ucuz olduğunu buldu. Bununla birlikte, bu, İnternet'in dosya depolamada yanlış giden ACID kontrolü eksikliği öyküleriyle dolu olmadığı anlamına gelmez, ancak genel olarak çözümün oluşturulması, anlaşılması ve sürdürülmesi daha kolay olduğu anlamına gelir.

Çoğu durumda, bu kötü bir fikirdir. Veritabanı dosyalarını şişirir ve çeşitli performans sorunlarına neden olur. Eğer kalırsam blob'ları sütunların çok sayıda içeren bir tablo daha da kötü.

Ancak! SQL Server gibi bazı veritabanlarında FILESTREAM sütun tipi vardır. Bu durumda, verileriniz aslında veritabanı sunucusundaki ayrı bir dosyada saklanır ve sadece dosyaya ait bir ID tabloya kaydedilir. Bu durumda, verileri SQL sunucusunda tutmamak için bir neden görmüyorum. Dosyalar otomatik olarak sunucu yedeklemesinin bir parçası olarak dahil edilir ve veritabanı ile dosyalar hiçbir zaman senkronize edilmez. Tony'nin dosya adlarını saklama önerisiyle ilgili sorun, veritabanının ve dosya sisteminin senkronizasyondan çıkabilmesidir. Veritabanı, diskten silindiğinde bir dosyanın var olduğunu iddia edecektir. Bir işlem veritabanını değiştiriyorsa ve ardından çöküyorsa, dosyalar ve veritabanı eşleşmeyecektir (yani, veritabanının dışındaki dosyalarda ACID yok ).

Evet, kötü bir uygulamadır.

DB üzerindeki performans etkisi:

• Eğer bir yaparsanız SELECTherhangi BLOB sütun ile, olur hep BLOB'lar olmadan (yüksek kapasiteli DB RAM tablolar uyacak şekilde optimize edilecektir) düz RAM veri almak için bir şans varken, bir disk erişimi yapmak;
• çoğaltma yavaş olacak, çoğaltma gecikmesi yüksek olacak, çünkü BLOB'u kölelere itmek zorunda kalacak. Yüksek çoğaltma gecikmesi, açıkça hesaba katmadığınız sürece her türlü yarış koşuluna ve diğer senkronizasyon sorunlarına neden olacaktır;
• DB yedekleme / geri yükleme işlemi çok daha uzun sürecek;

Hız avantajı - yok ! Bazı eski dosya sistemleri milyonlarca dosya içeren dizinleri iyi işleyemezken, çoğu modernin hiçbir sorunu yoktur ve aslında BD'ler (genellikle B-ağaçları) ile aynı tür veri yapıları kullanırlar. Örneğin ext4 (varsayılan Linux dosya sistemi) Htree kullanır .

Sonuç: DB performansınızı engelleyecek ve dosya alma performansını geliştirmeyecektir.

Ayrıca, web uygulaması bahsediyoruz çünkü - yapabileceği modern bir web sunucusu kullanarak dosya sistemi doğrudan statik sunum dosyalarını sendfile()syscall olan muazzam performans iyileştirme. DB'den dosya alıyorsanız bu elbette mümkün değildir. Örneğin , Ngnix'in düşük uçlu bir dizüstü bilgisayarda 1000 eşzamanlı bağlantıyla 25.000 req / s yapıyor olduğunu gösteren bu kriteri değerlendirin . Bu tür bir yük her türlü DB'yi kızartır.

Bu konuda pragmatik davranacağım ve "henüz optimize etme" ilkesini izleyeceğim. Şu anda mantıklı olan ve uygun bir şekilde uygulamak için geliştirme kaynaklarına sahip olduğunuz çözümü yapın. Çok fazla potansiyel sorun var . Ancak bunlar mutlaka gerçek sorun haline gelmez. Örneğin, 100 kullanıcınız varsa, muhtemelen bir sorun olmaz. Bu olabilir 100.000 veya 10.000.000 kullanıcılar varsa bir sorun. Ancak son durumda, daha fazla kalkınma kaynağının tüm meselelerle başa çıkabilmesi için bir temel bulunmalıdır.

Ancak veriyi veritabanında saklamak sizi diğer problemlerle uğraşmaktan kurtarır, örneğin dosyalar nerede saklanmalı, nasıl yedeklenmeli, vb. Uygulamayı barındıran işlemin dosya sistemine yazma erişimi olmadığından emin olmak için sunucuyu, işlemin verilerin depolandığı klasöre okuma / yazma erişimine sahip olacak şekilde yapılandırmanız gerekir.

Verileri kişisel olarak veritabanında saklamayı seçerdim, ancak BLOBS'un gerçekten ihtiyaç duyulana kadar okunmadığından emin olun, yani blog içeren tablolarda yürütülen "SELECT * FROM ..." yok. Ve performans sorunları yaşarsanız tasarımın veriyi veri tabanından dosya sistemine taşımayı kolaylaştırdığından emin olurum. Örneğin, dosya bilgilerini ayrı bir Dosya tablosunda saklayın , böylece dosya bilgilerini diğer iş varlıklarından uzak tutun.

Veritabanında okunan bir dosyayı temsil etmek için bir File sınıfınız olduğunu varsayarsak , daha sonra onu taşımanın kodlama etkisi minimum olacaktır.

Microsoft bu konuda birkaç yıl önce beyaz bir bildiri yayınladı. SqlServer'a yoğunlaşıyor, ancak burada bazı ilginç bilgiler bulabilirsiniz:

BLOB'a mı yoksa BLOB'a mı? Veritabanında veya Dosya Sisteminde Büyük Nesne Depolaması?

Sonuçlarının çok özlü bir versiyonu:

NTFS dosya sistemini ve SQL Server 2005'i karşılaştırırken, 256KB'den küçük olan BLOBS, SQL Server tarafından daha verimli bir şekilde kullanılırken, NTFS, 1 MB'tan büyük BLOBS için daha verimlidir.

Özel kullanım durumunuz için küçük testler yazmanızı tavsiye ederim. Önbellekleme etkilerinden sakınmanız gerektiğini unutmayın. (Fiziksel olarak mümkün olandan daha yüksek kapasiteye sahip gibi görünen diske kaydetme hızlarını ilk aldığımda şaşırdım!)

Veritabanının dışında dosya saklamanın eski geleneksel bilgeliği artık geçerli olmayabilir. Prensip olarak, hız üzerinden bütünlüğü tercih ederim ve modern bir DBMS ile ikisine birden sahip olabilirsiniz.

Tom Kyte aynı fikirde görünüyor :

Veritabanının dışında uzun süre saklamak istediğim verileri depolamanın hiçbir avantajı olmadığını biliyorum.

Veritabanında ise yapabilirim.

profesyonelce yönetildiğinden emin olun

yedeklenmiş

geri kazanılabilir (verilerin kalanıyla birlikte)

emniyete

ölçeklenebilir (100.000 belgeyi tek bir dizine koymayı deneyin, şimdi bunları masaya koyun - hangisi 'ölçeklendirir' - dizin değil)

Kolayca geri silme (geri dönüş) yapabilirim

Kilitlemem

Tutarlılığı okudum ...

Evet.

Dosya sisteminizden bir dosya sunuyorsanız, Web sunucunuz dosyayı doğrudan sokete kopyalamak için BSD veya Linux'ta sendfile () gibi bir çekirdek kodu kullanabilir. Çok hızlı ve çok verimli.

Dosyaların veritabanından çıkarılması, veriyi veritabanı sunucusunun diskinden veritabanı sunucusu belleğine, ardından db sunucusunun belleğinden db sunucusunun ağ bağlantı noktasına, ardından ağdan Web sunucunuza, ardından tekrar dışarıya kopyalamanız gerektiği anlamına gelir. Giden ağ bağlantısı.

Yapmamak için gerçekten iyi bir nedeniniz yoksa, dosya sistemindeki statik dosyaları sunmak her zaman daha iyidir.

Ünlü Tom Kyte, (Oracle) 'ın Oracle veritabanını dosya sunucusu olarak kullandığını yazdı ve mükemmel bir şekilde çalışıyor, normal dosya sisteminden daha hızlı, tam işlemciliğe sahip, performans kaybı olmadan ve tek bir yedekleme ile çalışıyor.

Evet, ancak dikkat edin, bunlar Oracle DB'nin üreticisidir ve diğer kullanıcılar için maliyet sorunları vardır. Dosyaların depolanması için Oracle gibi ticari veri tabanlarının kullanılması sadece maliyet etkin değildir.

Bununla birlikte, örneğin PostgreSQL ile, yalnızca blob depolama için başka bir DB örneğini çalıştırabilirsiniz. Daha sonra tam işlem desteğine sahipsiniz. Ancak işlemlerin maliyeti DB alanıdır. Birden fazla eşzamanlı işlem için birden fazla blob örneği depolamak için veritabanına ihtiyaç vardır. PostgreSQL'de en acı verici olan bu veritabanıdır, çünkü VACUUM işlemi yapılıncaya dek bu veritabanında işlem yapmak için yapılan blob kopyaları artık gerekli olmasa bile saklanır.

Öte yandan, dosya sistemi depolaması sırasında, birisi dosyayı değiştirdiğinde çok dikkatli olmalısınız, çünkü işlem geri alınabiliyor ve eski sürüm artık görünmeyene kadar dosyanın kopyası saklanmalıdır.

Dosyaların yalnızca eklendiği ve silindiği ve dosyalara işlemsel erişimin bir sorun olmadığı sistemde, dosya sistemi depolaması IMHO en iyi seçenek olacaktır.

Büyük BLOB'ları ayrı bir tabloda saklamak ve ana tablonuzdaki BLOB'a bir yabancı anahtar referansı tutmak genellikle en iyisidir. Bu şekilde, dosyayı yine de veritabanından alabilirsiniz (böylece herhangi bir özel koda ihtiyacınız yoktur) ve harici DB bağımlılıklarını çevreleyen sorunlardan kaçınırsınız (DB ve dosya sistemini senkronize, vb. açıkça bu tabloya katılırsanız (veya ayrı bir arama yaparsanız). 10 MB çok büyük değil, çoğu modern ticari veritabanının bir sorunu olmayacak. Bir dosyayı dosya sisteminde saklamamın tek nedeni veritabanı bant genişliğini azaltmak. Veritabanınız bu dosyaların çoğunu karıştırıyorsa, iş yükünü bölmeniz ve yalnızca bir tür dosya tanımlayıcısı saklamanız gerekebilir. Sonra dosyayı başka bir sunucudan yüklemek için ayrı bir arama yapabilirsiniz.

Bu sorunlardan bazılarıyla karşılaşabilirsiniz:

• Doing bir SELECT *büyük blob ile satır içerir hangi (Tabii ki belirli bir seçme yapması gerektiğini, ancak bazen uygulamalar böyle yazılır) damla gerekmez bile, çok uzun sürer
• Yedekleme yapmak çok daha uzun sürebilir. İhtiyaçlarınıza bağlı olarak, tablolarınızı yedekleme süresi boyunca kilitlemeniz gerekebilir, bu nedenle yedekleme sürenizi düşük tutmak isteyebilirsiniz
• Restorasyon da daha fazla zaman alacaktır.
• Alanınız tükenirse, bu sorunu çözmek için bir yol (belki de tüm veritabanını yeni bir sunucuya taşıma) düşünmeniz gerekir. Dosyaları dosya sisteminde saklamak için her zaman başka bir sabit sürücü takabilir ve yumuşak bağlantılar ayarlayabilirsiniz.
• Sadece hata ayıklama veya diğer bilgileri almak için bir dosyaya bakmak o kadar kolay değildir. Bu aynı zamanda veritabanına erişimi olmayan ancak çeşitli dosyalardan bazı bilgilere ihtiyaç duyan komut dosyalarını da içerir.

Elbette bazı avantajlar da elde edersiniz:

• Veri ve dosya menülerini senkronize ediyorlar
• Dosyayı veritabanını bilmeden kaldırmak mümkün değildir
• Dosyayı diskten okumak zorunda değilsiniz, ancak bir sql deyiminde yapabilirsiniz
• Veritabanını indirebilir, dökümü geliştirme ortamınıza dahil edebilir ve tüm bağımlılıklara sahip olabilirsiniz.

Şahsen, eksileri artılardan daha ağır bulduğum için yapmıyorum. Ancak yukarıda belirtildiği gibi tamamen kullanım durumunuza ve benzeri şeylere bağlıdır.

SiteCore gibi bazı Enterpirse İçerik Yönetim Sistemleri, sayfa verilerini depolamak için bir veritabanı ve dosyaları depolamak için başka bir veritabanı kullanıyor. MS SQL Server kullanıyorlar.

Pratik uygulama için, ilginizi çekebilecek şeyler:

Faydaları:

1. Tüm dosya içerikleri kesinlikle tablonuzla senkronize edilir. Yukarıdaki açıklamaların söylediği gibi, verileri yedeklemek, dosya sistemi ile senkronize tutmanız gerekmediğinden tamamen kullanışlıdır.
2. Kodlamadan, bir SQL seçmesinden doğrudan dosya içeriğini alabilirsiniz.
3. Bir sorgudan, dosya içeriğini veya boyutunu açıkça SQL ifadesinden bile filtreleyebilirsiniz.

Downsides:

1. Yapısının anlamsal olarak aynı olduğu ancak dosya içeriğini saklamadığı bir veritabanına kıyasla, veritabanınız sorgulama yaparken çok daha fazla bellek tüketme eğilimindedir.
2. Otomatik yedekleme, performans sorununa neden olabilir ama fazla olmayabilir. Veritabanı sunucunuzun 6 saatte bir şeyler yedeklediğini ve sahip olduğunuz veritabanlarının kayıt başına 10 MB'lık bir dosya depoladığını düşünelim. Bu senaryo istediğin gibi değil.