В рамках моей статьи он не применим. Потому что формирование его из PostgreSQL — слишком сложная и ресурсоемкая задача. Увы, если источник не MS SQL, то при загрузке в bcp вынужденно используем текстовый формат.
Зачем Вы переходите на демагогию? Вы не уважаете читателей Хабра?
Или Вы искренне считаете, что строительство железных дорог приводит к увеличению себестоимости продукции промышленного производства в государстве, так же как и повышение стоимости электроэнергии?
А цена этого? По Вашей же ссылке экпорт электроэнергии упал на 43%. О возросшем импорте скромно умолчали. А если во Франции вдруг друзья зеленые начнут АЭС закрывать, то энергетика Германии просто ляжет без перетоков из Франции. А это далеко не единственное государство, откуда Германия импортирует электроэнергию для покрытия неравномерной выработки из ВИЭ.
Порой у меня возникает подозрение, что зеленая энергетика в ЕС — дальновидный ход США. Чем дороже будет энергия в ЕС, тем конкурентней будет промышленность США.
Исландия — исключение, благодаря исключительной географии и низкой плотности населения. Например, в РФ гидроэлектростанции можно строить в Сибири. Но электроэнергии там и так избыток. А в европейской части строительство новой гидроэлектростанции нанесет такой удар по экологии, что «зеленой» ее назвать язык не повернется.
Геотермальные электростанции можно строить на Камчатке. В Паратунке даже работает маломощная. Вот только большие мощности можно получить только ближе к Долине Гейзеров, до которой, кроме как на вертолёте, не доберешься.
Вы ошиблись, потому, что не прочитали даже названия статьи.
SSIS медленней, чем описанный в статье способ.
Все равно в нем Вы будете делать те же шаги: экспортировать данные из PostgreSQL в текстовый файл и загружать их BULK INSERT из этого текстового файла в MS SQL. Но передавать по сети данные будете дважды (SSIS — выделенный хост).
Вы действительно думаете, что создание XML, его передача по сети, парсинг, INSERT INTO, да еще и в цикле по слайсам, может оказаться быстрее, чем bcp/BULK INSERT?
Простите, но у меня есть все основания считать, что Вы заблуждаетесь.
При этом, Вы имеете полное право опубликовать здесь код Вашего решения, сравнить время выполнения Вашего и моего кода и разбить меня в пух и прах.
Если же Вы предлагаете менее производительное, но универсальное решение, то, простите, первый код в статье справляется с задачей намного более универсальным путем, чем Ваш. Только медленно. И статья вовсе не об универсальности, а о достижении максимальной производительности.
mssql умеет в gzip
Даже если на стороне PostgreSQL сжать в GZIP xml длиной больше 4ГБ (а это можно сделать), то как Вы его на стороне MS SQL распакуете, если DECOMPRESS() возвращает varbinary(max), длина которого лимитирована 2ГБ?
Просто Вы уже дважды в комментариях призывали голосовать за свою статью, открыто нарушая этикет Хабра. А в этом сообщении еще и на личности перешли. Предположим, что Gordon01 неправ, первым перешел на личности и начал раздувать флейм в комментариях. Но это не повод тоже переходить на личности. Он тут просто гость с отрицательной кармой. А Вы все же автор статьи.
Без обид только пожалуйста. Я описал исключительно свое субъективное восприятие ситуации. Никого не обвиняю.
Один раз внутри bcp — неизбежность. Но зачем лишний раз гонять их на веб-сервер?
У нас три хоста: веб-сервер, MS SQL сервер и PostgreSQL сервер. Инициатор операции веб-сервер.
В моем примере, веб-сервер общатеся только с MS SQL. Код опубликован в статье.
Что же происходит в Вашем примере я не пойму, а код Вы не предоставляете.
То, что INSERT на удаленный сервер всегда медленнный. INSERT… SELECT на удаленный сервер не передать, а INSERT… VALUES ограничен по количеству вставляемых строк.
Иными словами, вставку строк через FDW или Linked Server лучше избегать. А если уж приперло — инкапсулировать данные в JSON/XML и вливать их по RPC.
Вряд ли. Не та целевая аудитория. Вот когда начнут сериалы снимать о том, как доблестная полиция чудом успела спасти ребенка от педофила или предотвратить теракт только благодаря тому, что удалось расшифровать переписку — это будет обозначать подготовку.
Тут срабатывает лавинный эффект. Достаточно незначительному количеству людей принципиально использовать только защищенные методы связи, желающие связаться с ними станут тоже переходить на эти методы.
Так же свободная лицензия и наличие поддержки защищенного стандарта SIP позволяет легко интегрировать тот же Jami с корпоративными средствами связи. С CommuniGate Pro и Asterisk Jami отлично дружит.
Не понимаю.
Вы что, предлагаете вместо использования ramfs, как у меня, дважды гонять эти несколько гигабайт по сети? Или наоборот, из C# на IIS по SSH ходить на сервер, где хостится PostgreSQL под выделенным для этих целей аккаунтом? В чем тогда профит и как управлять правами?
Приведите все же полностью код решения, чтобы можно было запустить его и убедиться, что Ваш вариант более производительный. Прямо по пунктам:
Мне жаль, что я не сумел донести до всех читателей, что статья не об открытии, а о самом производительном способе решения вполне типовой задачи.
А как обойтись без Linked Server я не понял. Кто «все эти команды» запустит при нажатии кнопки в вебформе, кто создаст в этом случае глобальную временную таблицу и как он узнает, что таблица уже заполнена?
Можно без словесных описаний. Просто приведите пример кода, выполняющего ровно ту же задачу, как у меня.
Есть проприетарный драйвер от DevArt. Однако, кроме стоимости, есть два «но».
Во-первых, у меня сейчас нет достаточно мощного сервера, чтобы с этим драйвером поиграться.
Во-вторых, не нравится мне сочетание Open Source с проприетарным blob. В любой момент это может вылезти боком. Например, захочу на PostgreSQL 13 перейти на зоне разработки, а он его до сих пор не поддерживает.
А это уже странно. Если не пытаться тянуть из Linked Server данные запросом напрямую, что явно не рекомендуется, а использовать RPC (EXEC (...) AT ...), как в моем первом примере, то выигрыш меньше 20% (12328 ms против 14793 ms).
что у вас DSN=pg_sql_server?
ODBC PostgreSQL Unicode(x64) 12.02.00.00
BCP всегда все обгоняет
Не совсем. Все же данные, вместо того чтобы напрямую попасть с сервера на сервер еще приходится сначала преобразовать в текстовый вид, затем записать в файл (пусть даже и на ramfs), запустить BCP, прочитать из файла и распарсить.
С обычными постоянными таблицами то все понятно. Но в случае временных или нелогируемых таблиц — все вовсе не однозначно.
SET STATISTICS TIME ON
DECLARE
@sql_str nvarchar(max)
DROP TABLE IF EXISTS #t
CREATE TABLE #t (
N int,
T datetime
)
SELECT @sql_str='
SELECT N, T
FROM generate_series(1,1000,1) N
CROSS JOIN generate_series($$2020-01-01$$::timestamp,
$$2020-12-31$$::timestamp,$$1 day$$::interval) T'
SELECT @sql_str='
INSERT #t (N, T)
SELECT N, T
FROM OPENROWSET(''MSDASQL'', ''DSN=pg_sql_server'', '''
+@sql_str+''') AS O'
EXEC (@sql_str)
SQL Server Execution Times:
CPU time = 5500 ms, elapsed time = 12328 ms.
Не утрируйте. Автомобиль есть в двух третях домовладений РФ. Если вычесть одиноких пенсионеров, алкоголиков и студенческие семьи, то получится, что личного автомобиля нет только у того, кто сам этого не хочет.
Вы уж простите, но сейчас даже таджики-гастарбайтеры себе автохлам покупают, варят, капиталят и на нём ездят.
Или Вы искренне считаете, что строительство железных дорог приводит к увеличению себестоимости продукции промышленного производства в государстве, так же как и повышение стоимости электроэнергии?
Порой у меня возникает подозрение, что зеленая энергетика в ЕС — дальновидный ход США. Чем дороже будет энергия в ЕС, тем конкурентней будет промышленность США.
Геотермальные электростанции можно строить на Камчатке. В Паратунке даже работает маломощная. Вот только большие мощности можно получить только ближе к Долине Гейзеров, до которой, кроме как на вертолёте, не доберешься.
SSIS медленней, чем описанный в статье способ.
Все равно в нем Вы будете делать те же шаги: экспортировать данные из PostgreSQL в текстовый файл и загружать их BULK INSERT из этого текстового файла в MS SQL. Но передавать по сети данные будете дважды (SSIS — выделенный хост).
Простите, но у меня есть все основания считать, что Вы заблуждаетесь.
При этом, Вы имеете полное право опубликовать здесь код Вашего решения, сравнить время выполнения Вашего и моего кода и разбить меня в пух и прах.
Если же Вы предлагаете менее производительное, но универсальное решение, то, простите, первый код в статье справляется с задачей намного более универсальным путем, чем Ваш. Только медленно. И статья вовсе не об универсальности, а о достижении максимальной производительности.
Даже если на стороне PostgreSQL сжать в GZIP xml длиной больше 4ГБ (а это можно сделать), то как Вы его на стороне MS SQL распакуете, если DECOMPRESS() возвращает varbinary(max), длина которого лимитирована 2ГБ?
Без обид только пожалуйста. Я описал исключительно свое субъективное восприятие ситуации. Никого не обвиняю.
У нас три хоста: веб-сервер, MS SQL сервер и PostgreSQL сервер. Инициатор операции веб-сервер.
В моем примере, веб-сервер общатеся только с MS SQL. Код опубликован в статье.
Что же происходит в Вашем примере я не пойму, а код Вы не предоставляете.
Иными словами, вставку строк через FDW или Linked Server лучше избегать. А если уж приперло — инкапсулировать данные в JSON/XML и вливать их по RPC.
Так же свободная лицензия и наличие поддержки защищенного стандарта SIP позволяет легко интегрировать тот же Jami с корпоративными средствами связи. С CommuniGate Pro и Asterisk Jami отлично дружит.
Вы что, предлагаете вместо использования ramfs, как у меня, дважды гонять эти несколько гигабайт по сети? Или наоборот, из C# на IIS по SSH ходить на сервер, где хостится PostgreSQL под выделенным для этих целей аккаунтом? В чем тогда профит и как управлять правами?
Приведите все же полностью код решения, чтобы можно было запустить его и убедиться, что Ваш вариант более производительный. Прямо по пунктам:
А как обойтись без Linked Server я не понял. Кто «все эти команды» запустит при нажатии кнопки в вебформе, кто создаст в этом случае глобальную временную таблицу и как он узнает, что таблица уже заполнена?
Можно без словесных описаний. Просто приведите пример кода, выполняющего ровно ту же задачу, как у меня.
Во-первых, у меня сейчас нет достаточно мощного сервера, чтобы с этим драйвером поиграться.
Во-вторых, не нравится мне сочетание Open Source с проприетарным blob. В любой момент это может вылезти боком. Например, захочу на PostgreSQL 13 перейти на зоне разработки, а он его до сих пор не поддерживает.
А это уже странно. Если не пытаться тянуть из Linked Server данные запросом напрямую, что явно не рекомендуется, а использовать RPC (EXEC (...) AT ...), как в моем первом примере, то выигрыш меньше 20% (12328 ms против 14793 ms).
ODBC PostgreSQL Unicode(x64) 12.02.00.00
Не совсем. Все же данные, вместо того чтобы напрямую попасть с сервера на сервер еще приходится сначала преобразовать в текстовый вид, затем записать в файл (пусть даже и на ramfs), запустить BCP, прочитать из файла и распарсить.
С обычными постоянными таблицами то все понятно. Но в случае временных или нелогируемых таблиц — все вовсе не однозначно.
SQL Server Execution Times:
CPU time = 5500 ms, elapsed time = 12328 ms.
Это против 881 ms через BCP выше.
Вы уж простите, но сейчас даже таджики-гастарбайтеры себе автохлам покупают, варят, капиталят и на нём ездят.