Почистване на осиротели файлове от GridFS

Първо, нека отделим време, за да разгледаме какво е GridFS всъщност е. И като за начало, нека прочетем от страницата с ръководство, която е посочена:

Така че с това от пътя и това може да е вашият случай на употреба. Но урокът, който трябва да научите тук е, че GridFS не еавтоматично методът "go-to" за съхраняване на файлове.

Това, което се е случило във вашия случай (и други) се дължи на спецификацията на "нивото на водача" че това е (а самата MongoDB го прави не магия тук), вашите „файлове“ са „разделени“ в две колекции. Една колекция за основната препратка към съдържанието, а другата за „парчетата“ от данни.

Вашият проблем (и други) е, че сте успели да оставите след себе си "парчетата", след като "главната" препратка е премахната. Така че с голям брой, как да се отървете от сираците.

Вашето текущо четене казва „цикли и сравни“ и тъй като MongoDB не прави обединения , тогава наистина няма друг отговор. Но има някои неща, които могат да помогнат.

Така че вместо да стартирате огромен $nin , опитайте да направите няколко различни неща, за да разбиете това. Помислете за работа в обратен ред, например:

db.fs.chunks.aggregate([
    { "$group": { "_id": "$files_id" } },
    { "$limit": 5000 }
])

Така че това, което правите там, е да получите различното стойности на "files_id" (които са препратките към fs.files ), от всички записи, за 5000 от вашите записи, с които да започнете. След това, разбира се, се връщате към зациклянето, проверявайки fs.files за съответстващ _id . Ако нещо не е намерено, тогавапремахнете документите, съответстващи на "files_id" от вашите "парчета".

Но това бяха само 5000, така че запазете последната id, намерен в този набор, защото сега ще изпълните отново същия сборен израз, но по различен начин:

db.fs.chunks.aggregate([
    { "$match": { "files_id": { "$gte": last_id } } },
    { "$group": { "_id": "$files_id" } },
    { "$limit": 5000 }
])

Така че това работи тъй като ObjectId стойностите са монотонни или „все по-голям“. Така че всичкинови записите винаги са по-големи от Последният. След това можете отново да направите цикъл на тези стойности и да направите същите изтривания там, където не са намерени.

Дали това „отнеме вечно“. Амида . Вие можете използва db.eval() за това, нопрочетете документацията. Но като цяло това е цената, която плащате за използването надве колекции.

Обратно към началото. GridFS спецификацията е проектирана по този начин, защото изрично иска заобиколете ограничението от 16 MB. Но ако това е сне вашето ограничение, тогава попитайте защо използвате GridFS на първо място.

MongoDB няма няма проблем съхраняване на "двоични" данни във всеки елемент от даден BSON документ. Така че не трябвате за използване на GridFS само за съхраняване на файлове. И ако го бяхте направили, тогававсички от вашите актуализации биха били напълно "атомни", тъй като действат само върху един документ ведно събиране наведнъж.

Тъй като GridFS умишлено разделя документи в колекции, след което, ако го използвате, тогава живеете с болката. Така че използвайте го, ако имате нужда от него го, но ако го направите , след това просто запазете BinData като нормално поле и тези проблеми изчезват.

Но поне имате по-добър подход, отколкото да зареждате всичко в паметта.