Вопрос о максимально возможном количестве документов в базе данных 1С:Предприятие 8.3 волнует многих администраторов и разработчиков при проектировании высоконагруженных систем. В отличие от старых версий (например, 1С 7.7), современная платформа в связке с промышленными СУБД предлагает практически неограниченные возможности, однако на практике мы сталкиваемся с рядом нюансов. Разберем подробно, от чего зависит "потолок" вашей базы и где на самом деле находятся критические точки.
Проанализируем сначала теоретические пределы. В 1С:Предприятие 8.3 для идентификации объектов (документов, справочников) используются уникальные идентификаторы — GUID (UUID). Это 128-битные числа, что теоретически позволяет создать $3,4 \times 10^{38}$ уникальных записей. С точки зрения адресного пространства, вы никогда не упретесь в ограничение количества ссылок.
Если мы рассматриваем SQL-серверы (MS SQL Server, PostgreSQL, Oracle), то они оперируют таблицами, которые могут содержать миллиарды строк. Рассмотрим важные аспекты:
Выясним причину, почему база может начать "тормозить" задолго до достижения физического лимита записей. В конфигурации Управление торговлей 11.4 создание одного документа реализации (Документ.РеализацияТоваровУслуг) порождает записи во множестве связанных таблиц:
Проанализируем ситуацию: если в документе 50 строк, он может создать 100–200 записей в различных таблицах движений. Таким образом, база "пухнет" не от самих документов, а от их движений по регистрам. Если регистры накопления спроектированы неоптимально (например, не закрываются итоги или не используются измерения), производительность упадет из-за роста таблицы итогов, а не из-за количества документов.
Рассмотрим подробнее вопрос взаимодействия пользователя с огромными массивами данных. Как показывает практика, база "сдыхает" не тогда, когда в нее записывают данные, а когда их пытаются отобразить.
В современных управляемых формах 1С используется ДинамическийСписок. Он считывает данные порциями (например, по 45–100 записей). Благодаря этому список документов из 10 миллионов записей открывается так же быстро, как из 100 штук. Однако в старых "толстых" формах или при попытке программного перебора всех данных без фильтров система может зависнуть. Основная нагрузка в этом случае ложится на индексы СУБД. Если индекс таблицы не помещается в оперативную память (RAM) сервера, СУБД начинает "свопиться" на диск, что замедляет работу в сотни раз.
Выясним, когда администратор скажет "стоп" росту базы. Настоящий предел определяется не программным кодом, а временем выполнения регламентных операций:
Чтобы ваша база "выдержала" как можно больше документов, рекомендуем придерживаться следующих правил:
1. Настройка версионирования объектов:
В УТ 11 по умолчанию может быть включено версионирование. Это значит, что при каждом изменении документа 1С копирует его целиком в регистр сведений ВерсииОбъектов. Разберем пример: если документ меняется 10 раз, он занимает в 10 раз больше места. Настройте расписание очистки устаревших версий.
2. Использование свертки базы:
Для "облегчения" системы периодически проводят свертку — удаление старых документов с переносом остатков на начало периода. Это позволяет держать объем данных в операционных пределах.
3. Мониторинг индексов:
Следите за тем, чтобы наиболее используемые индексы (по дате, по контрагенту) всегда находились в оперативной памяти сервера SQL.
4. Длина номера документа:
Рассмотрим технический момент из обсуждения: длина номера. Если в конфигурации задана длина номера 11 символов, это позволяет создать почти миллиард документов одного вида в год. Если вам этого мало, длину можно увеличить в Конфигураторе, но это скорее административная редкость, чем реальная проблема.
Платформа 1С 8.3 на SQL способна выдержать сотни миллионов и даже миллиарды документов. Ограничение не в количестве записей, а в мощности оборудования (RAM и скорость дисков NVMe) и административной возможности обслуживать такой объем данных. Пока у вас есть возможность расширять серверные мощности и проводить регламентные работы, база будет продолжать функционировать стабильно.