Veritabanınızdaki verilerle ilgili ikili dosyaları saklamak için en iyi yer neresidir? Sen-meli:

1. Bir blob ile veritabanında saklayın
2. Veritabanında bir bağlantı bulunan dosya sisteminde saklayın
3. Dosya sisteminde depolayın ancak içeriğin karma değerini değiştirin ve karma veritabanını depolayın.
4. Düşünmediğim bir şey

(1) 'in avantajları (diğerleri arasında) işlemlerin atomitesinin korunmuş olmasıdır. Maliyet, depolama (ve ilişkili akış / yedekleme) gereksinimlerini önemli ölçüde artırabilmenizdir

(3) 'ün amacı, atomiteyi bir dereceye kadar korumaktır - yazdığınız dosya sisteminin dosyaların değiştirilmesine veya silinmesine izin vermediğini ve dosya adı olarak her zaman doğru hassa sahip olduğunu zorlayabilirseniz. Buradaki düşünce, hash ile ilgili ekleme / güncelleme işlemine izin vermeden önce dosyayı dosya sistemine yazmak olacaktır - eğer bu işlem dosya sistemi yazdıktan sonra ancak DML veri tabanından önce başarısız olursa, bu iyi bir işlemdir, çünkü dosya sistemi tümünün deposudur. Olası dosyalar ve kareler - içinde işaret edilmeyen bazı dosyalar olup olmadığının bir önemi yoktur (ve dikkatli olursanız bunları periyodik olarak temizleyebilirsiniz)

DÜZENLE:

Bazı RDBMS'lerin bunu bireysel yollarıyla ele almış gibi görünüyorlar - başkalarının nasıl yaptığını bilmek isterim - ve özellikle postgresler için bir çözümde

1. Bir blob ile veritabanında saklayın

   Dezavantajı, veritabanı dosyalarınızı mevcut kurulumunuzla yedeklemek için oldukça büyük ve muhtemelen çok büyük hale getirmesidir. Bir avantaj, bütünlük ve atomikliktir.

2. Veritabanında bir bağlantı bulunan dosya sisteminde saklayın

   Bunu yaparken bu korkunç felaketlerle karşılaştım ve insanların bunu önermeye devam etmeleri beni korkutuyor. Felaketlerden bazıları:

   • Dosyaları yeniden düzenleyen ve DB içindeki yollar arasındaki bağlantıları sık sık kesen ve şimdi oldukları yerlerden ayrılan ayrıcalıklı bir kullanıcı (ancak bir şekilde bu benim hatam oldu).
   • Bir sunucudan diğerine taşınırken, bazı makinelerin mülkiyeti, eski makinenin yönetici hesabının (eski web sitesinin üzerinde çalıştığı) SID olarak etki alanının bir parçası değildi ve bu nedenle kopyalanan dosyalar ACL'lere sahipti. çözülememelidir, böylece kullanıcılara kullanıcı adı / şifre / etki alanı giriş istemi sunulur.
   • Yolların bazıları den 256 karakterden uzun olmak sevdirmek C:\tüm yol .docve NT tüm sürümleri uzun yolları ile başa çıkmak mümkün değildir.

3. Dosya sisteminde depolayın ancak içeriğin karma değerini değiştirin ve karma veritabanını depolayın.

   En son çalıştığım yer, yukarıdaki senaryolar hakkındaki açıklamama dayanarak bunu yaptı. Kuruluşun büyük veritabanlarıyla (40G'den büyük herhangi bir şeyin "çok büyük" olması için düzenlenmiş olduğu) deneyim kazanamamaları, büyük sabit diskler satın almamaları ve daha modern bir geri alma satın almamaları arasında bir uzlaşma olduğunu düşündüler. yukarı çözüm ve yukarıda belirttiğim # 1 ve 3 numaralı risklerden uzak durma ihtiyacı.

Bence DB'yi bir blob olarak saklamak, özellikle de yerine çalışma ve kullanılabilirlik endişeleriyle birlikte, çok sunuculu bir senaryoda daha iyi bir çözüm ve daha ölçeklenebilirdir.

Tam veri bütünlüğü için 1 numara. Veri kalitesini önemsemiyorsanız diğer seçenekleri kullanın. Bu kadar basit.

Çoğu RDBMS, BLOB'ları (örneğin, SQL Server filestream) depolamak için optimizasyonlara sahiptir.

Oracle için gidiyoruz, dbfs ve Secure Files'a bakın.

Secure Files her şeyi söylüyor, TÜM verilerinizi veritabanında güvende tutun. Loblarda düzenlenir. Güvenli Dosyalar, etkinleştirilmesi gereken lobların modernleştirilmiş bir sürümüdür.

dbfs, veritabanındaki bir dosya sistemidir. Bir Linux ana bilgisayarındaki ağ dosya sistemine benzer şekilde monte edebilirsiniz. Bu gerçekten güçlü. Blogu görün Ayrıca, gereksinimlerinize göre ayarlayabileceğiniz birçok seçenek vardır. Bir dba olarak, bir dosya sistemi göz önüne alındığında (veritabanına dayanarak, Linux üzerine kurulmuş), üzerinde herhangi bir sorun olmadan Oracle Veritabanı oluşturdum. (bir ... veritabanında saklanan bir veritabanı). Bunun çok faydalı olacağını değil, gücünü gösterdiğini söylüyor.

Diğer avantajlar: kullanılabilirlik, yedekleme, kurtarma, tümü diğer ilişkisel verilerle tutarlı olarak okunur.

Bazen boyut, belgeleri veritabanında saklamama nedeni olarak verilir. Bu veri muhtemelen herhangi bir şekilde yedeklenmelidir, bu yüzden veritabanında saklamamak için iyi bir sebep değildir. Özellikle eski belgelerin salt okunur olarak kabul edileceği bir durumda, veritabanının büyük bölümlerinin sadece okunması kolaydır. Bu durumda, veritabanının bu kısımları artık yüksek sıklıkta bir yedeklemeye ihtiyaç duymamaktadır.

Bir tabloda, veritabanının dışındaki bir şeye yapılan bir referans güvenli değildir. Kullanılabilir, kontrol edilmesi zor ve kolayca kaybolabilir. İşlemlere ne dersiniz? Veritabanı tüm bu sorunlar için çözümler sunar. Oracle DBFS ile dokümanlarınızı veritabanı dışı uygulamalara verebilirsiniz, hatta bir veritabanında düştüklerini bile bilmiyorlar.

Son, büyük bir sürpriz, bir dbfs dosya sisteminin performansı genellikle normal bir dosya sisteminden daha iyidir. Bu, özellikle dosyalar birkaç bloktan büyükse geçerlidir.

Bence buradaki doğru cevap başvurunuza ve bu belgelerin ne kadar önemli olduğuna bağlıdır.

Bir doküman yönetim sistemi veya saklanan dokümanların kurtarılabilirliğinin kritik olduğu bir sistem için (yani finansal, insan kaynakları veya CRM ile ilgili birçok şey), dokümanları satır içi olarak saklamak veya favori DB satıcınızın tescilli doküman teknolojisini kullanmak, Doğru Şey gibi görünüyor.

Ancak, ters kararın uygun olduğuna inandığım birçok uygulama var.

Yardım Masası sistemleri ve wiki tipi sistemler Ben veriyi tutmak için mantıklı bir çok yapar düşünüyorum olanlardır dışarı veritabanının. Bazılarının, Jira gibi, aslında belgeleri satır içi depolamak isteyip istemediğinizi seçme seçeneği sunduğuna inanıyorum.

Orta ölçekli bir işletme için, bir biletleme sistemi satır içi için belgeleri saklamak, megabayt olarak ölçülen ve gigabayt olarak ölçülen sıkıştırılmış bir yedekleme arasındaki fark anlamına gelebilir.

Kişisel olarak bir bilet sistemini birkaç dakika içinde tekrar çevrimiçi hale getirmeyi ve (genellikle daha az önemli olan) belgelerle birkaç saatliğine güreşmeyi tercih ederim, "kırılmış ve CTO boynumu aşağı çekiyor" RTO'yu geri yüklemek zorunda kalmadan ve günlükleri çok daha büyük bir yedekten tekrar oynatır.

Belgeleri ayrı tutmanın başka yararları da vardır.

• Belge meta verilerini kataloglayan, virüs taraması gerçekleştiren, anahtar kelime endekslemesi gerçekleştiren vb. İşlemleri kolayca gerçekleştirebilirsiniz.
• Dosyalara veritabanlarından daha iyi kendilerini ödünç veren yedekleme veya kurtarma işlemlerine (rsync, depolama anlık görüntüleri vb.) Yardımcı olacak araçlardan yararlanabilirsiniz.
• Sıkıştırma veya veri tekilleştirme özelliğini destekleyen bir depolama alanı kullanabilirsiniz (SAN yöneticilerinizin yıllardır yağmaladığı şeyler, yani dünya çapında veritabanı yöneticilerinin ağları)
• Birden fazla siteye kurulum yapmak için, merkezi bir veritabanını dağıtılmış bir dosya sistemi ile tamamlayabilirsiniz

# 2 ve # 3'ün karma bir kombinasyonunun akıllıca olabileceğini düşünüyorum. Orijinal dosya adlarını saklayın, ancak belgenin karma / sağlama toplamını hesaplayın ve saklayın; böylece birisinin dosyayı taşıması veya yeniden adlandırması durumunda kurtarmaya yardımcı olacak bazı referans noktalarınız olur.

Dosyaları orijinal dosya adlarıyla saklamak, uygulamaların kelimenin tam anlamıyla onları doğrudan bir dosya sisteminden alıp tel üzerinden veya kalın bir istemci dünyasında gönderebileceği, hatta kullanıcıyı doğrudan dosya sunucusuna yönlendirebileceği anlamına gelir.

Yapma

Veritabanında saklanan dosyaların olması için ters bir şey yoktur.

Kendinizi düşündüğünüzde zaten garip ve balık hissetmiyor mu:

Dosyaları bir veritabanında mı yoksa bir dosya sisteminde mi saklamalıyım ?

Daha da iyisi, yüksek sesle söyle.

Gerçeklere göre:

Veritabanını kullanmak

" PROS " ... ama tam olarak değil :

• "Atomicity" doğru olan ancak iki ucu keskin bir kılıç. Çünkü eksilerini bununla birlikte sürüklüyor.
• Bütünlük. Yukarıdaki ile aynı.

Gerçekten önyargılı olmak istemem ama ekleyecek daha fazla şey olduğunu sanmıyorum. Bunu düşünürseniz, profesyoneller o kadar da iyi değil.

Aşağıdaki bir şeyi unuttum, bu arada aşağıda okumaya devam edin.

EKSİLERİ:

• İş için yanlış araç
• Bakımı zor
• Yavaş
• Verilerin MB / gigabayt yüzlerce depolamak unutun kullanıcı BAŞINA .
• Hızla büyüyen bölgelerin yedeklenmesi bir kabus olacaktır.
• Geri yükleme / taşıma da emmek olacaktır.

Dosya sistemini kullanma

Artıları:

• Bakımı daha kolay
• Hızlı
• Veritabanı yedeklemelerinin bununla ilgisi yok
• Muhtemelen daha fazla taşınabilirlik *

CONS :

• Yok*

*İnce baskı

Şu anda kendine soruyorsun, bekle, demek istediğin bir şey yok mu ?! Nasıl olur?

Buradaki en büyük hata, insanların bir vidayı çekiçle vidalamaya çalıştıklarıdır.

Asıl sebep ve bunun sorulmasının tek sebebini söylemek kadar ileri gidebilirim çünkü dosya bağlantıları .

Bu, veritabanının çözmesi amaçlanmayan bir problemdir. Düşünürseniz bile saçma geliyor.

"Veritabanımı dosya bağlama sorunlarımı çözecektir."

Gerçekte, mantıksal olarak , uygulama aslında bağlantıların kullanımından ve sunulmasından sorumlu olmalıdır .

Bir çözüm:

1. Uygulamanızın URL isteklerini özel yollarla ele almasını sağlayın.
2. Bu rotayı veritabanınıza kaydedin.
3. Dahili olarak bu rota her çağrıldığında istediğiniz dosyaya eşlenir.
4. Dosyalarınızı başka bir yere taşırsanız, rotanın dosya adı değerini değiştirirseniz, o rota web'de nerede saklanır veya referans verilirse kullanılsın, her zaman aynı dosyayı sunar.

Bu aynı zamanda yerel yolları soyutlar, uygulamayı daha taşınabilir hale getirir, bakımını yapar ve hiçbir şeyi bozmadan herhangi bir dosya sistemine geçmeye izin verir.

Nasıl uygulanacağına gelince, bu cevabın kapsamı dışındadır ancak tartışmalı olarak en yaygın kullanılan web dilinde (PHP) genel bir örneğe bakabilirsiniz:

https://github.com/symfony/Routing

https://github.com/kriswallsmith/assetic

Bunların ikisi birlikte gerçekten güçlü.

Tecrübelerimi buraya takas olarak eklemek istiyorum. PostgreSQL'de en azından performans etkileri db sunucusu açısından oldukça düşüktür. Büyük blob'lar ana yığın tablolarda değil ayrı dosyalarda saklanır, böylece çok sayıda kayıt sayan işlemlerin dışına çıkarılır. Diğer dbs benzer bir şey yapabilir.

En büyük avantaj, tüm ilgili verileri atomiklik ve yedekleme amacıyla tek bir yerde saklamaktır. Bu, bir şeylerin yanlış gitme ihtimalini büyük ölçüde azaltır.

En büyük dezavantaj yukarıda anlattığım bir şey değil ve bu ön uçtaki bellek kullanımı. Her db'nin bunu nasıl işlediğini tam olarak bilmiyorum, bu nedenle bu uygulamaya bağlı olabilir, ancak PostgreSQL için, veriler bir çıkış ASCII dizesi olarak gelir (muhtemelen onaltılık, muhtemelen satır içi çıkışlarla). Bu daha sonra ön uçtaki ikiliye geri dönüştürülmelidir. Bunu yaparken gördüğüm birçok çerçeve, değeri (referans olarak değil) iletmeyi ve daha sonra buna dayalı yeni bir ikili dize oluşturmayı içerir. Bunu yapmak için Perl kullanmanın, başarmak için orijinal ikili belleğin birçok kez kullanılmasıyla sonuçlandığını hesapladım.

Karar: Dosyalara yalnızca zaman zaman erişiliyorsa, db'de depolardım. Sık sık ve tekrar tekrar erişiliyorsa, en azından PostgreSQL ile, maliyetlerin faydaları etkilediğini düşünüyorum.

Microsoft, gün içinde görüntüleri (ve benzer blob veri türlerini) veritabanında saklama yeteneğini artırdı. SQL Server 2000'in yeni ve harika bir özelliği oldu (Eminim 2000 idi, 7.0 değil) ve birçok kişi çoğunluğa sıçradı.

BLOBS'u veritabanında saklamanın avantajları ve dezavantajları vardır:

Bir yandan, tüm verileriniz ve ilgili resimleriniz veya belgeleriniz tek bir yerde saklanabilir ve erişilebilir. Uygulama kullanıcısı, özel ağ izinleri gerektirmez, çünkü görüntüleri / dosyaları / belgeleri sunan SQL'dir.

Öte yandan, sakladığınız BLOBS'ın boyutuna ve sayısına bağlı olarak veritabanınız oldukça büyüyebilir. Bu, yedeklemeleri, depolama gereksinimlerini, zamana duyarlı kurtarma işlemlerini vb. Etkiler.

SQL Server 2008, dosya akışı başlattı. Veritabanı, dosyalara işaretçiler içerir, dosyalar veritabanında değil, sunucuda bulunur, ancak veritabanını yedeklediğinizde dosyalar da yedeklenir.

Yedekleriniz oldukça büyüyebilir, ancak artık dosyalar / belgeler / bloblar / görüntüler ile bitmezsiniz.

Kişisel tercihim, veritabanının işaretçileri / ağ konumlarını depolamasına ve bir dosya sunucusunun dosyaları yönetmesine izin vermekti. Dosya sunucuları zaten bu tür görevler için daha iyi optimize edilmiştir.

Dosyaları bir veritabanında saklamayın.

İstisnasız, piyasadaki herhangi bir RDBMS'yi çalıştırabilen herkes, dosyaları depolamak için özel bir veritabanına sahiptir ve RDBMS'nin kendisi bunu kullanıyor! Bu veritabanı dosya sistemi . Şimdi, veritabanında dosya saklamanın olası sakıncalarından ve ayrıca dosyaları veritabanında saklamak için bazı azaltıcı faktörlerden bahsedelim.

• Veritabanındaki dosyalara hiçbir dosya bağlantısı yok . Ne anlama geliyor?

  • Programcı-talk: Sen CAN NOT (aramaya fseek), asenkron erişimi (ile kaynak yönetmek için hiçbir yeteneği yoktur asyncioya epoll), hiçbir orada sendfile(size çekirdek alanından kopya tasarruf).

  • Pratik uygulama: Bir müşteriye HTTP2 / 3 üzerinden bir video veya resim göndermek ister misiniz? Veritabanındaysa, önce sorgulamanız gerekir. Bu dosyayı hangi sorgu döndürürse döndürsün, o dosyanın bir sonraki adıma geçmeden önce tüm sorgunun sonuçlanmasını beklemeniz gerekir . Web sunucusundan farklı bir sunucuda bir rdbms içeren bir üretim kurulumunda, ilk önce dosyayı akıtmak yerine tamamen rdbms'den web sunucusuna aktarmanız gerekir. Bununla birlikte, taşıma katmanı dosya sistemi soyutlamasını sağladıysa (NFS'nin bile desteklediği) dosya üzerinde yarı yolda arama yapabilir ve dosyayı gerekenden daha fazla arabellek oluşturmadan hemen müşteriye geri göndermeye başlayabilirsiniz. Bu rutin olarak web sunucusu tarafından yapılır.nginx , Apache , PureFTP ve ProFTP.

• RDBMS'ye çift kopya. Veritabanında olduğu gerçeğine göre, muhtemelen iki kere yazmış olacaksınız. Önceden bir yazma günlüğüne (WAL) ve sonra tekrar tablo alanına.

• Güncelleme yok, hiç MVCC hiçbir şeyin güncellenmediği anlamına gelir, yalnızca değişikliklerle yeniden kopyalanır ve eski satır süresi dolmuş (silinir) olarak işaretlenir. Dosyada yapılacak herhangi bir güncelleme , sadece satırın tamamını değil tüm satırın yazılmasını gerektirir . Dosya sistemleri de veri günlük kaydı sağlayabilir, ancak buna nadiren ihtiyaç duyarsınız.

• Sorguyu yavaşlatmak için dosya okuma ve aktarma Dosyanın kendisi sorgulamanız gereken bir satırda saklanırsa, tüm satırın aktarılması için dosyayı beklemesi gerekir veya iki ayrı sorgu göndermeniz gerekir .

• DB istemcisinde bellek kullanımı . DB istemcisi (libpq, jdbc, odbc, freetds, vb.) Veya benzerleri büyük olasılıkla sorguyu bellekte tamponlayacaktır. Bu bellek içi arabellek tükendiğinde, bir disk arabelleği başlatabilir veya daha da kötüsü diske disklenmek üzere çekirdeğe geri dönebilir.

• Sorgu azaltıcı birçok veritabanı, zamana veya kaynaklara çok fazla ihtiyaç duyduğunda sorguları öldürme ve toplama becerisi sağlar. Unutmayın ki dosya transferleri hiçbir uygulamada ayrıntılı olarak sıralanmayacaktır. Bu sorgu 3 saniye sonra öldürüldü mü? Yoksa 1 saniye mi sürdü ve arka uç 2 saniye mi dosya aktardı? Sadece "maddeleştirilmiş" değil, sorguların% 99.9'u 1 KB, diğeri 1 GB döndüğünde bir sorgunun ne kadar zaman alacağını etkili bir şekilde nasıl belirteceksiniz?

• Yazma üzerine yazma ya da veri tekilleştirmeyi kaldırma XFS ve BTRFS, yazma-kopyalama ve çoğaltma işlemlerini şeffaf bir şekilde destekler. Bu, aynı resmin her yerde olması veya ikinci bir kopyasına ihtiyaç duyulması, dosya sistemi tarafından şeffaf bir şekilde ele alınabileceği anlamına gelir . Bununla birlikte, eğer dosya kendi başına durmuyorsa ve bir satırda veya bir mağazada ise, dosya sistemi muhtemelen veri tekilleştiremez.

• Bütünlük Birçok insan burada bütünlük hakkında konuşuyor. Dosya sistemi bozulmasını, dosya sistemini kullanan bir uygulamayı veya dosya sisteminin çekirdek yardımcı programlarını tespit etmede daha iyi olduğunu düşünüyorsunuz? Bir dosyayı üst üste ya da sıra dışı olarak depolayın; herhangi bir dosya sisteminin bozulması veritabanında gizlenir. xfs_repairdosya sistemi veya sabit disk bozulması olduğunda kurtarma işleminde son derece iyidir ve başarısız olursa, veri adli tıp yapmak hala çok daha kolay olacaktır.

• Dosyaları bir SAN'da veya bulutta depolamak istiyorsanız bulut geçişi daha da zorlaşacaktır çünkü artık depolama geçişi bir veritabanı geçişidir. Örneğin, dosyalarınız dosya sisteminde saklanıyorsa, bunları kolayca S3'e taşıyabilirsiniz (ve s3fsbunun gibi bir şey saydam olabilir).

İstisnalar

Dosyaların veritabanında saklanmasının birkaç geçerli kullanım durumu vardır,

• Ne zaman ihtiyaç geçişli dosyasını düzenlemek. Bu, kelimenin tam anlamıyla dosyayı düzenlemek için işleminizin bir parçası olduğu anlamına gelir. Veya işlem ilişkilerde veri bütünlüğü sorunları için başarısız olursa, dosyadaki düzenlemeleri geri alma yeteneğine ihtiyacınız vardır (tablolar).
• Dosya sisteminin tam olarak verilerle sürümlendirildiğinden ve gerektiğinde senkronize olma riskini alamadığınızdan emin olmanız gerektiğinde .
• Siz veritabanı ne zaman aslında dosyayı ayrıştırmak ve sorgulayabilirsiniz. Örneğin PostgreSQL'de topolojiler PostGIS ile sorgu olabilir. Bu noktada, bir dosya olsa da, bu bir depolama dökümü değil, sorgu için veridir.

azaltıcı etkenler

• Bazı veritabanlarında, veritabanının dosyayı diskte olduğu gibi özel olarak yönettiği "harici olarak yönetilen kaynak" kavramı vardır.

  • Büyük Nesne altyapısı yoluyla PostgreSQL , işlemin süresi boyunca bir kaynağa dosya aktarımı sağlar.

  • SQL Server 2017'nin filestream altyapısı , Dosya Yolu'nu almak ve bir Dosya Kolu açmak için kullanabileceğiniz işlemin süresi boyunca geçici bir erişim sağlar.

  • Oracle BFILEşunları sağlar (bunun, dahili LOB öğeleriyle bir ilgisi yoktur).SecureFile

• Veritabanlarından bazıları, büyük ikili nesneleri hat dışında tutar veya Oracle SecureFile gibi saklayabilir. Bu, dosyayı yeniden yazmadan satırı güncellemenizi sağlar.

• Oracle gibi bazı veritabanları, MVC'lerini WAL günlüğü olmadan yapar ve dosyayı iki kez yazmak zorunda kalmazlar.

• SQL Server ve Oracle gibi bazı veritabanları, üzerinde herhangi bir dosya tanıtıcısı olmadan, dosyadan "akış" yapma yeteneği sağlar. Bu, databaes sorgudan farklı bir bağlantıda çalışabilir veya çalışmayabilir. Ama burada tuşu ise olmasıdır olabilir (teoride) dosya akışı, o özelliğini kullanır sağlayıcı tarafından yapılan herhangi bir ürünün herhangi bir kanıt bulamıyorum. Örneğin, bunu yapmanıza izin veren NGINX / Apache köprüsü nerede?

• Oracle, Dahili LOB depolama (SecureFile gibi) aracılığıyla isteğe bağlı veri tekilleştirme, sıkıştırma ve şifreleme sağlar.

Sonuç

Veritabanına bir dosya koyduğunuz en kötü senaryo, performans ve takımlarla uyumluluk açısından çok kötü . Her zaman istisnai olarak uygulamaya bağlıdır. Hiç bir şekilde veritabanı bir dosya sistemi olmaktan daha iyi olamaz, ardından dosya sistemi. Her şekilde, bu bir uzlaşma ve güçlü hafifletici özellikler elde etseniz bile (SecureFile gibi), takımlar o kadar düşüktür ki, tüm desteniz RDBMS sağlayıcısı tarafından oluşturulmadığı sürece bir pazarlama noktasından çok daha fazlası değildir.

Basit tutun ve genel kural, dosyaları DB dışında tutmaktır .

Çözüm

Birden fazla kiracı ve kullanıcı için etkili bir şekilde çalışması için dosyaları nasıl saklamalısınız veya böyle bir biçimde bir dosya sistemi oluşturmalısınız? Dosya içeriğini özetlemek için kısmi olarak. Bu bugünlerde oldukça yaygındır ve iyi çalışır.

Kısmen uygulamaya / ortama (insanlar dahil) bağlı olmasına rağmen, blob için giderdim.

Her şeyi veritabanında tutmak, çoğaltmanın dosya verileri için işe yaradığı anlamına gelir. FS dosyalarını senkronize etmek için ayrı bir mekanizmaya ihtiyacınız olacak.

Bazı uygulamalarda, dosya sistemi yine de değiştirilmemelidir. Örneğin, bir üretim web sitesinde, tek kullanımlık olmayan veriler için dosya sistemini kullanmaktan kaçınıyorum (site bir SCM altında yaşıyor, bir veritabanındaki veriler).

Ayrı izinlere sahip birden fazla kullanıcı / uygulama bulunduğunu varsayarak, herhangi bir dosya sistemi depolaması DB ve FS erişim haklarındaki farklılıklar için bir fırsat sunar.

BLOB deposunda yapmayı düşündüğüm ayrıntılandırma, mantıklı olması durumunda veriyi yığınlamaktır; 20Mb'lik bir BLOB'dan yalnızca 512 bayta ihtiyacınız varsa, bu sektör benzeri erişim gerçek bir nimettir, özellikle uzaktaki müşterilerle (ve yine kısmi bir güncelleme çok daha az çoğaltma trafiği yaratırsa).

Benim oyum da hiçbiri için olmazdı. Verileri Amazon S3 veya Microsft CDN gibi bir sistemde saklayın ve bu URL'yi veritabanında saklayın.

Bu şekilde, ele alınacak canavar boyutlu veritabanları olmadan verilerin her zaman erişilebilir olmasını sağlama güvenilirliğini elde edersiniz.

Postgres için:

Aslında düz bir ön ödül. BYTEAİkili dizeleri saklamak için kullanılabilecek bir tür vardır. Varsayılan olarak, MS veya Oracle için belirtilenler gibi bir kullanım alanı yoktur. Böylece birçok büyük dosyayı depolamak ve onları almak sıkıcı olabilir. Ayrıca uygulama içindeki dosyaların dönüştürülmesini de yapmanız gerekir (bunun gibi ByteStreamveya benzer bir şekilde, bunun belirli bir MS / Oracle dosyası <-> veritabanı çözümleriyle nasıl çalıştığı hakkında hiçbir fikriniz yok). Ayrıca, loBLOB'ları yönetme çalışmalarına yardımcı olan bir tür de vardır, çünkü bu türlerin iç yönetiminin bazıları referansları takip edemeyebilir.

Ms SQL server deneyimimi ve çok sayıda dosyayı paylaşın. Dosyaları bir dosya sunucusuna kaydediyoruz. Veritabanında, biri dosya klasörleri ve erişim bilgileri için, diğeri dosya adı için iki tablo vardır. Veritabanını ve dosyaları korumak kolaydır. Dosyaları bile sunucular arasında kolayca taşıyabilirsiniz, sadece klasörler tablosunu değiştirmeniz gerekir.