← На главную

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

Имеет ли смысл разделять хранение файлов на два регистра сведений?

Разберем ситуацию с точки зрения архитектуры СУБД. В платформе 1С бинарные данные файлов помещаются в реквизиты с типом ХранилищеЗначения. На уровне реляционных баз данных (таких как MS SQL Server или PostgreSQL) подобные поля обрабатываются как LOB (Large Object). Это означает, что если размер содержимого превышает несколько килобайтов, СУБД физически размещает его вне основных строк таблицы — на специализированных страницах данных LOB, оставляя в основной строке лишь указатель.

Следовательно, разделение одного логического массива файлов на два отдельных регистра (например, «ОсновныеФайлы» и «ДополнительныеФайлы»):

1. Не дает выигрыша по занимаемому дисковому пространству. Суммарный объем страниц LOB останется прежним независимо от количества таблиц.
2. Не ускоряет индексный поиск. Скорость поиска по ключевым полям (измерениям) не страдает от наличия LOB-полей, так как само тело файла считывается только при явном обращении к ресурсу.
3. Усложняет программный код и интерфейс. Вместо работы с единой структурой разработчику приходится дублировать логику чтения, записи, контроля прав и отображения форм для двух различных объектов конфигурации.

Если требуется логически разделять файлы на основные и дополнительные, гораздо эффективнее добавить в структуру единого регистра измерение или реквизит с типом перечисления ВидФайла.

Подводные камни хранения файлов внутри базы данных СУБД

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

1. Нагрузка на оперативную память сервера приложений. При чтении реквизита с типом ХранилищеЗначения файл полностью загружается в память рабочего процесса сервера 1С (rphost). Если несколько пользователей одновременно открывают или выгружают тяжелые файлы (от 1 до 5 МБ), это провоцирует лавинообразный рост потребления RAM и может вызвать аварийный перезапуск рабочих процессов.
2. Разрастание журнала транзакций и фрагментация. Активная запись файлов, а тем более их последующее удаление или перемещение в архив, перегружает журнал транзакций (LDF в MS SQL Server или WAL в PostgreSQL). При этом физический размер файлов базы данных автоматически не уменьшается, а операции сжатия (shrink) на рабочих базах приводят к критической фрагментации индексов.
3. Резкое увеличение времени резервного копирования. База данных раздувается до сотен гигабайт или терабайтов, что делает процесс ежедневного полного бэкапа и последующего тестового восстановления долгим и ресурсоемким.
4. Ограничения версий СУБД. В файловом режиме лимит на размер одной таблицы составляет 4 ГБ, а в бесплатных редакциях СУБД (например, MS SQL Server Express) лимит всей базы ограничен 10 ГБ. В таких условиях хранение файлов внутри базы приведет к блокировке работы в кратчайшие сроки.

Оптимальные архитектурные решения для хранения файлов

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

Вариант 1. Использование механизма томов на диске (рекомендованный подход)

В типовых конфигурациях на базе Библиотеки стандартных подсистем (БСП) реализован механизм разделения: в самой базе данных хранятся только метаданные (наименование, размер, дата, ссылка на объект-владелец, контрольная сумма), а сами бинарные файлы физически записываются на сетевые тома (папки на сервере или в локальной сети).

Преимущества данного подхода:

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

Важная техническая деталь: права доступа к сетевой папке (UNC-пути) должны быть предоставлены не учетным записям пользователей, а учетной записи операционной системы, под которой запущен агент сервера 1С:Предприятия (по умолчанию usr1cv8), так как все операции с файлами на томах выполняет серверный процесс.

Вариант 2. Гибридное хранение и архивирование

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

1. Файлы за текущий период (например, последние 1–3 месяца) сохраняются непосредственно в базе данных для максимальной целостности при создании моментальных снимков базы.
2. По истечении срока регламентное задание переносит бинарное содержимое на файловый сервер, в S3-совместимое объектное хранилище или архивный контур, оставляя в регистре признак переноса и путь к файлу.

Если для архива создается отдельная база 1С, не рекомендуется организовывать обмен через устаревший механизм COM-соединения. COM привязан к среде Windows, не поддерживается на серверах под управлением Linux и медленно отрабатывает в многопоточном режиме. Взаимодействие между основной и архивной базой эффективнее реализовать через встроенные HTTP-сервисы с использованием объекта HTTPСоединение, передавая бинарные потоки напрямую.

Правила разработки при работе с бинарными данными

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

1. Запрет на использование хранилища в динамических списках. Категорически запрещено выводить ресурс с типом ХранилищеЗначения в форму списка регистра или использовать его в запросе динамического списка. В противном случае платформа будет вычитывать тяжелые бинарные данные для каждой отображаемой строки, что парализует работу пользовательского интерфейса. Список должен содержать только метаданные: имя, расширение, размер.
2. Дедупликация файлов. Добавим измерение или реквизит для хранения контрольной суммы файла (например, MD5 или SHA-256). Это позволит алгоритму перед записью проверять, существует ли уже такой файл в системе, и избегать дублирования одинаковых бинарных данных, если разные документы ссылаются на один и тот же файл.