Как правильно организовать хранение большого объема файлов и документов в 1С?

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

Анализ идеи: отдельная база данных под каждого контрагента или проект

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

1. Деградация кластера серверов 1С: процессы кластера (rmngr, rphost) расходуют значительные объемы оперативной памяти на поддержание метаданных, пулов соединений и фоновых заданий для каждой зарегистрированной базы, даже если она простаивает. Сотни баз быстро исчерпают ресурсы сервера.
2. Сложность администрирования: регламентные процедуры СУБД, мониторинг целостности, централизованное резервное копирование и регулярное обновление конфигураций превращаются в тяжелую эксплуатационную нагрузку.
3. Неэффективность внешних источников данных (ВИД): встроенные таблицы внешних источников не оптимизированы для передачи больших бинарных данных (BLOB). Чтение и сохранение файлов через ВИД лишены потоковых оптимизаций, вызывают просадки сетевого интерфейса и не обеспечивают транзакционную целостность.
4. Накладные расходы веб-сервисов: передача бинарных массивов через стандартные протоколы (SOAP/REST) в кодировке Base64 увеличивает сетевой трафик и расход оперативной памяти минимум на треть.

Почему файловая система превосходит хранение в СУБД

Специализированная файловая система — это наиболее эффективная среда для хранения бинарных данных. Сравним хранение непосредственно в СУБД (в реквизитах типа ХранилищеЗначения) и на дисковых томах:

1. Экономия буферного пула СУБД: при хранении бинарных файлов в таблицах СУБД чтение тяжелых данных моментально вымывает полезные кэшированные индексы и оперативные таблицы из оперативной памяти сервера базы данных.
2. Оптимизация журналов транзакций: запись тяжелых файлов приводит к взрывному росту журналов (LDF в MS SQL или WAL в PostgreSQL) и высокой нагрузке на базу временных таблиц (tempdb).
3. Упрощение резервного копирования: базу данных без файлов можно копировать за считанные минуты, а тома с файлами архивировать дифференциально стандартными средствами операционной системы.

Организация хранения файлов с помощью подсистемы БСП

В типовых решениях («1С:ERP», «1С:Комплексная автоматизация», «1С:Управление торговлей», «1С:Документооборот») и в «Библиотеке стандартных подсистем» (БСП) предусмотрен готовый механизм «Присоединенные файлы». Он решает задачу разделения метаданных и физических файлов «из коробки».

Рассмотрим структуру метаданных, используемую в этом механизме:

1. Справочник метаданных файла: например, Справочник.ДоговорыКонтрагентовПрисоединенныеФайлы. Он содержит реквизиты: наименование, расширение, размер, контрольную сумму (MD5 или SHA-256), автора, признак редактирования и ссылку на владельца.
2. Справочник «Тома хранения файлов»: содержит пути к каталогам на сервере (локальным путям или сетевым ресурсам UNC/NFS), максимальный объем тома и лимиты.
3. Регистр сведений: опционально используется для хранения бинарных частей файла, если хранение настроено в информационной базе, либо для версионирования.

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

Решение проблемы производительности файловой системы: хэширование путей

При хранении сотен тысяч файлов в одном каталоге файловая система (особенно NTFS) испытывает серьезное падение производительности при операциях перечисления файлов, синхронизации и резервном копировании. Для предотвращения деградации каталоги необходимо иерархически разделять.

Проанализируем правильный алгоритм распределения файлов по структуре папок с использованием хэш-суммы:

1. Для каждого загружаемого файла рассчитывается хэш (например, MD5 или SHA-1).
2. Первые 2–4 символа хэша используются в качестве имен подкаталогов, что дает равномерное распределение нагрузки.
3. Файл сохраняется с уникальным идентификатором (GUID) или самим хэшем в качестве имени.

Посмотрим на пример формирования пути сохранения файла на сервере:

Функция ПолучитьОтносительныйПутьКФайлу(ХэшФайла, Расширение) Экспорт
    // Берем первые два символа для каталога первого уровня
    ПапкаУровень1 = Сред(ХэшФайла, 1, 2);
    // Берем следующие два символа для каталога второго уровня
    ПапкаУровень2 = Сред(ХэшФайла, 3, 2);
    
    // Формируем относительный путь: \ab\cd\abcdef1234567890.pdf
    ИмяФайла = ХэшФайла + ?(ПустаяСтрока(Расширение), "", "." + Расширение);
    ОтносительныйПуть = ПапкаУровень1 + "\" + ПапкаУровень2 + "\" + ИмяФайла;
    
    Возврат ОтносительныйПуть;
КонецФункции

Защита производственных томов от перезаписи из копий базы

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

Для защиты необходимо использовать следующие правила:

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

Использование объектных S3-хранилищ (MinIO, Ceph)

В современных высоконагруженных системах сетевые папки SMB/NFS вытесняются объектными хранилищами, совместимыми с протоколом S3 (например, открытым решением MinIO). Это дает существенные преимущества:

1. Отсутствие файловых блокировок ОС при параллельном обращении множества пользователей.
2. Возможность масштабирования хранилища без привязки к дисковой разметке одного сервера.
3. Использование механизма преподписанных ссылок (Presigned URLs), когда платформа 1С лишь генерирует временную ссылку, а клиент скачивает файл напрямую из S3, снимая сетевую нагрузку с кластера серверов 1С.

Итог

Создание отдельных баз данных 1С под каждого контрагента или проект для хранения файлов архитектурно нецелесообразно и быстро парализует администрирование системы. Оптимальным решением является использование единой рабочей конфигурации со стандартной подсистемой присоединенных файлов (БСП), где файлы физически выносятся на серверные тома хранения или в объектное S3-хранилище с обязательным разбиением по подкаталогам на основе дат или хэш-сумм.