Влияние дополнительных индексов на объем базы данных 1С-SQL   

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

• Движение()
• ДвижениеПриход()
• ДвижениеРасход()
• Итог()
• Итоги()
• Остатки()
• Остаток()
• СводныеИтоги()
• СводныйИтог()
• СводныеОстатки()
• СводныйОстаток()
• УстановитьФильтр()

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

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

Тестировать будем просто. Для каждого из вариантов сожмем базу средствами SQL-сервера Shrink Database. Для максимального сжатия установим опцию перемещения страниц к началу - в этом режиме страницы данных и индексов будут уплотнены до минимального размера. Для того, чтобы сжатие сработало, база данных должна находится в режиме Simple (почитать можно здесь). Мы сравним как объем базы в целом, так и объем страниц данных и индексов для таблиц итогов и движений тестируемого регистра. В качестве тестового регистра возьмем регистр  "Партии". В моем случае там 4 измерения. Ниже представлен рисунок сжатия базы в режиме отсутствия отметок отбора.

Вот результат сжатия базы после перестройки базы с установкой всех отборов по регистру.

Разница видна сразу - база возросла с 713 до 939 Мегабайт. Разница - 226 Мегабайт.

Теперь посмотрим за счет чего изменился объем базы, воспользуемся обработкой по анализу таблиц баз данных из этой статьи. Запустим ее для обоих вариантов. Не забудьте предварительно нажать кнопку «Обновить», так как часто статистика не соответствует реальной. Ниже, на картинке представлены данные обоих вариантов, сведенные в одну общую таблицу.

Как видно, объем индексов увеличился на порядки - с 242 и 192 Килобайт в начале до 166 и 43 Мегабайт в конце для таблиц движений и итогов соответственно. Кроме того приблизительно на 25% увеличился объем данных таблицы движений, за счет того, что при добавлении индекса добавляется дополнительное поле DATE_TIME_IDDOC длиной в 23 байта в таблицу движений.

Выводы отсюда таковы - если база данных транзакционная, то большие накладные расходы на обслуживание дополнительных индексов (в моем примере 7 дополнительных индексов: 4 для движений и 3 для итогов) делают невыгодным наличие дополнительных индексов. Если же база данных аналитическая, то проведения документов в базе нет, а при построении отчетов скорость их будет увеличена по сравнению со стандартной. Так как в большинстве случаев базы данных смешанные, то можно пользоваться дополнительными индексами только при наличии явной необходимости, а лучше оптимизировать структуру регистра, как описано в предыдущей статье.

Перепечатка, воспроизведение в любой форме, распространение, в том числе в переводе, любых материалов с сайта www.softpoint.ru возможны только с письменного разрешения компании "СофтПоинт". Это правило действует для всех без исключения случаев, кроме тех, когда в материале прямо указано разрешение на копирование (основание: Закон Российской Федерации "Об авторском праве и смежных правах").