|
Оптимальный порядок измерений и состав доп-индексов регистра накопления | ☑ | ||
---|---|---|---|---|
0
fisher
14.01.14
✎
12:01
|
На примере конкретной ситуации.
Допустим, есть оборотный регистр "ПланПродаж" Измерения: Сценарий, Подразделение, Контрагент, Номенклатура. Как определить для него сабж? Допустим, что сценариев парочка, а подразделений - пяток. Контрагентов и ассортимента - много. Примерно сопоставимое количество. Очевидно вроде, что первым измерением должно стоять достаточно селективное и при этом часто используемое в соединениях. На эту роль хорошо подходит Контрагент или Номенклатура. Правильно? Тогда по каким измерениям имеет смысл установить признак дополнительного индексирования? Очевидно, что сценарии и подразделения тоже будут постоянно использоваться в соединениях и отборах, но их селективность невелика. Т.е. вроде большого смысла создавать по ним доп-индекс нет. Правильно? Но возможно имеет смысл установить доп-индексирование по номенклатуре, если первым измерением - контрагент. Или нет? В общем, просьба гуру оптимизации производительности навести ясность. |
|||
1
fisher
14.01.14
✎
12:09
|
Пока имхается, что выгоднее всего просто установить первым измерением контрагента, а вторым - номенклатуру. Чаще всего они используются в соединениях в паре, но контрагент чаще используется в отборах. В то время, как отбор по номенклатуре используется сравнительно редко.
Доп-индексы вроде нет смысла создавать в этой ситуации. Ммм? |
|||
2
Hmster
14.01.14
✎
12:10
|
говорить можно много, а лучше всего сделать замеры
|
|||
3
fisher
14.01.14
✎
12:11
|
(2) Ожидаемый коммент. Я на такие тоже мастер.
|
|||
4
y22-k
14.01.14
✎
12:11
|
(0) Есть же обработки на скуле показывающие рекомендуемые к созданию индексы запусти статстику на неделю и посмотри
|
|||
5
fisher
14.01.14
✎
12:14
|
Такое впечатление, что никто никогда в похожих ситуациях не делал никаких замеров, не смотрел на статистику и не делал никаких выводов. Все советуют как бы они поступили в первый раз в первый класс.
|
|||
6
Maxus43
14.01.14
✎
12:39
|
(5) те, кто это делал - готовый рецепт тебе не дадут тоже. Такой опыт стоит денег, тебе же лень всё это замерять? а им лень это отдавать. И не факт что ситуация такая же, зависит от конкретики много
|
|||
7
fisher
14.01.14
✎
12:50
|
Ясно-понятно. Не на мисте надо такие вопросы задавать.
|
|||
8
Maxus43
14.01.14
✎
12:51
|
(7) и на партнёрском кроме общих рекомендаций ничего не получишь...
|
|||
9
Адский плющ
14.01.14
✎
12:51
|
На первой конференции обсасывали этот вопрос.
|
|||
10
Sammo
14.01.14
✎
12:54
|
Количество записей еще не раскрыто
|
|||
11
fisher
14.01.14
✎
12:56
|
Допустим, пару десятков миллионов.
|
|||
12
Рэйв
14.01.14
✎
12:58
|
(0)я обычно иду от меньшего к большему.
То есть в таком порядке как у тебя в сабже. |
|||
13
fisher
14.01.14
✎
13:01
|
(12) Спасибо за первый коммент по существу.
|
|||
14
fisher
14.01.14
✎
13:02
|
(12) А из каких соображений именно так?
|
|||
15
fisher
14.01.14
✎
13:03
|
Не совсем понял. В смысле, от меньшей селективности к большей? Сценарий-Подразделение-Контрагент-Номенклатура?
|
|||
16
Рэйв
14.01.14
✎
13:04
|
(14)Из эстетических:-) Сравнительные замеры делать как то не приходило в голову.
|
|||
17
Рэйв
14.01.14
✎
13:04
|
(15)Ну да.
|
|||
18
MadHead
14.01.14
✎
13:11
|
я устанавливаю порядок по частоте использования фильтров/соединений.
Сценарий, Подразделение, Контрагент, Номенклатура Без отбора по сценарию вряд ли будут использоваться данные регистра. - это первое измерение. И так далее. Если часто используется отбор по контрагенту и при этому по предыдущим измерениям отбора нет, то можно дополнительно проиндексировать контрагента |
|||
19
fisher
14.01.14
✎
13:30
|
(18) Селективность индекса - не менее важная характеристика, чем частота его использования. Взять данные по некластерному индексу - довольно дорогостоящая операция (а в постгри, например, нет полного аналога кластерному индексу MSSQL, насколько я понял). Поэтому оптимизатор не использует такие индексы, т.к. дешевле выходит тупой перебор.
Если сценария всего два (или вообще один) - то селективность такого индекса будет хуже не придумаешь. |
|||
20
х86
14.01.14
✎
13:34
|
(0)еще же в стародавние времена на ИТС была статья про индексы
или уже нет таковой? |
|||
21
fisher
14.01.14
✎
13:39
|
Кстати, интересный вопрос.
К примеру, есть стандартный индекс Период+Сценарий+Контрагент+Номенклатура. А в запросе по периоду и сценарию отбор, а по контрагенту и номенклатуре - соединение. Будет ли при соединении с высокой вероятностью использован этот индекс при актуальной статистике и т.п.? Ну, это можно будет и потестить, если готового ответа нет... (20) Вот тоже смутно такое припоминал еще по 8.1 Но найти не могу. |
|||
22
fisher
14.01.14
✎
13:51
|
Не, соврал. Вроде есть у postgresql кластерные индексы.
Но итогах регистров накоплений они в 1С не используются. Видать шибко ресурсоемкая штука. |
|||
23
fisher
14.01.14
✎
13:54
|
Да и вообще, смотрю, индексы по измерениям 1С только в итогах строит. Т.е. если есть частые оперативные выборки за несколько дней месяца, а данных много - то может иметь смысл даже по первому измерению доп-индекс создавать.
|
|||
24
Hmster
14.01.14
✎
14:18
|
(3) немного оптимизировал УТ10 на постгре. был большой косяк с рлс - около 150-200 групп доступа, у каждого менеджера штук по 20-30 групп как минимум было.
поставил индексы в РС прав доступа и в таблицах по соединяемым полям. после этого бд стала шевелиться. на отчеты как правило можно забить, более важна логика программы, какие там соединения задействованы. порядок на производительность не мерял, но не думаю что будет ощутимый прирост |
|||
25
MadHead
14.01.14
✎
14:29
|
(19) про постгри нечего сказать не могу.
Селективность важная характеристика безусловно и если сценарий будет иметь низкую селективность, то скорее всего при отборе только по сценарию индекс не будет использован. Но с подходом из (18) запросы по максимуму будут использовать кластерный индекс который строится по умолчанию (ведь чаще всего отборов будет больше). |
|||
26
MadHead
14.01.14
✎
14:31
|
(23) скользкий конечно вопрос. На мой взгляд лучше уж создать агрегат или инклуд индекс средствами sql
|
|||
27
samozvanec
14.01.14
✎
14:32
|
(0) очень интересный вопрос. я раньше всегда делал как в (12) и (18), но потом почитал вот тут:
http://www.sql.ru/articles/mssql/03013101indexes.shtml и теперь хз. на эксперименты времени нет пока |
|||
28
fisher
14.01.14
✎
16:15
|
Ну, что касательно типовых, то я неоднократно встречал рассказы о том, что сабж был причиной вынесения поля "Номенклатура" в регистре партий на первое место (перед складом).
|
|||
29
Maxus43
14.01.14
✎
16:19
|
(28) в остальных регистрах зато номенклатура обычно в конце-середине... по типовым вобще сложно судить
|
|||
30
fisher
14.01.14
✎
16:56
|
(29) Остальные, как правило, были "полегче". Там типа особого смысла не было оптимизировать.
|
|||
31
fisher
14.01.14
✎
17:00
|
Вообще, касательно 1С - особой необходимости в оптимизации производительности вообще не возникает на таблицах относительно небольших объемов, как я понимаю. Обычно с головой хватает скана по кластерному индексу по периоду, поэтому одинэсовцы и не заморачивались.
|
|||
32
Maxus43
14.01.14
✎
17:03
|
(30) ну поди знай... РС вспомнить ЗУПовский если ГрафикиРаботПоВидамВремени - надо было оптимизировать... Там ещё в добавок стоят на всех измерениях "ОсновнойОтбор", нихрена не проиндексировано дополнительно и т.д.
|
|||
33
fisher
14.01.14
✎
17:05
|
Дополнительно индексировать - тоже надо очень осторожно, особенно на больших таблицах. База пухнет, запись замедляется. А реальный прирост на выборках далеко не всегда можно получить.
|
|||
34
х86
14.01.14
✎
17:30
|
тут немного про индексы
http://v8.1c.ru/o7/201312opt/index.htm http://its.1c.ru/db/METOD81#content:1590:1 |
|||
35
fisher
14.01.14
✎
18:12
|
(34) А как статья на ИТС называется? А то у меня ИТС украинский...
|
|||
36
fisher
14.01.14
✎
18:18
|
(34) Для меня стало новостью, что использование в условиях по периоду функций НАЧАЛОПЕРИОДА() и КОНЕЦПЕРИОДА() может привести к неэффективному выполнению запроса. Что-то я подобного не замечал...
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |