Вы действительно думаете, что создание 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.
Не утрируйте. Автомобиль есть в двух третях домовладений РФ. Если вычесть одиноких пенсионеров, алкоголиков и студенческие семьи, то получится, что личного автомобиля нет только у того, кто сам этого не хочет.
Вы уж простите, но сейчас даже таджики-гастарбайтеры себе автохлам покупают, варят, капиталят и на нём ездят.
С каких пор ARIMA перестала быть самообучающейся? Это одна из самых распостраненных моделей ML.
Я как раз наоборот, уже давно говорю именно о динамике, прогнозировании потока ТС и работе светофора на упреждение.
А Вы до сих пор не предоставили график кроссвалидации точности прогнозирования используемой нейросети хотя бы за час работы светофора.
Точно не быстрее, а медленней. Можете убедиться сами.
Во-первых, я уверен, что время формирования и парсинга XML всегда будет дольше времени формирования и парсинга текстового формата BCP. Хотя бы потому, что первый всегда больше второго.
Во-вторых, я уверен, что INSERT INTO всегда работает медленней, чем BULK INSERT
В-третьих, я уверен, что XML в БД не может быть больше 4ГБ ни при каких условиях. Что приводит и к усложнению кода, и к потере производительности.
В-четвертых, если уж таким путем идти, то JSON явно меньше размером., чем XML. Именно поэтому, если у меня есть гарантии, что объем JSON получится меньше гигабайта — его и использую. Но в рассматриваемой в статье ситуации объем точно может превышать 4 ГБ.
Во-первых, я не понял, с каких пор Bucardo стал поддерживать репликацию между MS SQL и PostgreSQL. Можете ссылочку дать?
Во-вторых, не понял смысл хранимки. BULK INSERT может быть только из файла. А остальные варианты вставки строк в MS SQL всегда медленней, чем BULK INSERT.
Простите, но у меня есть все основания считать, что Вы заблуждаетесь.
При этом, Вы имеете полное право опубликовать здесь код Вашего решения, сравнить время выполнения Вашего и моего кода и разбить меня в пух и прах.
Если же Вы предлагаете менее производительное, но универсальное решение, то, простите, первый код в статье справляется с задачей намного более универсальным путем, чем Ваш. Только медленно. И статья вовсе не об универсальности, а о достижении максимальной производительности.
Даже если на стороне 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 выше.
Вы уж простите, но сейчас даже таджики-гастарбайтеры себе автохлам покупают, варят, капиталят и на нём ездят.
Зависит от того, сколько раз этот код вызывается для получения конечного результата. Если миллионы раз — очень важно.
Я как раз наоборот, уже давно говорю именно о динамике, прогнозировании потока ТС и работе светофора на упреждение.
А Вы до сих пор не предоставили график кроссвалидации точности прогнозирования используемой нейросети хотя бы за час работы светофора.
Во-первых, я уверен, что время формирования и парсинга XML всегда будет дольше времени формирования и парсинга текстового формата BCP. Хотя бы потому, что первый всегда больше второго.
Во-вторых, я уверен, что INSERT INTO всегда работает медленней, чем BULK INSERT
В-третьих, я уверен, что XML в БД не может быть больше 4ГБ ни при каких условиях. Что приводит и к усложнению кода, и к потере производительности.
В-четвертых, если уж таким путем идти, то JSON явно меньше размером., чем XML. Именно поэтому, если у меня есть гарантии, что объем JSON получится меньше гигабайта — его и использую. Но в рассматриваемой в статье ситуации объем точно может превышать 4 ГБ.
Во-вторых, не понял смысл хранимки. BULK INSERT может быть только из файла. А остальные варианты вставки строк в MS SQL всегда медленней, чем BULK INSERT.
Можете погуглить. Это неоднократно обсуждалось.