С электромобилями все тоже не просто. Уже не раз всплывала информация, что по выбросам CO2 электромобили хоть и лучше бензиновых автомобилей, но находятся на уровне дизельных и проигрывают гибридам. Исключительно из-за технологии производства литиевых АКБ и незначительном сроке их службы.
Второй вопрос — отопление. Вы ради интереса посчитайте, во сколько Вам обойдется отопление, если отапливаться электричеством. Особенно, если речь о северных районах вдали от ГЭС. Вроде Мурманска, Архангельска, Магадана, Чукотки или Камчатки.
Сравнил. В 8.5 раз медленней через dtexec, чем через ramfs и BCP. Вы тут такой троллинг развели, что уже выхода не было, пришлось статью править. Троллинг потому, что сами проверить свои теоретические умозаключения Вы почему-то не смогли или не захотели.
промышленность платит намного меньше, что в России
Москва, население, даже по максимальному одноставочному тарифу 5,66
Юридические лица за низкое напряжение — 6.00
Высокое напряжение — отдельная тема и дополнительные затраты, включая и капитальные, и ФОТ обслуживающего персонала.
Какие ГЭС? Основными источниками электроэнергии являются Калининская, Смоленская, Курская и Нововоронежская АЭС. Значительный вклад дает Костромская ГРЭС и московские ТЭЦ. Ну и в районе 20-30% поступает уже с ГЭС.
Комбинаты строят у городов, а не ГЭС. Потому что на них работать кто-то должен. Откройте список алюминиевых комбинатов РФ и убедитесь, что значительная их часть вовсе не рядом с ГЭС. Откуда ГЭС в Кандалакше, Питере, Екатеринбурге или Владивостоке?
Чтобы тролли не смущали читателей, увеличил количество записей в 100 раз, увеличил длину строки на одно текстовое поле и добавил результат замера того, что через dtexec скорость в 8.5 раз ниже, чем через BCP.
Именно. Хотя могли начать готовить еще в 1985. Итого, проекту ITER 35 лет, а какая-либо активность была в течении менее 10 лет. Всего стоимость ITER оценивается в $19 млрд. Начальная стоимость была $5 млрд., но 35 лет зарплату и перемии сотрудники получали. Для сравнения, стоимость МКС — $150 млрд. и собиралась всего 12 лет. Если приравнять время=деньги, то ITER тогда можно было бы построить за 3-4 года.
ЗЯТЦ реализовать то и на десятки тысячелетий
Вы где собрались столько урана-235 добывать? На Марсе что ли?
Или Вас ввело заблуждение слово «замкнутый»? Ну так эта замкнутость снижает потребность в уране-235, но никак не исключает ее.
рынок с сотнями миллиардов долларов на кону
Рынок процессоров, но вовсе не 7нм на кремнии. Я же писал выше, что на этом рынке, в перспективе, можно конкурировать далеко не только на кремнии. И большой вопрос, что выгодней — догонять уже освоенные технологии США или разрабатывать свои технологии, более наукоемкие, но более перспективные.
Проект начал разрабатываться еще в 1985 году. Соглашение на строительство ITER было подписано 1992 году. Только в 2001 году был утвержден проект. Место было выделено в 2005 году. Строительство началось в 2010 году. А сборка — только в 2020.
Иными словами, если бы соглашение было бы подписано еще в 80-х, сразу же были бы выделены деньги на проект и площадка, то проектирование завершили бы еще до конца 80-х. А к 2000 году строительство было бы уже завершено. К 2010 году запустили бы DEMO. А сейчас, в 2020, на основании DEMO строили бы уже целую сеть рекаторов. Только США недофинансировали ITER на половину. Россия затянула все сроки в несколько раз.
Про остальные проекты то не надо. Они дальше теорий до сих пор не продвинулись. А положительный баланс термоядерной реакции уже достигнут.
А ядерная энергетика способна только продлить себе жизнь, уменьшая расход урана 235. Отказаться от него нереально, а запасы его невелики.
Странная цель
Нормальная реальная цель. С чего Вы решили что суперкомпьютеры в Китае строились просто так, а не под определенные задачи? Пруф?
А вот Ваши 7нм — самоцель. Сами по себе они ничего не дают. Кроме очередных 8K на шестидюймовом экране смартфона, которые все равно без лупы не отличить от FullHD.
Нашел исходник SqlBulkCopy. Да, там INSERT BULK.
Но принципиально это ничего не меняет.
Как только Вы попробуете взять данные из PostgreSQL не COPY в текстовый файл, сразу же нарветесь на ту же самую проблему, с которой начиналась статья. А именно с тормозного родного ODBC.
Может, конечно, в вашем мире большие данные — это 366K записей по 12 байт, что еле-еле переваливает за 4М.
Давайте закончим. Вы вообще не читаете то, что я пишу:
На данный момент в один присест передается не более 10 миллионов записей. Примерно по килобайту в текстовом представлении. Судя по тому, что я вижу:
KiB Mem: 26397264+total, 10538076 free, 70718568 used, 18271600+buff/cache
KiB Swap: 16777212 total, 16496636 free, 280576 used. 19215897+avail Mem
Где там в вашей статьей, что dtexec нельзя использовать как простую CLI как и bcp, дав ей те же реквизиты и tempdb, как и bcp, потому что…
Давать права пользователю, кредентиалы которого открытым текстом видны в SQL запросе, на таблицы своей БД совершенно не хочется. Тем более на запись. Поэтому остается только вариант с глобальной временной таблицей.
Принципиальной разницы между «в SQL запросе» или «в командной строке» я не вижу.
Что толку от dtexec, если он может только писать и только в tempdb? Уже не знаю который раз говорю: не поддерживается в нем Kerberos под Linux от слова совсем!
Пусть даже BCP, как «external tools» используется INSERT BULK. Все равно непонятно, что это в итоге меняет?
При любом раскладе, SSIS нужно данные с PostgreSQL как-то получить. В родном для PostgreSQL бинарном виде он тоже с ними ничего не сделает. Все равно предварительно драйвером будет выполнено преобразование в какой-то промежуточный формат. Даже если он данные засосет только в память, без создания временного файла, в любом случае, этот процесс будет медленней, чем когда PostgreSQL локально командой COPY пишет данные в ramfs. Так как на этом этапе вообще нет никакой сетевой активности. Исключительно пересылка память-память.
А раз мы начали с того, что BCP так же использует INSERT BULK, то на этом этапе разницы не заметим. Он так же локально из памяти (ramfs) возьмет исходные данные и перепакует их в двоичный поток.
Вы заголовок статьи хотя бы читали? Источник — PostgreSQL. Как он Вам данные в бинарном потоке для MS SQL предоставит?
Или Вы даже не читали статью по Вашей же ссылке?
BULK
Applies to: SQL Server 2008 and later.
Used by external tools to upload a binary data stream. This option is not intended for use with tools such as SQL Server Management Studio, SQLCMD, OSQL, or data access application programming interfaces such as SQL Server Native Client.
To use the Bulk Insert task to transfer data from other database management systems (DBMSs), you must export the data from the source to a text file and then import the data from the text file into a SQL Server table or view.
Запас у меня больше, чем на порядок. При меньшем запасе переключился бы с ramfs на tmpfs. Разница в их производительности — 1-2%. Несущественно.
То есть он у вас для «продуктивного использования подошёл», а к другой консольной утилите повышенные требования?
Да. Это подробно было описано в статье. Невнимательно читали. Используемый SQL Server аккаунт не имеет доступа ни к одной БД, кроме tempdb. Понятно, что с такими ограничениями SSIS вообще смысла не имеет.
Там где ваше решение упадёт, это продолжить работать.
С чего Вы решили, что оно упадет? bcp под Linux замечательно UTF-8 кушает.
я нигде не говорил, что bcp медленнее чем insert into ...select from
он быстрее.
я говорил что решение c xml/json блобом будет быстрее.
Вы не видите противоречия в своих же словах? Сначала вы говорите, что BCP быстрее, чем INSERT INTO… SELECT… FROM…, после чего сразу же говорите, что INSERT INTO… SELECT… FROM OPENJSON(...)/OPENXML(...) — вдруг быстрее BULK INSERT.
bcp дает полуфабрикат
Сам BCP действительно дает полуфабрикат. Но в описаном статье примере данные для BCP готовятся запросом в PostgreSQL, что дает уже целостное решение. Какая разница на какой стороне выполнять трансформацию данных?
Контрпример. Попробуйте источник OPENXML() из хотя бы миллиона записей указать в качестве USING в MERGE к таблице из десяти миллионов записей. Сразу заскучаете.
И в любом случае, хоть с JSON, хоть с XML, имеет всегда существенно больший размер, чем текстовый файл BCP. Следовательно, только на передаче по сети Вы проиграете.
как Вы его на стороне MS SQL распакуете, если DECOMPRESS() возвращает varbinary(max), длина которого лимитирована 2ГБ?
и на гзипе ничего там не «умрет»
Вы сильно уменьшили доверие ко всем Вашим утверждениям:
wget -c https://fias-file.nalog.ru/downloads/2021.04.16/fias_xml.zip
7za x fias_xml.zip
gzip AS_SOCRBASE_20210416_fda8d4a2-06ce-4c55-b751-c5b4dd7e7e70.XML
gzip AS_STEAD_20210416_5c40a3e2-887a-4025-a83c-cbe85b7f8e5b.XML
DROP TABLE IF EXISTS #t
CREATE TABLE #t (n int, b varbinary(max))
INSERT INTO #t (n, b)
SELECT 1, * FROM OPENROWSET(BULK N'X:\Temp\AS_SOCRBASE_20210416_fda8d4a2-06ce-4c55-b751-c5b4dd7e7e70.XML.gz', SINGLE_BLOB) rs
INSERT INTO #t (n, b)
SELECT 2, * FROM OPENROWSET(BULK N'X:\Temp\AS_STEAD_20210416_5c40a3e2-887a-4025-a83c-cbe85b7f8e5b.XML.gz', SINGLE_BLOB) rs
DECLARE @x1 xml
SELECT @x1=CONVERT(xml,DECOMPRESS(b))
FROM #t
WHERE n=1
DECLARE @x2 xml
SELECT @x2=CONVERT(xml,DECOMPRESS(b))
FROM #t
WHERE n=2
SQL Error [6365] [S0001]: An XML operation resulted an XML data type exceeding 2GB in size. Operation aborted.
Это не считая того, что использование GZIP снизило производительность на порядок.
Это говорит о том, что это лишь обертка над BULK INSERT. Естественно, ничто не мешает классу использовать временные файлы для того, чтобы сначала из любого источника в этот файл данные записать, а потом, при помощи BULK INSERT эти данные вставить.
Но при этом, хоть в лоб, хоть по лбю, временный файл точно медленней, чем ramfs, где данные просто остаются в памяти (кеше) до тех пор, пока файл не будет удален.
Не верите — просто включите профайлер на SQL Server и убедитесь.
А регулярно платить все больше и больше за электроэнергию хочется?
Просто «зеленая энергетика» позволяет, благодаря дотациям, окупать инвестиции буквально за год-другой. А инвестиции в термоядерную энергетику окупятся через 10-20 лет. На мой взгляд, это единственная причина столь медленного развития термоядерного управляемого синтеза.
Критический путь к чему?
К цели. Я же указал:
для примера, доминирование Китая в TOP-500 суперкомпьютеров.
Не подменяйте тезисы, пожалуйста. Передача данных между SQL серверами всегда подразумевает так же шаг вставки этих данных. Ключевая фраза — быстрее всего.
bulk copy
Нет такой команды в MS SQL. Класс SqlBulkCopy использует тот же самый BULK INSERT и более производительной возможности MS SQL Server не предоставляет.
Или Вы искреннее считаете, что класс SqlBulkCopy использует при общении с SQL сервером какие-то секретные недокументированные возможности?
Никаких секретных возможностей. BCP не более чем обертка над SQL командой BULK INSERT и именно так я его и использую. Но только без использования диска (даже ram disk). Только через кеш, благодаря ramfs.
Я утверждаю только, что если SSIS или еще что-то использует BULK LOAD, то без файла ему не обойтись.
Где вы там увидели, что COPY — это в чём-то быстрее чем обычный Sequential scan SELECTа?
COPY вообще никаких данных не передает клиенту, а SELECT — передает. При любых раскладах передача данных через TCP/IP будет медленней, чем запись в кеш, где данные и останутся при использовании ramfs, вплоть до удаления файла.
В качестве референса, ваш EXEC с прилинкованной таблицей (тот который исполнялся CPU time = 8187 ms, elapsed time = 14793 ms) у меня даёт CPU time = 11343 ms, elapsed time = 16634 ms. То есть в целом сетап виртуалки медленнее, работает с IO на обоих концах, но делает это быстрее чем ваш вариант.
Зачем брать в качестве референса пример, который не устраивал? В решении было CPU time = 0 ms, elapsed time = 881 ms.
Почему для сравнения Вы берете вообще неизвестно какую таблицу с неизвестным количеством строк, а не пример из статьи? Что с чем сравниваете?
Elapsed: 2.328 seconds
Это в разы медленней, чем 881 ms.
какой-то экспериментальный билд
Вы невнимательно читаете, то что Вам пишет оппонент.
Слишком много ограничений для продуктивного использования.
Сами почитайте.
Ни Kerberos авторизации, ни сторонних компонентов, ни каталога.
Просто модифицируйте свой код на C# так, чтобы он выполнял ровно ту же задачу, что описана в статье. Тогда сразу увидите, что он медленней варианта, предложенного в решении.
Естественно. Уже на сотнях тысяч записей он в разы быстрее любой другой альтернативы.
И не надо никаких текстовых файлов.
BULK INSERT физически не может быть не из файла. Просто по его определению.
Поймите простую вещь. Никакие сервисы или классы все равно не могут использовать какие-то секретные SQL команды. Они при общении с SQL сервером так же ограничены только теми командами, которые доступны пользователю при прямом общении с SQL сервером. И если в их реализации использование временного файла скрыто от пользователя, из этого совершенно не следует, что он не используется.
– Видишь суслика?
– Нет.
– Вот и я не вижу. А он есть.
Второй вопрос — отопление. Вы ради интереса посчитайте, во сколько Вам обойдется отопление, если отапливаться электричеством. Особенно, если речь о северных районах вдали от ГЭС. Вроде Мурманска, Архангельска, Магадана, Чукотки или Камчатки.
Москва, население, даже по максимальному одноставочному тарифу 5,66
Юридические лица за низкое напряжение — 6.00
Высокое напряжение — отдельная тема и дополнительные затраты, включая и капитальные, и ФОТ обслуживающего персонала.
Комбинаты строят у городов, а не ГЭС. Потому что на них работать кто-то должен. Откройте список алюминиевых комбинатов РФ и убедитесь, что значительная их часть вовсе не рядом с ГЭС. Откуда ГЭС в Кандалакше, Питере, Екатеринбурге или Владивостоке?
Именно. Хотя могли начать готовить еще в 1985. Итого, проекту ITER 35 лет, а какая-либо активность была в течении менее 10 лет. Всего стоимость ITER оценивается в $19 млрд. Начальная стоимость была $5 млрд., но 35 лет зарплату и перемии сотрудники получали. Для сравнения, стоимость МКС — $150 млрд. и собиралась всего 12 лет. Если приравнять время=деньги, то ITER тогда можно было бы построить за 3-4 года.
Вы где собрались столько урана-235 добывать? На Марсе что ли?
Или Вас ввело заблуждение слово «замкнутый»? Ну так эта замкнутость снижает потребность в уране-235, но никак не исключает ее.
Рынок процессоров, но вовсе не 7нм на кремнии. Я же писал выше, что на этом рынке, в перспективе, можно конкурировать далеко не только на кремнии. И большой вопрос, что выгодней — догонять уже освоенные технологии США или разрабатывать свои технологии, более наукоемкие, но более перспективные.
Нет ссылки — нет и веры Вашим словам. Я без пруфов не верю.
И это повод тратить кучу памяти на два TCP сокета, вместо того, чтобы использовать tftp по UDP? Вы сами себе противоречите.
Опять ссылки нет, потому что никто ее не опубликовал?
С снова ни одного материала в сети?
Вот чудеса то!
Иными словами, если бы соглашение было бы подписано еще в 80-х, сразу же были бы выделены деньги на проект и площадка, то проектирование завершили бы еще до конца 80-х. А к 2000 году строительство было бы уже завершено. К 2010 году запустили бы DEMO. А сейчас, в 2020, на основании DEMO строили бы уже целую сеть рекаторов. Только США недофинансировали ITER на половину. Россия затянула все сроки в несколько раз.
Про остальные проекты то не надо. Они дальше теорий до сих пор не продвинулись. А положительный баланс термоядерной реакции уже достигнут.
А ядерная энергетика способна только продлить себе жизнь, уменьшая расход урана 235. Отказаться от него нереально, а запасы его невелики.
Нормальная реальная цель. С чего Вы решили что суперкомпьютеры в Китае строились просто так, а не под определенные задачи? Пруф?
А вот Ваши 7нм — самоцель. Сами по себе они ничего не дают. Кроме очередных 8K на шестидюймовом экране смартфона, которые все равно без лупы не отличить от FullHD.
Но принципиально это ничего не меняет.
Как только Вы попробуете взять данные из PostgreSQL не COPY в текстовый файл, сразу же нарветесь на ту же самую проблему, с которой начиналась статья. А именно с тормозного родного ODBC.
Давайте закончим. Вы вообще не читаете то, что я пишу:
Принципиальной разницы между «в SQL запросе» или «в командной строке» я не вижу.
Что толку от dtexec, если он может только писать и только в tempdb? Уже не знаю который раз говорю: не поддерживается в нем Kerberos под Linux от слова совсем!
При любом раскладе, SSIS нужно данные с PostgreSQL как-то получить. В родном для PostgreSQL бинарном виде он тоже с ними ничего не сделает. Все равно предварительно драйвером будет выполнено преобразование в какой-то промежуточный формат. Даже если он данные засосет только в память, без создания временного файла, в любом случае, этот процесс будет медленней, чем когда PostgreSQL локально командой COPY пишет данные в ramfs. Так как на этом этапе вообще нет никакой сетевой активности. Исключительно пересылка память-память.
А раз мы начали с того, что BCP так же использует INSERT BULK, то на этом этапе разницы не заметим. Он так же локально из памяти (ramfs) возьмет исходные данные и перепакует их в двоичный поток.
Вы заголовок статьи хотя бы читали? Источник — PostgreSQL. Как он Вам данные в бинарном потоке для MS SQL предоставит?
Или Вы даже не читали статью по Вашей же ссылке?
Перечитайте внимательно статью:
В Вашем случае при вызове SqlBulkCopy? Ну тогда Вы вообще не понимаете, как он работает. Почитайте внимательней то, что я писал выше.
На данный момент в один присест передается не более 10 миллионов записей. Примерно по килобайту в текстовом представлении. Судя по тому, что я вижу:
Запас у меня больше, чем на порядок. При меньшем запасе переключился бы с ramfs на tmpfs. Разница в их производительности — 1-2%. Несущественно.
Да. Это подробно было описано в статье. Невнимательно читали. Используемый SQL Server аккаунт не имеет доступа ни к одной БД, кроме tempdb. Понятно, что с такими ограничениями SSIS вообще смысла не имеет.
С чего Вы решили, что оно упадет? bcp под Linux замечательно UTF-8 кушает.
Вы не видите противоречия в своих же словах? Сначала вы говорите, что BCP быстрее, чем INSERT INTO… SELECT… FROM…, после чего сразу же говорите, что INSERT INTO… SELECT… FROM OPENJSON(...)/OPENXML(...) — вдруг быстрее BULK INSERT.
Сам BCP действительно дает полуфабрикат. Но в описаном статье примере данные для BCP готовятся запросом в PostgreSQL, что дает уже целостное решение. Какая разница на какой стороне выполнять трансформацию данных?
Контрпример. Попробуйте источник OPENXML() из хотя бы миллиона записей указать в качестве USING в MERGE к таблице из десяти миллионов записей. Сразу заскучаете.
И в любом случае, хоть с JSON, хоть с XML, имеет всегда существенно больший размер, чем текстовый файл BCP. Следовательно, только на передаче по сети Вы проиграете.
Вы сильно уменьшили доверие ко всем Вашим утверждениям:
wget -c https://fias-file.nalog.ru/downloads/2021.04.16/fias_xml.zip7za x fias_xml.zip
gzip AS_SOCRBASE_20210416_fda8d4a2-06ce-4c55-b751-c5b4dd7e7e70.XML
gzip AS_STEAD_20210416_5c40a3e2-887a-4025-a83c-cbe85b7f8e5b.XML
SQL Error [6365] [S0001]: An XML operation resulted an XML data type exceeding 2GB in size. Operation aborted.Это не считая того, что использование GZIP снизило производительность на порядок.
Это говорит о том, что это лишь обертка над BULK INSERT. Естественно, ничто не мешает классу использовать временные файлы для того, чтобы сначала из любого источника в этот файл данные записать, а потом, при помощи BULK INSERT эти данные вставить.
Но при этом, хоть в лоб, хоть по лбю, временный файл точно медленней, чем ramfs, где данные просто остаются в памяти (кеше) до тех пор, пока файл не будет удален.
Не верите — просто включите профайлер на SQL Server и убедитесь.
Просто «зеленая энергетика» позволяет, благодаря дотациям, окупать инвестиции буквально за год-другой. А инвестиции в термоядерную энергетику окупятся через 10-20 лет. На мой взгляд, это единственная причина столь медленного развития термоядерного управляемого синтеза.
К цели. Я же указал:
Нет такой команды в MS SQL. Класс SqlBulkCopy использует тот же самый BULK INSERT и более производительной возможности MS SQL Server не предоставляет.
Или Вы искреннее считаете, что класс SqlBulkCopy использует при общении с SQL сервером какие-то секретные недокументированные возможности?
Я утверждаю только, что если SSIS или еще что-то использует BULK LOAD, то без файла ему не обойтись.
COPY вообще никаких данных не передает клиенту, а SELECT — передает. При любых раскладах передача данных через TCP/IP будет медленней, чем запись в кеш, где данные и останутся при использовании ramfs, вплоть до удаления файла.
Зачем брать в качестве референса пример, который не устраивал? В решении было CPU time = 0 ms, elapsed time = 881 ms.
Почему для сравнения Вы берете вообще неизвестно какую таблицу с неизвестным количеством строк, а не пример из статьи? Что с чем сравниваете?
Это в разы медленней, чем 881 ms.
Вы невнимательно читаете, то что Вам пишет оппонент.
Сами почитайте.
Ни Kerberos авторизации, ни сторонних компонентов, ни каталога.
Просто модифицируйте свой код на C# так, чтобы он выполнял ровно ту же задачу, что описана в статье. Тогда сразу увидите, что он медленней варианта, предложенного в решении.
BULK INSERT физически не может быть не из файла. Просто по его определению.
Поймите простую вещь. Никакие сервисы или классы все равно не могут использовать какие-то секретные SQL команды. Они при общении с SQL сервером так же ограничены только теми командами, которые доступны пользователю при прямом общении с SQL сервером. И если в их реализации использование временного файла скрыто от пользователя, из этого совершенно не следует, что он не используется.