Подтвердить что ты не робот

Преобразование данных из Mongo в MySQL (110M docs, 60Gigs) - Советы и предложения?

Мне поручили переносить данные из базы данных MongoDB в базу данных MySQL. (Есть серьезные причины для переноса - так что это нужно сделать).

Коллекция MongoDB:

  • Имеет около 110 миллионов документов
  • Весит 60 ГБ.
  • Имеет индексы для важных свойств
  • Выполняется автономный отдельный сервер Windows 2008, который не обслуживает какой-либо производственный трафик.

Программа, которую мы пробовали:

  • Экзамен большого экземпляра Amazon EC2 Win2008 с 7,5 гигабайтами оперативной памяти /8 записей файла страницы.
  • Консольное приложение С#, которое преобразует данные MongoDB в локальную базу данных MySQL.

Мы собираем 1K документов за раз в памяти от MongoDB, выполняем необходимую обработку и затем сохраняем их в MySQL db, делая периодические записи по 500 за раз.

Проблема, с которой мы сталкиваемся, заключается в том, что каждый 2.5 M docs, сервер задыхается, и Mongo реагирует очень медленно - сглаживает операцию извлечения данных приложения (Free RAM переходит на время обработки документов 1M)

Мы медленно продвигаемся вперед, убивая процесс mongod и начинаем его снова каждые 2.5M записи, когда он падает, но я уверен, что мы делаем что-то неправильно.

Вопрос:

Должен ли я переместить Mongo Server на большой экземпляр на базе Linux и MySQL на Amazon RDS для этого и переписать приложение преобразования в PHP? Помогло ли это?

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

Какие еще вещи я могу попробовать/советы, которые я могу использовать?

Спасибо, что прочел это!

- Обновление 01 -

Он был приблизительно 6 часов с момента перезапуска моего приложения и сделал следующее изменение:

  • Увеличенное количество просмотров Mongo Read от 1000 до 10 000 записей за раз. Пропустите (10K).limit(10K)
  • Удалены все индексы из целевой базы данных MySQL.
  • Увеличен размер страницы Windows с 4 до 8 гигов.

Моя память потребляет 100%, но приложение работает. (Последний раз он прохрипел через 52 минуты). Mongo - 6,8 гигабайта оперативной памяти, MySQL - 450 мегабайт и приложение конвертера - 400 мегабайт (приблизительные значения).

Обработано 11M записей до сих пор - но скорость снизилась до 370 записей/сек с примерно 500 записей/сек.

Следующие шаги состоят в том, чтобы изолировать как серверы Mongo, так и MySQL для разделения ящиков и - сохранить все их в той же зоне доступности Amazon, чтобы минимизировать время ожидания.

- Обновить 02 -

Мы внесли некоторые изменения в код, чтобы использовать Mongo Cursor и автоматически увеличивать его автоматически против использования .skip(). limt(). Это значительно ускорило процесс, и мы делали 1250 записей в секунду от 300 нечетных ранее. Тем не менее, приложение начало потреблять слишком много памяти и закончилось бы из ОЗУ и аварийным завершением, и его необходимо было перезапустить после каждых двух записей.

Мы использовали этот фрагмент кода:

var docs = db[collectionName].Find(query);
docs.SetBatchSize(numOfResultsToFetchAtATime);
foreach (var d in docs) {
  // do processing
}

Итак, что это значит, это выборка "numOfResultsToFetchAtATime" за раз, но затем автоматически выполняется в цикле и выбирает следующий набор записей. Монго позаботится об этой прогрессии с помощью курсора, и, следовательно, это намного быстрее.

Однако мы все еще не смогли успешно перенести это. Отправьте мой ответ с кодом, когда это произойдет правильно.

- Обновление 03: Успех -

Наконец, мы использовали предложение @scarpacci о выполнении mongoexport. Помните, что очень важно, чтобы mongodb находился в окне Linux, а не в окне окна.

Сначала мы попробовали сделать mongoexport из Windows на локальном MongoDB и независимо от того, что мы пробовали, он потерпит неудачу в разных местах для одной большой коллекции (13Gigs +)

Наконец, я восстановил БД на Linux-боксе, и mongoexport работал как шарм.

Нет конвертера Json → MySQL, так что многое нам нужно было сделать. С небольшой настройкой мы смогли использовать наше предыдущее приложение и прочитать файлы и напрямую написать MySQL. Это было быстро и относительно безошибочно.

У нас были некоторые проблемы с большими файлами, но с ним удалось разбить 13-гигабайтный файл на 500 мегабайтных файлов, и мы смогли успешно перенести все данные в MySQL.

Большое спасибо всем за то, что они проводят время, помогая нам. Надеюсь, что это объяснение поможет кому-то в будущем.

4b9b3361

ОТВЕТЫ

Ответ 1

Рассматривали ли вы использование mongoexport, а затем выполняли какую-то массовую вставку в MySQl? Не уверен, что это доступно в MySql, но мы все время выполняем что-то подобное в SQL Server. Можете ли сделать свалки/вставки легче разделиться и оптимизировать? Просто мысль....

Ответ 2

У меня возникли проблемы с переносом данных на SQLServer с использованием .NET один раз - хотя я старался держать его как можно более легким, он все же был недопустим медленным. В конце я написал быстрое приложение С++ OLEDB, и все прошло значительно быстрее. Я все еще пытаюсь понять, что я сделал неправильно в своем приложении .NET, но это может быть проблемой в .NET. Я бы не переписал преобразование в PHP, но перейдите с параметром производительности и используйте С++ (возьмите урок из Интернета, его не так сложно, а не для отложенного приложения)

Итак, это одна вещь, чтобы посмотреть в первую очередь, а также профиль вашего приложения С#, чтобы узнать, есть ли у него ошибка утечки памяти, которая медленно возвращает остальную часть системы в обход.

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

Запустите perfmon и посмотрите на память, свопинг, дисковое IO и использование процессоров Mongo, вашего приложения и экземпляра MySQL.

Ответ 3

Как только я переместил большую базу данных (не 60 ГБ, но достаточно большой, чтобы показать проблемы) Я закончил тем, что написал небольшое приложение, выполняющее эту работу.

Таким образом, я читаю из одной БД и писал другому, с каким-то (я столкнулся с аналогичными проблемами с сбоями базы данных и т.д.)

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

У нас были таблицы в обеих базах данных, без документов, но проблема будет быть одинаковым.

В конце концов:

  • Существует одно приложение, которое координирует перенос, но не имеет никаких связей с базой данных на нем
  • Несколько экземпляров, созданных из приложения для координации, для перемещения данных, выполнения рабочего элемента, закрытия после этого (есть способ сообщить об успехе перед закрытием). Таким образом, вы можете иметь несколько читателей/писателей и экспериментировать со счетом, я только около 10 одновременных экземпляров чтения/записи за один раз. Если ваши документы достаточно малы, вы можете создать много больше. Но все равно они будут очень быстро закрываться.

Примечание.. Не указывайте индексы в целевой базе данных при записи в это даст вам максимальную производительность. Установите индексы когда у вас есть все данные в них.

Ответ 4

Нет причин для того, чтобы вы записывали данные непосредственно в MySQL - разделили задание на два отдельных этапа, и вы будете запускать сначала MongoDB, а затем MySQL, чтобы они не конкурировали за ресурсы - похоже, что растущий MySQL процесс голодает Mongo по RAM или io.

Первый этап: получить данные от MongoDB, обработать его и сохранить в текстовый файл (как SQL). Остановите Mongo, запустите MySQL

Вторая стадия: запуск регулярного импорта базы данных с использованием файла, сгенерированного на этапе 1.

Ответ 5

Тот факт, что перезагрузка MongoDB исправляет проблему с производительностью и постоянное количество записей, которые вы можете обрабатывать до того, как оно появится, звучит как утечка ресурсов для меня. Я бы удостоверился, что все закрыто и т.д. Убедитесь, что MySQL не настроен на использование слишком большого объема памяти или, лучше, переместите его на другую машину.