При проектировании систем на платформе 1С:Предприятие 8 разработчики часто сталкиваются с задачей выбора оптимального места для хранения текстовых данных. Это могут быть логи, описания товаров, объемные JSON-ответы от сторонних сервисов или просто произвольные заметки. Правильный выбор влияет не только на удобство разработки, но и на общую производительность системы, размер базы данных и скорость выполнения бэкапов.
В этой статье мы подробно разберем все доступные механизмы, проанализируем их технические особенности на уровне СУБД и выясним, какой метод лучше всего подходит под конкретные задачи. Рассмотрим ситуацию, когда текст нужно считывать по определенному ключу, при этом данные не всегда должны быть привязаны к конкретному пользователю.
Если текстовая информация представляет собой независимую сущность, которую нужно быстро находить по определенному ключу (например, по коду товара или уникальному идентификатору внешней системы), использование Регистра сведений (РС) является одним из наиболее предпочтительных вариантов. Проанализируем, как это реализовать правильно.
Для хранения текста в регистре сведений следует использовать Ресурсы. Крайне важно помнить: никогда не используйте строки неограниченной длины в качестве Измерений. Это технически невозможно для большинства СУБД и приведет к критическим ошибкам производительности. Посмотрим на структуру такого регистра:
КлючДоступа (Строка фиксированной длины или УникальныйИдентификатор).ТекстДанных (Строка неограниченной длины или ХранилищеЗначения).Разберем подробнее, что происходит на уровне базы данных. В SQL Server строка неограниченной длины преобразуется в тип nvarchar(max). Если размер текста превышает 8000 байт, СУБД автоматически выносит эти данные на отдельные LOB-страницы (Large Object), оставляя в основной таблице только указатель. Это позволяет сканировать таблицу регистра очень быстро, если само текстовое поле не запрашивается в запросе.
Если текстовая информация логически привязана к какому-либо объекту (например, «Инструкция к товару»), логично хранить её в Справочнике. Рассмотрим ситуацию, когда нам нужно хранить тексты, не привязанные к существующим объектам метаданных. В этом случае создается отдельный справочник, где наименование или код служат ключом, а текст хранится в реквизите.
Использование справочников дает ряд преимуществ:
Однако, если основной задачей является именно быстрый доступ «ключ-значение» без необходимости визуального отображения в списках, регистр сведений будет работать быстрее за счет отсутствия избыточных полей (таких как ссылка, пометка удаления и т.д.).
Когда речь идет о действительно больших объемах текста (от 1 МБ и выше), стоит рассмотреть объект ХранилищеЗначения. Рассмотрим подробнее механизм его работы. В отличие от обычных строковых реквизитов, ХранилищеЗначения поддерживает автоматическое сжатие данных по алгоритму zlib.
Проанализируем пример кода для записи и чтения текста:
// Запись текста в ресурс регистра сведений или реквизит справочника
ТекстДляХранения = "Очень большой объем текста...";
Запись = РегистрыСведений.ХранилищеТекстов.СоздатьМенеджерЗаписи();
Запись.Ключ = "УникальныйКлюч_1";
Запись.Данные = Новый ХранилищеЗначения(ТекстДляХранения, Новый СжатиеДанных(9));
Запись.Записать();
// Чтение текста
ЗаписьЧтения = РегистрыСведений.ХранилищеТекстов.СоздатьМенеджерЗаписи();
ЗаписьЧтения.Ключ = "УникальныйКлюч_1";
ЗаписьЧтения.Прочитать();
Если ЗаписьЧтения.Выбран() Тогда
НужныйТекст = ЗаписьЧтения.Данные.Получить();
КонецЕсли;
Преимущества Хранилища значения:
Недостатки:
Выясним причину, по которой многие выбирают именно «Строку неограниченной длины». Если вашей системе требуется, чтобы пользователи могли находить документы или записи по фрагментам текста, вам необходим Полнотекстовый поиск (ПП).
Для строк неограниченной длины (в реквизитах или ресурсах) достаточно установить свойство «Полнотекстовый поиск — Использовать». Платформа 1С сама построит индекс и позволит выполнять поисковые запросы. В случае с ХранилищемЗначения вам придется программно извлекать текст и передавать его в индекс, что значительно усложняет разработку.
Проанализируем ситуацию, когда объем текстовой информации исчисляется гигабайтами (например, логи обмена). Хранение таких данных внутри SQL-базы приводит к её «раздуванию», замедлению обслуживания (CheckDB, реиндексация) и увеличению времени создания резервных копий.
В современных реалиях рекомендуется использовать:
Рассмотрим важный аспект работы с оперативной памятью. При чтении текста неограниченной длины или объекта из ХранилищаЗначения, 1С считывает данные в память целиком. Если в базе хранятся тексты объемом по 100 МБ, и их одновременно запросят 10 пользователей, рабочий процесс rphost может мгновенно исчерпать доступную память и аварийно завершиться.
Совет: Если вам нужно работать с очень большими текстами, старайтесь обрабатывать их порциями или записывать во временные файлы на стороне сервера, не загружая в переменные целиком.
Подведем итог нашему анализу и определим лучшее место для хранения в зависимости от условий:
Выбирая способ хранения, всегда ориентируйтесь на баланс между удобством поиска и нагрузкой на дисковую подсистему и оперативную память сервера.