Доброй ночи. Подскажите, пожалуйста, по такому вопросу. С mongoDB на

вы, но партия сказала решить задачу.

Есть БД, в ней коллекция binary_files, обычная файлопомойка. Файлы достаются редко и хорошо поддаются сжатию, поэтому, в целях экономии места решили их хранить в сжатом виде, а потом при запросе уже восстанавливать исходный файл.

Был написан скрипт, который прошёлся по всем записям в коллекции, извлёк старые бинарные данные, удалил их, положил новые, сжатые. Все работает.

После заметил, что вместо того, чтобы получить экономию места, наоборот, размер БД увеличился, проверил это командой show dbs и сам .wt файл распух.

Нагуглил в интернете, что монга не очищает место после удаления записи, а "переиспользует" его. Поправьте меня, пожалуйста, если я не прав.

Теперь вопрос - это нормальное поведение и это освобождённое место будет переиспользовано или как-то можно пересчитать и по-настоящему почистить данные?

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

Надеюсь, я объяснил все понятно.

>Теперь вопрос - это нормальное поведение и это освобождённое место будет переиспользовано Да > или как-то можно пересчитать и по-настоящему почистить данные? https://docs.mongodb.com/manual/reference/command/compact/

если у вас данные хорошо жмутся, то ожидаемо включенная по дефолту компрессия же сжимала данные достаточно и сдается мне, что ваш алгоритм просто хуже дефолтного snappy на ваших данных

Спасибо, изучаю. @yatoba , нет, мы все посчитали перед запуском скрипта, а также проверяли на тестовых данных, сжатие должно было дать эффект и он есть. Если интересно, то отпишусь позже, как запустим compact.

Если snappy хуже сжимает данные, то вы можете попробовать классический zlib или фейсбуковский zstd. snappy предназначен для good enough компрессии с низким memory & computational cost