Пример реализации хранения файлов и изображений во внешней СУБД MS SQL

Преамбула

До сего момента в нашей организации в самописной конфе использовался стандартный механизм из типовой торговли - ХранилищеДополнительнойИнформации, но когда объем базы достиг 48 Гб (размер прикрепленных файлов - 35 Гб) база стала ощутимо тормозить.

Была проведена ревизия хранимых файлов: конечно выяснилось, что пользователи крепили информацию чуть ли не в BMP формате с глубиной цвета в 24 бит, но сути это не меняло - основная масса документов была в нормальном виде и их размер был обусловлен большим количеством отсканированых листов. Анализ SQL Profiler показал, что никаких ощутимо тяжелых запросов на базу не идет, тем не менее счетчики производительности дисковых массивов показывали 70% очередь в обычном режиме и 97-100% при работе регламентных заданий. Была выявлена закономерность, что когда работал обмен с головной организацией с которым приходило большое количество сканированных файлов то у пользователей наблюдалось зависание 1С. Что и натолкнуло на мысль разнести хранимые в системе файлы и сканы документов с данными конфигурации.

Действо

Сначала был рассмотрен вариант разнесения данных конфигурации и хранимых файлов по разным файловым группам внутри той же базы, что позволило бы вынести таблицу ХранилищаДополнительнойИнформации на отдельный дисковый массив. Это увеличило бы производительность базы, но не решило бы проблему быстро растущей базы, которая за последние 3 месяца прибавила 15Гб. Такую базу сложнее обслуживать и поддерживать тестовые базы, которых у нас 6 шт.

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

На MS SQL была создана база состоящая из 1 таблицы:

FileTable

• FileID - char(36), по данному полю желательно создать индекс.
• Object -varbinary

Имена могут быть другими, но тогда придется подправить запросы в предлагаемой конфигурации.

Для указанной базы был создан отдельный пользователь с правами dbo, такой вариант лучше с точки зрения безопасности. Дополнительно база была создана на другом дисковом массиве.

Плюсы данного решения в следующем:

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

Эпилог

Сначала я хотел перетащить данные с помощью SQL, но решил тащить все же 1С, т.к. не хотелось, чтобы инфа была сжатой, да и в сам справочник писать информацию о размере файла и его UID было удобнее. Выгрузка базы прилагается, обработка по переносу данных - тоже. Все процедуры реализующие описанный выше функционалу по связи с внешней базой посредством ADO собраны в конце общего модуля РаботаСФайлами.

В самой конфе вам придется кое-что подправить ручками, эти строки отмечены комментариями вида "//РУЧНЫЕ ИЗМЕНЕНИЯ". Настроить нужно будет параметры подключения к внешней базе и строку подключения к базе 1С, которая будет нужна для защиты хранилища данных, на случай доступа к нему из тестовых баз.

На текущий момент база находится в рабочем режиме под полной нагрузкой: 200-250 пользователей онлайн, 2 обмена с БП, 1 обмен с УТ и 1 обмен с головной. Зависания 1С пропали, очередь на дисках приобрела нормальные показатели в 50% и до 90% в пике. При пиковых нагрузках зависаний 1с больше не наблюдается.

Добавление: 20/09/10 добавлено регламентное задание по очистке SQL базы от ссылок которых больше нет в справочнике ХранилищеДополнительнойИнформации.