Рубрика «lucene»

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

Решения с использованием elasticsearch имеют один существенный недостаток — очень большая вероятность рассогласования основной базы данных, например PostgreSQL, MySQL, mongodb и elasticsearch, в которой хранятся индексы для поиска.
Читать полностью »

Как Discord индексирует миллиарды сообщений - 1

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

Требования

  • Экономически эффективный: Основное взаимодействие пользователя с Discord — это наш текстовый и голосовой чат. Поиск — вспомогательная функция, и стоимость инфраструктуры должна отражать это. В идеале это значит, что поиск не должен стоить дороже, чем фактическое хранение сообщений.
  • Быстрый и интуитивно понятный: Все создаваемые нами функции должны быть быстрыми и интуитивными, в том числе поиск. Он должен выглядеть и ощущаться по высшему стандарту.
  • Самовосстановление: У нас нет отдела DevOps (пока), так что поиск должен выдерживать сбои с минимальным человеческим вмешательством или вообще без него.
  • Линейно масштабируемый: Как и с хранением сообщений, увеличение ёмкости поисковой инфраструктуры должно предусматривать добавление нодов.
  • Ленивая индексация: Не все пользуются поиском — мы не должны индексировать сообщения, пока кто-то не попытается хотя бы раз их найти. Вдобавок, после сбоя индекса должна быть возможность переиндексации серверов на лету.

Читать полностью »

Elasticsearch — поисковый движок с json rest api, использующий Lucene и написанный на Java. Описание всех преимуществ этого движка доступно на официальном сайте. Далее по тексту будем называть Elasticsearch как ES.
Подобные движки используются при сложном поиске по базе документов. Например, поиск с учетом морфологии языка или поиск по geo координатам.
В этой статье я расскажу про основы ES на примере индексации постов блога. Покажу как фильтровать, сортировать и искать документы.Читать полностью »

Пост расcчитан на начинающих, на людей незнакомых с технологией Apache Lucene. В нем нет материала о том, как устроен Apache Lucene внутри, какие алгоритмы, структуры данных и методы использовались для создания фреймворка. Пост является обучающим материалом-тизером, написанным для того, чтобы показать, как организовать простейший нечёткий поиск по тексту. В качестве материала для обучения предоставлен код на github, сам пост в качестве документации и немного данных для тестирования поисковых запросов.

Материал по работе с Apache Lucene и созданию простейшего нечёткого поиска - 1

Читать полностью »

Про отлов ядерных MCE (machine check error) и прочей гадости с помощью netconsole я писал недавно. Крайне полезная вещь. Одна проблема: throttling на CPU из-за локального перегрева (длительной нагрузки) фиксируется как MCE. Случается бэкап — и админам приходит страшное сообщение об MCE, которое на практике означает «чуть-чуть перегрелось» и точно не требует внимания к себе в 3 часа ночи.

Смехотворность проблемы ещё тем, что Linux фиксирует MCE после того, как throttling закончился. То есть режим 'normal', но вместо этого оно превращается MCE. Выглядит это так:

CPU0: Core temperature above threshold, cpu clock throttled (total events = 40997)
CPU4: Core temperature above threshold, cpu clock throttled (total events = 40997)
CPU4: Core temperature/speed normal
CPU0: Core temperature/speed normal
mce: [Hardware Error]: Machine check events logged

При этом мы точно хотим реагировать на нормальные MCE. Что делать?

В рамках logstash обработка сообщений предполагается stateless. Видишь сообщение — реагируешь. Внедрять же ради одного типа сообщений более сложную систему — оверкилл.

Казалось бы, есть фильтр (не путать с output) elasticsearch, который позволяет делать запросы. К сожалению, он не умеет делать 'if'ы, то есть remove_tag и add_tag будут отрабатывать вне зависимости от того, удался поиск или нет.

Грустно.
Читать полностью »

У Яндекса есть сервис для добросовестных рассыльщиков писем — Почтовый офис. (Для недобросовестных у нас в Почте есть Антиспам и кнопка «Отписаться».) С его помощью они могут понимать, какое количество их писем пользователи Яндекс.Почты удаляют, сколько времени их читают, насколько дочитывают. Меня зовут Антон Холодков, и я занимался разработкой серверной части этой системы. В этом посте я расскажу о том, как именно мы ее разрабатывали и с какими трудностями столкнулись.

Почтовый офис Яндекса: как мы сделали сервис, анализирующий результаты рассылок в реалтайме

Для рассыльщика интерфейс Почтового офиса полностью прозрачен. Достаточно зарегистрировать в системе свой домен или email. Сервис собирает и анализирует данные по множеству параметров: имени и домену отправителя, времени, признаку спам/не спам, прочитано/не прочитано. Также реализована агрегация по полю list-id — специальному заголовку для идентификации рассылок. Источников данных у нас несколько.
Читать полностью »

Мы живем во времена, когда кажется, что все просто и все есть. Нужно сделать масштабируемый проект — используем MongoDB, нужна очередь — вот RabbitMQ, нужно поднять функционал поиска — раз плюнуть: ставим Sphinx, Solr, ElasticSearch (нужное подчеркнуть).

Но здесь лишь доля правды: — при определенном везении можно поставить нужный сервер и все зашевелится. Загвоздка с поиском состоит в том, что пользователи уже порядком привыкли к высокой планке, которую задают «большие ребята», а тот поиск, что поднимется у вас «из коробки», будет явно недотягивать. И если очередь или базу данных вы можете добить железом прежде, чем будете оптимизировать, то поиск железом не добьешь.

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

Мы посмотрим, как с помощью нашего проекта http://indexisto.com сделан поиск на сайте http://maximonline.ru и сравним его с тем, что есть на других сайтах.

Для начала несколько примеров. Возьмем запрос «Битва за Лос Анджелес» и представим, что его напишут неправильно «Лос Анжелес биттва». Как видно, пользователь не знает точно, как пишется имя города, и забыл, как звучит название фильма, а также у него дрогнула рука в конце на слове «битва».

Выберем достойные проекты рунета, в которых есть префиксный поиск, и попробуем поискать там наш запрос:

Проект Правильный запрос Неправильный запрос
afisha.ru Как это сделано: префиксный поиск
все ОК
Как это сделано: префиксный поиск
Не найдено
ivi.ru Как это сделано: префиксный поиск
все ОК
Как это сделано: префиксный поиск
Не найдено
vk.com Как это сделано: префиксный поиск
все ОК
Как это сделано: префиксный поиск
Не найдено
maximonline.ru Как это сделано: префиксный поиск
все ОК
Как это сделано: префиксный поиск
все ОК

Читать полностью »

image
Некоторое время назад наш поиск стал работать быстрее. Особенно это заметно на сложных для движка запросах, в которых используется минимум фильтров и высокочастотные слова, что требует построить фасеты по результатам и отсортировать максимальные объёмы документов. Но и запросы средней сложности, где в выдаче немного документов, стали обрабатываться заметно быстрее. Почему возникла необходимость что-то ускорять и как мы это делали?
Читать полностью »

Библиотека полнотекстового поиска Lucene предоставляет возможность организовать поиск по текстовым документам. Существуют так же средства, с помощью которых можно организовать поиск «похожих» химических структур, например, OpenBabel. Иногда может возникнуть потребность объединить эти два вида поиска в единой «канве». Например, если нужно создать систему, которая может отвечать на такие запросы: найти вещество, в текстовом описании которого есть слово «аминокислота», структурно похожее на индол (ожидается, что мы найдём аминокислоту триптофан). В этой статье описано решение данной задачи на основе полнотекстового движка Lucene.
Читать полностью »

В моем веб-проекте на Playframework-e в один прекрасный момент потребовался поиск. Идею искать в базе через like я сразу отмел, потому что хотелось ранжирования и прочих плюшек «умного» поиска, а изобретать свой велосипед не было ни времени ни желания.
Так как проект на Java — было очень соблазнительно использовать для этого Lucene.
В гугле я сразу нашел замечательный модуль для Playframework-а под названием Search, также был найден модуль Elastic Search, который тоже использует Lucene, но он требует установки отдельного сервера, и потому был отметен. Модуль Search понравился мне своей простотой — все «навороты» в нем инкапсулированы, так что пользоваться им очень легко.
С установкой модуля, как и всегда в Play-e, проблем не возникло, команда play install search отработала на «ура» и выкачала модуль из репозитория.
Добавив module.search=${play.path}/modules/search-2.0 в application.conf я уже мог использовать его в приложении.
Следуя краткому руководству, я добавил к сущности Entry, по которой собственно и следовало осуществлять поиск, аннотацию @Indexed, а полю description — аннотацию @Field.
Написав в контроллере примерно следующий код:

public static void search(String phrase, int page) {
        int pageSize = PAGE_SIZE;
        Query query = Search.search("description:" + phrase, Entry.class);
        List<Entry> entries = query.page(page*pageSize, pageSize).fetch();
        long totalCount = query.count();
        render(entries, totalCount, page, pageSize, phrase);
}

Я уже был готов делать первые тесты и наращивать функционал, но тут начались проблемы…
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js