@daft, anladım hocam inceleyeyim o zaman detaylı, wcf ile yapacağım sunucu tarafını, php yi bulaştırmak pek olmaz gibi o zaman.. Ama bunun. net tarafı olursa iyi olabilir. Tabi ne kadar katkı sağlayacak projeye bilmiyorum, sonuçta o da bir şekilde veriyi saklıyor direk file olarak, benim veri gnderip almada sorunum yok, sadece saklama biçimini.. Eğer bu script de kendi sunucumda saklayacaksa veriyi ne avantajı olacak mesela, orayı anlayamadım.. @by_tet, hocam wcf ile yazacağım servisi, asp. net değil :) node. js yi hiç kullanmadım ama o da basit olarak benzer bir işi yapıyor, wcf de sorun yok yani :) veri iletme de dediğin gibi bir sıkıştırma algoritması kullanılabilir, sonuçta servis tarafını da ben yazacağım için sorun yok, diğerinde sıkıntıydı, eleman yazmış kafasına gre servisi uğraş dur :) son olarak wcf bu işin piridir :) Ülkesini Seven Her Türk Vatandasi, Ülkesinin Sessiz Istilasi'na karsi durmak zorunda.

Hocam db mb falan anlamam konuyuda tam okumadim ama bi fikrim var. Insan gozu yuksek frekanslari goremez. eger resimden yuksek frekanslari atarsan boyut kuculecektir diye dusunuyorum. resimleri isleyerek tekrar istedigin formatta kaydet. Unutmazsam bazi filtreler bakarim ama basit alcak geciren filtre isini gorur diye düşünüyorum.

hacı bak gene anlamadın veya ben anlatamıyorum script zaten senin sunucunda olacak, sen kuruyosun, sen kullanıyosun dropbox gibi bir sistemi sunucuna kurduğunu düşün

Hocam dbde resim tutulmaz ondan vazgeç. Resim için standardın dışına çıkmayı düşünürsen webp deneyebilirsin daha avantajlı https://developers.google.com/speed/webp/ yüklenen resmi dnüştürüp bir yerde tutacaksın. Resimleri kolay erişebileceğin şekilde ancak kendine zel bir algoritmayla klasrleyeceksin. İlerde lazım olursa pull cdn bağlar trafiği düşürürsün. resmi dnüştürürken de dbde saklayacağın bilgileri metadata olarak resme eklersen dbden de feragat edebilebilirsin. nasıl bulcam ben yüklenen resimleri db olmadan dersen dediğim gibi zel algoritmayla klasrleme yapacaksın sonuçta resmin nereye gittiğini bileceksin, nasıl çekeceğini de bileceksin. getirdikten sonra ihtiyacın varsa metdata okur gerisini halledersin. :|

şimdi alternatifleri değerlendirmek lazım hocam sql kısmında byte array - base64 vs şeklinde blob data olarak sakladın ihtiyaçların neler mysql mssql vs seçim yaptığın db için ekstra yük demek sql e eklediğin grsel sayısı ve trafik arttığı zaman sql şişecek ve sıkıntıya düşmene neden olacak. 2. alternatif grseli sunucuya yüklemek; Bu noktada ihtiyacın ne olacak dosya alanı ve trafik ihtiyacın olacak. Ben sql e resim saklama olayını sadece çok grsel olmayan bi kaç projemde kullandım. Bu işlemin geri dnüş hızı sunucu donanımı ile değişiklik gstermekte. Senin projeni ben yapıo olsam direk sunucuda barındırıp o şekilde kullanırım hatta geleceğe ynelik şişmeleri ve kullanıcı memnuniyetini artırmak istiyosan cdn hosting kullanarak daha saglıklı hizmet sunarsın ZzZzZzZ...!

cdn image hosting anahtar kelimen hocam +1 bir de nosql falan hiç düşünme daha nce denedin mi bilmiyorum da gerçek verinin 7-8 katı yer kaplıo db'de iğrenç

Selamlar, Şimdi bir projemiz için yeniden hatta sıfırdan başlıyorum her şeye, daha nce yapan arkadaş çekildi aradan ve kodunu kullanmamamızı istiyor, gerçi db sini ben tasarlamıştım ama neyse.. Sorum şu, kullanıcılar mobil uygulamalarla resim yükleyecekler. Ben bu resimlerin kalitesini ve boyutunu düşürerek atıyorum 200-300 kb lik dosyalar haline getirerek sunucu tarafında saklamak istiyorum. Bu resimleri de web üzerinden bazı kullanıcılara gstermek istiyorum. Proje tutarsa resim sayısı fazlalaşacak haliyle.. O yüzden şimdiden efektif bir çzüm bulayım derdindeyim. Eski arkadaş base64 e çevirip o şekilde db ye kaydediyor. Ancak bu yntem db yi çok şişirecektir diye düşünüyorum.. Bir de blob data şeklinde saklamak var tabi. Ve son olarak direk dosya şeklinde sunucuda barındırma. Tabi geri dnüşte sanal bir path üzerinden ya da byte array e çevirip kullanıcıya vereceğim.. Veritabanı olarak mysql ya da mssql kullanmayı düşünüyorum. Şuan amazon aws den alınmış bir windows server 2012 im var. WCF servisini oraya yazacağım, nosql i henüz düşünmüyorum ama o da olabilir bilemiyorum henüz.. Ama join ler çok olacağı için rdbms daha mantıklı geliyor. Ben webci değilim o yüzden byle projeler pek yapmıyorum.. Biraz araştırayım dedim her kafadan bir ses çıkmış :) Ama grdüğüm kadarıyla genel kanı; sql server ın diskte yer kaplamaktan daha pahalı olduğu. Bir de şyle bir şey aklıma geldi, api ile dropbox tarzı yerlere de resimleri gnderebilirim ama pek hoş olmaz en azından profesyonel olmaz. Bu konu hakkında zellikle dene yapmış, daha nce araştırma yapmış arkadaşlar fikirlerini sunarsa sevinirim. Yoksa ben de biliyorum şunu yap bunu yap demeyi :) Yani yapılacak şeyin en mantıklı iş olmasını gznüne alıyorum. unbalanced tarafından 21/Ağu/15 00:07 tarihinde düzenlenmiştir Ülkesini Seven Her Türk Vatandasi, Ülkesinin Sessiz Istilasi'na karsi durmak zorunda.

Daft bunu yazdı trooper bunu yazdı cdn image hosting anahtar kelimen hocam +1 bir de nosql falan hiç düşünme daha nce denedin mi bilmiyorum da gerçek verinin 7-8 katı yer kaplıo db'de iğrenç hocam ben ileri seviye veritabanı sistemleri dersi aldım :) tüm popüler nosql çzümlerince projeler geliştirdik ve ben çok sevdim ama kendi projelerimde kullanmıyorum... Yoksa doğru bir optimizasyonla güzel sonuçlar elde edersin. 7-8 kat veri kaplama olayını hiç duymadım :) sonuçta metin tabanlı bir imkan var, o kadar olmaması lazım.. ben ders mers almadım gzlemlediğim şeyi sylüyorum json datayı, nosql veritabanına yükledim 20 mb data db'de 160 mb tuttu üstelik db'den veri silsen dahi "reclaim free space" diye bi olay yok kendin compact ediyorsun tabi bu da ilerde performans sorunlarına yol açabilir diye düşünüyorum? https://owncloud.org/ hazır bi çzümle ilerlemeye izin var mı?

Optimasyon, optimasyon, optimasyon. Resim saklama-sunma olayında veritabanı kesinlikle iyi bir çzüm değildir. Kullanım temelinden şaşmamak lazım ki veritabanı verilerin listelenmesi bağlantılanması gibi durumları içerir. Tekrar eden verileri ynetmek, sunmak, bağlantılandırmak, küçültmek, sınırlandırmak... içindir veritabanı. Resim saklama-sunma olayı kesinlikle klasik dosya barındırıcılıktan farklı değildir. Farkı hızlı sunum ile oluşmaktadır ki hızlı sunumda resimlerin optimasyonundan geçer. İyi algoritmalar gerekirse ücretli algoritmalar ile resim boyutlarını küçülterek sana çok daha hızlı sunum ve verimli depolama sağlayacaktır. En büyük ihtiyacın optimasyon. Hatta rnek ile açıklayalım instagram resim çzünürlüğünü büyüttü ama dosya boyutları bundan çok etkilenmedi. Neden? Adamların sağlam optimasyonları var. Hatta eminim ki -incelemedim- saklamak için ayrı sunmak için ayrı optimasyonları var. Uygulamalarında bile kullandıkları algoritmaları sz konusudur. Edit: 1 rnek daha vermek istiyorum. Facebook'ta yeni yüklenen videolar sıkıntı çıkarmaz. Hemen izlersiniz ama çok eski bir videoyu izlemek istediğinizde videoya tıklarsınız video yüklenmez. Hata verir. Biraz bekleyip tekrar basarsanız videonun yüklendiğini greceksiniz. Adamlar bir süre kullanılmayan dosyaları çok küçültmek için yüksek seviyede sıkıştırma yapıyorlar sonucuna rahatlıkla varabiliriz. Nasıl olsa çok kullanılmıyor. İstek yapılmıyor. Arşive kalkmasında bir sıkıntı oluşmuyor. İsteyen olursa arşivden çıkartıp sıkıştırmasını çzüp gsteriyor. E seninki video değil resim. Olsa olsa 200 300kb olacak. Sıkıştırmasının çzülmesi çokta vakit almaz. Eski bir foto için biraz bekleyebilir kullanıcı.. PcK0 tarafından 21/Ağu/15 01:02 tarihinde düzenlenmiştir Sadece bi imza..

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 blgeden gelen resimlerin gsterilmesi 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 Ülkesini Seven Her Türk Vatandasi, Ülkesinin Sessiz Istilasi'na karsi durmak zorunda.

cdn image hosting anahtar kelimen hocam hocam bu da sonuçta dropbox gibi bir dosya servisi, belki biraz daha zelleşmiş ama ben hepsini bi arada tutmaktan yanayım.. İşler biraz devlet işine kayıyor, yani belki bizim sunucumuzda bile verilerin tutulmamasını isteyecekler. O yüzden harici bir servis kullanmayı şimdilik düşünmüyorum. Ama amazon un bu tarz bir cloud hizmeti var, acaba aws ile entegreli çalışıyorsa o tarz bir şeyler olabilir bakmak lazım Ülkesini Seven Her Türk Vatandasi, Ülkesinin Sessiz Istilasi'na karsi durmak zorunda.

http://stackoverflow.com/questions/3748/storing-images-in-db-yea-or-nay byle bişi buldum hocam konuyu açmadan nce küçük bir araştırma yaptım hocam, buraya da baktım zaten.. pek tatmin etmediği için konu açayım dedim Ülkesini Seven Her Türk Vatandasi, Ülkesinin Sessiz Istilasi'na karsi durmak zorunda.

http://stackoverflow.com/questions/3748/storing-images-in-db-yea-or-nay byle bişi buldum hocam black implies white, self implies other, life implies death.

unbalanced bunu yazdı Daft bunu yazdı trooper bunu yazdı cdn image hosting anahtar kelimen hocam +1 bir de nosql falan hiç düşünme daha nce denedin mi bilmiyorum da gerçek verinin 7-8 katı yer kaplıo db'de iğrenç hocam ben ileri seviye veritabanı sistemleri dersi aldım :) tüm popüler nosql çzümlerince projeler geliştirdik ve ben çok sevdim ama kendi projelerimde kullanmıyorum... Yoksa doğru bir optimizasyonla güzel sonuçlar elde edersin. 7-8 kat veri kaplama olayını hiç duymadım :) sonuçta metin tabanlı bir imkan var, o kadar olmaması lazım.. ben ders mers almadım gzlemlediğim şeyi sylüyorum json datayı, nosql veritabanına yükledim 20 mb data db'de 160 mb tuttu üstelik db'den veri silsen dahi "reclaim free space" diye bi olay yok kendin compact ediyorsun tabi bu da ilerde performans sorunlarına yol açabilir diye düşünüyorum? https://owncloud.org/ hazır bi çzümle ilerlemeye izin var mı? bir yerde bir terslik var hocam o halde.. nosql çzümleri çok daha fazla performanslı, biz bir sürü şey ile denedik, bu yeni nesil semantik web olayına bile girdik ne bileyim.. neyse zaten kullanmayı düşünmüyorum.. bahsettiğin cloud uygulama gibi çok alternatif var ama ben harici bir yerde saklamak istemiyorum, ola ki istenmezse o zaman sıkıntı çıkacak. Bu projenin bir ayağı devlet kurumları olacak, onlar da verilerin 3. şahıslara gitmesini istemeyebilirler, hatta kendi sunucularına kurmamızı isteyebilirler o yüzden harici bir yerde saklamak mantıklı gelmiyor. Ülkesini Seven Her Türk Vatandasi, Ülkesinin Sessiz Istilasi'na karsi durmak zorunda.

şimdilik hostin v. s. çok nemli değil hocam, sadece yapıyı düzgün kurma derdindeyim... db nin şişeceğini biliyorum aslında, ve resimlerin de bir süre db de tutulacağı gerçeği var.. bana mantıklı gelen de harici olarak tutmak ama belki bilmediğim daha farklı sonuçlar alabileceğim yntemler olabilir diye düşündüm.. Dediğim gibi webci değilim o yüzden çok da alernatifleri bilmiyorum.. Sadece mantıklı düşününce bi kaç sonuç çıkıyor. Facebook, instagram gibi uygulamalar milyonlarca resim saklıyorlar, biraz bunları araştırmak lazım aslında.. bunların nosql kullandığını biliyorum ama resimleri nasıl saklıyorlar ona bakmadım Ülkesini Seven Her Türk Vatandasi, Ülkesinin Sessiz Istilasi'na karsi durmak zorunda.

trooper bunu yazdı cdn image hosting anahtar kelimen hocam +1 bir de nosql falan hiç düşünme daha nce denedin mi bilmiyorum da gerçek verinin 7-8 katı yer kaplıo db'de iğrenç hocam ben ileri seviye veritabanı sistemleri dersi aldım :) tüm popüler nosql çzümlerince projeler geliştirdik ve ben çok sevdim ama kendi projelerimde kullanmıyorum... Yoksa doğru bir optimizasyonla güzel sonuçlar elde edersin. 7-8 kat veri kaplama olayını hiç duymadım :) sonuçta metin tabanlı bir imkan var, o kadar olmaması lazım.. Ülkesini Seven Her Türk Vatandasi, Ülkesinin Sessiz Istilasi'na karsi durmak zorunda.

Kesinlikle bende merak ediyorum. En basitinden thumblr bile dünya kadar resim atıyorsun, web ve mobil de sıkntı yaşatmıyor. Biri bu sitelerin mimarisini anlaırsa seve seve dinlerim. Bilmiyorum ne kadar işe yarar ama iş yerinde ki projede yaklaşık 3 bin profil resmini, server de olduğu gibi saklıyoruz. DB ye path saklııyoruz çağrıldığı yerden de çekiyoruz. https://www.youtube.com/watch?v=WC3-71NKwPw

@unbalanced Herkes sylemiş 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 grüyorum, dropbox vs.. de yle hakeza. O zaman sana kalan, resimlerini diskte saklayıp üstbilgilerini de veritabanında saklamak, SQL Server veya başka bir RDBMS. Uygulama bir web uygulaması olacağına gre, 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ı gzetmen ş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 , If-None-Match gibi başlıkları işleyip, Etag veya dosya değiştirilme tarihi değişmediyse dosya gvdesini tekrar istemciye gndermek 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 gzetiyor olurdu, ama bunları sen yapacaksın. Resimleri dosya sisteminde hangi yapıda saklayacağın meselesine gelince, bu başlı başına ilim aslında :DAma ben çok abartmayıp, resmin binary'sinden üretilmiş SHA1 zetini alıp, adını bununla belirlerim, rneğin: d7c4c05d9e752dbda0b2ea6455976649082ed247. jpgEn 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 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 , 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. kk_dizin/d7/c4/c0/5d/9e/75/2d/bd/a0/b2/ea/64/55/97/66/49/08/2e/d2/47/d7c4c05d9e752dbda0b2ea6455976649082ed247. jpgVeya 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:kk_dizin/2015/08/29/01/d7c4c05d9e752dbda0b2ea6455976649082ed247. jpgSon olarak orijinal resimleri belirlediğin bir süre sakla. rneğin 30 gün. Bunu kesinlikle yap, lazım olduğunda iyi ki yapmışım diyeceksin. Çizik echo "imzanız zel karakter içermemelidir";

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 grdüm ama bak yine bahsettiğin üzere "web ve mobil uygulamalar" diyince sen, istemci tarafında 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 gzü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 . Kolay gelsin :) anlıyorum.

hacı incelemedin herhalde :D harici bi yer değil, script o script dropbox tarzı üyelikli, dosya müzik resim barındırma, kullanıcılara birbirlerine link dağıtma imkanı veren vs vs apileri olan bi script

trooper bunu yazdı cdn image hosting anahtar kelimen hocam hocam bu da sonuçta dropbox gibi bir dosya servisi, belki biraz daha zelleşmiş ama ben hepsini bi arada tutmaktan yanayım.. İşler biraz devlet işine kayıyor, yani belki bizim sunucumuzda bile verilerin tutulmamasını isteyecekler. O yüzden harici bir servis kullanmayı şimdilik düşünmüyorum. Ama amazon un bu tarz bir cloud hizmeti var, acaba aws ile entegreli çalışıyorsa o tarz bir şeyler olabilir bakmak lazım hocam şimdi projenin teknik alt yapısını bilmeden afaki konuşuyorum ama devlet işi diyosunda belediyelerde var olan bilgi işlemciler network kurmaktan aciz ama başka kurumlarsa potansiyel kitlen o zaman değişir ama tavsiyem sub domain üzerinden vps barındırarak başlamak daha mantıklı geliyor ZzZzZzZ...!

@unbalanced Herkes sylemiş 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 grüyorum, dropbox vs.. de yle hakeza. O zaman sana kalan, resimlerini diskte saklayıp üstbilgilerini de veritabanında saklamak, SQL Server veya başka bir RDBMS. Uygulama bir web uygulaması olacağına gre, 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ı gzetmen ş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 , If-None-Match gibi başlıkları işleyip, Etag veya dosya değiştirilme tarihi değişmediyse dosya gvdesini tekrar istemciye gndermek 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 gzetiyor olurdu, ama bunları sen yapacaksın. Resimleri dosya sisteminde hangi yapıda saklayacağın meselesine gelince, bu başlı başına ilim aslında :DAma ben çok abartmayıp, resmin binary'sinden üretilmiş SHA1 zetini alıp, adını bununla belirlerim, rneğin: d7c4c05d9e752dbda0b2ea6455976649082ed247. jpgEn 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 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 , 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. kk_dizin/d7/c4/c0/5d/9e/75/2d/bd/a0/b2/ea/64/55/97/66/49/08/2e/d2/47/d7c4c05d9e752dbda0b2ea6455976649082ed247. jpgVeya 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:kk_dizin/2015/08/29/01/d7c4c05d9e752dbda0b2ea6455976649082ed247. jpgSon olarak orijinal resimleri belirlediğin bir süre sakla. rneğin 30 gün. Bunu kesinlikle yap, lazım olduğunda iyi ki yapmışım diyeceksin. anlıyorum.

@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.. Ülkesini Seven Her Türk Vatandasi, Ülkesinin Sessiz Istilasi'na karsi durmak zorunda.

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 Ülkesini Seven Her Türk Vatandasi, Ülkesinin Sessiz Istilasi'na karsi durmak zorunda.

@daft, yok incelemedim hocam isminden yola çıkarak syledim ama yine de dediğim gibi işe yaramayacak, çünkü ben kendi sunucumda tutmak istiyorum bunları.. bunu kullanmanın bir amacı yok o zaman.. zaten kendi sunucumdaysa api ye gerek olmadan erişirim @pck0, sağolasın hocam detaylı anlatımın için, katılıyorum sana optimizasyon nemli bir faktr, bu sebeple zaten her şeyi düşünerek hareket etmek istiyorum, düzgün bir iş çıksın istiyorum ortaya. Zaten db ye yazmam base64 olarak da, ama yapan eleman yle yapmış halbuki benim çizdiğim tasarımda path ini tutuyordu. Sıkıştırma olayını düşüneyim biraz.. çok eski olmadığı müddetçe sıkıştırmaya gerek olmayabilir. Boyutlarda fazla olmayacak zaten, normalde iphone ile çeklien bir resim bir kaç mb olabliyor, ben daha nce kullandığım algoritmayı kullanarak 100-300 kbye e düşürüyorum, aynı mantığını kullanacağım, ama ondan sonra sıkıştırma olayını bilemedim.. şimdi sıkıştırıp tekrar açmak gerekecek.. gzip kullanarak sıkıştırma işlemini yapabilirim ama belirli bir tarih sonraki olan resimleri sıkıştırmak daha mantıklı.. ama bu işi otomatik yapabilsem güzel olabilir. Zaten uygulamada temizlik şart olacak, mesela şehrin büyüklüğüne gre bu süre değişecek, yani yoğun istek gelen şehirlerde veri çok olacak, o yüzden çok eski verileri tutmamak gerekiyor, yani tutmak lazım ama kullancıya gsterilmeyecek. Ayrıca bu dataları belki firmalara da satabileceğiz. Düşünecek çok şey var o yüzden iyi bir şeyler yapma derdindeyim. Performans nemli bir faktr, yaklaşık 3000 tane bu şekil kuruluş var diyelim isviçrede, bunların 500 üne satsak.. Bir de farklı ülkelerden de istiyorlar. O yüzden global bir olaya da dnebilir, hiç bir şey de olmayabilir.. Ama her halukarda sistemi esnek, güçlü ve performanslı tasarlamam gerek. Maalesef tüm işler de bir tek bana kaldı Ülkesini Seven Her Türk Vatandasi, Ülkesinin Sessiz Istilasi'na karsi durmak zorunda.

1 - Tutacak yerin zaten db olamaz 2 - Klasrde tutacaksın ama direk atmayacaksın 3 - Resimlere sıkıştırma algoritmaları uygula sonra koy klasrüne 4 - relational bir db ye ihtiyacın yok, sadece resim saklayacaksan, nosql yapı kullanabilirsin Hello, i am nothing. I come from Neverland.

cdn image hosting anahtar kelimen hocam ayrıca tavsiyem db de tutmaman ilk etapta en ucuz yoldan vps alıp sub domaine ynlendirip sistemi bu şekilde kurman ilerleyen dnemlerde makinayı yükseltmen değiştirmen cdn geçişin daha kolay olur db de saklayıp sonradan geçiş yapman demek sana ekstra işçilik ekstra zaman ve projede revizasyon yapman demek trooper tarafından 21/Ağu/15 00:23 tarihinde düzenlenmiştir ZzZzZzZ...!

Her "performans" isminin geçtiği yerde krün dilenciyi bellediği gibi node. js diyorum fakat Hakikaten ihtiyacın node. js. asp. net muhtemelen işini yavaşlatacak. Node. js ile işin içine c de katarak servera ultra hakim bir şekilde tüm resimlerine vs hükmedebilirsin. rneğin asp. net te bir resmi gzipe çevirip onu direk işleme sokmadan gndermen muhtemelen seni zorlayacaktır. Hatta ben bilmiyorum bana imkansız bir olay direk yani Ama node. jste çok basit olacak. Bir de 1 mb hani 200kb a düşürebiliyorsan bu yeterli. Encode decode yapacak bi sistemle string compress yapmaktan başka çaren kalmıyor zaten daha ne kadar düşürebilirsin ki? Bir websitesi için de bir fotoğraf için 200kb gayet güzel. Milyonlarca fotoğraf saklayacak olduğunda artık server tarlasına geçersin Tüm bu yazdıklarımdan zet iki tavsiye, node. js ve string compress encode https://github.com/antirez/smaz rnek link mesela by_Tet tarafından 21/Ağu/15 01:47 tarihinde düzenlenmiştir iyibu! yeniden..