Highload-оптимизация 1С: теория и практика на примере консолидированной отчетности группы "Магнит" и розничной аптечной сети "Магнит"
Тема оптимизации 1С на больших данных бесконечная и всеобъемлющая, поскольку на производительность влияет целый ряд факторов – количество пользователей, данных, транзакций, неоптимальные запросы и т.д. Об инструментах для локализации проблем производительности и практических кейсах оптимизации рассказал Алексей Олейник, руководитель сектора автоматизации отчетности МСФО компании «Информационные технологии Магнит».
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
И напоследок, самая последняя особенность – это ускорение производительности за счет использования циклов в одну строку. Я в это не верил, но это действительно так. Первый кусок кода работает медленнее, чем второй кусок кода в пять с лишним раз.
Можно реальный пример ускорения? Не синтетический тест с циклом со сложением.
1С говорят с отключенной отладкой не будет работать это.
Обработка не в СУБД. Я часто встречаю пример, как на слайде – когда данные выгружаются из запроса в промежуточную таблицу значений, чтобы передать их в другой запрос. Так делать не нужно. Если эта таблица значений вам на сервере 1С не нужна, не выгружайте ее из запроса – сохраняйте все во временных таблицах и передавайте их в другой запрос непосредственно через менеджер временных таблиц.
Есть мнение, что менеджера тоже лучше избегать, ибо он скидывает таблицы на диск.
(3) Таблица значений тоже сохраняется на диск в сеансовые данные. Но это ерунда, по сравнению с временем, затрачиваемым при передачи больших ТЗ с сервера 1С на СУБД, Делается это пачками по 10 тысяч строк через BULK INSERT, но сильно легче от этого не становится. Причем пишется опять же во временную таблицу на диск.
Гораздо производительнее записать прямо на СУБД во временную таблицу, не спуская массив на сервер 1С.
Гораздо производительнее записать прямо на СУБД во временную таблицу, не спуская массив на сервер 1С.
2. По чекам. Дело в этом:
а нужно:
З.Ы.
Может стоило вообще через внутреннее соединение сделать типа так:
ЧекККМСерии.Ссылка.ВидЦены КАК ВидЦеныа нужно:
ВЫРАЗИТЬ(ЧекККМСерии.Ссылка КАК Документ.ЧекККМ).ВидЦены КАК ВидЦеныЗ.Ы.
Может стоило вообще через внутреннее соединение сделать типа так:
ЧекиККМ.ВидЦены КАК ВидЦены
ИЗ
Документ.ЧекККМ.Серии КАК ЧекККМСерии
ВНУТРЕННЕЕ СОЕДИНЕНИЕ ЧекиККМ КАК ЧекиККМ
ПО ЧекККМСерии.Ссылка = ЧекиККМ.Ссылка
И ЧекиККМ.Коррекция = ЛОЖЬ
(5)ЧекККМСерии - это табличная часть документа ЧекККМ. В нем Ссылка всегда строго типизирована, поэтому транслятор 1С запросов на СУБД просто проигнорирует Ваше "ВЫРАЗИТЬ(...)".
Проблема была в ЧекиККМ.Ссылка, а точнее соединение по этому полю. Транслятор 1С не видел, что идет соединение с полем одного типа, поэтому интерпретировал "ПО ЧекиККМ.Ссылка = ЧекиККМСерии.Ссылка" во что-то подобное
"ON CASE WHEN ЧекиККМ.RTRef = 0x... THEN ЧекиККМ.RRef END = ЧекиККМСерии._IDRef".
В свою очередь оптимизатор MS SQL 2017 увидел слева от "ON" нелюбимую конструкцию "CASE WHEN" и решил сделать HASH JOIN вместо очевидного LOOP JOIN. Поэтому система и считала хеши по всей таблице табличной части чеков ККМ, а когда их у Вас миллиарды, хеши считаются ооооочень долго.
Оптимизатор MS SQL 2012 и ниже делал еще хуже. Подробностей не помню, но был какой-то жесткий Lazy spool.
Проблема была в ЧекиККМ.Ссылка, а точнее соединение по этому полю. Транслятор 1С не видел, что идет соединение с полем одного типа, поэтому интерпретировал "ПО ЧекиККМ.Ссылка = ЧекиККМСерии.Ссылка" во что-то подобное
"ON CASE WHEN ЧекиККМ.RTRef = 0x... THEN ЧекиККМ.RRef END = ЧекиККМСерии._IDRef".
В свою очередь оптимизатор MS SQL 2017 увидел слева от "ON" нелюбимую конструкцию "CASE WHEN" и решил сделать HASH JOIN вместо очевидного LOOP JOIN. Поэтому система и считала хеши по всей таблице табличной части чеков ККМ, а когда их у Вас миллиарды, хеши считаются ооооочень долго.
Оптимизатор MS SQL 2012 и ниже делал еще хуже. Подробностей не помню, но был какой-то жесткий Lazy spool.
(6) Гораздо производительнее эту обработку кодом сделать в виде запроса 1С. Кто получал профильное программистское образование должны помнить, как мы реализовывали исполнение алгоритмах на разных абстракциях, вроде конечных автоматов. Так и в 1С - практически любой код можно переложить в запрос. А на больших объемах данных, обработка запросом гораздо производительнее.
Метод решения – переписать код и сделать вложенный запрос, где мы выбираем прямо из этой временной таблицы РАЗЛИЧНЫЕ Номенклатура, Характеристика. И после этого уже производим слияние с регистром сведений НоменклатураСегмента.
1С говорят, соединение с вложенным запросом - это плохо.
(7) На самом деле, в изначальном тексте есть вложенный запрос, просто Вы его не видите. В плане выполнения же он есть: внешний запрос - это конструкция РАЗЛИЧНЫЕ, а вложенный - это соединение таблиц.
В изначальном варианте, соединялись две таблицы и на результате их соединения уже выполнялись РАЗЛИЧНЫЕ (конструкции HASH AGGREGATE или последовательно "SORT + STEAM AGGREGATE"). Причем это очень тяжелые конструкции, которые имеют дурную привычку лезть в TempDB (если ошибаются с ожидаемым количеством строк).
После оптимизации, тяжелая операция РАЗЛИЧНЫЕ выполняется на гораздо меньшем множестве строк, еще до его умножения на количество сегментов. Отличия производительности тем больше, чем больше сегментов.
В изначальном варианте, соединялись две таблицы и на результате их соединения уже выполнялись РАЗЛИЧНЫЕ (конструкции HASH AGGREGATE или последовательно "SORT + STEAM AGGREGATE"). Причем это очень тяжелые конструкции, которые имеют дурную привычку лезть в TempDB (если ошибаются с ожидаемым количеством строк).
После оптимизации, тяжелая операция РАЗЛИЧНЫЕ выполняется на гораздо меньшем множестве строк, еще до его умножения на количество сегментов. Отличия производительности тем больше, чем больше сегментов.
Вопросы с вознаграждением
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|