Yeni bir web sitesi geliştiriyorum ve GridFS'yi tüm kullanıcı yüklemeleri için depolama alanı olarak kullanmak istiyorum, çünkü normal bir dosya sistemi depolamasına kıyasla birçok avantaj sunuyor.
Nginx tarafından sunulan GridFS ile karşılaştırmalar, nginx tarafından sunulan normal bir dosya sistemi kadar hızlı olmadığını göstermektedir.
Dışarıda, GridFS'yi bir üretim ortamında kullanan veya yeni bir proje için kullanan biri var mı?
Yanıtlar:
Şerefli trafik istatistiklerine sahip bir fiyat karşılaştırma web sitesinin parçası olan sunucularımızdan birinde işte gridfs kullanıyorum (günde yaklaşık 25 bin ziyaretçi). Sunucunun çok fazla ram, 2gigs'i yok ve işlemci bile gerçekten hızlı değil (Core 2 duo 1.8Ghz) ancak sunucunun bol depolama alanı var: raid 0 yapılandırmasında 10Tb (sata). Sunucunun yaptığı iş çok basit:
Fiyat karşılaştırıcımızdaki her ürünün bir resmi vardır (ürün veri tabanımıza göre yaklaşık 10 milyon ürün vardır) ve sunucuların görevi, resmi indirmek, yeniden boyutlandırmak, gridfs üzerinde depolamak ve ziyaretçilerin tarayıcısına teslim etmektir. .. ızgarada yoksa ... veya ... ızgarada zaten kayıtlıysa, ziyaretçilerin tarayıcısına teslim edin. Bu nedenle, bu bir 'geleneksel cdn şeması' olarak adlandırılabilir.
Çalıştığından beri bu sunucuda 4 milyon görüntü sakladık ve işledik. Yeniden boyutlandırma ve saklama işleri basit bir php betiği ile yapılır ... ama elbette bir python betiği veya java gibi bir şey daha hızlı olabilir.
Mevcut veri boyutu: 11,23 g
Mevcut depolama boyutu: 12,5 g
Endeksler: 5
Dizin boyutu: 849.65m
Güvenilirlik hakkında: Bu çok güvenilirdir. Sunucu yüklenmiyor, dizin boyutu tamam, sorgular hızlı
Hız hakkında: Elbette, yerel dosya depolama kadar hızlı değil mi, belki% 10 daha yavaş mı, ancak görüntünün işlenmesi gerektiğinde bile gerçek zamanlı olarak kullanılacak kadar hızlı mı, bizim durumumuzda bu çok php'ye bağlı. Bakım ve geliştirme süreleri de kısaltıldı: bir veya birden çok görüntüyü silmek çok kolay hale geldi: basit bir silme komutuyla db'yi sorgulamanız yeterli. Bir başka ilginç şey: eski sunucumuzu yerel dosya depolamayla yeniden başlattığımızda (binlerce klasörde milyonlarca dosya var), bazen saatlerce takılıyor çünkü sistem bir dosya bütünlüğü denetimi yapıyordu (bu gerçekten saatler sürdü ...). Gridfs ile artık bu sorunu yaşamıyoruz, görüntülerimiz artık büyük mongodb yığınlarında (2gb dosyalar) saklanıyor
Yani ... aklımda ... Evet, gridfs üretim için kullanılacak kadar hızlı ve güvenilir.
Bahsedildiği gibi, sıradan bir dosya sistemi kadar hızlı olmayabilir, ancak size sıradan dosya sistemlerine göre avantaj sağlar. biraz hızdan vazgeçmeye değer olduğunu düşündüğüm sağlar.
Nihayetinde, parçalama ile, GridFS depolamasının, sıradan bir dosya sistemi ve tek bir düğüm yerine aslında daha hızlı bir seçenek haline geldiği bir noktaya ulaşabilirsiniz.
Yine de daha büyük DB'ler için onarımlarla ilgili uyarı - geliştirmekte olduğumuz yeni bir sistem, mongo temiz bir şekilde çıkmadı ve 7TB GridFS'i onarmak 130 saat sürecek gibi görünüyor.
Bu nedenle, OpenStack Swift veya Ceph'e geçmeye bakacağımı düşünüyorum. Yine de o zamana kadar iyiydi. Ve nginx-gridfs modülü tatlıdır.
mdirolf'un nginx-gridfs modülü harika ve kurulumu oldukça kolay. Paint.ly'de üretimde tüm resimlere hizmet vermek için kullanıyoruz ve şu ana kadar herhangi bir problem yaşamadık.
Ne yaptığınızı bilmiyorsanız gridfs kullanmanızı önermem. GridFS, dosyaları parçalara bölen ve dosyaları iki koleksiyonda saklayan soyutlama katmanıdır. Daha fazla dosya - daha fazla ek yük. Dosyaların oldukça aynı boyutta olmasını ve 32 milyonu aşmamasını bekliyorsanız - doğru yoldasınız. Gridfs üzerinde büyük dosyalar saklamaya çalışmayın. Neden?
Yüklenen projeyi okumayı düşünüyorsanız - dosyaları doğrudan dokümanlara yüklemeyi düşünün (16M veya daha küçük boyutta ise) veya başka bir clusterfs seçin ve dosya adını / inode'u mantığınıza bağlayın.
Bu yardımcı olur umarım.