"Улучшение" поиска в динамических списках в 8.3.5

Опубликовал Aleksey.Bochkov в раздел Программирование - Работа с интерфейсом

Наверняка многие из вас читали публикацию 1С о доработке поиска в динамических списках - http://v8.1c.ru/o7/201401ls/index.htm.
В первом приближении кажется, что все отлично и пользователи теперь смогут работать еще более эффективно.
Но на практике ситуация очень далека от идеальной и имеет важные особенности.
Функциональность нового поиска основана на двух механизмах:
- полнотекстовый поиск (работает очень быстро и требует минимум вычислительных ресурсов);
- поиск средствами СУБД (в общем случае длительность поиска и затраты вычислительных ресурсов пропорциональны объему информации в таблице).

В текущей реализации поиск в списке будет осуществляться без использования полнотекстового поиска в следующих случаях (источник):
- полнотекстовый индекс выключен на уровне информационной базы;
- объект основной таблицы не индексируется полнотекстовым индексом;
- в результате поиска с помощью полнотекстового поиска, была получена ошибка.

Если же полнотекстовый поиск включен в информационной базе, а индекс не обновлен совсем или частично (из моей практики 95% информационных баз Заказчиков), то пользователь при поиске получит либо недостоверный, либо пустой результат поиска.

Спрашиваем у Фирмы 1С - как быть? как гарантировать достоверность результатов поиска всегда?
Получаем ответ: Да, для того, чтобы результаты поиска при включенном полнотекстовом поиске были актуальными, нужно следить за тем, чтобы индекс полнотекстового поиска был актуальным.Других вариантов эффективного и актуального поиска пока нет (источник).

А существует ли вообще "актуальный полнотекстовый индекс"? Зависит от числа пользователей, интенсивности изменения информации в базе и частоты запуска обновления индекса. Обычно обновление индекса запускают раз в 60 секунд. Хорошо, если объектов было изменено не много, и процедура успела обработать все изменения за эти 60 секунд. А если сделали перепроведение группы документов, или массовую перезапись справочника? В этом случае никто не может гарантировать время, через которое поиск по индексу снова даст достоверные данные.
В принципе, это не особо критично, кроме нескольких ситуаций. Частый вариант работы пользователей - установить в списке отбор по какому-то значению, например "Контрагенту", ввести новый или скопировать существующий документ и записать. Со старым поиском новый документ моментально был виден в списке. Теперь пользователь его увидит только через N секунд в лучшем случае, где N скорее ближе к 50-60 секундам, нежели к 2-3.
Если не заметить, что нового документа нет и по отобранным результатам предоставить информацию кому-либо, то она будет заведомо недостоверной.

Это было в случае нормальной работы с информационной базой. А что будет в специфических ситуациях? Приведу пару примеров.
1) В рабочей базе полнотекстовый индекс включен и часто обновляется. Пользователь просит развернуть ему копию рабочей базы, что по ней заняться анализом данных.
Восстанавливаем бэкап и даем доступ. Вот только полнотекстовый поиск работать не будет, т.к. индекс хранится не в СУБД, а в отдельных файлах (и в файловом, и в клиент-серверном варианте). Индекса нет в dt-файле.
т.е. чтобы пользователь смог использовать поиск по спискам - надо выключить полнотекстовый индекс в этой базе. Правда пользователь будет слегка удивлен тому, что поиск будет выполняться гораздо дольше. Либо перестроить индекс по всей базе.
 
2) (Актуально для более менее больших баз). В рабочей базе полнотекстовый индекс включен и часто обновляется. Наступает конец месяца и начинается закрытие периода. Начинаем массово грузить и перепроводить документы. Для снижения нагрузки на систему блокируем выполнение регламентных заданий, соответственно, и обновление индекс останавливается. Пользователи будут, мягко говоря, в недоумении - чего же в списках нет новых или измененных документов. Единственный выход - отключить полнотекстовый поиск для информационной базы, и, соответственно, получить еще большую нагрузку на оборудование за счет тяжелого поиска по всем реквизитам.

Таким образом, как мне кажется, операция по обновлению индекса станет еще одной головной болью администраторов информационных баз.
Система, ранее гарантировавшая 100% достоверность и актуальность информации в любой момент, сейчас превращается скорее в справочную систему, в которой нельзя быть полностью уверенным.
А пользователи получают еще один повод для упрека ИТ-шников - "ваша система неправильно работает".

См. также

Лучшие комментарии

5. lustin 23.07.2014 08:19
(0)

А существует ли вообще "актуальный полнотекстовый индекс"?


Немного не тот вопрос задаёте. В статье описано то, что в 1С нет функциональности которая называется "real time full text search". Если бы вопрос был задан как "А существует ли полнотекстовый поиск в реальном времени ?". Я бы в ответ на него не задумываясь дал ссылку на ElasticSearch.

То что изображено на картинке "в Зазеркалье", в том же "Эластичном поиске" ;-) называется
Поиск предложений (вольный перевод)

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

Итак, давайте анализировать от обратного, как в школе в математике:

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

Я не зря дал вам ссылку на инструмент из Web разработки и BigData - там эта задача стоит достаточно остро - в связи с тем что браузеров (а рабочее место пользователя сайта - это именно его браузер), много и вероятность выдачи неактуальной информации достаточно велика, в связи с этим, там эта задача решена с помощью 2 инструментов:
Обновления по расписанию http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/indices-update-settings.html
и порционного обновления документов в индексе по событию
http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/partial-updates.html

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

Но вместе с тем - вернемся к основному посылу. Нужен поиск в режиме реального времени ? Вопрос - зачем и кому ? Если кому-то нужно что-либо знать в режиме реального времени, то за это отвечает не аналитический инструмент поиска и анализа текстов документов, коим и является "полнотекстовый поиск", а некий инструмент "оповещения о событиях". Де факто мы хотим, чтобы группа пользователей работающая с одними сущностями наблюдала в режиме реального времени происходящие события у друг-друга. Как только у нас возникает словосочетание "коммуникация по событиям", то задача явно уходит в плоскость интеграции. И опять я приведу пример из мира Web - там близко к нашей задаче стоит модель разработки Comet
Аналогия в данном случае - это "Чат над документами" ;-)

То есть - мы с вами потихоньку проходим к следующему. Если объединить концепцию поиска в режиме реального времени и событийную модель, то для указанной задачи (если не использовать сторонние инструменты) проблема не во времени регламентного задания, а в двух вещах:

1. инициатором события обновления индекса должен быть инициатор события с сущностью приводящий к его неактуальности.
то есть необходим псевдокод типа:
Процедура ОбработкаКоманды()
  ВыполнитьЧтоТо()
  ЗапуститьЧастичноеОбновлениеИндексаВФоновомЗадании()
КонецПроцедуры
...Показать Скрыть


2. и самое главное это управление порциями полнотекстового поиска, то есть если происходит много частичных обновление небольшого количество документов - на данный момент порция вроде как 10000 документов и это константа.
то есть в идеале код процедуры ЗапуститьЧастичноеОбновлениеИндексаВФоновомЗадании выглядит так:
МенеджерПолнотекстовогоПоиска.ОбновитьИндекс(Ложь,Истина,1);

Для тех кто решил запустить это код, знают что третьего параметра там нет. А очень хочется.

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

1. для любителей поэкспериментировать с производительностью и посмотреть на полнотекстовый поиск -посмотрите на скорость ваших физический разделов на сервере 1С, где находятся служебные файлы поиска.
2. а также выполните следующий код:
Для сч = 1 по 50 Цикл
 ВыполнитьФоново("МенеджерПолнотекстовогоПоиска.ОбновитьИндекс(Ложь,Истина)");
КонецЦикла
МенеджерПолнотекстовогоПоиска.ОбновитьИндекс(Истина,Ложь)
...Показать Скрыть

с наблюдением за счетчиками Windows
Ответили: (6) (28)
# Ответить
2. Bronislav 23.07.2014 06:53
На днях тоже пробовал этот поиск. Результаты немного удивили.
Тут еще самое веселье, что если зайти в типовые конфигурации и посмотреть расписание регл задания по обновлению поиска, увидим интервал в 10 секунд.
А если зайти на итс и посмотреть "систему стандартов и методик разработки...", то видим:

Настройка расписания регламентных заданий:
• ни в каких случаях не следует задавать периодичность выполнения регламентных заданий меньше одной минуты;

Может конечно в новом итс это дело исправили, но все равно забавно.
+ 4 [ RegrZ; B2B; BigB; RomanRomans; ]
# Ответить
6. iTony73 23.07.2014 09:01
(5) lustin, Тот момент, когда комментарий, лучше статьи)))
Ответили: (7)
+ 2 [ jorikfon; JIeHIH; ]
# Ответить

Комментарии

1. Aleksey.Bochkov 23.07.2014 06:15
Коллеги, буду благодарен за ваше мнение и опыт.
Возможно, это поможет убедить Фирму 1С реализовать механизм качественнее.
Ответили: (3) (4)
# Ответить
2. Bronislav 23.07.2014 06:53
На днях тоже пробовал этот поиск. Результаты немного удивили.
Тут еще самое веселье, что если зайти в типовые конфигурации и посмотреть расписание регл задания по обновлению поиска, увидим интервал в 10 секунд.
А если зайти на итс и посмотреть "систему стандартов и методик разработки...", то видим:

Настройка расписания регламентных заданий:
• ни в каких случаях не следует задавать периодичность выполнения регламентных заданий меньше одной минуты;

Может конечно в новом итс это дело исправили, но все равно забавно.
+ 4 [ RegrZ; B2B; BigB; RomanRomans; ]
# Ответить
3. ander_ 23.07.2014 07:26
(1) Aleksey.Bochkov, что-то я сильно в этом сомневаюсь (что что-то поможет убедить фирму 1с) :) Уверен, что делали они это осознанно, взвешивая все плюсы и минусы.
Ответили: (4)
# Ответить
4. vandalsvq 23.07.2014 07:48
(3) ander_, а вот я не уверен что 1С делает все "взвешивая + и -", Такси и его изменение в будущем тому доказательство (самый яркий пример - Масштаб - компактный, обычный).

(1) Aleksey.Bochkov, спасибо за статью, невнимательно читал описание как работает поиск. На досуге надо подумать стоит ли его оставлять во вновь разрабатываемых решениях, до момента пока обычные пользователи не замучают 1С :)
# Ответить
5. lustin 23.07.2014 08:19
(0)

А существует ли вообще "актуальный полнотекстовый индекс"?


Немного не тот вопрос задаёте. В статье описано то, что в 1С нет функциональности которая называется "real time full text search". Если бы вопрос был задан как "А существует ли полнотекстовый поиск в реальном времени ?". Я бы в ответ на него не задумываясь дал ссылку на ElasticSearch.

То что изображено на картинке "в Зазеркалье", в том же "Эластичном поиске" ;-) называется
Поиск предложений (вольный перевод)

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

Итак, давайте анализировать от обратного, как в школе в математике:

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

Я не зря дал вам ссылку на инструмент из Web разработки и BigData - там эта задача стоит достаточно остро - в связи с тем что браузеров (а рабочее место пользователя сайта - это именно его браузер), много и вероятность выдачи неактуальной информации достаточно велика, в связи с этим, там эта задача решена с помощью 2 инструментов:
Обновления по расписанию http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/indices-update-settings.html
и порционного обновления документов в индексе по событию
http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/partial-updates.html

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

Но вместе с тем - вернемся к основному посылу. Нужен поиск в режиме реального времени ? Вопрос - зачем и кому ? Если кому-то нужно что-либо знать в режиме реального времени, то за это отвечает не аналитический инструмент поиска и анализа текстов документов, коим и является "полнотекстовый поиск", а некий инструмент "оповещения о событиях". Де факто мы хотим, чтобы группа пользователей работающая с одними сущностями наблюдала в режиме реального времени происходящие события у друг-друга. Как только у нас возникает словосочетание "коммуникация по событиям", то задача явно уходит в плоскость интеграции. И опять я приведу пример из мира Web - там близко к нашей задаче стоит модель разработки Comet
Аналогия в данном случае - это "Чат над документами" ;-)

То есть - мы с вами потихоньку проходим к следующему. Если объединить концепцию поиска в режиме реального времени и событийную модель, то для указанной задачи (если не использовать сторонние инструменты) проблема не во времени регламентного задания, а в двух вещах:

1. инициатором события обновления индекса должен быть инициатор события с сущностью приводящий к его неактуальности.
то есть необходим псевдокод типа:
Процедура ОбработкаКоманды()
  ВыполнитьЧтоТо()
  ЗапуститьЧастичноеОбновлениеИндексаВФоновомЗадании()
КонецПроцедуры
...Показать Скрыть


2. и самое главное это управление порциями полнотекстового поиска, то есть если происходит много частичных обновление небольшого количество документов - на данный момент порция вроде как 10000 документов и это константа.
то есть в идеале код процедуры ЗапуститьЧастичноеОбновлениеИндексаВФоновомЗадании выглядит так:
МенеджерПолнотекстовогоПоиска.ОбновитьИндекс(Ложь,Истина,1);

Для тех кто решил запустить это код, знают что третьего параметра там нет. А очень хочется.

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

1. для любителей поэкспериментировать с производительностью и посмотреть на полнотекстовый поиск -посмотрите на скорость ваших физический разделов на сервере 1С, где находятся служебные файлы поиска.
2. а также выполните следующий код:
Для сч = 1 по 50 Цикл
 ВыполнитьФоново("МенеджерПолнотекстовогоПоиска.ОбновитьИндекс(Ложь,Истина)");
КонецЦикла
МенеджерПолнотекстовогоПоиска.ОбновитьИндекс(Истина,Ложь)
...Показать Скрыть

с наблюдением за счетчиками Windows
Ответили: (6) (28)
# Ответить
6. iTony73 23.07.2014 09:01
(5) lustin, Тот момент, когда комментарий, лучше статьи)))
Ответили: (7)
+ 2 [ jorikfon; JIeHIH; ]
# Ответить
7. lustin 23.07.2014 09:32
(6) iTony73, я постарался статью дополнить. Алексей задал вполне правильный вопрос - в той же Управлении торговлей, эта проблема стоит достаточно остро.

Ну буду вам советовать, а просто скажу - что в режиме конкурентного поиска информации, на одном из проектов динамические списки поиска "смотрели" не в УТ напрямую, а во внешний ODBC источник и в ElasticSearch рядом с этим источником. Находя необходимую ссылку объекта - уже она передавалась в качестве объекта формы внутри кода 1С.
Но нас там спасло, что были хорошие python разработчики рядом с 1С-специалистами.
Отдельная веселая история как мы делали быструю и почти-синхронную реплику 1С данных, но это уже в интеграцию уходит.
Ответили: (8)
# Ответить
8. vandalsvq 23.07.2014 12:16
(7) lustin, почитал про ElasticSearch, очень интересно и познавательно. А можно подробнее чуток про связку? Можно в личном порядке ;)
Ответили: (10) (25) (26)
# Ответить
9. AlX0id 23.07.2014 13:16
Ну улучшение-то может и без кавычек.. Только вот область применения его резко сужена за счет требований актуальности полнотекстового поиска - то да.
На мой взгляд, так как улучшение в первую очередь интерфейсное, нежели структурное - можно было бы и спросить программистов - нужно ли использовать к данному списку полнотекстовый поиск или нет. Или хотя бы - нужен ли он уберактуальный или позапрошлогодний сойдет.. Все лучше, нежели пользователю выдавать сообщения о том, что его индекс полнотекстового поиска неактуален, видите ли - на мой взгляд большей подставы для штатных программеров трудно придумать..
# Ответить
10. lustin 23.07.2014 14:05
(8) vandalsvq, ты когда демо пришлешь ;-) Можно и в личном.
# Ответить
11. Yashazz 23.07.2014 16:35
Нерегулируемость и неуправляемость полнотекстового поиска, насколько я понял из статьи и комментариев, остались на уровне 8.1, так?
# Ответить
12. MarSeN 23.07.2014 16:51
Не сочтите за рекламу: для УФ (не интерфейс такси) пользуйте быстрый поиск из Universal Extensions - http://infostart.ru/public/266022/.
никаких индексов не требуется.
Для режима такси надо доработать
Ответили: (13)
# Ответить
13. Yashazz 23.07.2014 18:05
(12) Тогда уж лучше такое: http://infostart.ru/public/254906/, опять же, за рекламу не считать ))) Достаточно просто, легко портируемо и совершенно бесплатно)
Ответили: (15)
# Ответить
14. EvgeniuXP 23.07.2014 18:36
даже если выключен поиск, данные ищутся не правильно :), на пустой базе с тремя-четыремя фильтрует нормально, а вот где данных около 40 000 - фильтр уже работает не правильно - почему? - не знаю.

Набираю "Цех № 1" - то отображает все строки начиная с "Цех №", т.е. там может и 1 и 2 и 3 быть. Если пишу "ЭМП-1" - отображает все строки "ЭМП-", там тоже может и 1 и 2 и 3 и т.д. - на маломо количестве строк работает хорошо, на большом - ужасно. Поэтому выкинул это поле ввода, и когда пользователь вводит - появится окно как делать поиск - вот оно отлично работает.
# Ответить
15. MarSeN 23.07.2014 21:21
(13) Yashazz,
Не увидел там быстрого поиска
Ответили: (16)
# Ответить
16. Yashazz 24.07.2014 00:37
(15) MarSeN, там не быстрый поиск, там отбор по ячейке)

Так что, умеет 8.3.5 обновить только полнотекстовый индекс по конкретному справочнику, например?
Ответили: (17)
# Ответить
17. AlX0id 24.07.2014 12:07
(16) Yashazz,
МенеджерПолнотекстовогоПоиска (FullTextSearchManager)
ОбновитьИндекс (UpdateIndex)
Синтаксис:

ОбновитьИндекс(<РазрешитьСлияние>, <Порционное>)
Параметры:

<РазрешитьСлияние> (необязательный)

Тип: Булево.
Разрешает слияние индексов.
Если Истина, то выполняется слияние частичного и полного индексов.
Значение по умолчанию: Ложь.
<Порционное> (необязательный)

Тип: Булево.
Истина - обновление индексов будет осуществляться порциями. При каждом вызове метода выполняется порционное обновление индекса. Размер порции равен 10 тысяч объектов индексирования. При этом сначала в порцию выбираются объекты, не привязанные ко времени (например, справочники), затем, если порция еще не заполнена, выбираются объекты, привязанные ко времени (например, документы). Сначала выбираются новые объекты, а затем старые. При выборе анализируются все временные объекты, в том числе и регистры сведений с периодами (берется старшая дата периода), так, чтобы порция включала поровну объекты всех типов.
После индексирования данных одной порции процесс завершается.
Если Ложь, то индексирует все.
Значение по умолчанию: Ложь.
Описание:

Обновляет индекс полнотекстового поиска.

Из 8.3.5, собсн.
Ответили: (18)
# Ответить
18. Yashazz 24.07.2014 14:17
(17) ИТС и СП я читать умею, спасибо. Я спрашивал о несколько другом... Ну что ж, значит, нифига никакого прогресса за последние 5 лет.
Ответили: (19)
# Ответить
19. AlX0id 24.07.2014 15:09
(18) Yashazz,
Про прогресс как раз-таки вопроса и не было ))
Ну да - нет его. Почему-то вот с ПТ у них приоритетнее бантики-рюшечки, нежели реальные проблемы, что делать..
# Ответить
20. serno 29.07.2014 14:45
Про задействование полнотекстового поиска в этом механизме не знал, спасибо.
>поиск средствами СУБД
Этот момент не раскрыт, тут то же может быть много сюрпризов т.к. поиск идет по Like
Ответили: (21)
# Ответить
21. lustin 01.08.2014 21:39
(20) serno, А чего его раскрывать, если уж в свое время обсуждали или проходили, только делали мы это еще на 7.7 и MSSQL 2000

Ключевая ссылка http://www.1cpp.ru/forum/YaBB.pl?num=1216299078/0
По большому счету для 8.* это уже не так актуально в связи с тем что в 1С язык запросов "не пробрасываются" ключевые слова в TSQL например это CONTAINS() или FREETEXT(), в 1С++ можно было играться напрямую ;-)

Тут лучше подойдет ссылки на MSDN
http://msdn.microsoft.com/ru-ru/library/ms142571.aspx

У Oracle своя реализация, есть ли у них поддержка морфологии русского языка мне пока неизвестно, у MSSQL есть
http://docs.oracle.com/cd/B28359_01/text.111/b28303/ind.htm#i1006201

Про PostgreSQL начинать лучше с http://www.sai.msu.su/~megera/postgres/talks/fts_pgsql_intro.html

Как мы все понимаем - реализация у каждого сервера СУБД ключевых слов и подходов разная.

Была в свое время гразно-хакерская идея у одних моих знакомых на Oracle - они делали патч подменяющий запросы с LIKE по определенной таблице и полю: но дальше идеи это не пошло - уж слишком большим "костылем" это оказалось: никто в здравом уме такое поддерживать не согласился. Я уже не говорю про лицензионное соглашение
Ответили: (22) (23)
# Ответить
22. lustin 01.08.2014 21:44
(21) lustin, да и дополню - единственное что на данный момент недо-исследовано, нельзя ли использовать ключевые слова для full text search во внешних источниках 1С.
# Ответить
23. serno 04.08.2014 17:43
(21) lustin.
Алексей, спасибо за ссылки, но речь таки не про Full-Text Search, ибо он в данном случае не используется, а именно про запросы с конструкциями Like %строка% и как это "быстро" работает.
Ответили: (24)
# Ответить
24. lustin 18.08.2014 01:54
(23) serno, ну так и я про тоже самое, только опосредовано.

Конструкции (пишу по памяти):

1. like 'test%' попадают в индекс и работают быстро
2. like '_____test%' работают быстро за счет точного количества символов впереди
3. like '%test' и like '%test%' - работают медленно и оптимизации не подлежат, совсем. То есть вообще.. И 1С тут не причем.
http://stackoverflow.com/a/5039845

Нет другого выхода как использовать ключевые слова CONTAINS() и FREETEXT(), в качестве замены конструкции ПОДОБНО %хрень%

Единственный возможный способ в 1С использовать полнотекстовый поиск на уровне СУБД - это.... внезапно внешний источник данных.
Но там опять не тревиально и на границе разумного и лицензионного соглашения.
Способ использовался еще на 7-ке.

1. для каждой таблицы создаются VIEW с нормальным наименование, причем обязательно с параметром WITH SCHEMABINDING - чтобы обновлять VIEW было проще после обновления метаданных
2. соответственно внешний источник прописывается уже к полученной VIEW, в тексте запроса к внешнему источнику указываются нужные нам ключевые слова CONTAINS и т.д

Но я этот способ даже не пробовал - это ... Уж слишком он выглядит костылем. Особенно когда узнаешь что полнотекстовый поиск на уровне СУБД зависит от словаря языка, и там оказывается очень не ожидаемые результаты можно получить.
# Ответить
25. lustin 18.08.2014 02:00
(8) vandalsvq, Если до Инфостарта потерпишь покажу тебе на примере на локальной машине.
Ответили: (27)
# Ответить
26. lustin 19.10.2014 00:10
(8) vandalsvq, попробовал начать описывать подход к ElasticSearch. Тебе не очень понравится - там пока много намеков на Hive, Hadoop и ElasticSearch. Обещаю на Infostart Event рассказать чуть подробней. А пока накидываю ссылки и заметки для будущей статьи http://xdd.silverbulleters.org/t/bigdata-logmanager-dlya-1s/62
Ответили: (27)
# Ответить
27. vandalsvq 08.11.2014 20:56
(25) lustin, на Ивенте маленько поспрашивал, счас сам копать начинаю почуток. Может быть выложу готовый инструмент для 1С, если конечно он получиться. А то ведь как оно бывает. Руки крюки - только голова молодец :)))))))

(26) lustin, статью посмотрел, ну да, это не совсем то что мне надо, но тоже полезно. Добавил в заметки, когда будут руки честаться эластиком плотно тогда думаю любая статья пригодится. А уж твои тем более.
# Ответить
28. Lapitskiy 04.01.2016 05:05
(5) lustin, ... тот момент, когда IT специалист, вместо решения проблемы, объясняет, что заказчик просто тупой.
+ 1 [ ardn; ]
# Ответить
29. hame1e00n 18.01.2016 10:37
Тоже наткнулся на проблемы с этим быстрым поиском, когда он работает в связке с полнотекстовым поиском.
Делал самописную конфу, за основу взял БСП. Полнотекстовый поиск включил.
Примерно через полгода этот быстрый поиск перестал нормально работать, хотя все регламентные задания работают и выполняются часто.
Как это выражается: результат поиска сейчас один, через час другой, завтра - третий.
Пользователи в непонятках.
Очистка и перезаполнение индекса не дали результата.
В итоге отключил полнотекстовый поиск, теперь быстрый поиск в списке работает нормально (правда чуть медленнее).
# Ответить
30. damiron 19.01.2016 15:38
Добрый день всем!
Вопрос: Целесообразно ли использовать ПП, скажем, для поиска дублей справочников? Платформа 8.3.6.2237.
Спасибо.
Ответили: (31)
# Ответить
31. Aleksey.Bochkov 21.01.2016 10:53
(30) damiron,
Полнотекстовый поиск дает чуть больше возможностей в поиске близких по смыслу дубликатов (морфология слов, различный порядок и т.д.). Наверное в этой части имеет смысл его использовать. Если говорить про полное совпадение (по ИНН, наименованию, коду и т.д.), то лучше делать обычными запросами, т.к. результат обычного запроса гарантирует 100% достоверность результата, а полнотекстовый поиск - нет.
# Ответить
Внимание! За постинг в данном форуме $m не начисляются.
Внимание! Для написания сообщения необходимо авторизоваться
Текст сообщения*
Прикрепить файл






IE 2016