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

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

Действо

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

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

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

FileTable

Source: infostart.ru