Pull to refresh

Comments 9

Статья сильно попахивает генератором. Сплошная тавтология. Да ещё и ботов нагнали..

Последний пример вообще дважды вредный - какой pandas, вы о чём вообще?

дважды вредный - какой pandas, вы о чём вообще

Трижды. Не бывает миграции одноразовой, практически никогда. Это процесс. И он практически всегда построен на том или ином способе выбрать свежие данные из одной базы, и добавить их в другую. Поэтому нормальные процессы миграции как правило строятся на чем-то типа Golden Gate, ну или применительно к постгресу - debesium. Т.е. что-то что читает WAL, пересылает транзакции в другое место, и там их применяет к другой БД.

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

Всё правильно пишите, но посмею всё-таки поправить - Debezium

Да, вы совершенно правы. Просто мне приходится немного работать с аналогами, Streamgate и SIDEC, а про сам дебезиум я скорее теоретически знаю, и он более широко известен.

Согласен. Если миллиарды строк затея так себе. Но если делать инкрементальную загрузку? А данных не так много(например: еженедельно данные обновляются в по 1 тыс. строк).

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

Sign up to leave a comment.

Articles