Комментарии 7
Интересно какие запросы на уровне Lucene проходят... Если не секрет, какой примерно объем записей в индексе ( условно до 10 млн документов, 100, 500)? Кластер или все в одном люсин индексе храните?
Используете wildcard запросы? Join каким либо образом?
Сейчас начал копаться с OpenSeacher, это опенсорс форк эластика от Амазон. Планирую его использовать в пет проекте и возможно сделать сравнение с Солр на достаточно большом индексе, миллионов 200 записей, обычный поиск, джойн и KNN.
PS Общее впечатление от Эластика еще 5 версии осталось хорошее, уровень разработчиков выше чем в Solr, которым пришлось длительное время пользоваться, таков был выбор маркетинга (стоимость) а до этого поддерживать кастомную версию на базе Solr. К сожалению, Solr хромает по качеству и тикеты не всегда исправляют. Хотя Solr объединили с Люсин проектом, впечатление что разные по уровню команды.
Опс, читаю, Эластик снова вернулся в open source, забавно, я пропустил этот момент.
Очередная ИИ статья ни о чем для того, чтобы собрать классы? "Мы использовали эластик для поиска, это сработало, эластик класный" Потрясающе. Держите нас в курсе.
В чем смысл этой статьи?
Как-то странно сначала написано - цитата:
"И конечно, Elasticsearch прекрасно интегрируется с PHP-фреймворком Symfony, которым пользовались наши разработчики."
Затем в пункте трудностей:
"Недостаточная гибкость библиотеки для Symfony: стандартный модуль оказался ограниченным, поэтому мы разработали собственную интеграционную структуру поверх чистого PHP-клиента"
Да и поиск не работает
Хотелось бы видеть технические подробности, а не "вот это". Например, как настраивали, тестировали производительность, с какими проблемами столкнулись. Почему так а не эдак. Примеры запросов и их оптимизация
Ужасно. Никакой конкретики по условиям задачи и предыдущему стеку. Нет цифр до/после, только после. Нет сравнений с конкурентами. Вполне возможно, что раньше использовался классическая реляционная база, но её просто плохо приготовили и можно было не добавлять стек и не использовать новые ресурсы. В некоторых задачах тот же постгрес будет не хуже эластика, а то и лучше из-за наличия связей и возможности эти связи эффективно доставать.
Надпись про "время обработки запроса не зависит от объема данных" максимально сомнительна, даже в корне неверна и вводит в заблуждение. Эластик знаменит тем, что при достаточно большом объеме начинает потреблять слишком много ресурсов и в итоге замедляется, а если у вас такой объем, что есть ощущение, что запрос всегда занимает 0.3 секунды, то скорее всего весь датасет поместится в оперативке и не факт, что эластик будет лучшим решением.
Скорее всего поиск можно ускорить ещё сильнее просто использовав какой нибудь редис или любую хранилку в оперативной памяти в связке с асинхронным сервером и буквально по задержке сети возвращать ответ на любое нажатие клавиши пользователем. Да тот же кликхауз постоянно сравнивают с эластиком по скорости выполнения запросов к структурированным или полу-структурированным данным, но в статье не рассказано.
В общем и целом, хотелось бы услышать больше. Сейчас статья ни о чем и даже на рекламу эластика не тянет даже с натяжкой (не говоря о том, что все стараются на OpenSearch переехать)
Эффективный поиск с Elasticsearch: как мы повысили конверсию на 27%