Чёрный пояс 1С: подчинённый справочник на 5+ млн записей - три варианта рефакторинга и критерии выбора
Пять миллионов строк в подчинённом справочнике - это не проблема дизайна. Это проблема времени: когда-то архитектура была разумной, и кто-то вынужден разбираться с её последствиями. Если ты сейчас смотришь на эту таблицу и думаешь «как мы сюда вообще попали», значит, пора разбираться. Вопрос «регистр или справочник» в общем виде мы разбирали отдельно - здесь конкретный кейс: уже есть подчинённый справочник с пятью миллионами записей, он тормозит, и нужно решать что делать.
Что происходит на самом деле
Связка «реквизит ссылочного типа в основном объекте → подчинённый справочник по этой ссылке» - классический паттерн. Допустим, в справочнике «Контрагенты» есть реквизит «Договор», который ссылается на «ДоговорыКонтрагентов». Всё работает хорошо, пока записей в подчинённом справочнике десятки тысяч. При пяти миллионах запросы начинают тормозить по нескольким причинам сразу.
Первая - СУБД не может эффективно использовать индекс по составному ключу «Владелец + Порядок», если выборка по владельцу возвращает тысячи строк. Второй - при каждом обращении к объекту платформа может подтягивать связанные записи, даже когда они не нужны явно. Третья - если подчинённый справочник используется в запросах без явной фильтрации по владельцу, планировщик СУБД делает полный скан.
Прежде чем выбирать вариант рефакторинга, надо понять, что именно тормозит: чтение по конкретному владельцу, массовые выборки без фильтра, или запись в обоих направлениях. От этого зависит, какой путь правильный.
Вариант первый - регистр сведений вместо подчинённого справочника
Самый трудоёмкий, но при выполнении критериев - наиболее долгосрочный вариант. Регистр сведений с измерением «Владелец» - независимый (без регистраторов) или с периодичностью «Не периодический» - это другая модель данных. Индексирование по измерениям в клиент-серверных базах (MSSQL / PostgreSQL) работает иначе: платформа строит кластерный индекс по измерениям, запрос «все записи для этого контрагента» превращается в точечный поиск, а не в скан по владельцу. На файловой базе это неприменимо - она ограничена по размеру задолго до пяти миллионов записей.
Этот путь подходит, когда выполняются все три условия: у записей нет собственной бизнес-логики в обработчиках ПриЗаписи, нет иерархии, и доступ к данным идёт преимущественно через запросы, а не через форму объекта.
Цена перехода - миграция данных и переписывание всех мест, где используется объектная модель подчинённого справочника. При пяти миллионах записей это нетривиально, но выполнимо пошагово: (1) создать новый регистр сведений с нужными измерениями и ресурсами; (2) написать обработку переноса с выборкой пакетами по 1000-5000 строк; (3) запустить перенос через фоновые задания (клиент-сервер) или циклом с подтверждением пользователя (файловая база); (4) переключить все запросы и формы на новый объект; (5) удалить подчинённый справочник после проверочного периода.
Вариант второй - индексы и оптимизация существующей структуры
Иногда проблема не в модели данных, а в том, что нужных индексов нет. В 1С подчинённый справочник автоматически получает индекс по полю «Владелец», но если в запросах есть дополнительные условия - по реквизиту «Актуален», «Дата», «Тип» - этот индекс не используется эффективно.
В этом случае можно добавить индекс по реквизиту в конфигураторе (свойство реквизита «Индексировать» - «Индексировать с дополнительным упорядочиванием»), а в запросах явно указывать этот реквизит в условии ГДЕ, чтобы оптимизатор СУБД мог использовать составной индекс.
Критерии выбора: проблема проявляется только в конкретных отчётах или формах, а не системно. Узкое место - конкретный запрос, а не архитектура в целом. Это путь наименьшего сопротивления с заметным, но ограниченным эффектом - порядки роста существенно меньше, чем при смене модели данных. Если объём данных продолжает расти, этот потолок придётся проходить повторно; при стабильном объёме может оказаться достаточным навсегда.
Вариант третий - денормализация через кэш-реквизиты
Если чаще всего нужно не всё содержимое подчинённого справочника, а одно-два агрегированных значения - «последний договор», «количество активных позиций», «сумма по открытым договорам» - имеет смысл хранить эти значения прямо в основном объекте. Реквизит «ДатаПоследнегоДоговора» в справочнике «Контрагенты», который обновляется при записи подчинённого объекта.
Это денормализация, и она нарушает «чистоту» модели. Зато запрос «дай мне всех контрагентов, у которых последний договор старше года» вместо JOIN с пятимиллионной таблицей читает один индекс основного справочника.
Критерии выбора: паттерн доступа к данным хорошо известен и стабилен, значений для кэширования немного (1-3 агрегата), и команда готова поддерживать синхронизацию через подписки на события. Если паттерн доступа будет меняться - этот путь создаёт технический долг быстрее, чем первые два.
Как выбирать на практике
Перед выбором архитектуры задай себе один вопрос: что именно болит прямо сейчас - медленное чтение конкретной записи, медленная выборка по всем записям владельца, или медленная запись? Ответ разный - путь разный. Без этого любой рефакторинг - стрельба по площади.
Три вопроса, которые стоит задать перед выбором.
Первый: что именно тормозит - читать или писать? Если запись, то денормализация и регистр решают по-разному, а оптимизация индексов не поможет совсем.
Второй: как часто читается вся коллекция по владельцу, а как часто - конкретные записи? Если в основном «дай все договоры контрагента» - регистр. Если «дай договор с таким-то номером» - оптимизация индексов может быть достаточной.
Третий: есть ли у записей бизнес-логика в обработчиках? Если ПриЗаписи подчинённого справочника делает что-то важное - провести рефакторинг с переходом на регистр сложнее, придётся эту логику переносить явно.
В проектах, с которыми сталкивалась редакция, переход на регистр плюс денормализация одного-двух агрегатов давал наилучший результат. Это не универсальный рецепт - отправная точка для анализа. Если объём данных стабилен и профиль запросов известен, оптимизация индексов может быть достаточной и постоянной мерой без переезда на другую модель данных.
Рефакторинг на пяти миллионах записей - это не страшно. Страшно обнаружить, что его откладывали два года, потому что «работает же».
Попробовать НОПик →