Forum
Aktif konular
Üyeler
Kurallar
Arama
Resim Saklama [Beyin Fırtınası] Resim Saklama [Beyin Fırtınası]
-
1 - Tutacak yerin zaten db olamaz
2 - Klasörde tutacaksın ama direk atmayacaksın
3 - Resimlere sıkıştırma algoritmaları uygula sonra koy klasörüne
4 - relational bir db ye ihtiyacın yok, sadece resim saklayacaksan, nosql yapı kullanabilirsin
-
@iQsuz, hocam acayip ilginc bir fikir teoride :) bu bahsettigin filtre islemlerini yaptim eskiden, mesela yuksek gecirgenlik olanini bir projede kullandik ama bu filtreler orjinalini bozuyor :) sonucta crop islemi yapiyorsun ve gecmeyeni siliyorsun.. O yuzden orjinaline dondurelemez.
@ozgunlu, hocam zaten bildigim seyleri soylemissin konuda da yazdim bunlari... relational db ye gelince onun sebebi resim ile ilgili degil ki benim farkli yapilarda iliskisel tablolarim var ve bunlar arasinda joinli sorguyu cok yapmam gerekiyor bu sebeple nosql kullanmak mantikli degil..
-
@unbalanced
Herkes söylemiş sen de farkındasın zaten, resmi veritabanında saklamak gibi bir işe girişme, yedek alması bile başlı başına iş olur çıkar.
Bir de data dosyalarındaki büyük parçalanmalardan dolayı bir DBA gerekir arkasını toparlamak için, gerek yok.
3. parti bir cdn çözümü (hali hazırda aws kullanıyorsun s3 güzeldir bu konuda) istemediğini de görüyorum, dropbox vs.. de öyle hakeza.
O zaman sana kalan, resimlerini diskte saklayıp üstbilgilerini (metadata?) de veritabanında saklamak, SQL Server veya başka bir RDBMS.
Uygulama bir web uygulaması olacağına göre, istemcilerin de ağırlıklı olarak tarayıcılar olacak. Burada devreye giren aslında hızlı bir web deneyimini yaşamamızı sağlayan önbellekleme standartları, bunları unutmamak lazım. Kısacası sanal yol üzerinden istekleri ele alırken olabildiğine "http" standartlarını gözetmen şart.
Bir resim dosyasının istemci tarafında önbelleklenmesi ile ilgili yanıt başlıklarından sonuna kadar yararlan. Cache-Control, Expires, Last-Modified, Etag vs..
Resim üst bilgilerini saklayacağın tablonda ise yeni bir resim kaydında, resmin yolu dışında zaten yanıt başlıklarına da ekleyeceğin Last-Modified, ETag, Cache-Control başlıkları için sütunlar yer alsın.
Resmin güncellenmesi halinde Last-Modified ve Etag yeni verilerle güncellensin. Etag'ler genelde kısa hash'ler olurlar.
Bu implementasyon, sanal yolda istekleri karşılarken istek başlıklarında If-Modified-Since (dosyada şu tarihten sonra değişiklik olmadıysa dosyayı gönder), If-None-Match (Etag artık bu değilse dosyayı gönder) gibi başlıkları işleyip, Etag (If-None-Match değeri) veya dosya değiştirilme tarihi(If-Modified-Since değeri) değişmediyse dosya gövdesini tekrar istemciye göndermek yerine boş ancak durum kodu "304 Not Modified" olan bir yanıt vermek gibi temel gereksinimleri içersin.
Tüm bunlar statik dosyaların istemci tarafındaki önbelleklemesinden sunucu tarafını haberdar edip, eğer gerek yoksa ek her türlü masrafı engellemek için.
Eğer dosyayı statik olarak doğrudan web sunucu üzerinden sunuyor olsaydın her modern web sunucusu gibi bu temel standartları hali hazırda gözetiyor olurdu, ama bunları sen yapacaksın.
Resimleri dosya sisteminde hangi yapıda saklayacağın meselesine gelince, bu başlı başına ilim aslında :D
Ama ben çok abartmayıp, resmin binary'sinden üretilmiş (veya rastgele?) SHA1 özetini alıp, adını bununla belirlerim, örneğin: d7c4c05d9e752dbda0b2ea6455976649082ed247.jpg
En kral dosya sistemi dahi bir dizin içinde belli bir dosya sayısından sonra insan eliyle buna erişmek istediğinde bir yerden sonra sapıtmaya başlayacağından (dosya yöneticileri zaten patates olacak da) sorun çıkmaması için aşağıdaki hash'deki 16 lıkların her birinden oluşan ardışık dizinlerde kendi adıyla saklarım. Bir nevi luhn'umsu (değil tabi :D), bir şekilde dosya adından hangi dizin hiyerarşisinde saklandığının belli olduğu bir yapı. Bu tür bir saklamaya gerçekten aşırı dosya yüklenen bir uygulamada ihtiyaç duyabilirsin.
kök_dizin/d7/c4/c0/5d/9e/75/2d/bd/a0/b2/ea/64/55/97/66/49/08/2e/d2/47/d7c4c05d9e752dbda0b2ea6455976649082ed247.jpg
Veya daha okunabilir olan ve daha makul sayılarda yeni nesne eklenen bir uygulamada resmin eklendiği tarihten bir zaman damgası yaratarak saklaman da makul olabilir. Bugün saat 01:00:00-01:59:59 srasında yollanan bir dosya için aşağıdaki gibi mesela:
kök_dizin/2015/08/29/01/d7c4c05d9e752dbda0b2ea6455976649082ed247.jpg
Son olarak orijinal resimleri (yeniden boyutlandırma vs.. gibi işlemlerden önce) belirlediğin bir süre sakla. Örneğin 30 gün. Bunu kesinlikle yap, lazım olduğunda iyi ki yapmışım diyeceksin. -
detaylı cevaplar için teşekkürler hocam, bu saklama şekliyle ilgili güzel fikirler verdin.. Ancak cache mekanizması v.s beni çok bağlamıyor.. Belirtmedim mi bilmiyorum ama bir wcf servisi yazıyorum hocam, web ve mobil uygulamalar bu resimleri çekecek..bu cdn olayına da biraz daha detaylı bakayım.. bir sürü işle uğraşıyorum hangi birine kafa yoracağımı şaşırdım valla..
tekrar teşekkürler
-
unbalanced bunu yazdı
detaylı cevaplar için teşekkürler hocam, bu saklama şekliyle ilgili güzel fikirler verdin.. Ancak cache mekanizması v.s beni çok bağlamıyor.. Belirtmedim mi bilmiyorum ama bir wcf servisi yazıyorum hocam, web ve mobil uygulamalar bu resimleri çekecek..bu cdn olayına da biraz daha detaylı bakayım.. bir sürü işle uğraşıyorum hangi birine kafa yoracağımı şaşırdım valla..
tekrar teşekkürler
Rica ederim. WCF'den bahsettiğini gördüm ama bak yine bahsettiğin üzere "web ve mobil uygulamalar" diyince sen, istemci tarafında (tarayıcıda) önbellekleme yapmak iyi bir şey olduğundan bahsettim.
Gün içinde bir istemci aynı resme 10 kere baktığında 10 kere senin sunucundan tekrar ona akması iki taraf için de iyi bir şey değil.
Bahsettiklerim gözünü mü korkutu yoksa karışık mı geldi bilmiyorum ama hayata geçirmesi çok basit şeyler, hem sunucuyu epey yükten kurtarır hem de bak mobil diyorsun, kullanıcıların bant tüketimini düşürür, uygulaman hızlanır (tamam ilüzyon bu ama aynı zamanda hakikat). Kolay gelsin :)
-
hocam şimdi baya yorgunum, en son yazdığımdan ne anlam çıkardın bilmiyorum şimdi :)
wcf de cache mekanizması var, şuan çalıştığım firmada zaten bu sistemden hareket ediyoruz.. Bu farklı bir şey.. Bir de web de olan bir cache var bunu da webi yapacak arkadaşın düşünmesi gerekiyor..
mobil zaten direk wcf servisi kullanacağı için onun cache kullanmasına gerek yok, wcf de olacak zaten bu.
benim senin yazdıklarında ilginç bulduğum dosyalama şekli.. Şimdi bu resimleri belirli bir hiyerarşiyle kaydetmek istiyorum aslında.. Tamam isim olarak da kaydedebilirim de tarihten çok farklı kriterler koyarak kaydetmem gerekecek.. Aslında hala orada düşünmediğim bir nokta var.. Müşterisi olmayan bölgeden gelen resimlerin gösterilmesi ve o müşteri eklendiğinde o resimlerin ona eklenmesi :) İşte bu yüzden tarih-saat yerine hali hazırda müşteri varmış gibi bir yol üzerinden kayıt etmek gerekiyor.. Projeyi bilmediğin için bu kısmı anlamamış olabilirsin..
Düşünecek çok şey var, bi yandan kafam tezde, bi yandan almancada, bir yandan wcf de, bir yandan bu projenin nasıl olacağını düşünmekte, bir yandan işte yaptığım projede.. Hepsi birbirinden karışık işler
-
buzukatak bunu yazdı
@unbalanced
Herkes söylemiş sen de farkındasın zaten, resmi veritabanında saklamak gibi bir işe girişme, yedek alması bile başlı başına iş olur çıkar.
Bir de data dosyalarındaki büyük parçalanmalardan dolayı bir DBA gerekir arkasını toparlamak için, gerek yok.
3. parti bir cdn çözümü (hali hazırda aws kullanıyorsun s3 güzeldir bu konuda) istemediğini de görüyorum, dropbox vs.. de öyle hakeza.
O zaman sana kalan, resimlerini diskte saklayıp üstbilgilerini (metadata?) de veritabanında saklamak, SQL Server veya başka bir RDBMS.
Uygulama bir web uygulaması olacağına göre, istemcilerin de ağırlıklı olarak tarayıcılar olacak. Burada devreye giren aslında hızlı bir web deneyimini yaşamamızı sağlayan önbellekleme standartları, bunları unutmamak lazım. Kısacası sanal yol üzerinden istekleri ele alırken olabildiğine "http" standartlarını gözetmen şart.
Bir resim dosyasının istemci tarafında önbelleklenmesi ile ilgili yanıt başlıklarından sonuna kadar yararlan. Cache-Control, Expires, Last-Modified, Etag vs..
Resim üst bilgilerini saklayacağın tablonda ise yeni bir resim kaydında, resmin yolu dışında zaten yanıt başlıklarına da ekleyeceğin Last-Modified, ETag, Cache-Control başlıkları için sütunlar yer alsın.
Resmin güncellenmesi halinde Last-Modified ve Etag yeni verilerle güncellensin. Etag'ler genelde kısa hash'ler olurlar.
Bu implementasyon, sanal yolda istekleri karşılarken istek başlıklarında If-Modified-Since (dosyada şu tarihten sonra değişiklik olmadıysa dosyayı gönder), If-None-Match (Etag artık bu değilse dosyayı gönder) gibi başlıkları işleyip, Etag (If-None-Match değeri) veya dosya değiştirilme tarihi(If-Modified-Since değeri) değişmediyse dosya gövdesini tekrar istemciye göndermek yerine boş ancak durum kodu "304 Not Modified" olan bir yanıt vermek gibi temel gereksinimleri içersin.
Tüm bunlar statik dosyaların istemci tarafındaki önbelleklemesinden sunucu tarafını haberdar edip, eğer gerek yoksa ek her türlü masrafı engellemek için.
Eğer dosyayı statik olarak doğrudan web sunucu üzerinden sunuyor olsaydın her modern web sunucusu gibi bu temel standartları hali hazırda gözetiyor olurdu, ama bunları sen yapacaksın.
Resimleri dosya sisteminde hangi yapıda saklayacağın meselesine gelince, bu başlı başına ilim aslında :D
Ama ben çok abartmayıp, resmin binary'sinden üretilmiş (veya rastgele?) SHA1 özetini alıp, adını bununla belirlerim, örneğin: d7c4c05d9e752dbda0b2ea6455976649082ed247.jpg
En kral dosya sistemi dahi bir dizin içinde belli bir dosya sayısından sonra insan eliyle buna erişmek istediğinde bir yerden sonra sapıtmaya başlayacağından (dosya yöneticileri zaten patates olacak da) sorun çıkmaması için aşağıdaki hash'deki 16 lıkların her birinden oluşan ardışık dizinlerde kendi adıyla saklarım. Bir nevi luhn'umsu (değil tabi :D), bir şekilde dosya adından hangi dizin hiyerarşisinde saklandığının belli olduğu bir yapı. Bu tür bir saklamaya gerçekten aşırı dosya yüklenen bir uygulamada ihtiyaç duyabilirsin.
kök_dizin/d7/c4/c0/5d/9e/75/2d/bd/a0/b2/ea/64/55/97/66/49/08/2e/d2/47/d7c4c05d9e752dbda0b2ea6455976649082ed247.jpg
Veya daha okunabilir olan ve daha makul sayılarda yeni nesne eklenen bir uygulamada resmin eklendiği tarihten bir zaman damgası yaratarak saklaman da makul olabilir. Bugün saat 01:00:00-01:59:59 srasında yollanan bir dosya için aşağıdaki gibi mesela:
kök_dizin/2015/08/29/01/d7c4c05d9e752dbda0b2ea6455976649082ed247.jpg
Son olarak orijinal resimleri (yeniden boyutlandırma vs.. gibi işlemlerden önce) belirlediğin bir süre sakla. Örneğin 30 gün. Bunu kesinlikle yap, lazım olduğunda iyi ki yapmışım diyeceksin.Çizik
Kısayol
Şikayet
Özel Mesaj
Alıntı yap
Cevapla