Kullanıcı tarafından yüklenen dosyaları bir web sunucusuna depolama

Kullanıcıların dosyaları yüklemesine izin veren bir web sitesinde çalışıyorum (resimler ve başka türlü). Bu alanda daha önce hiç tecrübem yok ve bu dosyaları saklamak ve dizinlemek için doğru şekilde bir giriş elde etmeyi umuyordum.

Yüksek hacimli verilere iyi ölçeklenen bir mimariye sahip olmak isterim, şu anda aşırı derecede yüksek (facebook- google-scale) hacimler hakkında endişelenmiyorum.

Dosya sistemindeki dosyaları depolamayı düşünüyordum.

/files/{username}/

Ve her bir kullanıcının yüklediği her dosyanın dosya adları (ve dolayısıyla URL'leri) ile kendi tablosuna sahip olduğu bir karşıya yükler 'e sahip olmak (ve saklamak isteyebileceğim diğer ekstra bilgiler). Veritabanının sonuncusu (her kullanıcıya kendi masasının verilmesi) benim için çok verimsiz gibi gözüküyor, ancak tek bir tablodaki tüm dosyaların kayıtlarının tutulması, tek bir dosyanın her seferinde tüm tablo boyunca aranmasını gerektiriyor erişilebilir.

Her bir kullanıcıya kendi tablosunu vermeyi düşünmenin arkasındaki mantığım, verilere karşılık gelen verileri ararken tablolardaki verileri parçalamak ve arama sürelerini kısaltmak için temiz ve ayrı bir yol olmasıdır.

 7
katma düzenlendi
Görünümler: 6
kaynak
ro ru fr es pt de hi bn ar be uk

2 cevap

Uygulamanızın ve veritabanınızın yapısı ve yapısına bağlıdır. Klasör tabanlı, bir veritabanı blobunda saklanan resimler, bir kimlik doğrulama ağ geçidiyle erişilen web dışı dosya klasörleri dahil birçok teknik kullandım ...

Temp fotoğrafları veya bir şey gibi doğrudan uygulama veya veritabanıyla ilgili olmayan harici görüntüler için, bunları bir klasöre koyma eğilimindeyim. Yapınızın bir kullanıcının resimlerinden oluştuğu görülüyorsa, görüntülerle ilişkili metadataların etiketler gibi olmasını beklerim. Bu durumda, büyük olasılıkla, bunun için bir kapasiteye sahip olduğumu farzederek, resmi bir veritabanı tablosunda saklayacağım. Fotoğrafların güvenlik altına alınması gerekiyorsa, kimlik doğrulaması yapılmadan diğer kullanıcılara erişilemezse, bir veritabanının kendi güvenliği olacaktır, buna karşın dosya tabanlı bir depolama yetkisiz erişimi önlemek için bir çeşit hile gerektirecektir.

Kullanıcı başına bir tablo kullanmam, sadece ID, userid, resim blob öğelerinden oluşan bir tablo.

Bu yardımcı olur mu?

3
katma
kaynak
Bu yardımcı olur. Ancak, birkaç sorun var. Şu anda, her veritabanı için 1GB sınırlayan bir paylaşımlı web sunucusu kullanıyoruz, böylece veritabanındaki resimler/dosyaları bir blob olarak saklamak mümkün olmayacaktır. Ayrıca, bir tablodaki tüm resimler belirli bir fotoğrafın arama sürelerini artırmaz mı? Kullanıcı başına bir masanın arkasındaki mantığım, kullanıcıyı bilmenin, hangi tabloyu arayacağımı ve dolayısıyla daha az kayıtta arama yapmanın (bunu, userid'e dayalı olarak sharding olarak düşün) bilmem gerektiğiydi. Bu mantıklı olmaz mıydı? Kaybettiğim bir şey mi var?
katma yazar xbonez, kaynak
Bir dizinin boyutu, SQL yürütmesini etkiler, ancak büyük bir dizine eklenmemiş blob kümesi fark edilmeyecektir. Ama alanınız yoksa, bu bir tartışma noktasıdır. Bu durumda, bunları dosya sisteminde saklamanız gerekir. Tek bir klasörde büyük bir dosya sayısından kaçınmak iyi bir uygulama olduğundan, bir kullanıcı/klasör klasörü yapısı, bir LOT'unuz varsa tamamdır. Doğrudan erişimden kaçınmak için bir yere .htaccess koyarım (onlara erişme yetkisine sahip olduğunuzu varsayarsak) ve bir fotoğraf kullanırmı? İd = başlıkları resim/jpeg veya neyse değiştirirse ne olursa olsun ve eko okuma dosyası görüntüdür.
katma yazar Matt H, kaynak

Ne olursa olsun Matt H önerisi iyi bir fikirdir. elde etmeye çalışıyorsunuz kullanıcı düzeyinde görüntü erişimi başına. Ancak veritabanınızda saklanan alanınızda sınırlı olduğunuzu kabul ettiğinizde, görüntüleri ikili verilerde sakladığınız kadar verimsizdir.

Kullanıcı başına bir tablo kullanmak kötü tasarımdır. Dosyayı yükleyen kullanıcı, tüm dosya yüklemelerini ve herhangi bir dosya meta verilerini içeren tablodaki bir alan/sütun olmalıdır. Dosya isminin GUID oluşturulmasını öneriyorum; bu, benzersiz olması garantilidir ve kullanıcıların tüm görüntülere kolayca erişmesini engellemeye çalışıyorsanız, tahmin edilmesi kolay bir otoantrement alanından daha iyi.

Performanstan endişe duyuyorsunuz, ancak milyonlarca kayıt üzerinde milyonlarca işlem yapana kadar, belirli bir zaman çerçevesinde yüklenen (bir zaman damgasını veya benzeri bir dosyayı saklıyorsanız) görüntülerin seçilmesiyle ilgili sorgularınız maliyet açısından çok küçüktür. Hız bir sorunsa, kullanıcı adına belirli bir görüntü sorgusunu önemli ölçüde hızlandıracak bir B-ağacı dizini ekleyebilirsiniz.

Güvenlik, erişim ve organizasyon konusuna geri dönün. Görüntüleri kullanıcı başına bir klasörle saklayın (kullanıcı sayısına bağlı olarak, klasörlerin sayısı yönetilemez bir düzeye kadar büyüyebilir). Görüntülerin herkese açık olarak sunulmasını istemiyorsanız, bunları web dışı bir klasörde saklayın, uygulamanızın verileri okumasını sağlayın ve görüntüyü kullanıcı için oluşturması için akışa alın. Daha karmaşık ama gerçek dosyayı internetten saklıyorsunuz. Ayrıca, kimliği doğrulanmış bir kullanıcı tarafından tüm görüntü isteklerini doğrulayabilirsiniz.

3
katma
kaynak