Многие администраторы и разработчики баз данных на платформе «1С:Предприятие 8» сталкивались с удивительным феноменом. Если полностью очистить индекс полнотекстового поиска (ППД), физически удалить файлы индекса с диска сервера приложений и отключить регламентные задания его обновления, пользователи в клиентской части не замечают никаких изменений. Поиск в динамических списках, справочниках и документах продолжает работать как ни в чем не бывало. Возникает закономерный вопрос: если всё прекрасно функционирует без тяжелого, занимающего гигабайты индекса, зачем вообще тратить ресурсы сервера на его обслуживание?
В этой статье мы подробно разберем, какие процессы скрываются «под капотом» платформы 1С при работе с полнотекстовым поиском. Мы проанализируем, как система эмулирует поиск, почему такое поведение на крупной рабочей базе может привести к катастрофическому падению производительности СУБД, и как правильно оптимизировать этот механизм без полного отключения.
Для начала разберем, как устроен полнотекстовый поиск на физическом уровне в штатном режиме. Фирма «1С» использует собственную запатентованную технологию индексирования текстовых данных. Важно понимать, что этот движок работает на уровне кластера серверов «1С:Предприятие», а СУБД (будь то MS SQL Server, PostgreSQL, IBM DB2 или Oracle) абсолютно ничего не знает о существовании полнотекстового индекса 1С.
Все проиндексированные данные хранятся в виде файлов с расширением .fttx в каталоге под названием 1Cv8FTxt. Этот каталог располагается внутри папки конкретной информационной базы на сервере приложений 1С. Когда пользователь вводит поисковый запрос в динамическом списке или через общую форму поиска, платформа выполняет трехэтапный алгоритм:
1Cv8FTxt, анализирует поисковый запрос с учетом морфологии языка и быстро находит список уникальных идентификаторов (GUID) объектов, которые соответствуют условию поиска.WHERE Ссылка В (&СписокСсылок).Ссылка является первичным ключом таблицы в СУБД, для выполнения этого запроса СУБД использует операцию Clustered Index Seek. Это максимально быстрая операция доступа к данным, которая выполняется за доли миллисекунды и практически не нагружает дисковую подсистему и процессор сервера СУБД.Таким образом, полноценный индекс ППД защищает СУБД от тяжелых поисковых запросов, переводя всю нагрузку по анализу текста на сервер приложений 1С и его локальные диски.
Если индекс ППД пуст, неактуален или физически удален, платформа 1С не выдает ошибку пользователю. Вместо этого включается так называемый «режим эмуляции на запросах». Платформа пытается выполнить поиск собственными силами СУБД.
Рассмотрим, как именно платформа транслирует условия поиска в SQL-запросы. Нам важно понять правила разбиения поисковой строки и построения условий:
ИмяПоля ПОДОБНО %Слово%.ИмяПоля >= НачалоДня(Слово) И ИмяПоля <= КонецДня(Слово).Все эти условия для каждого слова объединяются логическим оператором И, а условия внутри полей — оператором ИЛИ. В итоге получается огромный, тяжелый SQL-запрос с множеством конструкций LIKE (ПОДОБНО).
На небольших тестовых базах данных или копиях объемом до 10–15 ГБ эмуляция действительно может работать с приемлемой скоростью. Это вводит разработчиков в заблуждение, заставляя их думать, что индекс ППД не нужен. Однако на высоконагруженных рабочих базах (Production) этот подход неизбежно приведет к катастрофе по нескольким причинам.
Во-первых, это проблема полного сканирования таблиц (Full Table Scan / Clustered Index Scan). Обычные B-Tree индексы, используемые в современных СУБД, работают по принципу поиска с начала строки. Когда платформа формирует запрос вида ПОДОБНО '%ТекстПоиска%', в начале поисковой строки стоит подстановочный знак процента %. Для СУБД это означает, что индекс использовать невозможно. СУБД вынуждена полностью прочитать всю таблицу с диска в оперативную память, строка за строкой, чтобы проверить совпадение подстроки в середине текста. Если в таблице миллионы записей, один такой поиск заставит сервер прочитать гигабайты данных с диска.
Во-вторых, утилизация ресурсов сервера. Представим, что несколько пользователей одновременно решили найти нужный товар в справочнике номенклатуры или документ в журнале за прошлый год. Каждый такой поиск инициирует стопроцентную загрузку дисков и процессора СУБД. В результате время отклика системы для остальных пользователей вырастет в разы, начнут возникать таймауты и блокировки на транзакциях записи.
Некоторые администраторы решают пойти на компромисс: они оставляют полнотекстовый поиск включенным в конфигурации, но отключают регламентные задания по обновлению и слиянию индекса, чтобы сэкономить процессорное время сервера приложений. Это одна из самых опасных ошибок.
Рассмотрим, как работает фиксация изменений. Когда пользователь создает или изменяет любой объект в базе данных (документ, элемент справочника), платформа 1С проверяет, включен ли для этого объекта полнотекстовый поиск. Если включен, платформа делает запись в специальную системную таблицу СУБД — очередь изменений полнотекстового поиска (обычно это таблица с именем вида _FTSIndexQueue). Эта очередь хранит ссылки на объекты, которые необходимо проиндексировать при следующем запуске фонового задания.
Если регламентные задания отключены, очередь изменений никогда не очищается. Системная таблица начинает бесконтрольно расти, раздувая физический размер базы данных. С каждым днем СУБД тратит все больше ресурсов на запись новых данных, так как ей приходится постоянно вставлять записи в огромную неиндексированную таблицу очереди. Запись документов и элементов справочников начинает замедляться по экспоненте.
Если вы твердо решили отказаться от полнотекстового поиска, его необходимо отключить полностью на уровне платформы. Недостаточно просто выключить фоновые задания. Выполните в коде или через стандартную обработку «Управление полнотекстовым поиском» следующую команду:
ПолнотекстовыйПоиск.УстановитьИспользованиеПолнотекстовогоПоиска(Ложь);
Это действие полностью остановит регистрацию изменений в СУБД и предотвратит раздувание базы данных.
Помимо колоссальной разницы в производительности, отключая полнотекстовый поиск, мы лишаем пользователей важного интеллектуального функционала, к которому они привыкли. Обычные SQL-запросы с оператором ПОДОБНО не способны предоставить следующие возможности:
ПОДОБНО найдет только точное совпадение основы.# (например, #кабель) система найдет слова с опечатками или переставленными буквами. SQL-поиск так делать не умеет.ghbdtn система найдет привет).И, ИЛИ, НЕ, а также оператор расстояния между словами РЯДОМ.Начиная с современных версий платформы 8.3, разработчики 1С внедрили умный гибридный (комбинированный) алгоритм поиска для динамических списков:
_FTSIndexQueue).ПОДОБНО.Этот алгоритм работает великолепно и обеспечивает мгновенный поиск даже самых свежих данных. Но если индекс ППД пуст или удален, платформа считает, что абсолютно все данные в информационной базе являются «новыми и непроиндексированными». В результате гибридный поиск деградирует до тотального сканирования всей таблицы базы данных через SQL-запросы.
Вместо полного отключения полнотекстового поиска, которое лишает пользователей удобства и создает риски для СУБД, мы рекомендуем провести полную ревизию настроек индексации в конфигурации. Рассмотрим пошаговый план оптимизации:
ПолнотекстовыйПоиск (установив значение Не использовать) для тех объектов, по которым пользователи никогда не ищут данные (например, технические справочники, классификаторы, подчиненные регистры сведений).Такой взвешенный подход позволит сохранить все преимущества быстрого и интеллектуального поиска для пользователей, одновременно минимизировав нагрузку на дисковую подсистему сервера приложений 1С и полностью обезопасив СУБД от тяжелых неоптимальных запросов.