В первом приближении кажется, что все отлично и пользователи теперь смогут работать еще более эффективно.
Но на практике ситуация очень далека от идеальной и имеет важные особенности.
— полнотекстовый поиск (работает очень быстро и требует минимум вычислительных ресурсов);
— поиск средствами СУБД (в общем случае длительность поиска и затраты вычислительных ресурсов пропорциональны объему информации в таблице).
В текущей реализации поиск в списке будет осуществляться без использования полнотекстового поиска в следующих случаях (источник):
— полнотекстовый индекс выключен на уровне информационной базы;
— объект основной таблицы не индексируется полнотекстовым индексом;
— в результате поиска с помощью полнотекстового поиска, была получена ошибка.
Если же полнотекстовый поиск включен в информационной базе, а индекс не обновлен совсем или частично (из моей практики 95% информационных баз Заказчиков), то пользователь при поиске получит либо недостоверный, либо пустой результат поиска.
Спрашиваем у Фирмы 1С — как быть? как гарантировать достоверность результатов поиска всегда?
Получаем ответ: Да, для того, чтобы результаты поиска при включенном полнотекстовом поиске были актуальными, нужно следить за тем, чтобы индекс полнотекстового поиска был актуальным.Других вариантов эффективного и актуального поиска пока нет (источник).
А существует ли вообще «актуальный полнотекстовый индекс»? Зависит от числа пользователей, интенсивности изменения информации в базе и частоты запуска обновления индекса. Обычно обновление индекса запускают раз в 60 секунд. Хорошо, если объектов было изменено не много, и процедура успела обработать все изменения за эти 60 секунд. А если сделали перепроведение группы документов, или массовую перезапись справочника? В этом случае никто не может гарантировать время, через которое поиск по индексу снова даст достоверные данные.
В принципе, это не особо критично, кроме нескольких ситуаций. Частый вариант работы пользователей — установить в списке отбор по какому-то значению, например «Контрагенту», ввести новый или скопировать существующий документ и записать. Со старым поиском новый документ моментально был виден в списке. Теперь пользователь его увидит только через N секунд в лучшем случае, где N скорее ближе к 50-60 секундам, нежели к 2-3.
Если не заметить, что нового документа нет и по отобранным результатам предоставить информацию кому-либо, то она будет заведомо недостоверной.
Это было в случае нормальной работы с информационной базой. А что будет в специфических ситуациях? Приведу пару примеров.
1) В рабочей базе полнотекстовый индекс включен и часто обновляется. Пользователь просит развернуть ему копию рабочей базы, что по ней заняться анализом данных.
Восстанавливаем бэкап и даем доступ. Вот только полнотекстовый поиск работать не будет, т.к. индекс хранится не в СУБД, а в отдельных файлах (и в файловом, и в клиент-серверном варианте). Индекса нет в dt-файле.
т.е. чтобы пользователь смог использовать поиск по спискам — надо выключить полнотекстовый индекс в этой базе. Правда пользователь будет слегка удивлен тому, что поиск будет выполняться гораздо дольше. Либо перестроить индекс по всей базе.
2) (Актуально для более менее больших баз). В рабочей базе полнотекстовый индекс включен и часто обновляется. Наступает конец месяца и начинается закрытие периода. Начинаем массово грузить и перепроводить документы. Для снижения нагрузки на систему блокируем выполнение регламентных заданий, соответственно, и обновление индекс останавливается. Пользователи будут, мягко говоря, в недоумении — чего же в списках нет новых или измененных документов. Единственный выход — отключить полнотекстовый поиск для информационной базы, и, соответственно, получить еще большую нагрузку на оборудование за счет тяжелого поиска по всем реквизитам.
Таким образом, как мне кажется, операция по обновлению индекса станет еще одной головной болью администраторов информационных баз.
Система, ранее гарантировавшая 100% достоверность и актуальность информации в любой момент, сейчас превращается скорее в справочную систему, в которой нельзя быть полностью уверенным.
А пользователи получают еще один повод для упрека ИТ-шников — «ваша система неправильно работает».
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Коллеги, буду благодарен за ваше мнение и опыт.
Возможно, это поможет убедить Фирму 1С реализовать механизм качественнее.
На днях тоже пробовал этот поиск. Результаты немного удивили.
Тут еще самое веселье, что если зайти в типовые конфигурации и посмотреть расписание регл задания по обновлению поиска, увидим интервал в 10 секунд.
А если зайти на итс и посмотреть «систему стандартов и методик разработки…», то видим:
Настройка расписания регламентных заданий:
• ни в каких случаях не следует задавать периодичность выполнения регламентных заданий меньше одной минуты;
Может конечно в новом итс это дело исправили, но все равно забавно.
(1) что-то я сильно в этом сомневаюсь (что что-то поможет убедить фирму 1с) 🙂 Уверен, что делали они это осознанно, взвешивая все плюсы и минусы.
(3) ander_, а вот я не уверен что 1С делает все «взвешивая + и -«, Такси и его изменение в будущем тому доказательство (самый яркий пример — Масштаб — компактный, обычный).
(1) спасибо за статью, невнимательно читал описание как работает поиск. На досуге надо подумать стоит ли его оставлять во вновь разрабатываемых решениях, до момента пока обычные пользователи не замучают 1С 🙂
(5) lustin, Тот момент, когда комментарий, лучше статьи)))
(6) iTony73, я постарался статью дополнить. Алексей задал вполне правильный вопрос — в той же Управлении торговлей, эта проблема стоит достаточно остро.
Ну буду вам советовать, а просто скажу — что в режиме конкурентного поиска информации, на одном из проектов динамические списки поиска «смотрели» не в УТ напрямую, а во внешний ODBC источник и в ElasticSearch рядом с этим источником. Находя необходимую ссылку объекта — уже она передавалась в качестве объекта формы внутри кода 1С.
Но нас там спасло, что были хорошие python разработчики рядом с 1С-специалистами.
Отдельная веселая история как мы делали быструю и почти-синхронную реплику 1С данных, но это уже в интеграцию уходит.
(7) lustin, почитал про ElasticSearch, очень интересно и познавательно. А можно подробнее чуток про связку? Можно в личном порядке 😉
Ну улучшение-то может и без кавычек.. Только вот область применения его резко сужена за счет требований актуальности полнотекстового поиска — то да.
На мой взгляд, так как улучшение в первую очередь интерфейсное, нежели структурное — можно было бы и спросить программистов — нужно ли использовать к данному списку полнотекстовый поиск или нет. Или хотя бы — нужен ли он уберактуальный или позапрошлогодний сойдет.. Все лучше, нежели пользователю выдавать сообщения о том, что его индекс полнотекстового поиска неактуален, видите ли — на мой взгляд большей подставы для штатных программеров трудно придумать..
(8) vandalsvq, ты когда демо пришлешь 😉 Можно и в личном.
Нерегулируемость и неуправляемость полнотекстового поиска, насколько я понял из статьи и комментариев, остались на уровне 8.1, так?
Не сочтите за рекламу: для УФ (не интерфейс такси) пользуйте быстрый поиск из Universal Extensions — .
никаких индексов не требуется.
Для режима такси надо доработать
(12) Тогда уж лучше такое: , опять же, за рекламу не считать ))) Достаточно просто, легко портируемо и совершенно бесплатно)
даже если выключен поиск, данные ищутся не правильно :), на пустой базе с тремя-четыремя фильтрует нормально, а вот где данных около 40 000 — фильтр уже работает не правильно — почему? — не знаю.
Набираю «Цех № 1» — то отображает все строки начиная с «Цех №», т.е. там может и 1 и 2 и 3 быть. Если пишу «ЭМП-1» — отображает все строки «ЭМП-«, там тоже может и 1 и 2 и 3 и т.д. — на маломо количестве строк работает хорошо, на большом — ужасно. Поэтому выкинул это поле ввода, и когда пользователь вводит — появится окно как делать поиск — вот оно отлично работает.
(13) Yashazz,
Не увидел там быстрого поиска
(15) MarSeN, там не быстрый поиск, там отбор по ячейке)
Так что, умеет 8.3.5 обновить только полнотекстовый индекс по конкретному справочнику, например?
(16) Yashazz,
ОбновитьИндекс (UpdateIndex)
Синтаксис:
ОбновитьИндекс(<РазрешитьСлияние>, <Порционное>)
Параметры:
<РазрешитьСлияние> (необязательный)
Тип: Булево.
Разрешает слияние индексов.
Если Истина, то выполняется слияние частичного и полного индексов.
Значение по умолчанию: Ложь.
<Порционное> (необязательный)
Тип: Булево.
Истина — обновление индексов будет осуществляться порциями. При каждом вызове метода выполняется порционное обновление индекса. Размер порции равен 10 тысяч объектов индексирования. При этом сначала в порцию выбираются объекты, не привязанные ко времени (например, справочники), затем, если порция еще не заполнена, выбираются объекты, привязанные ко времени (например, документы). Сначала выбираются новые объекты, а затем старые. При выборе анализируются все временные объекты, в том числе и регистры сведений с периодами (берется старшая дата периода), так, чтобы порция включала поровну объекты всех типов.
После индексирования данных одной порции процесс завершается.
Если Ложь, то индексирует все.
Значение по умолчанию: Ложь.
Описание:
Обновляет индекс полнотекстового поиска.
Показать
Из 8.3.5, собсн.
(17) ИТС и СП я читать умею, спасибо. Я спрашивал о несколько другом… Ну что ж, значит, нифига никакого прогресса за последние 5 лет.
(18) Yashazz,
Про прогресс как раз-таки вопроса и не было ))
Ну да — нет его. Почему-то вот с ПТ у них приоритетнее бантики-рюшечки, нежели реальные проблемы, что делать..
Про задействование полнотекстового поиска в этом механизме не знал, спасибо.
>поиск средствами СУБД
Этот момент не раскрыт, тут то же может быть много сюрпризов т.к. поиск идет по Like
(20) serno, А чего его раскрывать, если уж в свое время обсуждали или проходили, только делали мы это еще на 7.7 и MSSQL 2000
Ключевая ссылка
По большому счету для 8.* это уже не так актуально в связи с тем что в 1С язык запросов «не пробрасываются» ключевые слова в TSQL например это CONTAINS() или FREETEXT(), в 1С++ можно было играться напрямую 😉
Тут лучше подойдет ссылки на MSDN
У Oracle своя реализация, есть ли у них поддержка морфологии русского языка мне пока неизвестно, у MSSQL есть
Про PostgreSQL начинать лучше с
Как мы все понимаем — реализация у каждого сервера СУБД ключевых слов и подходов разная.
Была в свое время гразно-хакерская идея у одних моих знакомых на Oracle — они делали патч подменяющий запросы с LIKE по определенной таблице и полю: но дальше идеи это не пошло — уж слишком большим «костылем» это оказалось: никто в здравом уме такое поддерживать не согласился. Я уже не говорю про лицензионное соглашение
(21) lustin, да и дополню — единственное что на данный момент недо-исследовано, нельзя ли использовать ключевые слова для full text search во внешних источниках 1С.
(21) lustin.
Алексей, спасибо за ссылки, но речь таки не про Full-Text Search, ибо он в данном случае не используется, а именно про запросы с конструкциями Like %строка% и как это «быстро» работает.
(23) serno, ну так и я про тоже самое, только опосредовано.
Конструкции (пишу по памяти):
1. like ‘test%’ попадают в индекс и работают быстро
2. like ‘_____test%’ работают быстро за счет точного количества символов впереди
3. like ‘%test’ и like ‘%test%’ — работают медленно и оптимизации не подлежат, совсем. То есть вообще.. И 1С тут не причем.
Нет другого выхода как использовать ключевые слова CONTAINS() и FREETEXT(), в качестве замены конструкции ПОДОБНО %хрень%
Единственный возможный способ в 1С использовать полнотекстовый поиск на уровне СУБД — это…. внезапно внешний источник данных.
Но там опять не тревиально и на границе разумного и лицензионного соглашения.
Способ использовался еще на 7-ке.
1. для каждой таблицы создаются VIEW с нормальным наименование, причем обязательно с параметром WITH SCHEMABINDING — чтобы обновлять VIEW было проще после обновления метаданных
2. соответственно внешний источник прописывается уже к полученной VIEW, в тексте запроса к внешнему источнику указываются нужные нам ключевые слова CONTAINS и т.д
Но я этот способ даже не пробовал — это … Уж слишком он выглядит костылем. Особенно когда узнаешь что полнотекстовый поиск на уровне СУБД зависит от словаря языка, и там оказывается очень не ожидаемые результаты можно получить.
(8) vandalsvq, Если до Инфостарта потерпишь покажу тебе на примере на локальной машине.
(8) vandalsvq, попробовал начать описывать подход к ElasticSearch. Тебе не очень понравится — там пока много намеков на Hive, Hadoop и ElasticSearch. Обещаю на Infostart Event рассказать чуть подробней. А пока накидываю ссылки и заметки для будущей статьи
(25) lustin, на Ивенте маленько поспрашивал, счас сам копать начинаю почуток. Может быть выложу готовый инструмент для 1С, если конечно он получиться. А то ведь как оно бывает. Руки крюки — только голова молодец :)))))))
(26) lustin, статью посмотрел, ну да, это не совсем то что мне надо, но тоже полезно. Добавил в заметки, когда будут руки честаться эластиком плотно тогда думаю любая статья пригодится. А уж твои тем более.
(5) lustin, … тот момент, когда IT специалист, вместо решения проблемы, объясняет, что заказчик просто тупой.
Тоже наткнулся на проблемы с этим быстрым поиском, когда он работает в связке с полнотекстовым поиском.
Делал самописную конфу, за основу взял БСП. Полнотекстовый поиск включил.
Примерно через полгода этот быстрый поиск перестал нормально работать, хотя все регламентные задания работают и выполняются часто.
Как это выражается: результат поиска сейчас один, через час другой, завтра — третий.
Пользователи в непонятках.
Очистка и перезаполнение индекса не дали результата.
В итоге отключил полнотекстовый поиск, теперь быстрый поиск в списке работает нормально (правда чуть медленнее).
Добрый день всем!
Вопрос: Целесообразно ли использовать ПП, скажем, для поиска дублей справочников? Платформа 8.3.6.2237.
Спасибо.
(30) damiron,
Полнотекстовый поиск дает чуть больше возможностей в поиске близких по смыслу дубликатов (морфология слов, различный порядок и т.д.). Наверное в этой части имеет смысл его использовать. Если говорить про полное совпадение (по ИНН, наименованию, коду и т.д.), то лучше делать обычными запросами, т.к. результат обычного запроса гарантирует 100% достоверность результата, а полнотекстовый поиск — нет.
День добрый!
Столкнулся с такой особенностью проявления работы поиска.
Создал форму произвольную в документе. На ней расположил динамический список с произвольным запросом. Если запустить в тонком клиенте то все работает хорошо. Если через веб клиента — то в самой строке текст не набирается (невидно), хотя если установить курсор на строку в списке и набрать часть слова то произойдет отсев как через строку ПП.
Как исправить отображение текста в ПП при наборе или его включить?
С уважением, Андрей
(32) может дело в языке? Одна буква набрана на русском, а другие на белорусском или украинском?
(33) нет не в этом, раскладку проверял…
текст просто не отображается…
(34) меняли наименование вручную?
Обновление индекса у вас работает?
(32) Хм… буквально вчера столкнулся с такой же проблемой. Случаем, свойство «ТолькоПросмотр» у таблицы не Истина?
(36) Спасибо Евгений!
Именно так если стоит у таблицы «ТолькоПросмотр» признак Истина то наблюдается такая картина! Проверил! Если убрать все ок!
Вопрос решен!
А эта ошибка с поиском ещё актуальна для новых платформ? что необходимо обновлять индексы каждую минуту