[0-f] arasında değişen yaklaşık 3 milyon dosyanın (kitap kapakları) 3 alt alt seviyede depolandığı bir web sitesi işletiyorum:

0/0/0/
0/0/1/
...
f/f/f/

Bu, dizin başına yaklaşık 2400 dosyaya yol açar; bu, bir dosya almamız gerektiğinde çok hızlıdır. Bu dahası birçok soru tarafından önerilen bir uygulamadır .

Ancak, bu dosyaları yedeklemem gerektiğinde, yalnızca 10m'lik dosyaları içeren 4k dizinlerine göz atmam çok uzun sürüyor.

Bu yüzden, bu dosyaları bir dosyada (veya 4k'lık kaplarda) depolayabiliyor muyum ki, her biri tam olarak bir dosya sistemi (bir tür monte edilmiş ext3 / 4 kap?) Gibi davranır mı? Bunun neredeyse dosya sistemindeki bir dosyaya doğrudan erişmek kadar verimli olacağını ve bunun başka bir sunucuya çok verimli bir şekilde kopyalanmasının büyük avantajı olacağını düşünüyorum.

Bunun en iyi nasıl yapılacağı hakkında herhangi bir öneriniz? Veya uygulanabilir herhangi bir alternatif (noSQL, ...)?

Milyonlarca dosyaya hızlıca erişmek ve bunları yedeklemek için seçenekler

Benzer sorunları olan insanlardan borç almak

Bu, USENET haber sunucularına ve web proxy'lerini önbelleğe alan daha kolay bir soruna benziyor: rastgele erişilen yüz milyonlarca küçük dosya. Onlardan bir ipucu almak isteyebilirsiniz (genellikle hiç yedekleme yapmaları gerekmediği sürece).

http://devel.squid-cache.org/coss/coss-notes.txt

http://citeseer.ist.psu.edu/viewdoc/download;jsessionid=4074B50D266E72C69D6D35FEDCBBA83D?doi=10.1.1.31.4000&rep=rep1&type=pdf

Açıkçası, döngüsel haber dosya sisteminin döngüsel niteliği sizin için önemli değildir, ancak kullanıcının paketlenmiş görüntülere sahip çoklu disk dosyalarına / cihazlarına ve kullanıcının konum bilgisini aramak için sağladığı bilgilerden hızlı bir indeks almasına ilişkin alt seviye kavramı çok uygundur.

Özel dosya sistemleri

Tabii ki, bunlar sadece bir dosyada bir dosya sistemi oluşturmak ve kendi dosya sistemi kodunuzu yazmanız dışında onu geri döngü üzerine monte etmekle ilgili insanların konuştukları ile aynı kavramlardır. Elbette, sisteminizin çoğunlukla okuma olduğunu söylediğiniz için, aslında bir disk bölümünü (veya boyutlandırma esnekliği için lvm bölümünü) bu amaç için ayırabilirsiniz. Yedeklemek istediğinizde, salt okunur dosya sistemini bağlayın ve ardından bölüm bitlerinin bir kopyasını alın.

LVM

Yukarıda bir bölümün dinamik boyutlandırılmasına izin vermek için faydalı olduğundan LVM'den bahsetmiştim; Ancak, elbette, LVM çok uygulanabilir olabilecek başka özelliklere sahiptir. Özellikle bir dosya sistemini bir anda dondurmanızı sağlayan "anlık görüntü" işlevi. Herhangi bir kazayla rm -rfya da her neyse, anlık görüntüyü rahatsız etmeyecektir. Tam olarak ne yapmaya çalıştığınıza bağlı olarak bu, yedekleme ihtiyaçlarınız için yeterli olabilir.

RAID-1

RAID'e zaten aşina olduğunuzdan ve muhtemelen güvenilirlik için zaten kullandığınızdan eminim, ancak RAID-1 en azından RAID yazılımı kullanıyorsanız (donanımsal RAID ile kullanabilirsiniz, ancak bu gerçekten Daha düşük güvenilirlik sağlar çünkü aynı model / revizyon kontrol cihazının okunması gerekebilir). Konsept, normal güvenilirlik ihtiyaçlarınız için gerçekte ihtiyaç duyduğunuzdan daha fazla bir diske sahip bir RAID-1 grubu oluşturmanızdır (örneğin, RAID-1 yazılımını iki diskli veya muhtemelen büyük bir disk ve donanım ile kullanıyorsanız üçüncü bir disk) Donanımın üstünde RAID-1 bulunan RAID-1 yazılımı olan daha küçük disklere sahip RAID5). Yedekleme zamanı geldiğinde, bir disk takın, mdadm'dan bu diski baskın grubuna eklemesini isteyin, tamlık gösterene kadar bekleyin, isteğe bağlı olarak bir onaylama taraması isteyin ve sonra diski çıkarın. Tabii ki,

Geri döngü yöneticisini kullanarak sanal bir dosya sistemi bağlayabilirsiniz, ancak bu yedekleme işleminizi hızlandıracak olsa da normal işlemleri etkileyebilir.

Başka bir alternatif, dd kullanarak tüm cihazı yedeklemektir. Örneğin, dd if=/dev/my_device of=/path/to/backup.dd.

Muhtemelen bildiğiniz gibi, probleminiz yerellik. Tipik bir disk araması 10ms kadar sürer. Bu nedenle, yalnızca 10 milyon rastgele yerleştirilmiş dosyadaki "stat" (veya açık ()) çağrısı için 10 milyon arama veya 100000 saniye veya 30 saat gerekir.

Bu nedenle, dosyalarınızı daha büyük kaplara koymalısınız; öyle ki ilgili sayı, arama zamanınızdan ziyade sürücü bant genişliğinizdir (tipik olarak tek bir disk için 50-100 MB / sn). Ayrıca, bant genişliğini artırmanıza izin veren (ancak arama süresini kısaltmaz) bir RAID atabilirsiniz.

Muhtemelen size bilmediğiniz bir şeyi söylemiyorum, ama benim açımdan "konteynır" fikrinizin sorunu kesinlikle çözeceği ve hemen hemen her konteynırın çözeceğidir. Geri döngü bağları büyük olasılıkla her şey kadar iyi çalışacaktır.

Birkaç seçenek var. En basit ve tüm Linux dosya sistemlerinde çalışması gereken ddbölümün tamamını ( /dev/sdb3veya /dev/mapper/Data-ImageVol) tek bir görüntüye kopyalamak ve bu görüntüyü arşivlemektir. Tekil dosyaları geri yükleme durumunda, geridöngü görüntüyü ( mount -o loop /usr/path/to/file /mountpoint) ekleyin ve ihtiyacınız olan dosyaları kopyalayın. Tam bölüm geri yüklemesi için, ilk ddkomutun yönünü tersine çevirebilirsiniz , ancak gerçekten aynı boyutta bir bölüme ihtiyacınız var.

Kullanım durumunuza bakılırsa, tek tek dosya geri yükleme işlemlerinin hiç gerçekleşmezse çok nadir görülen bir olay olduğunu tahmin ediyorum. Bu nedenle görüntü tabanlı bir yedekleme burada gerçekten anlamlıdır. Bireysel geri yüklemeleri daha sık yapmanız gerekiyorsa, aşamalı LVM anlık görüntülerini kullanmak çok daha uygun olacaktır; ancak yine de kritik "her şeyi kaybettik" felaketleri için görüntü tabanlı yedekleme yapmanız gerekir. Görüntü tabanlı geri yükleme işlemleri, yalnızca geri yükleme blokları olduğu için katran temelli geri yükleme işlemlerinden çok daha hızlı gitme eğilimindedir , her fopen / fclose ile oldukça fazla meta veri işlemi gerçekleştirmez ve aynı zamanda oldukça sıralı bir disk işlemi olabilir. daha fazla hız artar.

Alternatif olarak, Google videosu @casey'nin yarısına kadar değinildiği gibi, XFS (eğer karmaşıksa) harika bir dosya sistemidir. XFS'nin daha iyi olan xfsdumpyardımcı programlarından biri, tüm bir dosya sistemini tek bir dosyaya aktaracak olan ve genellikle yapabilenden daha hızlı yapan yardımcı programdır tar. Dosya sistemine özgü bir yardımcı programdır, bu nedenle fs içindekilerin katran yapamadığı şekillerde yararlanabilirsiniz.

Zaten çalıştırmıyorsanız, öncelikle EXT4’e yükseltmeyi denemenizi öneririz.

Google, EXT4'ün neden iyi bir fikir olduğu konusunda birçok araştırma yaptı .

Bundan sonra dağıtılmış bir dosya sistemi mimarisi dağıtmaya bakmalısınız. Örneğin:

• http://www.xtreemfs.org/
• http://code.google.com/p/kosmosfs/
• http://hadoop.apache.org/hdfs/

Belki basit bir cevap, ama benim ilk düşüncem MongoDB üzerine inşa edilmiş GridFS gibi bir şey kullanmaktı . Birincil dil sürücülerinin birçoğu bunu kutudan çıkarır, bu nedenle kodunuzun dosya okuma bölümleriyle değiştirebilmeniz gerekir. Ayrıca, var olan dizininizi sadece bu dosyalara yönlendiren yolları da yapabilirsiniz.

Aklınıza gelebilecek bir sorun, Mongo'nun sürekli diskten arıyorsa, oldukça hızlı bir şekilde yavaşlama eğiliminde olmasıdır. 10 milyon dosya ile verilerinizin çoğunun diskte olmasını bekliyorum. GridFS'deki dosyaların parçaları 4 MB'dir, hatırladığım kadarıyla, eğer dosyalar bundan daha büyükse, bir dosyayı almak için çeşitli masraflı işlemler yapacaksınız. Anahtar, dosyalarınızı zaten derli toplu bir dizin yapısına göre parçalamak olacaktır, böylece yükü hafifletmek için birkaç kutu üzerinde çalışan Mongo örneklerinin bulunmasını sağlayabilirsiniz. Ancak, performans gereksinimlerinizin ne olduğunu bilmiyorum, bu yüzden fazla düşünebilirim.

Tüm bunların faydası nedir? Doğru yapılırsa, diskle oldukça yakından eşleşen performans okur . Ayrıca, Mongo bir DB örneğindeki verilerin tüm alanını hızlıca ve hatta veritabanı hala çalışıyorken yedeklemenin birçok harika yolunu sunar .

Veri depolamanız için bir cihaz modelinden memnun kalırsanız, belki NexentaStor'u düşünebilirsiniz . Başlık altında OpenSolaris'te ZFS çalıştırıyor, ancak tüm yönetim bir web GUI üzerinden gerçekleştiriliyor.

Sorununuza yardımcı olacak birkaç özellik var.

• Enterprise sürümü, tüm dosya sisteminde tarama gerektirmeyen anlık görüntülere dayanan bir uzaktan çoğaltma biçimini destekler.

• Ellerinizi kirletmemenizin sakıncası yoksa ZFS, son dosyadan bu yana hangi dosyaların eklendiğini, değiştirildiğini veya silindiğini, tüm dosya sistemini taramanıza gerek kalmadan etkili bir şekilde bildiren çok kullanışlı bir ZFS diff komutuna sahiptir. Artımlı yedekleme yapmak için gereken süreyi büyük ölçüde azaltmak için bunu yedekleme sisteminize dahil edebilirsiniz.

Standart bir dumpyardımcı program kullanabilirsiniz EXT4 dosya sistemini çok sayıda dosyayla yedeklemek için. Bu yardımcı program ilk önce bir dosya sisteminde hangi blokların kullanıldığını kontrol eder ve daha sonra aramaların çoğunu elimine eder.

restoreTarafından oluşturulan yedekleri geri yüklemek için ilgili bir yardımcı program var dump.

Seviye - 1 yedekleme, son seviye 0 (tam) yedeklemeden, seviye 2 - seviye 1 yedeklemesinden değiştirilmiş dosyaları vb. Değiştirerek yedeklemeleri destekler.

Artımlı yedeklemeler için, bir seçenek yeni kapaklar için ikinci bir gölge ağacına sahip olmak olacaktır. Yani, tüm okuma işlemlerinde kullanılan ana ağacınıza sahip olursunuz. Aynı zamanda bir newfiles/012345.....jpgrehberiniz olurdu ; yeni eklenen kapaklar, ana ağaçta olduğu gibi burada da bir bağlantı oluşturur. Yedekleme yaparken, zaman zaman ana ağacı yedekleyebilirsiniz, ancak (daha küçük) newfilesağacı çok daha düzenli olarak yedekleyebilirsiniz .

newfilesAğacı küçük tutmak için , ana ağacın yeni bir yedeğini gerçekleştirmeden önce, yeni dosya ağacını boşaltabileceğinizi unutmayın:

mv newfiles newfiles_
mkdir newfiles
rm -rf newfiles_

Bunu yaptığınızda, elbette ana ağacın yeni bir yedeğini oluşturmaya karar verdiniz.

Biraz eşzamanlılık eklemek genellikle yardımcı olur.

Ben de senden benzer bir problemim var; benim durumumda çoğu HTML, PHP veya JPEG dosyası olan 30 milyon civarında dosyayı yedeklemem gerekiyor. Benim için ss üzerinde BackupPC + rsync Tamam tür çalışır; tam yedekleme yaklaşık bir gün sürer, ancak artanlar genellikle birkaç saat içinde sona erer.

İşin püf noktası her bir ana seviye dizinini (0, 1, 2 ... a, b, c ...) BackupPC'ye kopyalamak için yeni bir hedef olarak eklemek ve yedeklemeyi paralel olarak gerçekleştirmesine izin vermek, böylece aynı anda dizinleri yedeklemektir. a / , b / , c / * vb. Disk alt sisteminize bağlı olarak, birkaç işlem ile yaklaşık 10 işlem arasındaki herhangi bir şey muhtemelen yedekleme işleminin en hızlı yoludur.

LVM anlık görüntüleri ve blok düzeyinde yedekleme de bir seçenektir, ancak BackuPC ve dosya düzeyinde yedekleme ile gerektiğinde bireysel dosyaları veya dizinleri geri yükleyebilirsiniz.

Benjamin,

Sanırım, probleminiz dizin düzeyinde dosya sayısına göre çözülebilir!

Bir dizinde 20.000 dosya saklarsanız, erişim süresi önemli bir faktöre göre değişiyor mu?

Ayrıca dosya sistemi meta verilerini ayrı bir daha hızlı erişim sürücüsünde saklamak üzerine de düşündünüz mü? (SSD gibi).

Bunun yerine eski bir ilişkisel veritabanı öneririm.

byteaBirincil anahtar olarak dosya tanımlayıcı ile birlikte, dış bölümlemeli (ikili) sütun olarak görüntü verisi olan 256 bölümlenmiş tablo (cover_00, cover_01, ..., cover_ff) içeren bir PostgreSQL kullanırdım . Bir görüntünün alınması hızlı olur (birincil anahtardaki bir dizin sayesinde), veri bütünlüğü garanti edilir (ACID uyumlu veritabanı), yedekleme disk düzeninde olur, bu nedenle çok fazla arama yapılmaz.