Рано или поздно перед любым администратором крупных информационных систем «1С» встает вопрос оптимизации дискового пространства и повышения производительности СУБД. Ситуация, когда рабочая база достигает размера 250 Гб при 500 активных пользователях, является классическим примером системы средней нагруженности. С одной стороны, база растет медленно, но с другой — запуск исторических отчетов за прошлые периоды начинает заметно снижать общую производительность системы.
В этой статье мы подробно проанализируем, почему стандартная свертка базы далеко не всегда является лучшим выходом, и разберем по шагам современные архитектурные подходы к масштабированию и оптимизации хранения данных на MS SQL Server.
Прежде чем приступать к радикальным мерам (таким как распределенные базы данных или правила обмена), давайте выясним реальные причины роста базы и рассмотрим альтернативные, более надежные варианты организации хранения.
Идея «частично подчистить рабочую базу» на первый взгляд кажется логичной, но на практике она таит в себе множество подводных камней. Давайте разберем, почему опытные специалисты не рекомендуют прибегать к свертке без жесткой необходимости:
Рассмотрим более эффективные и безопасные способы решения этой проблемы.
Проанализируем структуру таблиц вашей базы в MS SQL Server. В 90% случаев основной объем базы занимают не текстовые данные документов, а присоединенные файлы: сканы договоров, PDF-счета, изображения товаров и архивы. Хранить такие «тяжелые» бинарные данные непосредственно внутри SQL-таблиц крайне неэффективно.
Использование Библиотеки стандартных подсистем (БСП) позволяет легко решить эту проблему, настроив хранение файлов во внешних томах на сетевом диске. Давайте разберем, как это работает:
\\server\storage\1c_files).Результат: База SQL мгновенно «худеет» (иногда на 50–70%), операции резервного копирования (бэкапы) начинают проходить в разы быстрее, а оперативная память сервера СУБД перестает тратиться на кэширование тяжелого бинарного контента.
Начиная с платформы 8.3, в «1С» встроен штатный механизм создания копий баз данных. Этот инструмент идеально подходит для решения проблемы «тяжелых отчетов», которые мешают оперативной работе пользователей.
Мы можем настроить автоматическую репликацию выбранных таблиц (например, оборотных регистров, данных по продажам и закупкам) во внешнюю СУБД. В качестве получателя копии может выступать бесплатный PostgreSQL, развернутый на отдельном сервере, или специализированный Дата-акселератор (In-Memory DB от «1С»).
Начиная с версии платформы 8.3.27, Дата-акселератор поддерживает постоянное хранение данных на физическом диске. Это значит, что нам больше не нужно держать гигантские объемы оперативной памяти (ранее требовалось от 512 Гб RAM) — система подгружает архивные данные с диска по мере необходимости.
Для настройки копии базы данных на уровне платформы используется встроенный язык. Рассмотрим пример настройки копии базы данных:
// Создание и активация копии базы данных
КопияБД = КопииБазДанных.СоздатьПараметрыКопии();
КопияБД.Имя = "АналитическаяКопия";
КопияБД.СУБД = ТипСУБДКопииБазыДанных.PostgreSQL;
КопияБД.СтрокаПодключения = "Srvr=""ArchiveServer"";Ref=""archive_db"";Usr=""admin"";Pwd=""password"";";
КопииБазДанных.ЗаписатьПараметрыКопии(КопияБД);
КопииБазДанных.АктивироватьКопию(КопияБД.Имя);
После этого все тяжелые отчеты, построенные на СКД, платформа будет автоматически перенаправлять на эту копию, полностью освобождая ресурсы основной рабочей базы на MS SQL.
Если данные за прошлые года удалять нельзя, но скорость работы с актуальным периодом падает, мы можем прибегнуть к технологии секционирования таблиц непосредственно внутри СУБД MS SQL. Это прозрачный для платформы «1С» процесс, который позволяет физически разделить таблицы по временным интервалам.
Рассмотрим алгоритм действий системного администратора:
PRIMARY для текущего года и ARCHIVE для прошлых лет).Для конфигурации «1С» и для конечных пользователей база остается абсолютно единой. При этом СУБД при оперативной работе (проведении документов текущего дня) обращается только к быстрой секции, игнорируя гигабайты архивных данных.
Если физический размер рабочей базы все-таки критически важно удерживать в пределах определенных лимитов, мы можем организовать гибридную архитектуру. Схема выглядит следующим образом:
Если пользователю раз в год действительно понадобится открыть старый документ, система выполнит быстрый фоновый запрос к архивной базе через HTTP или Web-сервисы и отобразит данные «на лету» без захламления рабочей базы.
Посмотрим на пример простейшего веб-сервиса для получения структуры старого документа в формате JSON:
Функция ПолучитьДокументИзАрхива(ИдентификаторДокумента) Экспорт
УстановитьПривилегированныйРежим(Истина);
СсылкаНаДокумент = Документы.РеализацияТоваровУслуг.ПолучитьСсылку(Новый УникальныйИдентификатор(ИдентификаторДокумента));
Если СсылкаНаДокумент.ПолучитьОбъект() = Неопределено Тогда
Возврат "Документ не найден в архиве";
КонецЕсли;
// Формируем структуру данных для передачи в рабочую базу
ДанныеДокумента = Новый Структура;
ДанныеДокумента.Вставить("Номер", СсылкаНаДокумент.Номер);
ДанныеДокумента.Вставить("Дата", СсылкаНаДокумент.Дата);
ДанныеДокумента.Вставить("Контрагент", СсылкаНаДокумент.Контрагент.Наименование);
ЗаписьJSON = Новый ЗаписьJSON;
ЗаписьJSON.УстановитьСтроку();
ЗаписатьJSON(ЗаписьJSON, ДанныеДокумента);
Возврат ЗаписьJSON.Закрыть();
КонецФункции
Иногда корень проблем кроется не в размере базы, а в отсутствии должного администрирования СУБД. База в 250 Гб для MS SQL Server является относительно небольшой, и при грамотной настройке она должна работать мгновенно.
Убедимся, что на сервере настроены регулярные регламентные задания:
FULLSCAN для критически важных таблиц (таблицы итогов и остатков).Выполняя эти несложные рекомендации по оптимизации СУБД и выносу файлов во внешние тома, вы сможете сохранить целостность базы данных и обеспечить высокую скорость работы пользователей без необходимости проводить сложную и рискованную операцию свертки.