Что работает быстрее: справочник или регистр сведений в 1С? Развенчиваем мифы на основе теста с 4 млн записей

В сообществе разработчиков 1С давно ведется спор о том, какой объект метаданных использовать для хранения больших массивов информации — справочник или независимый регистр сведений. Существует устойчивый миф, пришедший из старых обучающих курсов, что при объеме данных свыше миллиона записей справочник неизбежно «зависнет», поэтому для хранения плоских списков нужно использовать только регистры. Но так ли это на самом деле?

В этой статье мы подробно разберем практический эксперимент, проведенный на базе СУБД PostgreSQL с использованием современной платформы «1С:Предприятие», сравним показатели производительности справочника и регистра сведений при объеме в 4 миллиона строк и проанализируем глубинную внутреннюю кухню платформы 1С и СУБД.

Условия и методика проведения эксперимента

Проанализируем параметры тестового стенда, на котором проводилось сравнение:

• Версия платформы: 8.3.13.1644 (64-разрядная)
• СУБД: PostgreSQL 9.6
• Объем данных: 4 000 000 записей
• Структура объектов: Справочник и независимый непериодический регистр сведений имели абсолютно одинаковую структуру реквизитов. В состав реквизитов входило поле типа ХранилищеЗначения с большим объемом данных для имитации реальной нагрузки на дисковую подсистему.

Давайте посмотрим на результаты замеров производительности в ключевых операциях:

1. Поиск конкретного значения запросом: Результат абсолютно одинаковый. Обе таблицы возвращают результат с одинаковой скоростью.
2. Фильтрация в списке по одной колонке: Разницы нет, показатели идентичны.
3. Перемещение по списку (навигация в динамическом списке): Справочник продемонстрировал явное преимущество (Справочник ++). Навигация и прокрутка строк справочника выполняются плавнее.
4. Запись нового элемента / новой записи: Запись в справочник выполняется быстрее, чем в регистр сведений (Справочник ++).
5. Поиск в списке через стандартное поле глобального поиска: Справочник показал колоссальное преимущество (Справочник ++++++++). Поиск по регистру сведений привел к длительному ожиданию, тогда как справочник выдал результаты практически мгновенно.

Выясним причины такого поведения системы и разберем физические механизмы хранения данных.

1. Физическая структура таблиц в СУБД и скорость записи

Разберем подробнее, как СУБД физически располагает данные на диске и почему запись в справочник оказывается быстрее. Для анализа объема дискового пространства и размера таблиц СУБД пригодится обработка для оценки размера таблиц и индексов в разрезе метаданных 1С.

Для каждого типа объекта СУБД создает кластерный (физический) индекс:

• Справочники: Кластерным индексом таблицы справочника всегда является поле Ссылка (в СУБД это поле _IDRRef), которое хранит уникальный 16-байтный идентификатор (GUID). При генерации новых элементов платформа использует оптимизированные, последовательно возрастающие UUID (Sequential UUID). Это позволяет СУБД выполнять запись максимально «плоско» и последовательно. СУБД просто дописывает новые строки в конец таблицы без необходимости перетасовки старых данных на диске. Проверка уникальности кода или наименования выполняется по отдельным некластерным индексам, что не оказывает критического влияния на общую скорость вставки.
• Регистры сведений: У независимого регистра сведений нет уникального поля ссылки. Кластерный индекс здесь является составным. Он строится по совокупности всех измерений (а для периодических регистров — еще и по полю «Период»). При записи нового набора СУБД вынуждена осуществлять проверку уникальности по всему составному ключу и вставлять запись в строго определенное физическое место в кластерном индексе. Если новые записи имеют хаотичный набор измерений, это неизбежно приводит к так называемому расщеплению страниц (page splits) в СУБД, сильной фрагментации индекса и, как следствие, к существенному замедлению дисковых операций записи.

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

НаборЗаписей = РегистрыСведений.ТестовыйРегистр.СоздатьНаборЗаписей();
НаборЗаписей.ОбменДанными.Загрузка = Истина;
// Заполнение набора записей данными
НаборЗаписей.Записать();

2. Работа динамических списков и пагинация

Превосходство справочника при перемещении по списку напрямую связано с тем, как динамический список запрашивает данные у СУБД порциями (страницами). Проанализируем разницу в SQL-запросах, которые генерирует платформа 1С для СУБД:

• Для справочника уникальным идентификатором строки является одно простое поле — Ссылка. Чтобы выбрать следующую порцию данных при прокрутке списка вниз, СУБД выполняет быстрый и лаконичный запрос, условие выборки в котором выглядит как WHERE Ссылка > ПоследняяПолученнаяСсылка. Такой запрос идеально попадает в индекс и отрабатывает мгновенно.
• Для регистра сведений однозначным идентификатором строки выступает составной КлючЗаписи, состоящий из всех измерений регистра. Чтобы спозиционироваться на следующей странице данных, платформа вынуждена генерировать сложнейший SQL-запрос с множеством вложенных логических условий вида: WHERE (Измерение1 >= Последнее1) И (Измерение2 > Последнее2).... Подобные конструкции создают колоссальную нагрузку на оптимизатор запросов СУБД, снижая общую отзывчивость интерфейса при работе с многомиллионными регистрами.

3. Полнотекстовый поиск в списках

Фантастическая разница в скорости глобального поиска (Справочник ++++++++) объясняется использованием механизмов полнотекстового поиска (ПТС):

• Для справочников индексация в ПТС по умолчанию включена для всех строковых реквизитов, кода и наименования. При поиске в динамическом списке платформа обращается к предрассчитанному индексу ПТС, мгновенно получает список соответствующих ссылок и выводит их пользователю.
• Для регистров сведений полнотекстовый поиск зачастую отключен в свойствах конфигурации или не поддерживается для определенных типов измерений. В этом случае глобальный поиск вырождается в тяжелое сканирование всей таблицы СУБД (Table Scan) с использованием конструкции LIKE '%СтрокаПоиска%'. На таблице в 4 миллиона записей такой запрос гарантированно отправляет интерфейс системы в глубокое зависание.

4. Контроль ссылочной целостности и подчиненные структуры

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

Когда мы связываем один справочник с другим через свойство «Владелец», платформа 1С накладывает жесткий контроль ссылочной целостности. При записи элемента подчиненного справочника платформа под капотом выполняет неявные запросы для проверки физического существования владельца и накладывает дополнительные блокировки на таблицы СУБД. В регистрах сведений такой автоматической проверки «из коробки» нет. Регистр просто хранит ссылки в измерениях как плоские значения данных. Ответственность за контроль целостности в РС полностью лежит на разработчике, что делает запись в регистры более «легковесной» в сложных реляционных схемах при отсутствии жестких требований к ссылочной структуре.

Революционные оптимизации регистров сведений в современных версиях платформы (8.3.25 и выше)

Если в старых версиях платформы (включая тестовую 8.3.13) регистры сведений значительно уступали справочникам в сценариях частой и конкурентной перезаписи, то начиная с версии платформы 8.3.25 фирма 1С кардинально обновила механизмы работы с независимыми регистрами сведений. Переход на современные версии платформы и плановое обслуживание инфраструктуры обеспечивает Обновлятор 1С для автоматического архивирования и тестирования баз.

Рассмотрим ключевые нововведения, которые существенно повысили скорость работы с регистрами сведений:

Внедрение новых режимов записи (Слияние и Удаление)

Раньше метод Записать() для набора записей регистра работал по принципу полного замещения данных по отбору (сначала выполнялась операция удаления старых записей СУБД, затем вставка новых). Это приводило к избыточным блокировкам и фрагментации индексов. Теперь разработчикам доступно системное перечисление РежимЗамещения со следующими режимами:

• Слияние (Merge): В один шаг СУБД обновляет существующие записи (совпадающие по ключевым измерениям) и добавляет новые. Это исключает этап предварительного удаления, значительно снижает уровень блокировок и повышает скорость работы высоконагруженных очередей данных в разы.
• Удаление (Delete): Из базы физически удаляются только те записи, которые совпадают по ключевым полям с переданным набором данных. Для корректной очистки системы от информации по конкретному юридическому лицу применяется выборочное удаление организаций с рекурсивной очисткой связанных объектов.

Посмотрим на пример использования нового режима записи:

НаборЗаписей = РегистрыСведений.ИсторияСтатусов.СоздатьНаборЗаписей();
// Заполнение ключевых измерений и ресурсов
НоваяСтрока = НаборЗаписей.Добавить();
НоваяСтрока.Документ = СсылкаНаДокумент;
НоваяСтрока.Статус = Перечисления.СтатусыДокументов.Проведен;

// Используем новые возможности платформы 8.3.25
НаборЗаписей.Записать(Истина, РежимЗамещения.Слияние);

Режим сокращения типа при реструктуризации

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

Резюме: правила выбора объекта метаданных

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

• Выбирайте Справочник, если:
  1. Вам критически важна ссылка на объект (GUID) для связывания его с другими таблицами базы данных. При выполнении миграции между базами, в которых ссылки объектов не совпадают, используется перенос данных между похожими конфигурациями 1С по полям поиска.
  2. Данные будут активно выводиться в динамические списки пользователей с необходимостью быстрой навигации и полнотекстового поиска.
  3. Требуется иерархическая структура данных (группы и элементы).
• Выбирайте Регистр сведений, если:
  1. Вам требуется контролировать уникальность записей по нескольким полям одновременно (составной уникальный ключ).
  2. Данные имеют периодический характер (требуется хранить историю изменения срезов во времени).
  3. Вам не нужна ссылка на саму строку данных, и объект используется исключительно как плоская таблица для накопления технической, аналитической или служебной информации.

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