Как хранить большой справочник вне основной информационной базы 1С?

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

Использование механизма «Внешние источники данных»

Проанализируем первый и самый очевидный способ — использование объекта метаданных ВнешниеИсточникиДанных. Этот механизм позволяет подключаться к сторонним базам данных (через ODBC-драйверы) и работать с их таблицами так, будто это объекты 1С. Разберем основные аспекты этого подхода:

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

Этот метод идеально подходит, если справочник является по сути «архивным» или справочным классификатором, который редко меняется в самой 1С.

Секционирование таблиц на уровне MS SQL Server

Выясним причину, по которой иногда лучше не менять ничего в коде 1С, а воздействовать на уровне СУБД. Если ваша задача — не просто «вынести» данные, а распределить нагрузку на дисковую подсистему, нам поможет горизонтальное секционирование (Partitioning).

Посмотрим на этот процесс по шагам:

1. Создаем дополнительные файловые группы в базе данных MS SQL.
2. Размещаем файлы этих групп на разных физических дисках (например, старые данные на медленных HDD, новые — на быстрых SSD).
3. Определяем функцию и схему секционирования, которые разделят таблицу справочника (например, по диапазону кодов или дате создания).

Важное преимущество: Платформа 1С «не заметит» изменений. Она продолжит работать с одной таблицей, в то время как SQL Server сам будет распределять данные по разным физическим файлам. Это позволяет эффективно управлять дисковым пространством, не переписывая конфигурацию.

Механизм «Хранилище двоичных данных» (версии 8.3.21+)

Проанализируем современное решение, появившееся в последних релизах платформы. Механизм ХранилищеДвоичныхДанных предназначен для того, чтобы вынести содержимое реквизитов с типом ХранилищеЗначения во внешнее хранилище (например, файловую систему или S3-совместимое хранилище).

Разберем нюансы использования:

• Данный метод поможет только в том случае, если основной объем справочника составляют файлы: сканы документов, картинки, PDF-вложения.
• В самой таблице SQL останется только ссылка на файл (GUID).
• Для обычных текстовых реквизитов или чисел этот метод бесполезен, так как они все равно останутся в основной таблице справочника.

Сжатие данных (Data Compression)

Если вынос данных затруднен, рассмотрим вариант их «уплотнения» средствами СУБД. MS SQL Server поддерживает сжатие на уровне строк (Row) и страниц (Page). Выясним, как это работает:

Сжатие страниц позволяет находить повторяющиеся значения в блоках данных и заменять их короткими ссылками. Для справочников с большим количеством типизированных данных (например, одинаковые артикулы, города, статусы) это может дать экономию места до 50–70%.

1С официально поддерживает работу с включенным сжатием таблиц на стороне SQL. Это не выносит таблицу из базы, но радикально уменьшает её физический размер.

Гибридная архитектура «Прокси-справочник»

Рассмотрим креативный подход, который часто применяется в высоконагруженных системах. Суть заключается в разделении справочника на «легкую» и «тяжелую» части.

1. В основной базе 1С мы оставляем справочник, содержащий только поля для поиска: Код, Наименование, Ссылка. Это обеспечит работу ссылочной целостности и быстрый подбор.
2. Все дополнительные тяжелые данные (длинные описания, технические характеристики, историю изменений) переносим в отдельную базу SQL или NoSQL (например, ClickHouse или MongoDB).
3. В момент открытия карточки товара в 1С мы программно подтягиваем данные из внешней системы.

Пример программного обращения к внешней базе через ADO для получения данных:

Connection = Новый COMОбъект("ADODB.Connection");
Connection.Open("Driver={SQL Server};Server=ExternalServer;Database=ExtraData;Uid=user;Pwd=password;");
RecordSet = Connection.Execute("SELECT FullDescription FROM CatalogDetails WHERE GUID = '" + Строка(СсылкаНаОбъект.УникальныйИдентификатор()) + "'");
Если Не RecordSet.EOF Тогда
    ТяжелоеОписание = RecordSet.Fields("FullDescription").Value;
КонецЕсли;
Connection.Close();

Профилактика и очистка

Прежде чем приступать к радикальным мерам, проанализируем, чем именно заняты эти 22 Гб. Очень часто рост справочника вызван не реальными данными, а сопутствующим «мусором»:

• Версионирование объектов: Проверьте регистр сведений ВерсииОбъектов. Часто история изменений занимает в 5–10 раз больше места, чем сами данные справочника. Настройте регламент очистки старых версий.
• Индексы: В MS SQL размер индексов может превышать размер самой таблицы. Выполните реорганизацию и дефрагментацию индексов.
• Дубли: Проведите поиск и слияние дублей. В справочниках на 40 млн элементов часто содержится до 20–30% избыточных записей, возникших из-за некорректных обменов.

Таким образом, выбор метода зависит от характера данных. Для файлов используйте ХранилищеДвоичныхДанных, для огромных таблиц с данными — Секционирование или ВнешниеИсточникиДанных, а для оптимизации текущего хранения — Сжатие страниц и очистку ВерсийОбъектов.