Т.е. базовый тест - 58 сек, с параметром OPTIMIZE_FOR_SEQUENTIAL_KEY = ON 55.6 сек, первичный ключ с некластерным индексом - 57.6 сек, таблицы, оптимизированные для памяти - 32.7 сек. Т.е. прирост производительности такой себе... Мы избавились от PAGELATCH_EX, но никакой выгоды не получили. А зачем избавлялись-то? Можно сказать, что таблицы, оптимизированные для памяти ещё какой-то выход. Но если у вас на сервере, допустим 128 Гб RAM, а таблица, которую надо оптимизировать, где-то 500 Гб, то как-то оно, знаете, не то получается...
Да любое количество индексов. С каждой новой версией этот функционал расширялся. Начиная с SQL Server 2016 (более старой версии нет в наличии) этот код работает
DECLARE @t TABLE
(c1 int INDEX IX_c1,
c2 int INDEX IX_c2,
c3 int INDEX IX_c3,
INDEX IX_c1_c2_c3 (c1, c2, c3)
);
На сегогдняшний день все более-менее продвинутые СУБД поддерживают большинство типов хранения данных. Например, MS SQL Server. На сегодняшний день она и реляционная, и колоночная, и графовая. Ну, ключ-значение даже не обсуждается. А поддержка XML и JSON вполне позволяет отнести её и к документо-ориентированным. Не упомянута и Cosmos DB, которая поддерживает API всех 5 типов.
Удалось обнаружить корреляцию между показателями fillfactor и LOGMGR_QUEUE
И как сильно влияет ожидание LOGMGR_QUEUE на производительность вашей системы?
https://www.sqlskills.com/help/waits/logmgr_queue/ This wait type is when the log writer thread (or one of the log writer threads, on 2016+) is waiting for something to do (either log to flush or a write to complete).
According to Microsoft documentation, this wait type occurs when a task is waiting for any outstanding log I/Os to finish. If you see this wait type you should not be worried because it indicates that the log writer is waiting to be invoked by a session or the checkpoint process. In other words, it is telling you that there is no current log activity. It’s most unlikely to see this wait type on user sessions because the log writer is a background process.
Пример у нас база на 5GB, хостится на сервере с 128GB RAM
У нас 5 TB на сервере с 128GB RAM — так что без "оверинжениринга" никак. И там не доли процента из производительности индекса. Так что без ребилдинга не обойтись.
В-о-о-т!!! Очень верно сказано. Например, не "Функциональное ядро в виде конвейера на Python", а "Реализация конвейера на Python в функциональном стиле".
В общем понимании ядро — это то, вокруг чего строится или функционирует всё остальное — как в атоме, клетке или программе.
А несведущий человек из названия статьи может решить, что вся работа Python основывается на "функциональном ядре в виде конвейера".
А зачем вы добавили этот и предыдущий посты в хабы F# и Clojure? Из-за одного примера конвейера на F#? Думаю, не стоит засорять хабы материалом, не имеющим к их темам отношения.
Хм. Теперь немного лучше — "Функциональное ядро в виде конвейера на Python".
Хочу спросить — а в каком ещё виде встречаются функциональные ядра, кроме как в виде конвейера?
И какие ещё бывают ядра? Подозреваю, объектно-ориентированные и императивные.
Пушечные и клеточные не предлагать.
Но в качестве плюса хочу отметить нормальное форматирование кода, без этих ужасных номеров строк.
Microsoft SQL Server includes a popular command-line utility named bcp for quickly bulk copying large files into tables or views in SQL Server databases. The SqlBulkCopy class allows you to write managed code solutions that provide similar functionality. There are other ways to load data into a SQL Server table (INSERT statements, for example) but SqlBulkCopy offers a significant performance advantage over them.
The SqlBulkCopy class can be used to write data only to SQL Server tables. But the data source is not limited to SQL Server; any data source can be used, as long as the data can be loaded to a DataTable instance or read with a IDataReader instance.
— т.е. если вы почему-то хотите использовать именно Bulk Insert Task, а не какой-то другой компонент.
А если вы хотите использовать Data Flow Task, то в качестве назначения вы можете использовать:
Я не знаю внутренней организации Data Flow Task в SSIS, но здесь и здесь о промежуточной загрузке в текстовый файл ничего не говорится, заливка данных идёт из таблицы в таблицу.
А можно писать как-то покороче, используя командлеты Powershell, а не библиотеки .Net?
Например,
$webClient = New-Object Net.WebClient
$webClient.UseDefaultCredentials = $true
$webClient.Proxy.Credentials = $webClient.Credentials
$webClient.Headers.Add("user-agent", "PowerShell automated task")
# Подозреваю, что из-за того, что данные передаются без BOM, то получение данных
# через DownloadString с последующим выводом выдаст на экран кракозябры.
# Поэтому в явном виде преобразуем в UTF8
$newsData = $webClient.DownloadData("https://news.webits.1c.ru/news/Updates/atom")
Write-Host ([System.Text.Encoding]::UTF8).GetString($newsData)
Во-вторых, даже тестовая задача должна иметь какой-то смысл.
Удалить из полного пути папки символы 'd', 'e', 'f', 'l', 'o', 'r' — не представляю, где это может пригодиться.
Напомню, метод Trim(Char[]) удаляет все начальные и конечные вхождения набора символов, указанного в массиве, из текущей строки.
В-третьих, в F# это выглядит так же красиво без всяких мутабельных переменных
let path = @"C:\users\test\folder"
let myTrim (str: string) =
str.Trim((str.Split('\\') |> Array.last).ToCharArray())
myTrim path
А System.IO.Path.DirectorySeparatorChar можно и в Powershell вставить
Т.е. базовый тест - 58 сек, с параметром OPTIMIZE_FOR_SEQUENTIAL_KEY = ON 55.6 сек, первичный ключ с некластерным индексом - 57.6 сек, таблицы, оптимизированные для памяти - 32.7 сек. Т.е. прирост производительности такой себе...
Мы избавились от PAGELATCH_EX, но никакой выгоды не получили.
А зачем избавлялись-то?
Можно сказать, что таблицы, оптимизированные для памяти ещё какой-то выход. Но если у вас на сервере, допустим 128 Гб RAM, а таблица, которую надо оптимизировать, где-то 500 Гб, то как-то оно, знаете, не то получается...
Да любое количество индексов. С каждой новой версией этот функционал расширялся. Начиная с SQL Server 2016 (более старой версии нет в наличии) этот код работает
И опять же в MS SQL Server есть тип данных geography.
Так что разделение СУБД по типам становится всё менее и менее актуально
На сегогдняшний день все более-менее продвинутые СУБД поддерживают большинство типов хранения данных.
Например, MS SQL Server. На сегодняшний день она и реляционная, и колоночная, и графовая.
Ну, ключ-значение даже не обсуждается.
А поддержка XML и JSON вполне позволяет отнести её и к документо-ориентированным.
Не упомянута и Cosmos DB, которая поддерживает API всех 5 типов.
И как сильно влияет ожидание LOGMGR_QUEUE на производительность вашей системы?
https://www.sqlskills.com/help/waits/logmgr_queue/
This wait type is when the log writer thread (or one of the log writer threads, on 2016+) is waiting for something to do (either log to flush or a write to complete).
https://www.mssqltips.com/sqlservertip/4131/troubleshooting-sql-server-transaction-log-related-wait-types/
LOGMGR_QUEUE wait type
According to Microsoft documentation, this wait type occurs when a task is waiting for any outstanding log I/Os to finish. If you see this wait type you should not be worried because it indicates that the log writer is waiting to be invoked by a session or the checkpoint process. In other words, it is telling you that there is no current log activity. It’s most unlikely to see this wait type on user sessions because the log writer is a background process.
Например, Glenn Berry исключает его при оценке статистики ожиданий в систему
https://www.dropbox.com/s/k1vauzxxhyh1fnb/SQL%20Server%202019%20Diagnostic%20Information%20Queries.sql?dl=0 (строка 1047)
А вот дефрагментация индекса при активной вставке или обновлении не в конец индекса может повлиять.
У нас 5 TB на сервере с 128GB RAM — так что без "оверинжениринга" никак. И там не доли процента из производительности индекса. Так что без ребилдинга не обойтись.
Думаю, пользователи, посещающие F# и Clojure, наверняка заходят на Функциональное программирование. Кроме того, ещё есть Haskell, Scala, Erlang, Elm, Lisp.
Да, это правда
В-о-о-т!!! Очень верно сказано. Например, не "Функциональное ядро в виде конвейера на Python", а "Реализация конвейера на Python в функциональном стиле".
В общем понимании ядро — это то, вокруг чего строится или функционирует всё остальное — как в атоме, клетке или программе.
А несведущий человек из названия статьи может решить, что вся работа Python основывается на "функциональном ядре в виде конвейера".
А зачем вы добавили этот и предыдущий посты в хабы F# и Clojure? Из-за одного примера конвейера на F#? Думаю, не стоит засорять хабы материалом, не имеющим к их темам отношения.
Хм. Теперь немного лучше — "Функциональное ядро в виде конвейера на Python".
Хочу спросить — а в каком ещё виде встречаются функциональные ядра, кроме как в виде конвейера?
И какие ещё бывают ядра? Подозреваю, объектно-ориентированные и императивные.
Пушечные и клеточные не предлагать.
Но в качестве плюса хочу отметить нормальное форматирование кода, без этих ужасных номеров строк.
"Лес(хвойный)"(идея) не соответствует табличке при входе ("Тропические леса Амазонки").
А название статьи такое всеобъемлющее — "Функциональное ядро на Python"
Стиль изложения напоминает учебник для старших классов
Не для спора, а так, просто почитать
https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/sql/bulk-copy-operations-in-sql-server
Microsoft SQL Server includes a popular command-line utility named bcp for quickly bulk copying large files into tables or views in SQL Server databases. The SqlBulkCopy class allows you to write managed code solutions that provide similar functionality. There are other ways to load data into a SQL Server table (INSERT statements, for example) but SqlBulkCopy offers a significant performance advantage over them.
The SqlBulkCopy class can be used to write data only to SQL Server tables. But the data source is not limited to SQL Server; any data source can be used, as long as the data can be loaded to a DataTable instance or read with a IDataReader instance.
Ключевая фраза
— т.е. если вы почему-то хотите использовать именно Bulk Insert Task, а не какой-то другой компонент.А если вы хотите использовать Data Flow Task, то в качестве назначения вы можете использовать:
И не надо никаких текстовых файлов .
Мне казалось, вопросы кодирования экспорта-импорта данных давно ушли в прошлое, что есть целая куча тулзов для этого. Но я ошибался.
Поэтому задам вопрос.
А почему, например, не использовать SQL Server Integration Services?
www.cdata.com/kb/tech/postgresql-ssis-task-import-2008.rst
www.devart.com/ssis/postgresql.html
zappysys.com/blog/ssis-load-postgresql-table-data-csv-file/?gclid=Cj0KCQjwvYSEBhDjARIsAJMn0lj7HWz_EHYWouExV9OZ8uObrhrXXlL3byC154X3xtAhKsutMUgIKgQaAgMcEALw_wcB
Например, можно заменить
Во-первых, велосипед можно сделать по-красивее
Во-вторых, даже тестовая задача должна иметь какой-то смысл.
Удалить из полного пути папки символы 'd', 'e', 'f', 'l', 'o', 'r' — не представляю, где это может пригодиться.
Напомню, метод Trim(Char[]) удаляет все начальные и конечные вхождения набора символов, указанного в массиве, из текущей строки.
В-третьих, в F# это выглядит так же красиво без всяких мутабельных переменных
А System.IO.Path.DirectorySeparatorChar можно и в Powershell вставить