2015-01-19 2 views
3

При попытке запустить дамп базы данных с использованием запроса от db около 5 миллиардов, время выполнения показывает, что этот дамп не будет завершен в любое разумное время (100 + дней). Запрос также застыл после того, как он, кажется, закончился 0%, около 22 или около того часов спустя - строка после является линией metadata.json.Как ускорить Mongodump, Dump Not Finishing

Свалка линия:

mongodump -h myHost -d myDatabase -c mycollection --query "{'cr' : {\$gte: new Date(1388534400000)}, \$or: [ { 'tln': { \$lte: 0., \$gte: -100.}, 'tlt': { \$lte: 100, \$gte: 0} }, { 'pln': { \$lte: 0., \$gte: -100.}, 'plt': { \$lte: 100, \$gte: 0} } ] }" 

И мои последние несколько строк вывода был (. Набраны как я не могу добавлять изображения пока)

[timestamp] Collection File Writing Progress: 10214400/5066505869 0% (objects) 
[timestamp] Collection File Writing Progress: 10225100/5066505869 0% (objects) 
[timestamp] 10228391 objects 
[timestamp] Metadata for database.collection to dump/database/collection.metadata.json 

Любые мысли, чтобы помочь улучшить производительность или любая идея о том, почему это так долго?

+1

Напишите этот запрос в оболочке mongo, используйте объяснение(), чтобы увидеть, что такое план запроса. Возможно, запрос сам по себе медленный. – marcinn

+0

В дополнение к выводу функции explain() вы также можете подтвердить, какая версия MongoDB вы используете? Сколько результатов вы ожидаете от своих 5 миллиардов исходных документов? Неясно, действительно ли 10 миллионов объектов - ваш полный набор результатов, поскольку последняя строка, ссылающаяся на «metadata.json», обычно испускается, когда дамп завершается для данной коллекции. – Stennie

+0

Привет всем, Так что даже .explain() занимает очень много времени (пару часов +) для запуска. Это обычное дело? Я даже попробовал упростить .explain() только для фильтра местоположения (если координаты x и y-координаты находятся в пределах диапазона) и все еще занимает некоторое время. Будет продолжать работать и обновляться. – Wes

ответ

2

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

Вопрос также описан здесь: https://jira.mongodb.org/browse/TOOLS-845. Тем не менее, это действительно не дает большой части резолюции из «Works as Designed». Возможно, в индексе есть что-то смешное, но я думаю, что в моем случае это была просто достаточно большая коллекция, что объем доступа к диску серьезно тяжело работал для моего бедного Mac Mini.

Одно решение? Завершите запись, а затем используйте --forceTableScan, что делает последовательный проход через данные, что может быть быстрее, чем использование индекса _id, если вы используете настраиваемое поле _id (я был).

Документы немного отрывочны, но они читаются так, как будто нормальное поведение mongodump может состоять в том, чтобы перемещать индекс _id с помощью моментального снимка и затем фильтровать по запросу. Другими словами, он может пересекать все 5 миллиардов записей в заказе _id, а не хранить порядок данных, то есть случайным образом, чтобы завершить запрос. Таким образом, вы можете лучше создать инструмент, который читает из реального индекса и записывает напрямую.

Для меня достаточно --forceTableScan, и это означало, что оно фактически завершается успешно, и (б) оно на порядок или быстрее.

Смежные вопросы