Возможно ли собрать Cap GridFS?

Question

Я пытаюсь сохранить результаты моих приложений в базе данных монго. Для этого есть некоторые проблемы: сначала мы генерируем много данных, потому что это файлы необработанных изображений, до 50 МБ на запись и 5 записей в секунду на полной скорости, что в худшем случае, хотя и не типично. Это не проблема с использованием gridFS. В mongod.cfg мы используем directoryPerDB: true и создаем символическую ссылку для папки базы данных результатов на выделенный SSD, где хранится вся база данных результатов. Все данные настроек хранятся в нескольких разных базах данных на диске ОС, а в данных результатов имеется выделенный диск. Все это отлично подходит для нашего приложения.

Моя проблема заключается в заполнении диска результатов. Мне нужно иметь ограниченную коллекцию с максимальным размером, а затем удалить только самые старые файлы. Но я не вижу способа сделать это с помощью gridFS? Есть ли настройка или что-то, что мне не хватает, что позволило бы укутать это?

Я нашел этот ответ GridFS disk management, но это похоже на mongod, и я не думаю, что вы можете установить квоту на базу данных, поскольку база данных Results - единственная, что мне нужно ограничить.

На этом этапе я предполагаю, что напишу задачу, которая периодически очищает самые старые файлы, если сумма превышает пороговое значение, я просто боюсь, что это не будет очень эффективным. Есть ли рекомендации по наилучшему способу справиться с этим?

Answer 1

Короче говоря: вы не можете использовать GridFS полезным способом. Вот почему:

При сохранении файла в GridFS, он разбивается на куски 255kB, по умолчанию в коллекции под названием fs.chunks, который абсолютно может быть ограничен, делая

db.createCollection("fs.chunks",{capped:true, size:52428800}) 

укупорки будет применяться к тем кускам, которые являются отдельными документами. Поэтому, когда вы добавляете файл, который заставит fs.chunks превышать его кепку, удаляются только куски самых старых файлов. Другая проблема заключалась бы в том, что метаданные файлов, которые хранятся в fs.files по умолчанию, не будут обновляться, оставив устаревшие записи в fs.files, для которых нет записей в fs.chunks, или, что еще хуже, только часть фрагментов по-прежнему настоящее время.

Есть способы преодолеть это (проверяя, является ли размер в байтах объединенных блоков равным полем длины документа fs.files соответствующего файла, например), но они по меньшей мере столь же сложны (и намного медленнее!), так как выполняется предварительная установка чека, коллекция будет превышать порог с использованием статистики коллекций и удалять как можно больше из самых старых файлов, чтобы они соответствовали новому файлу без превышения порога.

Последний, кстати, является моим предложением о том, как решить вашу проблему.

Другим решением будет использование специального экземпляра с ограничениями, применяемыми в моем ответе на упомянутый вами вопрос.