Оптимальный порядок измерений и состав доп-индексов регистра накопления #694500

На примере конкретной ситуации. Допустим, есть оборотный регистр "ПланПродаж" Измерения: Сценарий, Подразделение, Контрагент, Номенклатура. Как определить для него сабж? Допустим, что сценариев парочка, а подразделений - пяток. Контрагентов и ассортимента - много. Примерно сопоставимое количество. Очевидно вроде, что первым измерением должно стоять достаточно селективное и при этом часто используемое в соединениях. На эту роль хорошо подходит Контрагент или Номенклатура. Правильно? Тогда по каким измерениям имеет смысл установить признак дополнительного индексирования? Очевидно, что сценарии и подразделения тоже будут постоянно использоваться в соединениях и отборах, но их селективность невелика. Т.е. вроде большого смысла создавать по ним доп-индекс нет. Правильно? Но возможно имеет смысл установить доп-индексирование по номенклатуре, если первым измерением - контрагент. Или нет? В общем, просьба гуру оптимизации производительности навести ясность.

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

говорить можно много, а лучше всего сделать замеры

Ожидаемый коммент. Я на такие тоже мастер.

Есть же обработки на скуле показывающие рекомендуемые к созданию индексы запусти статстику на неделю и посмотри

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

те, кто это делал - готовый рецепт тебе не дадут тоже. Такой опыт стоит денег, тебе же лень всё это замерять? а им лень это отдавать. И не факт что ситуация такая же, зависит от конкретики много

Ясно-понятно. Не на мисте надо такие вопросы задавать.

и на партнёрском кроме общих рекомендаций ничего не получишь...

На первой конференции обсасывали этот вопрос.

Количество записей еще не раскрыто

Допустим, пару десятков миллионов.

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

Спасибо за первый коммент по существу.

А из каких соображений именно так?

Не совсем понял. В смысле, от меньшей селективности к большей? Сценарий-Подразделение-Контрагент-Номенклатура?

Из эстетических:-) Сравнительные замеры делать как то не приходило в голову.

Ну да.

я устанавливаю порядок по частоте использования фильтров/соединений. Сценарий, Подразделение, Контрагент, Номенклатура Без отбора по сценарию вряд ли будут использоваться данные регистра. - это первое измерение. И так далее. Если часто используется отбор по контрагенту и при этому по предыдущим измерениям отбора нет, то можно дополнительно проиндексировать контрагента

Селективность индекса - не менее важная характеристика, чем частота его использования. Взять данные по некластерному индексу - довольно дорогостоящая операция (а в постгри, например, нет полного аналога кластерному индексу MSSQL, насколько я понял). Поэтому оптимизатор не использует такие индексы, т.к. дешевле выходит тупой перебор. Если сценария всего два (или вообще один) - то селективность такого индекса будет хуже не придумаешь.

еще же в стародавние времена на ИТС была статья про индексы или уже нет таковой?

Кстати, интересный вопрос. К примеру, есть стандартный индекс Период+Сценарий+Контрагент+Номенклатура. А в запросе по периоду и сценарию отбор, а по контрагенту и номенклатуре - соединение. Будет ли при соединении с высокой вероятностью использован этот индекс при актуальной статистике и т.п.? Ну, это можно будет и потестить, если готового ответа нет... Вот тоже смутно такое припоминал еще по 8.1 Но найти не могу.

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

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

немного оптимизировал УТ10 на постгре. был большой косяк с рлс - около 150-200 групп доступа, у каждого менеджера штук по 20-30 групп как минимум было. поставил индексы в РС прав доступа и в таблицах по соединяемым полям. после этого бд стала шевелиться. на отчеты как правило можно забить, более важна логика программы, какие там соединения задействованы. порядок на производительность не мерял, но не думаю что будет ощутимый прирост

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

скользкий конечно вопрос. На мой взгляд лучше уж создать агрегат или инклуд индекс средствами sql

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

Ну, что касательно типовых, то я неоднократно встречал рассказы о том, что сабж был причиной вынесения поля "Номенклатура" в регистре партий на первое место (перед складом).

в остальных регистрах зато номенклатура обычно в конце-середине... по типовым вобще сложно судить

Остальные, как правило, были "полегче". Там типа особого смысла не было оптимизировать.

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

ну поди знай... РС вспомнить ЗУПовский если ГрафикиРаботПоВидамВремени - надо было оптимизировать... Там ещё в добавок стоят на всех измерениях "ОсновнойОтбор", нихрена не проиндексировано дополнительно и т.д.

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

тут немного про индексы

А как статья на ИТС называется? А то у меня ИТС украинский...

Для меня стало новостью, что использование в условиях по периоду функций НАЧАЛОПЕРИОДА и КОНЕЦПЕРИОДА может привести к неэффективному выполнению запроса. Что-то я подобного не замечал...