#mongodb
#mongodb
Вопрос:
У меня есть приложение, которое использует mongo для хранения данных с коротким сроком службы. Все данные старше 45 минут удаляются скриптом, что-то вроде:
oldSearches = [list of old searches]
connection = Connection()
db = connection.searchDB
res = db.results.remove{'search_id':{"$in":oldSearches}})
Я проверил текущее состояние —
>db.results.stats()
{
"ns" : "searchDB.results",
"count" : 2865,
"size" : 1003859656,
"storageSize" : 29315124464,
"nindexes" : 1,
"ok" : 1
}
Итак, согласно этому, 1 ГБ данных занимает 29 ГБ хранилища. Папка с данными выглядит следующим образом (вы можете видеть, что многие файлы очень старые — последний доступ к ним был в середине мая):
ls -l /var/lib/mongodb/
total 31506556
-rwxr-xr-x 1 mongodb nogroup 6 2011-06-05 18:28 mongod.lock
-rw------- 1 mongodb nogroup 67108864 2011-05-13 17:45 searchDB.0
-rw------- 1 mongodb nogroup 134217728 2011-05-13 14:45 searchDB.1
-rw------- 1 mongodb nogroup 2146435072 2011-05-20 20:45 searchDB.10
-rw------- 1 mongodb nogroup 2146435072 2011-05-28 00:00 searchDB.11
-rw------- 1 mongodb nogroup 2146435072 2011-05-27 13:45 searchDB.12
-rw------- 1 mongodb nogroup 2146435072 2011-05-29 16:45 searchDB.13
-rw------- 1 mongodb nogroup 2146435072 2011-06-07 13:50 searchDB.14
-rw------- 1 mongodb nogroup 2146435072 2011-06-06 01:45 searchDB.15
-rw------- 1 mongodb nogroup 2146435072 2011-06-07 13:50 searchDB.16
-rw------- 1 mongodb nogroup 2146435072 2011-06-07 13:50 searchDB.17
-rw------- 1 mongodb nogroup 2146435072 2011-06-06 09:07 searchDB.18
-rw------- 1 mongodb nogroup 268435456 2011-05-13 14:45 searchDB.2
-rw------- 1 mongodb nogroup 536870912 2011-05-11 00:45 searchDB.3
-rw------- 1 mongodb nogroup 1073741824 2011-05-29 23:37 searchDB.4
-rw------- 1 mongodb nogroup 2146435072 2011-05-13 17:45 searchDB.5
-rw------- 1 mongodb nogroup 2146435072 2011-05-18 17:45 searchDB.6
-rw------- 1 mongodb nogroup 2146435072 2011-05-16 01:45 searchDB.7
-rw------- 1 mongodb nogroup 2146435072 2011-05-17 13:45 searchDB.8
-rw------- 1 mongodb nogroup 2146435072 2011-05-23 16:45 searchDB.9
-rw------- 1 mongodb nogroup 16777216 2011-06-07 13:50 searchDB.ns
-rw------- 1 mongodb nogroup 67108864 2011-04-23 18:51 test.0
-rw------- 1 mongodb nogroup 16777216 2011-04-23 18:51 test.ns
Согласно «top», mongod использует 29 ГБ виртуальной памяти (и 780 Мб RSS)
Почему у меня такие ненормальные значения? Нужно ли мне запускать что-то дополнительное к функции .remove(), чтобы очистить базу данных от старых значений?
Комментарии:
1. Из интереса, вы исследовали использование ограниченных коллекций для решения такого рода проблем? Это устранило бы проблемы с дисковым пространством, устранило бы необходимость в скрипте удаления и, возможно, сделало бы приложение быстрее…
2. В качестве примечания: для таких недолговечных данных я бы использовал Redis, который поддерживает истечение времени ожидания для любых данных.
3. Mongo просто перегружен хранилищем. BSON занимает много места, потому что он хранит полное имя ключа, а также значение для каждого поля в документе. Как уже говорили другие, существуют обходные пути, но вам нужно будет согласиться с использованием большой файловой системы, если вы используете MongoDB.
Ответ №1:
Размер виртуальной памяти и резидентный размер будут казаться очень большими для процесса mongod. Это благоприятно: пространство виртуальной памяти будет чуть больше размера открытых и отображенных файлов данных; размер резидентной памяти будет варьироваться в зависимости от объема памяти, не используемой другими процессами на компьютере.
http://www.mongodb.org/display/DOCS/Caching
Когда вы удаляете объект из коллекции MongoDB, занимаемое им пространство автоматически не собирается мусором, а новые записи добавляются только в конец файлов данных, отчего они становятся все больше и больше. Это все объясняет:
http://www.mongodb.org/display/DOCS/Excessive Disk Space
Для начала просто используйте:
db.repairDatabase()
Комментарии:
1. насколько я читал — восстановление полностью заблокирует mongodb на некоторое время — верно? Есть ли у вас какие-либо ожидания — сколько времени это займет?
2. @Andrew: Вы можете скопировать файлы базы данных и запустить
db.repairDatabase()
ни на одном производственном сервере, чтобы посмотреть, сколько это займет.3. Я знаю, что этот запрос устарел, но, похоже, поведение Mongo с тех пор не изменилось; неужели нет лучшего способа освободить место, кроме блокировки всего вашего производственного экземпляра? только меня это раздражает?
4. @JMac нет, я тоже нахожу это чрезвычайно раздражающим. Я унаследовал MongoDB от «устаревшего» приложения и не могу дождаться, когда избавлюсь от него. Эта штука ответственна за более чем 90% всех наших проблем / сообщений об ошибках.
5. Я знаю, что это ужасно старая тема, но я просто хотел указать на возможность добавления элемента в набор реплик. При этом данные для нового участника автоматически сжимаются. После добавления запустите нового участника как основного и удалите все с предыдущего основного и повторно добавьте его в набор. Хотя для больших наборов данных это может занять время, это не заблокирует вашу базу данных.