Wrapper большие объемы данных из удаленной БД в postgresql?
По объемам это порятка 100 000 000 строк, атрибутов по строке немного порядка 10
Да ничего такого в принцыпе. Но я всегда предпочитаю dblink, как более предсказуемый.
Спасибо! А dblink чем получше?
Тем, что понять, что будет делать fdw когда пишэшь какой-нибудь нормальный запрос с JOIN и парой условий -- не так просто. Проблемы почти как с индэксами, но отлажывать ещё сложнее кмк. И вот если это буквально один запрос, который переносит данные (изредка) -- то проще по-моему написать точный запрос на сервер через dblink, чем гадать что и в каком порядке будет просить fdw.
в принципе у меня проблема переноса одной таблицы в другую один в один, то есть в источнике есть таблица A(a1,a2,a3,a4,a5) и она должка переехать в целевую БД тоже в таблицу A(a1,a2,a3,a4,a5)
это как-то повлияет на выбор межде fdw и dbink?
Можэт, slony напустить? Если это неодноразовое? Чего самому изобретать-то?
если он это сможет сделать я не против. Уточню проблематику, нужно периодически сливать таблицу из green plum в postgreslq, запускать процесс нужно по расписанию
Вы правда хотите двадцать гигабайт таблицу именно по расписанию? А то можэт как раз slony с постоянной заливкой журнала будет дешэвле?
И да, перелив "полностью по расписанию" выглядит как задача для pg_dump скорее, честно говоря. Ну, то есть можно по-всякому по-другому... Но зачем, когда есть pg_dump, его легко жать, можно мониторить прогресс и он ужэ написан.
Боюсь такое не очень ложится на бизнес процесс, то есть: 1/ аналитические данные подготавливаются в green plum к определенной дате 2/ по наступлению даты Х считается, что аналитика в сторонней системе подготовлена и ее нужно целиком забрать 3/ инкремента нет, забирается каждый раз все под чистую
Ну, если реально нет, тогда понятно что нет смысла.
а можно в такой схеме как-то без вермешели из bash скриптов сделать следующее 1/ слить таблицу из green plum 2/ восстановить во временную таблицу в postgresl 3/ сделать переключение в postgresql предудущей версии таблицы на новую, которая была восстановлена из последнего слепка ?
Ну, можно вермишэль хоть на Си писать так-то.
это да, никто не спорит, однако хотелось бы просто иметь в схеме постгреса простое декларотивное описание на установку необходимых расширений, создание процедуры на выборку и переключение таблиц и крон задачи. Чтобы все это присутствовало в миграции раскатывалось вместе с новым инстнсом БД
Не советую тащить крон в постгрес. Всё, что есть -- не очень хорошэе, плюс не очень ложытся база данных в юникс с его файловой системой. Но если притащишь -- то в принцыпе запуск ssh и оперирование с файлами ужэ совсем тривиально. Но всё-таки по-моему лучшэ крон, миграцыи и прочее писать в отдельные какие-нибудь плейбуки или там операторы.
Спасибо огромное! Буду эксперементировать
Обсуждают сегодня