Исходное сообщение
"Компания HashiCorp меняет лицензию на своё ПО с MPLv2 на про..." Отправлено Аноним, 13-Авг-23 07:01
> Вы на полном серьезе пишете, что используете ELK для номенклатуры, даже не стыдясь собственного невежества >и еще и хамите старшим, фу таким быть. Это что, секта Свидетелей Поха? Не зашкварно одного из самых ноющих желчегонных кадров всея опеннета выгораживать? Ну и стыдоба. По существу вопроса - у нас все ранжирование по релевантности было чисто на данных из полей документов (карточек товаров) уже сохраненных в индексе. Весовые функции были описаны как хранимки внутри ES на Painless скриптовом языке. Ничего не имею против Solr, но видел его последний раз в коммерческом проекте в 2015 году. Тогда он был неудобный, требовал Zookeeper для кластера и имел единый кэш для всего шарда, а не сегмента. Не знаю, как там сейчас. Elastic все используют банально по причине высокой популярности и большого количества людей на рынке труда, которые в нем имеют опыт. Может для вас, как крупного и уверенного в себе специалиста, важно разбираться в нюансах Lucene-деривативов, но простите мне субъективное мнение, за 12 лет в профессии, я видел только, что на проектах люди выбирали между full text поиском встроенными средствами Postgres/MySQL и специализированными документо-ориентированными БД, изначально заточенными под полнотекстовый поиск с возможностью его кастомизации в широких пределах. А будет это Sphinx/Solr/Elastic - тут уже разрабов с каким бэкграундом будет проще и быстрее схантить, на том и будет.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> Вы на полном серьезе пишете, что используете ELK для номенклатуры, даже не стыдясь собственного невежества >и еще и хамите старшим, фу таким быть. > Это что, секта Свидетелей Поха? Не зашкварно одного из самых ноющих желчегонных > кадров всея опеннета выгораживать? Ну и стыдоба. > По существу вопроса - у нас все ранжирование по релевантности было чисто > на данных из полей документов (карточек товаров) уже сохраненных в индексе. > Весовые функции были описаны как хранимки внутри ES на Painless скриптовом > языке. Ничего не имею против Solr, но видел его последний раз > в коммерческом проекте в 2015 году. Тогда он был неудобный, требовал > Zookeeper для кластера и имел единый кэш для всего шарда, а > не сегмента. Не знаю, как там сейчас. Elastic все используют банально > по причине высокой популярности и большого количества людей на рынке труда, > которые в нем имеют опыт. Может для вас, как крупного и > уверенного в себе специалиста, важно разбираться в нюансах Lucene-деривативов, но простите > мне субъективное мнение, за 12 лет в профессии, я видел только, > что на проектах люди выбирали между full text поиском встроенными средствами > Postgres/MySQL и специализированными документо-ориентированными БД, изначально заточенными > под полнотекстовый поиск с возможностью его кастомизации в широких пределах. А > будет это Sphinx/Solr/Elastic - тут уже разрабов с каким бэкграундом будет > проще и быстрее схантить, на том и будет.
	Введите код, изображенный на картинке: