Экспертный взгляд на оптимизацию производительности на примере исправления и декомпозиции запроса

20.07.22

База данных - HighLoad оптимизация

+88 –
> > > > > > > > > > > > > > > > > > > >
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
Еще один интересный пример оптимизации производительности ERP. Описываем решение проблемы подробно по шагам.

В данной статье мы изложим некоторую примерную последовательность действий по выявлению проблемы производительности и ее поэтапному решению (с картинками и комментариями). Думаю, что будет особенно интересно новичкам, а также тем, кто планирует столкнуться с СУБД Postgres или уже ведет активную работу в этом направлении. 

Структура статьи:

  • Введение и постановка задачи
  • Ищем точку возникновения
  • Получаем исполняемый текст запроса
  • Подготавливаем исходный запрос в консоли запросов
  • Анализируем план исходного запроса
  • Оптимизация шаг 1. Исправление очевидной ошибки
  • Оптимизация шаг 2. Декомпозиция запроса
  • Заключение

 

Введение и постановка задачи

 

Для решения этой задачи нам понадобится:

  • конфигурация «Мониторинг производительности» - в ней будем оценивать количество событий, точки возникновения, собирать статистику онлайн;
  • доступ к целевой конфигурации ERP - в ней будем смотреть проблемный код и получать текущий запрос;
  • консоль запросов – моделирование, оптимизацию;
  • конвертер текстов SQL в представления 1С – преобразовывать нечитаемое представление в читаемое тестов и планов, создавать графическое представление плана запросов;
  • доступ к базе Postgres для проверки некоторых гипотез (опционально).

Те счастливчики, у которых есть конфигурация ERP, УТ, КА с хорошим набором данных смогут повторить эксперимент у себя. На демонстрационной базе прочувствовать всю глубину рассматриваемой проблемы не получится, но посмотреть планы и увидеть результат работы можно попробовать. 

 

Исходная информация:

Проблема проявилась в документе установка цен номенклатуры у известных пользователей (есть ФИО) конфигурации ERP 2.4. Нам предстоит выявить проблему и исправить эту ситуацию. 
 

Что мы будем делать?

Мы найдем точку возникновения проблемы, получим текст запроса и будем отлаживать в консоли запросов, исправляя проблему. Раз, два, три... Поехали!

 

I) Ищем точку возникновения

 

Для того чтобы было удобно и просто искать места проблем, мы рекомендуем установить и настроить конфигурацию "Мониторинг производительности". Это удобно cделать на продуктовом  и на тестовом сервере. Если вы конечно не приверженец Old-school и любите работать в каком-нибудь парсере руками.

Т.к. у нас это уже настроено, то мы сразу посмотрим картинку из журнала длительных замеров. Поставим фильтр по длительности, пользователю или текстовому вхождению - это зависит от входящей информации по проблеме. В текущем случае будем фильтровать по вхождению «установка цен» в поле "context".

 

 

Система отобрала подходящие записи. И из картинки выше видно, что время подобных событий достигает иногда десятков минут, чуть чаще не более 10 с. Вообще разброс достаточно большой.

Давайте посмотрим где это происходит. Двойной клик по полю выделенной строки открывает отдельную вкладку с контекстом выполняемой операции.

 

 

Анализируем контекст:

  • Это процедура открытия документа "Установка цен номенклатуры". На это нам указывает команда "получить форму";
  • Это основная форма документа;
  • Проблема формируется запросом. Самая последняя позиция стека содержит команду "Запрос.Выполнить()";
  • Этот запрос похоже находится в модуле «УстановкаЦенСервер» - функция «ЗагрузитьТабличнуюЧастьТовары»;
  • Этот запрос расположен в строке «3907»;
  • Если мы посмотрим еще несколько записей журнала, то можем встретить вторую функцию «ЗагрузитьСтарыеЦеныНоменклатурыПредприятия», они имеют похожую структуру, но она выполняется обычно быстрее.

Давайте глазками посмотрим что это за запрос, как он выглядит и что из себя представляет. Поэтому переходим к следующей части.

 

II) Получим исполняемый текст запроса

 

Чтобы получить искомый текст нам необходимо выполнить набор простых действий:

  • Открываем конфигурацию;
  • В дереве метаданных находим общий модуль «УстановкаЦенСервер» и открываем его;
  • Переходим в точку выполнения запроса - это позиция «3907».  Для быстрого перехода к позиции нажимаем сочетания «Ctrl»+«G».
  • В итоге мы должны оказаться в функции «ЗагрузитьТабличнуюЧастьТовары».

 

 

Где-то чуть выше должен находиться нужный нам текст запроса их два, но нам нужен тот что используется для продажи. На первый взгляд, он довольно простой:

 
 Исходный текст запроса

 

Что про него можно сказать:

  • Это пакет, и он состоит из двух частей;
  • В первой загружается таблица данных и формируется временная таблица;
  • А во втором выполнятся выборка с учетом этих входных данных;
  • Проблема находится во второй части пакета, т.к. текст SQL представления начинается с ключевого слова "SELECT", а не "INSERT";
  • В нем есть несколько интересных параметров - «ТекстЗапросаКоэффициентУпаковки1» и «ТекстЗапросаКоэффициентУпаковки2», которые подставляются в программном коде следующим образом:
 
 Программное преобразование запроса (подстановка значения параметров "ТекстЗапросаКоэффициентУпаковки")

 

Мы не можем просто так взять текущий текст для его анализа в консоли. Поэтому будем получать собранный запрос в отладке. Далее действуем так:

  • Ставим точку останова в позиции «3907»;
  • Стартуем предприятие;
  • Открываем любой документ; 
  • Получаем текст запроса.

 

 

Соберитесь! Полный текст запроса приведен внутри свернутого спойлера. Если будете его смотреть, то делайте это аккуратно и без резких движений)

 
 Полный текст запроса

 

Что будем делать дальше? А дальше мы будем выполнять исходный запрос, чтобы посмотреть что-там такое происходит.

 

III) Подготавливаем исходный запрос в консоли запросов

 

Для продолжения работы нам необходима любая консоль запросов. Открываем ее и далее начинаем дорабатывать запрос. 

1) Создаем первый пакет и называем его "Исходный запрос". Далее мы будем копировать его с установленными параметрами для выполнения экспериментов.

 

 

2) Исправим первый запрос пакета, чтобы нам не требовалось подгружать таблицу данных. Некоторые консоли могут такого не уметь, да и набивать 3-4 тысячи строк это ужасное удовольствие. Для этого мы изменим одну строчку с выборкой из временной таблицы следующим образом:

 

 

3) Вставляем ключ "Key-12345" для быстрого поиска по логу запросов. Это изменение будет выглядеть следующим образом:

 
Добавляем ключ в текст запроса

 

ВЫБРАТЬ
	”Key-12345” КАК Ключ,
	ВременнаяТаблицаТовары.Индекс КАК Индекс,
	ВременнаяТаблицаТовары.Номенклатура КАК Номенклатура,
	ВременнаяТаблицаТовары.Характеристика КАК Характеристика,
	//....

 

 

4) Найдем подходящий документ среди всех документов установки цен. Для этого воспользуемся запросом получения списка документов с количеством позиций в табличной части:

 
 Текст запроса для подбора документа установки цен

Результат запроса примерно такой:

 

 

5) Выбираем документ с 4871 записью (это похоже наш пример из первого пункта, где искали точку возникновения) и устанавливаем параметр "Ссылка" в консоли запросов. 

6) Если у вас консоль долго рисует таблицу данных или вы решили взять документ с парой сотен тысяч строк, то разумно будет не выводить результат выполнения в таблицу или табличный документ (у некоторых консолей такой функционал присутствует, или доработайте самостоятельно).

7) Теперь мы можем выполнить исходный запрос и, выпив чашку кофе, продолжить процесс оптимизации.

Далее мы посмотрим план запроса и попробуем определить варианты решения проблем.

 

IV) Смотрим и анализируем исходный план запросов.

 

Будем считать, что у вас уже настроено сохранение длительных планов запросов на Postgres как на продуктовом сервере, так и на тестовом. Если это не так, то срочно выполняем необходимые действия - подключить компоненту auto_explain (как это делается можно найти в интернете или кратко в статье "Пример пошагового решения проблемы производительности на базе Postgres SQL с картинками").

Настроить сохранение планов запросов на продуктовом сервере следует сделать потому что:

  • не всегда легко удается повторить полностью поведение на тестовом сервере;
  • мы сразу можем начать анализировать проблему, пропуская задачу воспроизведения этой ситуации;

Давайте найдем текстовый план запроса и воспользуемся обработкой конвертации представлений SQL в 1С:

  • Открываем текстовый файл лога;
  • Находим наш текст запроса поиском по вхождению ключа "Key-12345";
  • Копируем текстовый план запроса;
  • Вставляем в конвертер;
  • Жмем последовательно кнопки "преобразовать" и "объяснить план запроса";
  • Открываем браузер и смотрим, что там такое.

 

 

Полученный план запроса можно посмотреть по ссылке: https://explain.tensor.ru/archive/explain/7922ca5d978f541c7d9dee619365c80e:0:2022-07-19#visio

Сначала обратим на правую часть схемы, в которой самый большой красный круг. Это самый тяжелый участок, на который тратится до 98% ресурсов.

 

 

На картинке ниже мы поясняем соответствие операторов их тексту запроса:

  • красным цветом показана временная таблица товаров;
  • фиолетовым - получение виртуальной таблицы срез последних на дату;
  • синим - фильтрация данных индекса по полям "Номенклатура" и "Характеристика"

 

 

Получается, что у нас проблема при получении данных из виртуальной таблицы среза последних регистра "Цены номенклатуры"! А почему? Потому что внутри виртуальной таблицы отсутствует необходимый отбор по измерению "ВидЦены". Мы должны максимально использовать любую возможную фильтрацию данных. Можно воспользоваться пояснениями от 1С: Типичные причины неоптимальной работы запросов и методы оптимизации

 

 

Мы готовы к первому шагу оптимизации!

 

V) Первый шаг оптимизации

 

В текущем запросе у нас с вами явная проблема - отсутствие в виртуальной таблице фильтра по измерению "ВидЦены". Давайте выполним исправление:

1) В консоли запросов копируем исходный запрос и переименовываем его в "Оптимизация 1" 

2) Исправляем текст запроса в соответствии с примером ниже. Подставим условие в виртуальную таблицу "СрезПоследних" регистра "Цены номенклатуры":

 
 Оптимизация запроса - первый этап

 

//...
ИЗ
	ВременнаяТаблицаТовары КАК ВременнаяТаблицаТовары
		ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры.СрезПоследних(
				&Дата,
				(Номенклатура, ВидЦены, Характеристика) В
					(ВЫБРАТЬ
						ВременнаяТаблицаТовары.Номенклатура,
						ВременнаяТаблицаТовары.ВидЦены,
						ВременнаяТаблицаТовары.Характеристика
					ИЗ
						ВременнаяТаблицаТовары)) КАК ЦеныНоменклатуры
//...

 

2) Меняем текст ключа на "Key-optim-1"

3) Выполняем запрос и смотрим результаты. Результаты у нас впечатляющие, данный запрос выполнился быстрее чем за 5 с.

https://explain.tensor.ru/archive/explain/80e06f99ebef84b08293e1b0e61126ac:0:2022-07-15#visio

4) Давайте откроем план запроса и посмотрим что изменилось:

  • наша первая проблема исчезла, теперь на этот блок приходится всего 2% ресурсов;
  • появилось, точнее вышли на первый план, три старых блока сканирования таблицы регистра - 21%, оператор цикла (Nested Loop) 45% и оператор Materialize 13%.

 

Сделаем несколько выводов:

  • В описании блока Nested Loop мы видим что всего выбрано 4871 строк, но отброшено порядка 22 миллиона (RRbF - удаленные строки по фильтру). Похоже зря тратятся ресурсы. 
  • Так же мы видим кучу маленьких Index Scan примыкающих к основной оси схемы - это левые соединения с упаковками номенклатуры для получения коэффициентов, размеров и т.п. скрыто через две точки, которые 1С сама разворачивается в запросах SQL. Это то что скрывалось в «ТекстЗапросаКоэффициентУпаковки1» и «ТекстЗапросаКоэффициентУпаковки2».
  • Скан таблицы регистра (Seq Scan) конечно выглядит не очень здорово, но он выполняется всего один раз (Loop=1) и т.к. присутствует оператор hash join. 

Давайте попробуем ограничить трату ресурсов на эти прогоны. В системе с одним пользователем - это выглядит не существенно. Когда их количество увеличится, то вносимый вклад будет более значительным. Однако, давайте взглянем, как выглядит этот запрос, когда в табличной части будет в 10 раз больше товаров. План запроса: https://explain.tensor.ru/archive/explain/3e61a905418d4284e66f4bf71ea3323d:0:2022-07-19#visio

 

 

Мы видим что количество обрабатываемых строк в цикле превысило 11 миллиардов, а время от 2 секунд улетело куда-то в район нескольких тысяч (суммарно). И это при ~78 тысячах строк. Поэтому мы подходим к следующему этапу оптимизации.

P.S. В версии ERP 2.5 эта ошибка недостающего поля фильтра устранена и запрос работает приемлемо быстро.

 

VI) Второй шаг оптимизации

 

Все из той же статьи рекомендаций 1С можно вынести следующий совет по работе с виртуальными таблицами в соединениях. Мы выполним процедуру декомпозиции запроса или проще говоря - разобьем один сложный запрос на несколько простых.

Глаза боятся запроса, но консоль все сделает! Начинаем процесс второго этапа оптимизации:

  • Копируем в консоли запрос оптимизация 1 и называем его оптимизация 2;
  • Далее открываем конструктор и на вкладке "Пакет запросов" дублируем "Запрос пакета 2";
  • Активизируем запрос пакета 2;
  • Создаем из него временную таблицу с названием "ВтЦеныНоменклатуры";
  • На вкладке "Таблицы и поля" удаляем временную таблицу товаров, добавляем новые требуемые поля "Номенклатура,Характеристика,ВидЦены,Цена,Упаковка", меняем текст ключа на что-то в духе "Key-optim-part-1", а также индексируем по трем измерениям.
  • Последним шагом переключаемся на "Запрос 3" пакета запросов, меняем текст ключа на "Key-optim-part-2" и выполняем подмену виртуальной таблицы на временную "ВтЦеныНоменклатуры"
  • Готово преобразование.
  • Теперь мы выполняем запрос и смотрим его результаты.  
 
 Текст оптимизированного запроса монстра

 

У нас должно получиться два запроса и два плана, которые суммарно должны быть лучше одного из первого этапа оптимизации. В итоге общее время консоли запросов получилось около 2 секунд. Давайте посмотрим  как изменились планы запросов.

 

 

Если мы посмотрим, то увидим что ушли блоки где гонялись лишние данные при соединении временной таблицы товаров и виртуальной цен номенклатуры (Nested Loop и Materialize). Это как раз то место, которое разбивает данный запрос на де части.

Остался только блок сканирования таблицы, чтобы избавиться от этого запроса нам надо попробовать переписать запрос срез последних, но этого уже мы делать не будем. Желающие могут попробовать самостоятельно выполнить эту операцию.

 

Заключение

 

Были обнаружены и исправлены:

  • ошибка отсутствия необходимого фильтра по полю измерению внутри виртуальной таблицы,
  • а также упрощен исходный запрос путем разбиения его на две части (декомпозиция). 

В результате решения задачи мы смогли уменьшить время выполнения запроса системы в ~300-400 раз, а в некоторых случаях улучшение достигает невероятных ~1000 пунктов).

Также был продемонстрирован пошаговый подход с картинками и комментариями к анализу и выявлению проблем производительности, который можно использовать при решении подобных задач самостоятельно.

Совет: Будьте в тренде, следуйте простым рекомендациям (не ленитесь) и Вы ожидаемо получите хорошие результаты. 

 

Ссылки от автора по вопросам оптимизации производительности

производительность оптимизация эксперт postgres

+88 –

См. также

SALE! 15%

Infostart Toolkit: Инструменты разработчика 1С 8.3 на управляемых формах

Инструментарий разработчика Роли и права Запросы СКД Программист Платформа 1С v8.3 Управляемые формы Запросы Система компоновки данных Конфигурации 1cv8 Платные (руб)

Набор инструментов программиста и специалиста 1С для всех конфигураций на управляемых формах. В состав входят инструменты: Консоль запросов, Консоль СКД, Консоль кода, Редактор объекта, Анализ прав доступа, Метаданные, Поиск ссылок, Сравнение объектов, Все функции, Подписки на события и др. Редактор запросов и кода с раскраской и контекстной подсказкой. Доработанный конструктор запросов тонкого клиента. Продукт хорошо оптимизирован и обладает самым широким функционалом среди всех инструментов, представленных на рынке.

10000 руб.

02.09.2020    159334    872    399    

861
Мониторинг серверов и баз 1С

Журнал регистрации Мониторинг Системный администратор Программист Бизнес-аналитик Руководитель проекта Платформа 1С v8.3 Платные (руб)

В сферу обязанностей при работе с клиентами входит контроль работы баз данных и серверов 1С. Нужно понимать что происходит в базах, есть ли ошибки, зависания у пользователей и фоновых задач, блокировки или какое-то необычное поведение системы, получение информации о причинах возникновения проблем и их оперативное устранение и т.д. В качестве источников информации использую консоль кластеров 1С, технологический журнал 1С, журналы регистрации базы 1С. Для автоматизации части операций мониторинга и анализа создал инструмент на основе 1С.

9000 руб.

28.08.2019    33918    22    21    

74
Сравнение габаритов товаров Ozon в модуле Synchrozon

Учет доходов и расходов Логистика, склад и ТМЦ Маркетплейсы Мониторинг Пользователь Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Розничная и сетевая торговля (FMCG) Оптовая торговля, дистрибуция, логистика Управленческий учет Платные (руб)

Расширение модуля Synchrozon для удобного контроля габаритов на Ozon! Разработка позволяет мгновенно сравнивать установленные габариты товаров, с габаритами, указанными на Ozon, чтобы выявлять любые несоответствия. Поможет сократить расходы на логистику, гарантируя, что все данные о товарах остаются точными и актуальными.

3600 руб.

31.10.2024    336    1    0    

3
Контроль расхода памяти сервера 1С:Предприятие 8

Мониторинг Системный администратор Программист Платформа 1С v8.3 Россия Платные (руб)

Обработка позволяет использовать подобные КОРП-функциональности механизмы контроля расхода памяти (сеансом на 1 вызов и рабочими процессами), реагируя завершением "тяжелых" вызовов, перезапуском рабочих процессов при чрезмерном потреблении этого важного ресурса.

3600 руб.

03.05.2023    5101    3    0    

3
Конфигурация Session Monitor

Мониторинг Инструменты администратора БД Системный администратор Платформа 1С v8.3 Россия Платные (руб)

Конфигурация Session Monitor предназначена для мониторинга сервера 1С с целью отслеживания чрезмерной нагрузки от конкретных сеансов и скорости реакции рабочих процессов.

1500 руб.

01.12.2020    15986    38    0    

56
Примеры настроек технологического журнала

Технологический журнал Программист Платформа 1С v8.3 Бесплатно (free)

Шпаргалка по настройке технологического журнала.

27.04.2024    11287    kuzyara    5    

116
Анализируем SQL сервер глазами 1С-ника

HighLoad оптимизация Инструменты администратора БД Системный администратор Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Обработка для простого и удобного анализа настроек, нагрузки и проблем с SQL сервером с упором на использование оного для 1С. Анализ текущих запросов на sql, ожиданий, конвертация запроса в 1С и рекомендации, где может тормозить.

2 стартмани

15.02.2024    12407    241    ZAOSTG    80    

115
Начните уже использовать хранилище запросов

HighLoad оптимизация Запросы

Очень немногие из тех, кто занимается поддержкой MS SQL, работают с хранилищем запросов. А ведь хранилище запросов – это очень удобный, мощный и, главное, бесплатный инструмент, позволяющий быстро найти и локализовать проблему производительности и потребления ресурсов запросами. В статье расскажем о том, как использовать хранилище запросов в MS SQL и какие плюсы и минусы у него есть.

11.10.2023    19313    skovpin_sa    15    

105
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. quazare 3800 20.07.22 18:19 Сейчас в теме
Я правильно понял, что в типовом запросе не было виртуальных проиндексированных таблиц и отсутствовал одно соединение по фильтру вид цены?

Ну тогда, вероятно в запросе нужно сделать уничтожение виртуальных таблиц после их использования?
+ – Ответить
3. ivanov660 4577 20.07.22 21:57 Сейчас в теме
(1)
1. Да относительно фильтра "ВидЦены". Типовой запрос приведен в спойлере "Исходный текст запроса" и в нем отсутствует в условии фильтра поле "ВидЦены", есть только "Характеристика" и "Номенклатура", а этого не достаточно для оптимальной работы.
2. Не понял что такое виртуальная проиндексированная таблица. Попробую ответить так: мы разбили запрос на две части и в первой создали временную таблицу фактически для того чтобы "упростить жизнь" планировщику запросов. Postgre в отличии от MS SQL не такой "умный" и работает хуже. На СУБД MSSQL такой деградации производительности из-за отсутствия фильтра внутри виртуальной таблицы не происходит. Можно проверить этот факт самостоятельно.
3. Обычно удаление временных таблиц необходимо делать, когда в пакете будет использоваться таблица с таким же именем. В остальных случаях платформа подчищает хвосты самостоятельно.
ardn; +1 – Ответить
2. gzharkoj 520 20.07.22 21:39 Сейчас в теме
Нарушены два требования 1с:
1. Все отборы,которые могут установлены виртуальных таблицах должны находится в параметрах виртуальной таблицы. В запросе отбор по Виду цены находился в левом соединении, а не в виртуальной таблице
2. Не использовать соединения с подзапросами, рекомендация сформировать отдельную временную таблицу. По факту запрос к виртуальной таблице СрезПоследних цен развернется в подзапрос, поля соединения не будут проиндексированы у подзапроса. В целом так можно делать, когда количество результирующих строк виртуальной таблицы не много, до 1к, на больших данных будут просадки, что автор и показал с ~5к позициями товаров.
Дмитрий74Чел; quazare; ardn; ivanov660; +4 –1 Ответить
10. nicxxx 255 21.07.22 11:21 Сейчас в теме
(2)
2. Не использовать соединения с подзапросами, рекомендация сформировать отдельную временную таблицу.

Перейти на MSSQL, там это проблема решена :)
+ – Ответить
11. ivanov660 4577 21.07.22 11:24 Сейчас в теме
(10)
1. Не совсем так, подобную проблему вы можете словить и в этой СУБД. Она "умнее" да, но не везде и всегда.
2. Официально купить MS SQL на текущий момент вроде нет возможности для российских компаний.
+ – Ответить
4. VSvintsov1 21.07.22 05:03 Сейчас в теме
автор предлагает повторить это тестирование на стандартных конфигурациях. - верно ли я понял , что авторство запроса с конструкцией: 
.....
ИЗ
	ВременнаяТаблицаТовары КАК ВременнаяТаблицаТовары
		ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры.СрезПоследних(
....


принадлежит разработчикам типовых конфигураций ?
+ – Ответить
5. ivanov660 4577 21.07.22 08:58 Сейчас в теме
(4) Да, и в этом нет ничего не обычного.
Дмитрий74Чел; +1 – Ответить
6. cdiamond 235 21.07.22 09:03 Сейчас в теме
(4) Видимо так. Но однозначно говорят что это криминал только вроде на курсе специалиста по платформе. На курсе по эксперту уже с оговорками и условиями ) Всё зависит от объема данных в тех или иных таблицах - здесь же очевидно авторы конфигурации не рассчитывали что номенклатуры будут десятки тысяч и на все будут устанавливать цены. В целом таких непредусмотренных ситуаций в ERP 2.4 довольно много и это отличное поле для оптимизаторов. Есть еще другая сторона вопроса - злоупотребление временными таблицами, в котором 1С является чемпионом в нашей галактике, очевидно что загонять миллионы строк во временную таблицу тоже решение так себе, за которое нужно платить большими объемами оперативной и твердотельной памяти.
Созинов; +1 – Ответить
8. ivanov660 4577 21.07.22 09:44 Сейчас в теме
(6)
1. Предположение что в продуктовой базе компании, которая будет использовать ERP, номенклатуры будет не более чем в демонстрационной базе - это, на мой взгляд, не профессиональный подход. ERP позиционируется как конфигурация для больших компаний.
2. Если в ситуации, когда нет выбора, то использовать или не использовать временную таблицу, решается практически как в данной статье. Думаю, что миллион строк при возможности работы за 3 с - это лучшее решение, чем виртуальная таблица и 1 час на открытие каждого документа (если вы так переживаете за время жизни жесткого диска, то можете сделать RAM диск под tmp файлы). С другой стороны чтобы избежать этого можно заставлять пользователя делать 100 документов для установки цен, но такой подход - это курам на смех.
papami; +1 – Ответить
12. TMV 14 21.07.22 23:06 Сейчас в теме
(8) Бывают ли у вас документы с количеством строк записей в наборе по какому-либо регистру более 100 тысяч?
+ – Ответить
9. ivanov660 4577 21.07.22 09:55 Сейчас в теме
(6) В некоторое ближайшее время, мы планируем выложим обработку, которая позволит из демонстрационной базы в относительно "сжатые сроки", сделать нормальную базу для проверки ее работы при больших объемах данных. Пока мы ее тестируем и проверяем свои задачи, но за 2-е суток удалось создать оптимальное число, законченных цепочек.
Вот тут и можно будет развернуться для проверок тех или иных списков и запросов, идей.
Прикрепленные файлы:
Дмитрий74Чел; Созинов; CAV; +3 – Ответить
17. Дмитрий74Чел 239 28.07.22 16:51 Сейчас в теме
(9) Шикарно!
+ – Ответить
7. Serg O. 297 21.07.22 09:38 Сейчас в теме
Спасибо, статья как всегда очень круто оформлена.
Максимально подробно и с красивыми картинками.
Огромный +
Sejix; Jimbo; user1559729; ubnkfl; ardn; ivanov660; +6 – Ответить
13. TMV 14 21.07.22 23:09 Сейчас в теме
(0) Имеет ли значение порядок в секции Индексировать в запросе формирования временной таблицы? В регистре сведений порядок измерений другой.
+ – Ответить
15. ivanov660 4577 22.07.22 08:45 Сейчас в теме
(13)Главный критерий - это наличие всех полей использующихся в соединениях.
TMV; +1 – Ответить
14. TMV 14 21.07.22 23:12 Сейчас в теме
Остался только блок сканирования таблицы, чтобы избавиться от этого запроса нам надо попробовать переписать запрос срез последних, но этого уже мы делать не будем
Насколько помню, эта тема очень спорная - вам удалось переписать срез последних, вообще на практике используете?
+ – Ответить
16. ivanov660 4577 22.07.22 09:10 Сейчас в теме
(14)А почему спорная? В других системах учета нет никаких виртуальных таблиц и все делается руками. На сколько я помню коллеги говорили, что использование виртуальных таблиц упрощает сам запрос и позволяет не забыть включить служебные поля типа "Активность".
Сам запрос виртуальной таблицы можно переписать, к примеру так: 
ВЫБРАТЬ
	Т.Номенклатура КАК Номенклатура,
	Т.ВидЦены КАК ВидЦены,
	Т.Характеристика КАК Характеристика,
	Т.Цена КАК Цена,
	Т.Упаковка КАК Упаковка
ИЗ
	(ВЫБРАТЬ
		МАКСИМУМ(Ц.Период) КАК Период,
		Ц.Номенклатура КАК Номенклатура,
		Ц.Характеристика КАК Характеристика,
		Ц.ВидЦены КАК ВидЦены
	ИЗ
		РегистрСведений.ЦеныНоменклатуры КАК Ц
	ГДЕ
		Ц.Активность = ИСТИНА
		И Ц.Период < &Период
	
	СГРУППИРОВАТЬ ПО
		Ц.Номенклатура,
		Ц.Характеристика,
		Ц.ВидЦены) КАК ВнТ
		ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК Т
		ПО (Т.Номенклатура = ВнТ.Номенклатура)
			И (Т.Характеристика = ВнТ.Характеристика)
			И (Т.ВидЦены = ВнТ.ВидЦены)
			И (Т.Период = ВнТ.Период)
ГДЕ
	Т.Активность = ИСТИНА
Показать

Если это будет более оптимальный вариант, то почему же не использовать? Да, иногда мы вместо виртуальных таблиц мы используем работу с физическими таблицами.
+ – Ответить
Оставьте свое сообщение