Comments 13
С помощью Npgsql и его штатных средст (NpgsqlDataReader, NpgsqlDataAdapter, CreateInsertMethod(), Prepare()) можно тоже добиться неплохой скорости. А если распараллелить на несколько потоков - можно таблицы с несколькими млн данных перегнать за приемлемое время.
Спасибо за интересную идею. В своём материале я дал ссылку на этот github коммент, содержащий ряд методов: https://github.com/npgsql/npgsql/issues/2779#issuecomment-573439342
Используя их я получил значительный прирост скорости. Могу ли я запросить хорошие примеры использования этих средств? Было бы интересно сравнить их в их лучшем виде с упомянутыми.
Спасибо за ссылку. Очень полезная. В принципе, я также использовал InsertPrepared и результат на 100000 почти тот же что и в описании из твоей ссылки.
Вот как это делал я: https://github.com/greenDev7/PGMigrationTest/blob/main/Form1.cs
У меня в таблице 14 столбцов. Однако, если данных будет порядка нескольких миллионов, то нужно уже чот выдумывать. Пока спасают pg_dump и pg_restore ))
Нерабочие варианты
Вариант 1: Insert + Select
Это рабочий вариант в postgresql. Достаточно таблицу источника подключить к БД приёмника (не наоборот) через FDW. И это один из самых эффективных способов. К тому же, на нём можно сделать захват изменений и не потерять тех данных, что сделали в источнике во время копирования.
Спасибо за идею. Не знал про это расширение.
Ради таких комментариев я опубликовал свою первую статью на хабре. Буду надеяться что во-первых удачную, а во-вторых не последнюю.
Из того, что я могу понять на данный момент - оно альтернатива вариантам с dblink, которые я выделил в отдельные варианты.
Поправьте меня если я не прав.
FDW более производителен
На FDW можно сделать read only доступ для выгрузки данных. Но у него есть
updatableопцияdblink подключение существует в рамках сессии в которой оно создано, в то время как fdw пермаментен
dblink доступен на более ранних версиях PostgreSQL
Что делает его более выигрышной альтернативой dblink. Мне было бы интересно услышать ваше сравнение FDW и dblink подкреплённое реальным опытом, в силу того что я не имел опыта с FDW.
А можете рассказать как правильно мигрировать на новые версии Субд когда сама БД весит к много и в нее постоянно идет запись)
Могу ли я уточнить, что есть много? Пол сотни гигабайт? Пол террабайта? Террабайты? Или более?
Мне самому было услышать ваше решение этой проблемы, ибо исходное описание совпадает с тем что на моём проекте и я использовал методы представленные в моём материале.
Я опасаюсь что у меня не будет хорошего решения для вас. Это был мой первый раз.
Я видел, что пока я готовил мой материал к выходу, вышел цикл статей с сходной тематикой от ppetrov91. Полагаю у него должно быть куда больше компетенции в данном вопросе.
Силами самой СУБД postgres: pg_upgrade с параметром -k, будет небольшой перерыв, конечно.
Переносил данные с MS SQL на Postgres. Сначала через ODBC драйвер постргеса с помощью MS SQL Studio. 45 миллионов строк вставлялось примерно 4 часа. Каждая запись вставлялась отдельным инсертом, поэтому так долго. А это только одна таблица, там еще несколько таблиц по 3-4 миллиарда записей. В итоге переносил кусками через CSV. Правда одна таблица с комментариями содержала переносы строк в ячейке. Постгрес такого издевательства не смог пережить при импорте.
Не использовали tds_fdw?
Что делать, если кроме данных надо перегнать ещё кучу хранимок... Переписывать их все состариться можно.
Поваренная книга миграции данных между БД или как перенести данные из одной БД в другую с минимальной болью V1.1