Полнотекстовый поиск в 1С. №1 Грабли в динамических списках

18.07.20

Задачи пользователя - Поиск данных

Полнотекстовый поиск в 1С и все что с этим связано. Часть №1: особенности работы в динамических списках.

Найти, найти, найти

Поиск - одна из самых важных задач, которую решает платформа 1С. Чем больше размер базы, массив данных в ней, тем острее эта задача.

Стандартные возможности поиска средствами СУБД (будь это файловая база или SQL Server, PostgreSQL) не всегда работают эффективно, а уж тем более не могут удовлетворять условиям гибкого поиска по текстовому содержимому объектов. Да, поиск по индексированным полям решает множество задач, но вот гибкий поиск по текстовому содержимому на уровне СУБД не всегда работает на нужном уровне, особенно если речь идет о платформе 1С. Тут на помощь приходит полнотекстовый поиск платформы!

В серии из нескольких статей мы коснемся различных аспектов работы полнотекстового поиска в контексте платформы 1С. Разберемся зачем он вообще нужен, как работает, где используется и, самое главное, как мы можем его использовать. И хотя на первый взгляд серию статей нужно было бы начать с теории и простейших примеров, но не в этот раз. Мы начнем с "граблей" и боли. Чтобы было интересней.

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

Это первая часть публикации по этой теме. Появление продолжения будет зависеть от Вас. Будет интерес - будет и материал :)

И так, на старт, внимание....

Марш! Начнем с проблемы

Вот простая ситуация. В информационной базе создано почти 1 миллион документов "Заказ клиента". Это не плохо и не хорошо само по себе. Менеджеры по продажам каждый день работают со списком заказов, ищут в нем значения по различным полям, подбирают заказы в реализации или отчеты для отборов. В общем, поиск заказов клиентов - операция, которая выполняется даже чаще, чем их создание.

Если база в каком-то смысле "запущена" и не обслуживается в полной мере, то полнотекстовый поиск в ней может быть просто недоступен. Например, он может быть включен, но регламентные задания обновления и слияния полнотекстового индекса отключены. Или же использование полнотекстового индекса полностью выключено. А бывает еще хуже - полнотекстовый индекс используется, задания обновления индекса не включены, но при этом есть неактуальный индекс многолетней давности. В итоге поиск работает, но не находит все значения.

В списке заказов клиента поиск выполняется несколькими способами (чаще всего). Например, нужно найти заказы клиента, у которых в номере есть "85245" и имя клиента содержит слово "Сириус". Вот как это может выглядеть при выключенном / нерабочем полнотекстовом поиске:

 
 По нажатию Ctrl+F попадаем в поле поиска (обычно справа вверху) и набираем нужное значение.

Вот так выглядит стандартный поиск, который сейчас по умолчанию добавлен во все формы списков средствами платформы.

Выглядит достаточно удобно, т.к. искомые значения вводим в одно поле и ждем результата. Да и скорость вроде бы нормальная. Зачем вообще полнотекстовый поиск? К этому мы вернемся чуть позже.

 
 Выделяем нужную колонку и после нажатия Alt+F ищем по нужному значению.

Альтернативный способ, который раньше был основным и вызывался через Ctrl+F - это поиск значений по отдельным колонкам. Да, раньше не было единого поля поиска над списком, но я думаю Вы и так знаете. Вот так это выглядит.

Этот способ визуально даже быстрее предыдущего. Далее мы также разберем почему. Полнотекстовый индекс в таком варианте никак не используется.

Есть и другие способы поиска (через настройку списка, например), но сейчас это не принципиально. Поэтому рассматривать их не будем.

И так, у нас есть два способа поиска, которые на первый взгляд работают быстро и эффективно и, что самое главное, не требуют настройки и обслуживания полнотекстового индекса. Все операции поиска выполняет СУБД. Но, прежде чем радоваться, давайте проверим а что там на уровне базы данных происходит.

Пример №1: Ищем с помощью единого поля поиска

В первом случае, когда мы выполняли поиск через единое поле ввода, платформа 1С сгенерировала очень интересные запросы к базе данных. Да, их было несколько и они очень объемные. Оставил комментарии в той части, которая важна для нашей темы.

 
 Очень интересный SQL-запрос поиска без полнотекстового индекса 1С. №1
 
 Очень интересный SQL-запрос поиска без полнотекстового индекса 1С. №2
 
 Очень интересный SQL-запрос поиска без полнотекстового индекса 1С. №3
 
 Очень интересный SQL-запрос поиска без полнотекстового индекса 1С. №4

И так, платформа 1С сгенерировала аж 4 запроса для поиска по вхождению частей строки "Сириус 85245". Несмотря на то, что SQL-запросы похожи между собой, на самом деле они выполняют разную работу. Вот основные действия платформы в этом случае:

  • Платформа формирует SQL-запрос динамического списка и добавляет в него фильтры в соответствии с частями строки поиска.
  • Можно выделить основные отборы:
    • Отбор по разделителю данных.
    • Далее идет отбор по вхождению строки "Сириус" во все строковые поля, которые выводятся в динамический список. Причем это не только поля заказа клиента, но и других таблиц (регистра "Состояния заказов клиента", "Состояние ЭП" и др.
    • После идет отбор по вхождению строки "85245" как в строковые поля списка (как в пункте выше), так и устанавливается отбор на числовые поля списка (процент долга, процент оплаты и др.). Причем на числовые поля отборы устанавливаются бессмысленные (значение в полях может быть меньше, равно или больше искомого значения). Есть другие варианты? :)
  • Далее в зависимости от 1 из 4 запросов устанавливается особый отбор:
    • В первом запросе по определенной дате и ссылке, которая должна быть больше или равна определенного значения.
    • Во втором запросе по дате и по ссылке, которая меньше определенного значения.
    • Отбора по ссылке уже нет. Только по дате документа, которая должна быть больше определенного значения.
    • Отбора по ссылке уже нет. Только по дате документа, которая должна быть меньше определенного значения.

Таким образом платформа 1С пытается разделить получение данных на части:

  1. Получаем данные на определенную дату вплоть до секунды, но с разными отборами по ссылке.
  2. Далее получает данные по тем документам, у которых дата больше ранее отбираемого значения.
  3. На последнем этапе получает данные по документам, у которых дата меньше отбираем значения.

На тех этапах, когда в запросе имеется отбор на равенство конкретной дате документа все в принципе хорошо. Это селективный отбор и индекс по дате документа позволяет получать данные очень эффективно, никаких проблем. Но вот в остальных случаях, когда отбора на равенство по дате нет и вместо него появляется отбор по дате больше (или равно) и меньше определенного значения - тут начинается веселье. Взгляните на монструозный план запроса, который был сгенерирован СУБД для запроса, где дата документа больше определенного значения (см. запрос №3).

 
 Страшный план запроса

Для конкретно нашего примера запрос "съел" весомые ресурсы:

  • Выполнялся примерно 8 секунд (CPU 8157 мс).
  • Прочитаны все записи таблицы заказов клиентов.
  • Использовал 10119361 страниц памяти (reads). А если вспомнить что каждая страница 8 КБ, то...

В общем, как видно стандартный поиск в списках через единое поле ввода может создавать тяжелые по использованию ресурсов запросы, которые могут поспорить со многими тяжелыми аналитически отчетами. Что самое удивительное - в нашем примере платформа 1С сгенерировала два тяжелых запроса: один с отбором по дате больше указанной даты документа, а второй с отбором меньше заданного значения. По затраченным ресурсам они практически не отличаются. 

А ведь у нас искусственный пример, где поиск выполнялся одним пользователем. В многопользовательской среде все куда хуже!

Пример №2: Ищем с помощью отборов в отдельных колонках

Тут все значительно проще в части диагностики, чем в первом примере. Если мы устанавливаем отбор по двум колонкам через Altf+F, то платформа также генерирует 4 запроса по тем же принципам, что и выше. Но в этот раз отбор по искомым значениям в SQL-запросе иной. Не буду приводить все сформированные SQL-запросы, остановимся лишь на 1 самом "тяжелом".

 
 Тяжелый запрос с отбором по 2 колонкам

Запрос стал проще и вместо страшных комбинаций условий отборов из предыдущего примера у нас появились конкретные условия по номеру документа и имени клиента (партнера). Запрос стал "кушать" меньше ресурсов:

  • Время выполнения примерно 2 секунды (CPU 2234 мс)
  • Прочитаны все записи таблицы заказов клиентов.
  • Общее количество прочитанных страниц 3514415.

Фактически, запрос выполняется в 4 раза быстрее, чем то что было выполнено в примере ранее. Но запрос все равно "съедает" непростительный объем ресурсов, особенно критичный для многопользовательской информационной системы.

Но можно ли такие операции поиска как-то оптимизировать?

Что обычно приходит в голову

Мы еще не добрались до полнотекстового поиска, нужно еще потерпеть. Обычно, когда разработчики сталкиваются с подобными проблемами тяжелых операций поиска, то первое что они предлагают - это ограничить функционал динамических списков и убрать возможность выполнять поиска вышеописанными методами.

Что это значит? Да очень просто:

  • Поиск через Ctrl+F и Alt+F больше невозможно выполнить. Стандартное поле поиска вверху списка убирают полностью.
  • Также запрещают использовать гибкий поиск через "Все действия -> Настроить список"
  • В шапку формы списка выводят несколько полей, по которым можно выполнять поиск. При этом отборы устанавливаются строго определенного типа (равно, начинается с...). Делается это для того, чтобы условия отборов могли использовать индексы. Как известно, условия "ПОДОБНО %<тут значение>%" не используют индексы.

Профит!

Но работает это только в том случае, если бизнес согласен на такое. Тем более нужны будут доработки (даже если это делается расширениями). Да и сделать это во всех списках не всегда возможно, а еще остается поиск при вводе по строке...

В общем, решение может помочь, но чтобы довести его до ума придется потратить время как на разработку, так и на последующее сопровождение.

А вот и полнотекстовый поиск!

Как Вы могли увидеть, гибкий поиск по текстовому содержимому объектов обрабатывается СУБД не самым лучшим образом. И это нормально! Оператор поиска "LIKE" и не предназначен для такой задачи. На стороне СУБД для таких целей есть собственные движки полнотекстового поиска, которые платформа 1С не использует. Вместо этого фирма "1С" пошла своим путем и создала собственный движок для полнотекстового поиска данных, который мы и можем использовать для оптимизации подобного рода операций.

Тем более по умолчанию подразумевается, что поле поиска в тех же динамических списках будет использовать именно полнотекстовый поиск, а не возможности СУБД. Во многих базах (файловых и клиент-серверных) полнотекстовый индекс строится и обслуживается с помощью регламентных заданий и пользователи, разработчики, админы об этом могут просто не знать. Работает - не трогай, как говорится :).

Но чтобы убедиться, что построение и использование индекса полнотекстового поиска исправит наши тяжелые запросы выше - проведем эксперимент. Построим индекс полнотекстового поиска (я использовал инструмент "Мастер полнотекстового поиска", но никто не мешает Вам использовать стандартные обработки платформы). Размер индекса для всей базы с почти миллионом заказов клиента получился равным 7 ГБ.

Но рано радоваться, нужно проверить поможет ли полнотекстовый индекс в нашем конкретном случае.

Еще один эксперимент

А теперь выполним поиск через Ctrl+F как это делали ранее и посмотрим что на уровне базы данных. Повторный поиск через Alt+F делать не будем, т.к. поиск по конкретным колонкам всегда выполняется с помощью средств СУБД. А вот поиск через поле поиска - то что нужно.

Ничего не изменилось! Платформа генерирует те же самые тяжелые SQL-запросы, что в самом первом примере. Полнотекстовый поиск никак не используется! Даже визуально видно, что поиск занимает такое же количество времени. Давайте попробуем кое-что изменить.

Попробуем выполнить поиск только по части номера - "85245". Сразу скажу результат - снова ничего не изменилось. Платформа также настойчиво генерирует "страшные" SQL-запросы и игнорирует полнотекстовый индекс.

Идем дальше и через "Еще -> Изменить форму" оставляем в списке только колонки "Номер", "Дата", "Сумма", "Клиент". Эти поля 100% есть в составе заказа клиента и не получаются из сторонних таблиц, как например статусы заказа. Пытаемся выполнить поиск еще раз и...

Поиск отработал практически мгновенно! То, что нам нужно! При этом на стороне базы данных сформированы также 4 аналогичных запроса, но в них появились отборы по ссылкам. Это порции данных, которые были найдены с помощью полнотекстового поиска.

 
 Запрос с фильтрами по результатам полнотекстового поиска

А вот если попробовать ввести строку поиска "Сириус 85245", то полнотекстовый поиск снова игнорируется и платформа опять (или снова) лезет с тяжелым запросом к базе данных.

Что все это значит?

В официальной документации сказано, что использование полнотекстового индекса в поиске динамического списка имеет следующие нюансы:

  1. Полнотекстовый поиск должен быть включен для всех объектов, которые участвуют в запросе списка и могут использоваться в качестве основной таблицы. При этом все поля, выводимые в список, должны также быть с включенным полнотекстовым поиском.
  2. Полнотекстовый индекс должен обслуживаться должным образом (не забыть настроить регл. задания).
  3. Поиск выполняется по колонкам, которые отображаются в таблице.
  4. Поиск по ссылочным полям выполняется по полям представления, которые также должны быть добавлены в полнотекстовый индекс.
  5. Сначала выполняется поиск по основной таблице. К результатам полнотекстового поиска добавляются все непроиндексированные ссылки из основной таблицы. Результат полнотекстового поиска используется для отборов по ключевым полям.
  6. При возникновении ошибок полнотекстового поиска режим поиска переключается на стандартных механизм, то есть с помощью средств баз данных.
  7. Если есть отборы "Равно", то они в любом случае добавляются в финальный запрос с учетом отбора по результатам полнотекстового поиска.
  8. Строка поиска разбивается на слова (максимум 20) и не должна превышать 1000 символов. Пробел и табуляция - разделители слов. Для каждого фрагмента создается свой набор условий по ИЛИ. Все фрагменты соединяются в И.

Часть из этих правил Вы могли увидеть в примерах выше, в т.ч. разбиение условий на фрагменты в запросах и так далее. Но почему в нашем случае полнотекстовый поиск не срабатывал, если указать имя партнера в строке поиска?

Причина для этого была только одна: в запросе имеются условия соединения и поля с регистрами сведений со статусами заказов и ЭП. Эти таблицы не проиндексированы. Причем эти поля использовались в запросе даже если убрать их из списка выводимых полей через "Изменить форму". Решение - упростить запрос в списке, удалив эти регистры, и все должно заработать. Ну или проиндексировать их.

Все так просто?

К сожалению, нет. Именно в этом примере нам повезло и мы нашли причину. Но бывают ситуации куда сложнее. Ситуация еще может усугубляться особенностями версии платформы и режимом совместимости. Например:

  • Платформа 8.3.12 с конфигурацией с совместимостью 8.3.4 в некоторых случаях может вообще не выполнять поиск. Также в этой версии не работает ограничение по метаданным для полнотекстового поиска. Если фильтр установлен, то возвращается пустой результат.
  • Также в одной из новых версий платформ не выполнялся полнотекстовый поиск по ссылочным полям, только по непосредственно полям основной таблицы.

Отлаживать такое поведение очень сложно и часто поиск причин выполняется по знаменитой методике "Метод тыка". А самое тяжелое здесь то, что даже типовые конфигурации не гарантируют, что в динамических списках будет работать полнотекстовый поиск. В примерах выше была конфигурация УТ 11. А если там все и работает корректно, то кто знает когда это может сломаться...

В высоконагруженных системах поиск в динамических списках может быть очень опасен, создавая повышенную нагрузку на всю систему в самых непредсказуемых проявлениях. Полнотекстовый поиск то может работать, а может и нет :) Особенно после обновления платформы!

Только начало

Конечно, может стоило начать серию статей по полнотекстовому поиску в 1С с базовых теоретических знаний и примеров. Но на мой взгляд лучше сразу начать с хардкора.

В следующих статьях, если данная тема будет интересна сообществу, мы рассмотрим такие темы как:

  • Программная работа с полнотекстовым поиском
  • Сопровождение полнотекстового индекса и контроль его работы
  • Продвинутая отладка работы полнотекстового поиска в списка и других местах конфигурации
  • Как используется полнотекстовый поиск в типовых конфигурациях
  • Особенности обновления платформы в контексте полнотекстового поиска
  • Полнотекстовый поиск нестандартными средствами
  • Несколько кейсов по производительности платформы 1С при работе с полнотекстовым индексом
  • Как можно сломать полнотекстовый индекс на пустом месте.

А Вы используйте штатный полнотекстовый поиск 1С? Дайте знать в комментариях :) Любые вопросы, предложения по этой теме приветствуются :)

Другие ссылки

Авторские разработки

 
 Другие разработки

полнотекстовый поиск администрирование разработка обновление платформы

См. также

Быстрый поиск дублей с четким/нечетким поиском по любому сочетанию реквизитов/реквизитов таб. частей с отбором и быстрой заменой значений в ЛЮБЫХ базах 8.1-8.3 (УТ 10.3, БП 2, ЗУП 2.5, КА 1.1, УТ 11, БП 3, УНФ 1.6/3.0, КА 2, ЗУП 3 и т.д.)

Поиск данных Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Платные (руб)

Обработки помогут Вам легко и, главное, быстро (в 5 раз и быстрее штатной обработки 1С), выполнить поиск дублирующих данных в Ваших базах 1С на платформах 8.1-8.3. Это позволит уменьшить объем лишней информации в справочниках и документах, планах видов характеристик и др., упростит работу с данными пользователям. А так же можно, одним нажатием, узнать в каких ссылочных объектах есть вообще дубли! Понятное расположение команд и настроек, в сочетании с описанием и справкой, еще упростят процесс. А так же обновления Вы получаете бесплатно в течение года с момента приобретения данных обработок! (Обновление от 27.11.2023, версия 6.12)

9600 руб.

14.05.2012    155085    324    252    

556

Журнал изменений с восстановлением состояния ссылочных объектов и архивацией по HTTP / COM (расширение + конфигурация, 8.3.14+, ЛЮБАЯ конфигурация)

Архивирование (backup) Журнал регистрации Поиск данных Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 1С:Управление торговлей 11 Платные (руб)

База данных «сама» меняет данные в документах/справочниках? Тогда данный журнал изменений для Вас! Практически не влияет на скорость записи объектов за счет быстрого алгоритма! Скорость работы почти в 2 раза выше типового механизма "История изменений"! Позволяет следить за изменениями и удалением в любых ссылочных объектах конфигурации, с возможностью архивации по HTTP(!) или COM, и сверткой данных. А так же, может восстановить состояние реквизитов (значения) до момента изменения или удаления объекта из базы. Есть ДЕМО-база где можно самостоятельно протестировать часть функционала! Работает на любых платформах выше 8.3.14+ и любых конфигурациях! Версия 3.1 от 24.08.2023!

19200 руб.

15.05.2017    42470    10    24    

38

Поиск номенклатуры в интернете (Розница 2.3, Управление торговлей 11.4)

Розничная торговля WEB-интеграция Поиск данных Платформа 1С v8.3 Оперативный учет 1С:Розница 2 1С:Управление торговлей 11 Управленческий учет Платные (руб)

Альтернатива сервису 1С Номенклатура, не требует подписки ИТС, ищет данные в открытых источниках. Для поиска товара по штрихкоду в сети интернет, полезно для первоначального заполнения базы.

1999 руб.

15.10.2020    18374    22    63    

23

Кто такая Мантикора?

Поиск данных Платформа 1С v8.3 Россия Абонемент ($m)

Статья об опыте развертывания и интеграции с базой данных Manticore Search для быстрого полнотекстового поиска.

1 стартмани

30.11.2023    2999    andreysidor4uk    14    

45

PowerOffice

Поиск данных Корректировка данных Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

PowerOffice - обработка для поиска, просмотра и обработки данных для пользователей. Доступ к объектам на просмотр и редактирование данных определяется правами пользователя.

1 стартмани

05.06.2023    1902    23    PowerBoy    1    

15

Получение ссылки по бинарной строке PostgreSQL или MSSQL

Поиск данных Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Абонемент ($m)

Получение ссылки в 1С по бинарной строке из PostgreSQL в виде строки формата bytea или из MSSQL в виде шестнадцатиричной строки. Кроме ссылочных объектов ссылки могут быть получены и для перечислений. Это может быть полезно при анализе логов журнала регистрации или СУБД.

1 стартмани

04.04.2023    2559    2    berserg    2    

12

Поиск документов с ошибками проведения, универсальный

Поиск данных Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Абонемент ($m)

Обработка позволяет найти проведенные документы без движений и, наоборот, НЕ проведенные документы с движениями. Подходит для любой конфигурации.

1 стартмани

18.08.2022    2971    21    KVIKS    3    

10
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. tormozit 7133 18.07.20 23:56 Сейчас в теме
Опечатка в SQL запросе №1
динаического -> динамического
YPermitin; +1 Ответить
2. PerlAmutor 129 19.07.20 08:19 Сейчас в теме
В ERP в форме списка контрагентов и номенклатуры используется программный полнотекстовый поиск. Был случай, пользователи начали жаловаться, что при поиске некоторых контрагентов выдается ошибка, в то время как другие ищутся без проблем. Выяснилось, что при использовании методов полнотекстового поиска возвращалось количество найденных записей, но при этом в результатах было пусто. При попытке обхода результата в цикле количество записей использовали как индекс, который выходил за границы диапазона. Причем другого способа проверки количества результатов полнотекстового поиска в платформе нет. После полного перестроения индекса проблема ушла.

Я тут наткнулся еще на одну нерешенную задачку. У меня есть форма выбора с динамическим списком, причем поле там всего одно - строковое. При передаче в форму выбора параметра "ТекущаяСтрока" ничего не происходит, т.к. значение - не ссылочного типа, а строкового.

Как же найти в динамическом списке нужную строку и спозиционироваться на неё?
YPermitin; +1 Ответить
3. пользователь 19.07.20 08:39
(2) случаи, когда только перестроение индекса помогало - были. К сожалению, часто.

А какой там запрос в списке? Ссылку нельзя в запросе получить и сделать обязательной к получению? Тогда по неи и позиционироваться.
7. PerlAmutor 129 19.07.20 19:59 Сейчас в теме
(3) Там внешний источник данных, ссылок нет никаких, только строковый идентификатор в качестве уникального значения. От ссылочных полей отказался по той причине, что таблица периодически перестраивается и записи таблицы могут получить идентификаторы, которые день назад принадлежали другим записям. 1С все это дело пытается кэшировать и из-за этого возникают проблемы с получением представлений. Видим на экране одно, а внутри содержится другое. Искали одно, а получили другое.
10. пользователь 20.07.20 10:34
(7) тут все усложняется. Обычно позиционирование по ссылке выполняется. А по строке... Надо "химичить".
14. Yashazz 4707 21.07.20 00:54 Сейчас в теме
(7) Попробуйте поиграть с "Вид ключа" в режиме "Значение поля" и с "Поле ключа", например, в явном виде указать в качестве вида именно это строковое поле; тогда ТекущаяСтрока и на клиенте, и на сервере вернёт именно ключевую строку. Ну, естесссно, если строки уникальны и годятся на ключ. Если нет, тогда ставьте вид ключа "Номер строки" и выкручивайтесь через СКД дин.списка и её текущие настройки.
...сделать, что ли, об этом публикацию...
4. ivanov660 4325 19.07.20 09:39 Сейчас в теме
Согласен, напрягает сильно этот бизнес со своим поиском в динамических списках по "трем символам", возможности добавления полей через две точки, отборов, группировок и сортировок по не предназначенным полям. Иногда хочется установить формы отчетов с жесткими отборами и ограничением первые 50)
shu_vol; Mechanist; Yashazz; JohnyDeath; YPermitin; +5 Ответить
5. пользователь 19.07.20 10:08
6. muskul 19.07.20 10:13 Сейчас в теме
Всегда были проблемы с этим поиском. то номенклатура не ищется то клиенты.
YPermitin; +1 Ответить
8. Yashazz 4707 19.07.20 22:00 Сейчас в теме
Юрию респект за хорошую статью, а инструменту платформы - категорическое "фу", проще своими силами эмулировать, чем штатное юзать.
user1699642; EliasShy; YPermitin; +3 Ответить
9. bulpi 215 20.07.20 10:33 Сейчас в теме
Эта статья в очередной раз подтвердила мою уверенность в том, что полнотекстовой поиск - фигня, и использовать его не надо.
11. пользователь 20.07.20 10:35
(9) я постараюсь переубедить в следующих публикациях.

Все таки использовать его можно и нужно.
user633166; +1 Ответить
12. user633166 12 20.07.20 13:01 Сейчас в теме
(11) Спасибо за детальный разбор, но соглашусь с (8) и (9) - уверенности в инструменте такие поиски причин, почему что-то не находится, хотя оно есть, не добавляют. И где "ждут тебя эти грабли"? Когда "прилетят"?

А следующую публикацию ждём...
Mechanist; mvxyz; Yashazz; YPermitin; +4 Ответить
16. Yashazz 4707 21.07.20 01:08 Сейчас в теме
(12) Да, если мы с уровня "слияние/обновление индексов и разница между ними" перейдём к тезаурусам, стоп-словам и вообще АОТЕЯ в 1С, то я "за" двумя руками!
13. пользователь 20.07.20 23:41
(0) Вот еще интересная публикация по этой теме: https://infostart.ru/public/1267438/
15. Yashazz 4707 21.07.20 00:57 Сейчас в теме
(13) Неее. Мне кажется, там решение частного случая в рамках документации...

И вообще, пока нет программных средств управления полнотекстовым, или хотя бы настройки индексации (словари, размеры порций, порядок слияния, размещение, я уж не говорю про шкалу релевантности, уровень шума и синтагматические связки), он остаётся вещью в себе и чёрным ящиком.
Ощущение, что портировали некую хрень, прикрутили к платформе, да сами не сильно в ней разобрались. Прям иногда интересно, что это было - Сфинкс, или что-то на основе Solr'a...
YPermitin; +1 Ответить
17. ITSun 22.07.20 15:58 Сейчас в теме
Очень детально и наглядная подача, спасибо за статью! +
YPermitin; +1 Ответить
18. omen3333 4 27.07.20 21:56 Сейчас в теме
Спасибо за статью.

Работал в фирме с двумя десятками УТшек, в двух из которых тоже была тысяча тысяч заказов, индекс полнотекстового поиска в каждой из таких баз весил > 25Гб. На время слияния индекс занимал ещё столько же места. Т.е. при одновременном слиянии индекса во всех базах, сервер периодически оставался без места на дисках. Долго пытались его облегчить, пришлось отключить. Но там старая платформа было, 8.3.12-13.

А поиск в списке заказов по не индексированным колонкам иногда надолго (пока не грохнешь зависший сеанс) вешал проц. под 90%, лечилось поиском виноватого пользователя и расспросами куда нажимал.
Емельянов Алексей; YPermitin; +2 Ответить
19. rukalico 14.03.21 12:41 Сейчас в теме
Не понятен момент -
А вот если попробовать ввести строку поиска "Сириус 85245", то полнотекстовый поиск снова игнорируется и платформа опять (или снова) лезет с тяжелым запросом к базе данных
По клиенту ведь включен полнотекстовый поиск, почему же в такому случае он все равно не срабатывает?
20. OstHusky 32 27.04.21 14:19 Сейчас в теме
В типовых конфигурациях есть, например, регистр сведений "НаличиеФайлов", он используется для отображения скрепки в списках всех документов, к которым можно присоединять файлы. У этого регистра выключено использование полнотекстового поиска, получается, что полнотекстовый поиск не будет работать в большинстве списках документов? Как-то странно со стороны 1С так делать или это не так? Регистр наличие файлов можно выбрать как основную таблицу списка, соответственно он должен быть включен для этого регистра.
21. scaramouche 12.08.21 11:14 Сейчас в теме
отличная статья! большое спасибо!
Оставьте свое сообщение