Управление индексами

[SeiOkami]

Проблематика

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

2. Для многих объектов нет возможности влиять на состав кластерного индекса.

3. Нет возможности использовать included columns. Из-за чего усложняется реализация покрывающих индексов для запросов, выбирающих большие объёмы данных.

4. Нет возможности создавать фильтрованные индексы.

5. Некоторые служебные поля вообще не могут быть включены ни в один индекс. Например, «Активность» регистра накопления или «НомерСтроки» табличной части. В результате, при использовании этих полей в запросе, покрывающим может быть только кластерный индекс. При работе с большими выборками, это приводит к сканированию кластерного индекса или ресурсоёмким key lookup.

6. Нет возможности использовать некластерные колоночные индексы или создавать индексируемые представления с кластерными колоночными индексами.

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

При этом эти ограничения воспринимаются как искусственные, т.к. фактически эти манипуляции с индексами можно проделать при работе напрямую с СУБД. Более того:

1. Администрирование базы данных и расследование проблем производительности всё равно требует работать с БД напрямую.

2. Иногда, изменение структуры таблиц БД рассматривается как приемлемое решение на тренинге 1С:Эксперт.

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

Предлагаемое решение

Расширить возможность настройки индексов таблиц.
Вместо существующего подхода, при котором для полей устанавливается режим индексирования, предлагается добавить новую закладку в редактор свойств объекта метаданных.
Свойство «Индексировать» реквизитов/измерений/ресурсов удаляется с панели свойств.

При переходе на новую версию платформы, настройки индексирования объекта не теряются – на их основании создаются новые объекты конфигурации. На скриншоте ниже, индексы «ПоСсылке», «ПоДате», «ПоНомеру» и «ПоПрефиксу» были созданы автоматически при переходе на новую версию платформы. Таким образом, никаких дополнительных действий разработчика конфигурации при переходе не потребуется.

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

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

Для индекса допустима установка следующих параметров:

• Наименование (Строка (80))
• Тип: Кластерный/Некластерный. + Проверка на то, что кластерный только один.
• Включая колонки. Список. Выбор из всех полей, доступных для использования в полях индекса.

Добавление полей возможно из фиксированного списка, который определяется как:

• Стандартные реквизиты
• Пользовательские реквизиты/измерения/ресурсы
• Общие реквизиты

При изменении объекта метаданных в конфигураторе, который может влиять на индексы таблиц (например, общий реквизит, критерий отбора, свойство «Ведущее» и т.д.), выполнять проверку:

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

Кнопка «По умолчанию для объекта» открывает окно с выбором индексов, которые система предлагает построить для объекта по умолчанию. Данные выводятся в виде дерева. Для каждой строки можно поставить флажок. Для описанного выше примера (см. скриншот выше) в окне индексов по умолчанию будет выведен перечень из индексов: «ПоСсылке», «ПоДате», «ПоНомеру» и «ПоПрефиксу». При этом, если разработчик конфигурации в окне работы с индексами удалит индекс «ПоПрефиксу», то в окне индексов по умолчанию, он будет выведен как предлагаемый к созданию. Это позволит разработчику конфигурации контролировать наличие критичных для работы индексов и при необходимости возвращаться к структуре индексов по умолчанию. Достаточно будет выбрать индекс «ПоПрефиксу» флажком и нажать кнопку.

[alex7six]

В переписке с КОРП-поддержкой по данному кейсу сотрудник поддержки сказал, что изменения "базовых" механизмов всегда имеют последствия.
В ответ ему было предложено как минимизировать риски данных изменений:

Сейчас мы имеет 4 источника создания индексов:

1. Стандартные: по номеру, дате и кластерный по ссылке
2. Пользовательские: установка свойства «Индексировать» или «Индексировать с доп. упорядочиванием» у реквизита документа
3. Критерии отбора: когда реквизит документа входит в состав критерия отбора
4. Общий реквизит: когда документ входит в состав общего реквизита с включенным разделением данных.

Теперь об изменениях.

Давайте введем в платформу признак «Режим управления индексами базы данных» со значениями «Простой» и «Экспертный».

Простой – это как сейчас.

Экспертный рассмотрим далее.

В данном режиме у нас меняется режим отображения индексированных реквизитов документа: если сейчас это палитра свойств документа и другие объекты платформы(п. 3 и 4, описанные выше), то теперь все индексы документа будут располагаться на отдельной вкладке:

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

Итого: Мы просто меняем механизм отображения индексов в IDE, при этом никак не затрагивая механизм их создания, изменения, т.е. риски ошибок в базовом механизме платформы минимальны!

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

Далее мы немного развиваем этот механизм: даем возможность создавать произвольные индексы как было описано в кейсе.

Со стороны СУБД конструкция для создания индексов простая: CREATE NONCLUSTERED INDEX index_name.
Вот в принципе и все, как видите никакие базовые механизмы платформы мы кардинально не меняем.

[SeiOkami]

Отправлено боту 1С 06.04.2021 в 12:36

[SeiOkami]

В плане задач на 8.3.25 появилась такая строчка:

Повышение гибкости настройки индексов | Запланирована

Надеемся, что это то самое. Ставлю соответствующую метку