Полнотекстовый поиск в 1С: почему мы отключили его для 860 объектов

Полнотекстовый поиск в 1С — штука полезная. Нашёл контрагента по части названия, документ по номеру, товар по описанию. Удобно. Проблема в том, что по умолчанию он включён для всех объектов метаданных. Всех. Включая регистры накопления, регистры сведений, перечисления и обработки. Объекты, по которым никто никогда не будет искать текстовым поиском.

В одном из проектов мы обнаружили, что полнотекстовый поиск (ПТП) был включён для 1097 объектов метаданных. Тысяча с лишним. При каждом обновлении индекса ПТП платформа перебирала изменения во всех этих объектах. Обновление занимало десятки минут и создавало ощутимую нагрузку на SQL Server.

Как устроен полнотекстовый поиск внутри

Платформа 1С использует собственный механизм полнотекстового индексирования (не SQL Server Full-Text Search). При каждом изменении данных в объекте, для которого включён ПТП, запись попадает в очередь на индексацию. Регламентное задание «Обновление индекса полнотекстового поиска» периодически обрабатывает эту очередь.

Чем больше объектов с включённым ПТП — тем больше очередь, тем дольше обновление индекса, тем больше нагрузка на диск и CPU. Даже если ПТП включён для регистра накопления, по которому ни один пользователь никогда не будет искать текстовым поиском, — платформа всё равно индексирует каждое изменение.

Второй эффект: размер индекса ПТП. На базе с 860 лишними объектами индекс занимал 12 ГБ. После очистки — 2.8 ГБ. Меньше индекс — быстрее поиск для тех объектов, где он действительно нужен.

Третий эффект менее очевидный, но существенный: нагрузка на SQL Server. При каждом обновлении индекса ПТП платформа выполняет SELECT из таблиц всех объектов с включённым ПТП, чтобы найти изменённые записи. Даже если изменений нет — запросы выполняются. 860 объектов — 860 запросов при каждом обновлении. На загруженном сервере это ощутимо.

Четвёртый эффект: при обновлении конфигурации 1С (регулярная операция при доработках) платформа пересоздаёт индексы ПТП для всех изменённых объектов. Чем больше объектов с ПТП — тем дольше этап «Обновление полнотекстового индекса» при обновлении. На крупных конфигурациях это может добавлять 10-20 минут к времени деплоя.

Аудит: что было включено

Мы провели аудит конфигурации — стандартной 1С:ERP 2.5 с доработками. Полнотекстовый поиск был включён (свойство «Использование полнотекстового поиска» = «Использовать») для следующих категорий:

• Регистры сведений: 320 объектов. Курсы валют, настройки, служебные данные — текстовый поиск по ним не нужен
• Регистры накопления: 180 объектов. Движения документов, остатки — ищут по запросам, не текстовым поиском
• Регистры бухгалтерии: 85 объектов. Проводки — аналогично
• Перечисления: 95 объектов. Фиксированные списки — зачем по ним искать?
• Обработки: 60 объектов. Не содержат данных для поиска
• Прочие справочники: 120 объектов. Служебные классификаторы, настроечные справочники

Отдельная категория — планы обмена и последовательности. Технически они тоже могут иметь включённый ПТП, хотя практической пользы от этого нет никакой. В нашем проекте таких объектов оказалось 18 — мелочь по сравнению с регистрами, но убрали и их.

Итого 860 объектов, для которых ПТП включён без необходимости.

Что оставили

Полнотекстовый поиск оставили для 237 объектов:

• Все документы: 222 объекта. Пользователи реально ищут документы по номеру, контрагенту, комментарию
• Справочник Контрагенты: поиск по названию, ИНН, части реквизитов
• Справочник Номенклатура: поиск по наименованию, артикулу, штрихкоду
• Справочник Сотрудники / ФизическиеЛица: поиск по ФИО
• Несколько ключевых справочников с пользовательскими данными

Критерий простой: если пользователь может нажать Ctrl+F (или ввести текст в строку поиска) и ожидать результат из этого объекта — оставляем. Если объект — внутренний механизм конфигурации — выключаем.

Третий критерий: частота изменений. Справочник «Номенклатура» меняется редко — добавили товар, изменили название. Индексация стоит копейки. Регистр накопления «ТоварыНаСкладах» меняется тысячи раз в день. Индексировать его бессмысленно дорого, а искать текстовым поиском по движениям регистра никто не будет.

Мы составили чек-лист из трёх вопросов для каждого объекта: 1) Пользователь будет искать в нём текстом? 2) Данные в нём читаемые (текст, названия, номера)? 3) Объект меняется реже 100 раз в час? Если хотя бы на один вопрос ответ «нет» — ПТП выключаем.

После аудита мы обнаружили ещё одну проблему: некоторые документы с включённым ПТП содержали в реквизитах только числовые значения (суммы, количества). Текстовый поиск по числам теоретически возможен, но на практике никто не ищет документы по сумме через строку полнотекстового поиска. Эти документы тоже кандидаты на отключение, хотя мы их оставили — на общем фоне их вклад минимален.

Как отключали

В конфигураторе нет массовой операции «отключить ПТП для N объектов». Каждый объект — отдельно: открыть свойства, найти «Полнотекстовый поиск», переключить на «Не использовать». 860 раз.

Мы пошли другим путём: выгрузили конфигурацию в XML (ВыгрузитьКонфигурациюВФайлы), написали скрипт, который находит все XML-файлы с тегом <FullTextSearch>Use</FullTextSearch> и заменяет на DontUse — исключая документы и ключевые справочники из белого списка.

# Замена ПТП для всех объектов, кроме белого списка
find . -name "*.xml" -not -path "*/Documents/*" \
  -not -path "*/Catalogs/Контрагенты/*" \
  -not -path "*/Catalogs/Номенклатура/*" \
  -not -path "*/Catalogs/Сотрудники/*" \
  -exec sed -i 's/<FullTextSearch>Use/<FullTextSearch>DontUse/g' {} +

Итого: 7581 замена в XML-файлах. Загрузили обратно в конфигуратор, обновили базу данных.

Результат

Эффект проявился сразу по нескольким направлениям:

Обновление индекса ПТП: с 47 минут до 8 минут. Регламентное задание, которое раньше нагружало сервер почти час, теперь отрабатывает за несколько минут. Освободились ресурсы CPU и диска в рабочее время.

Размер индекса ПТП: с 12 ГБ до 2.8 ГБ. Меньше данных на диске, меньше нагрузка при полной перестройке индекса.

Скорость текстового поиска: субъективно быстрее. Меньший индекс — быстрее поиск по тем объектам, где он реально используется. Точных замеров не делали, но пользователи отметили разницу.

Обновление конфигурации: при обновлении конфигурации платформа пересоздаёт индекс ПТП для изменённых объектов. Чем меньше объектов с ПТП — тем быстрее обновление.

Что делать после отключения

После массового отключения ПТП нужно пересоздать индекс полнотекстового поиска. Старый индекс содержит данные по всем 1097 объектам — он уже не нужен.

В конфигураторе: Все функции → Полнотекстовый поиск → Очистить индекс → Обновить индекс. Или программно:

// Очистка и перестроение индекса ПТП
ПолнотекстовыйПоиск.ОчиститьИндекс();
ПолнотекстовыйПоиск.ОбновитьИндекс();

Первое обновление индекса после очистки займёт больше обычного — платформа индексирует все существующие данные для оставшихся 237 объектов с нуля. На базе 80 ГБ это заняло около 40 минут. Но это разовая операция. Последующие обновления (инкрементальные) — 5-8 минут.

После перестроения проверьте, что поиск работает корректно: попробуйте найти контрагента, документ, товар. Если что-то не находится — возможно, объект случайно попал в «чёрный список» при массовом отключении. Вернуть ПТП для одного объекта — дело минуты.

Автоматизация аудита

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

Логика скрипта:

1. Обходит все XML-файлы объектов метаданных
2. Считает количество объектов с FullTextSearch = Use
3. Разбивает по категориям: документы, справочники, регистры, перечисления, обработки
4. Формирует отчёт: сколько объектов включено, сколько рекомендуется отключить
5. Генерирует скрипт замены с белым списком

Скрипт прогоняется за 10 секунд и выдаёт готовый набор команд sed для замены. Остаётся только проверить белый список и запустить.

Белый список для типовых конфигураций 1С (ERP, УТ, КА) примерно одинаковый: документы + 5-10 ключевых справочников (Контрагенты, Номенклатура, Сотрудники, Организации, Договоры). Различия — только в специфических справочниках для конкретной конфигурации.

Мониторинг после оптимизации

После отключения лишних объектов важно убедиться, что очередь индексации не растёт. Если КоличествоВОчереди стабильно около нуля — всё хорошо. Если растёт — значит, скорость индексации не успевает за потоком изменений даже после оптимизации.

Добавьте проверку очереди ПТП в мониторинг. Простейший вариант — регламентное задание, которое раз в час проверяет размер очереди и пишет в журнал регистрации:

КоличествоВОчереди = ПолнотекстовыйПоиск.КоличествоВОчереди();
Если КоличествоВОчереди > 10000 Тогда
    ЗаписьЖурналаРегистрации(
        "ПТП.ОчередьРастёт",
        УровеньЖурналаРегистрации.Предупреждение,,,
        "В очереди ПТП: " + КоличествоВОчереди);
КонецЕсли;

Порог 10 000 — ориентировочный. Для активной торговой базы нормально иметь в очереди несколько сотен записей — они обрабатываются при следующем запуске регламентного задания. Если очередь стабильно выше 10 000 — индексация не справляется.

Когда ПТП — зло

Полнотекстовый поиск становится проблемой в двух сценариях:

Первый: большая активная база с частыми изменениями данных. Регистры накопления в торговой сети — тысячи движений в минуту. Если ПТП включён для регистра, каждое движение попадает в очередь индексации. При 10 000 движений в час очередь может расти быстрее, чем обрабатывается.

Второй: конфигурация с большим количеством объектов метаданных. 1С:ERP, 1С:Комплексная автоматизация, 1С:УТ — тысяча объектов и больше. Если ПТП включён для всех по умолчанию, индекс разрастается до десятков гигабайт.

Рекомендация: при внедрении любой крупной конфигурации — провести аудит ПТП. 15 минут на скрипт + 2 часа на выгрузку/загрузку конфигурации = экономия часов серверного времени каждый день.

Как проверить текущее состояние

Быстрая проверка без выгрузки в XML: в конфигураторе откройте «Все функции» → «Полнотекстовый поиск» → «Обновить индекс». Посмотрите время выполнения. Если обновление занимает больше 15 минут на базе до 50 ГБ — стоит провести аудит.

Программно — через встроенные средства:

// Проверка состояния ПТП
МенеджерПТП = ПолнотекстовыйПоиск.ПолучитьМенеджер();
Сообщить("Дата актуальности: " + МенеджерПТП.ДатаАктуальности());
Сообщить("Количество в очереди: " + МенеджерПТП.КоличествоВОчереди());

Если КоличествоВОчереди постоянно больше нуля и растёт — индексация не успевает за изменениями. Значит, ПТП включён для слишком многих объектов, или сервер не справляется с нагрузкой.

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