17-10-2018, Saat: 10:26
(17-10-2018, Saat: 09:27)Abdullah ILGAZ Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol Kısaca Hayır. Kapladığı yer hesaba koyulursa resimleri veritabanında tutmak hata yapmaktır. Image, Blob gibi alanlara gizlenen resimlerin gizlenme sebebi "gizlilik"tir.
Diğer görüşteki arkadaşlar ve Tuğrul hocaya saygı duyarım ama kesinlikle katılmıyorum. Yazdıklarınıza katkı olsun diye söylemek istiyorum dizinde tutun demek gidin de sistemdeki herkese bu dizine okuma yazma izni verin demek değil. Bu dosyaları dizine yazacak ve dizinden okuyacak bir web servisiniz olacak ve sadece o web servis ilgili dizine ulaşacak. Ayrıca istediğiniz şekilde dizin yapısı oluşturarark sürekli full backup'lar yerine incremental backup'lar alabilirsiniz. Dosyaların güvenliği için de dosyaları gerekiyorsa encrpyt/decrpyt yapabilirsiniz gerekiyorsa.
Veritabanı sisteminin, sistemde en özel yere sahip olduğunu ve bunun dışında yapılabilecek hiç bir işin bu sunucu/sistem içersinde yapılmaması gerektiğini ya da istendiği an veritabanına çıkarmaya elverişli olması gerektiğini düşünüyorum.
Tabii ki her önerme her durumda doğru olmayabilir ama resimleriniz bir kaç terabayt boyutuna ulaştığında (sunucu kapasitesi yetmediğinde) çok kolay bir şekilde başka bir sunucu ekleyip bu sistem ile yolunuza devam edebilirsiniz. Ayrıca hangi dosyanın hangi adreste olduğunu veritabanında olduğunu tutarak da istediğiniz zaman dosyaları taşıyıp veritabanını da update eden bir servisle/script ile sunucu değişikliğini dahi çok rahat yapabilirsiniz.
17-10-2018, Saat: 10:44
(17-10-2018, Saat: 10:25)Tuğrul HELVACI Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
600 KB bir resim dosyasını Base64 olarak ele aldım. Base64 formatı 200 KB (%33) arttı.
17-10-2018, Saat: 11:12
Yaşanmış bir gerçek olduğu için şunu açıkça söyleyebilirim ki; Bir sistemdeki serbest bileşenlerin sayısı ne kadar artarsa (bu örnekte resimlerin ayrı bir klasörde tutulması durumu) bunların belli bir düzen içinde işlemesi, dış müdahalelere açık olup olmamasının kontrol edilmesi, yedeklenmesi, bazı durumlarda doğrulanması, klasör/lerin yerel bir sistemde olup olmadığı ile ilgili eş güdümün sağlanması, mevcut verilerin taşınması gibi durumlar da dahil olmak üzere o derece zorlaşır. İşi çok iyi biliyorsunuzdur, yaparsınız ama bu, işin kolay olduğu ve dikkatinizi azaltmamanız gerektiği anlamına gelmez. Tetikte olmanız gereken, kontrol etmeniz gereken bir sürü durum oluyor, (yukarıda arkadaşlar ve üstadlar saydı, yeniden listelemeye gereki görmüyorum.)
Dolayısıyla ben de bu tarz (özellikle döküman yönetimi çerçevesinde) resimleri, taranmış evrakları ve elektronik belgeleri veritabanında tutmaktan yanayım ve öyle yapıyorum. Çok da faydasını gördüm.
Resim ve dökümanları ayrı bir tabloda tutmak çoğu zaman durumu kurtarıyor fakat iş, dökümanların gigabyte'larca / terabaytlarca yer kaplamasına varacaksa ayrı bir tabloda tutmaktan ziyade yükü hafifletmek, darboğazlar yaratmamak adına o kısmı ayrı bir veritabanında tutmak bazen daha makul bir seçenek haline gelebiliyor.
Çoğu belge türlerinde zip/rar gibi sıkıştırma yöntemleriyle hacimden kazanma yoluna gidiyoruz fakat Resimler için uyguladığım ek bir işlem ise onları belli bir ölçekte yeniden boyutlandırmak, duruma göre jpeg formatına çevirip öyle kaydetmek gibi yollar izliyoruz.
17-10-2018, Saat: 12:05
Benim genelde kullandığım yöntem
Farklı bir veritabanı oluşturuyorum (Resim sayısı çok fazla ve boyutlar büyük)
Veritabanında Resim Id'sinin son 2 digitini alıp bu şekilde 100 tablom oluyor 00..99 (Bu tablolarda veri sıkıştırılmış halde duruyor)
Resimlerin küçültülmüş olan örnek gösterimi son digit ile 10 tabloda tutuluyor.
Normalde data uzerinde gezinirken küçük boyutlu resimler kişiye gösteriliyor
Kişi eğer resim üzerine çift tıklayıp detaya giderse orjinal boyut olan tabloya ulaşılıyor (UnZip yapılıyor)
Resim ID sine göre bir procedure hangi tabloya gideceğini biliyor ve datayı oradan alıyor.
Eğer resimleri küçük diye bişey olmaz düşüncesiyle hepsini bir yere koyunca 5-6 yıl sonra erişimde ciddi problemler yaşanıyor tecrübe ile sabit.
buda benim yoğurt yiyişim
17-10-2018, Saat: 12:14
Her iki durumunda arti ve eksileri mevcut. Tamamen ihtiyaca göre degisiyor bence. Bazı uygulamalarımda klasor acip icerisine resimleri atiyorum. Database tarafında da bir tabloya resim yolunu atiyorum.
Bazı uygulamalarımda dogrudan tablo icerisine aktarıyorum. Ayrı bir tabloda tutyorum. Bazı uygulamalarımda resim boyutu cok ucuk boyutlara ulasma ihtimali olunca ve kullanıcıya resim boyutu kısıtlaması koyamadigim zaman sadece resimleri ayri bir database de tutuyorum.
17-10-2018, Saat: 15:38 (Son Düzenleme: 17-10-2018, Saat: 15:40, Düzenleyen: sabanakman.)
Problemi bir başka zemine taşıyacak başka bir soru. Dosyaları bulut sistemlere yedekleyen mekanizma nasıl çalışır? Hem milyonlarca dosya hem de farklı zamanlara ait versiyonlandırma ile tutulmaktadırlar. Sanırım bunu yapmanın yolu ancak veritabanı ile mümkün olabilir. Zira bu denli büyük kapasite ve sayılara ulaşan sistemlerde dosyalar üzerinden çalışmak işi çığrından çıkaracaktır fakat veritabanı üzerinden çalışmak işleri daha düzenli hale getirecektir. Bu benim tahminim. Yanılıyor da olabilirim. Basit bir kaç tane vesikalık için de olsa çok büyük karmaşık sistemler için de olsa veritabanı bana daha cazip duruyor. Bu da kişisel yoğurt yeme şeklim, programlamada çareler tükenmez .
17-10-2018, Saat: 22:27 (Son Düzenleme: 17-10-2018, Saat: 22:33, Düzenleyen: ssahinoglu.)
Herkes duruma göre değiştiğinde hemfikir sanırım.
Ben genellikle taşınabilirliği önemsediğim için dosya olarak tutmayı daha çok yeğlerim.
Veritabanı bozulursa tüm resimler gitmez. Çok büyük veritabanı dosyasını onarmaya gerek kalmaz.
Fakat çok dosya oluşması disk erişimi için, benim tercih edebileceğim, bir sorundur.
Eğer çok aşırı dosya olursa bunları da kodlanmış bir dizin ağacında tutmak faydalıdır.
dosya id: 1234567.jpg
1234567 = $00 $12 $D6 $87
Böylelikle 3 katmanlı dev bir dizin ağacı oluşur.
her dizin altında 256 alt dizin, en alttaki dizinde de 256 dosya bulunur.
Toplam 4 milyar resim kapasitesi için maksimum dizin sayısı ise 16 milyon olacaktır.
256 yerine siz 100 de kullanabilirsiniz. Böylece kodlamanıza gerek kalmaz.
Nihayet işletim sistemi dizinleri ve dosyaları ararken fazla yorulmayacaktır.
Ayrıca yedeklemem ve gerektiğinde dosyalara girip müdahale etmem kolay olur.
Dahası dosyaların yanında farklı belgeleri tutmak da mümkündür.
Sanırım tek bir noktada buluşamadık. Burada instagramı göz önünde bulundurursak . Sizce bu uygulama resimleri veritabanında mı tutuyor yoksa dosyada mı tutuyor ?
Ayrıca dosyada tutulan bu resimlerin güvenlik açısından hangi platformda saklamak mantıklı ? daha öncesinde SFTP olarak okumuştum. ama bu hizmeti veren çok yer yok sanırım. Microsoft Azure da bu hizmeti veriyor sanırım ama biraz pahalı .
Yani kullanıcıların tekil olarak fotoğrafı kaydetmesinden daha çok, uygulama fotoğraf paylaşım platformu olarak düşündüğümüzde hangisini kullanmamız mantıklı olur ?
17-10-2018, Saat: 23:52
Bu konuda benimde düşüncem veritabanına kaydedilmesi yönünde. Yazılanların bir kısmından anladığım; harici bir klasörde tutulması durumunda resimlere doğrudan erişim imkanı ve database bozulduğunda resimlere bir şey olmaz düşüncesi ön plana çıkıyor. Projeye özgü özel bir durum yoksa, resimlerde veritabanı sisteminindeki "verinin" bir parçasıdır. Başka bir ifade şekli ile cari tablosundaki veriler önemli ise resim veriside aynı öneme sahip olması gerekir.
Tasarladığımız sistem Cluster database yapısında ise (farklı lokasyonlarda veya coğrafyalarda) , verinin bir parçasının database sisteminin dışına çıkartılması (resimlerin dizine aktarılması) cluster yapısının bize sağlamış olduğu senkronizasyon mekanizmalarından faydalanamayacağımız anlamına gelir. Cluster sistemini database deki verileri node lar arasında senkronize ederken, bizim yazacağımız farklı bir servis de resimleri aynı şekilde farklı lokasyonlardaki sunuculara senkronize etmesi gerekir. Bu senkronize işlemininde clustera senkronize olması gerekir , yoksa verinin linki diğer node a gitmiş fakat linkin bağlı olduğu resim farklı bir kanaldan senkron olmayı beklediğinden veri bütünlüğü bozulmuş olacaktır. Bu esnada ilgili veriye erişmek isteyen uygulamayı kullanan kullanıcıya biraz bekleyin resimler diğer depoda hemen çırağı gönderip getirtiyorum demeniz gerekecektir
Veri tabanı bozulmaları sık yaşanıyorsa, çözüm büyük boyutlu verileri dışarıya alarak restore işlemini (buradaki restore herzaman tam bir restore olmayacaktır. Bu yapıda dizindeki dosyalar ile veri tabanındaki linklerin tutarlı olduğu durumu garanti değildir) hızlandırmak olmamalı, bozulmanın önüne geçecek yapıyı kurmak olmalıdır.
18-10-2018, Saat: 00:44
Yazılan fikirler gayet güzel hoş fikirler. Elinize emeğinize sağlık fakat okurken görmediğim noktalarıd a göstermiş oldunuz. Mesela dizinde saklayanlar için şöyle bir sorum var. Dizinde sakladığınız resme aynı anda kaç client açabilir? A -B-C kullanıcıları aynı anda aynı resmi görüntülediğinde durum ne olur. Sonuçta her bir kullanıcı kendi formundaki image nesnesine ilgili resmi çağırmış olacak . Mantıken windowsta aynı resmi bir çok defa farklı ekranda açabiliyoruz mantığına bakılarak sorun olmaması gerek ama sizce sorun olurmu ?