Elasticsearch: Как найти иголку в стоге сена за 10 мс

МЕНЮ


Главная страница
Поиск
Регистрация на сайте
Помощь проекту
Архив новостей

ТЕМЫ


Новости ИИРазработка ИИВнедрение ИИРабота разума и сознаниеМодель мозгаРобототехника, БПЛАТрансгуманизмОбработка текстаТеория эволюцииДополненная реальностьЖелезоКиберугрозыНаучный мирИТ индустрияРазработка ПОТеория информацииМатематикаЦифровая экономика

Авторизация



Представьте каталог на 10 миллионов товаров. Пользователь вводит в поиск: "айфон 15 про макс".

1. Почему SQL здесь бессилен?

В реляционной базе (PostgreSQL/MySQL) вы бы написали:

SELECT * FROM products WHERE name LIKE '%айфон 15%'

В чем проблема?

1. Full Table Scan: База данных не может использовать обычный B-Tree индекс для поиска по части слова (с LIKE '%...'). Ей придется прочитать все 10 миллионов строк на диске, чтобы найти совпадения. Это убьет процессор.

2. Нулевая толерантность к ошибкам: Если пользователь опечатался и написал "айфно", SQL вернет 0 результатов. Бизнес потерял клиента.

3. Нет релевантности: SQL не понимает, какой товар подходит "лучше". Он просто отдает всё, что нашел, по дате добавления.

2. Инвертированный индекс (Inverted Index)

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

Вместо того чтобы искать слово на страницах, мы заранее составляем список всех слов и записываем, на каких страницах они встречаются.

Пример:

У нас есть три товара (Документа):

• Doc 1: "Красный телефон Apple"

• Doc 2: "Синий чехол для телефона"

• Doc 3: "Красный чехол"

Инвертированный индекс будет выглядеть так:

• красный -> [Doc 1, Doc 3]

• телефон -> [Doc 1, Doc 2]

• apple -> [Doc 1]

• синий -> [Doc 2]

• чехол -> [Doc 2, Doc 3]

Теперь, если мы ищем "красный телефон", система просто берет списки для этих двух слов: [1, 3] и [1, 2]. Пересечение этих списков - Doc 1. Мы нашли результат за O(1)! Никакого сканирования миллионов строк.

3. Встречайте Elasticsearch (ES)

Elasticsearch - это не просто база данных, это полноценный поисковый движок (написанный на Java поверх библиотеки Apache Lucene).

Он хранит данные не в таблицах, а в виде JSON-документов, и автоматически строит инвертированный индекс для каждого текстового поля.

Магия Elasticsearch:

1. Анализаторы (Стемминг и Лемматизация): Перед тем как положить текст в индекс, ES его обрабатывает. Он приводит слова к базовой форме, убирает окончания и предлоги.

• Слова "айфон", "айфону", "айфоном" попадут в индекс как один токен "айфон".

2. Поиск с опечатками (Fuzzy Search): ES использует Расстояние Левенштейна (сколько букв нужно изменить, чтобы получить правильное слово).

• Запрос "йафон" автоматически найдет "айфон", потому что разница всего в одну перестановку.

3. Релевантность (Scoring - BM25): ES каждому результату присваивает "Оценку". Чем реже слово встречается во всей базе и чем чаще в конкретном документе, тем выше этот документ будет в выдаче.

4. Как это выглядит в Архитектуре?

Важное правило: Elasticsearch не заменяет вашу основную базу данных.

ES - это поисковик. Он может потерять данные при сбоях (он оптимизирован на скорость чтения, а не на надежность хранения ACID).

Правильный паттерн (CQRS-лайт):

1. "Правда" живет в PostgreSQL.

2. Когда товар добавляется или меняется в Postgres, вы отправляете событие в брокер сообщений (Kafka) или используете CDC (Change Data Capture - например, Debezium), чтобы прочитать логи БД.

3. Специальный воркер берет эти изменения из Kafka и синхронизирует их с Elasticsearch.

4. Фронтенд: за созданием/покупкой товара ходит в Postgres, а за поиском — в Elasticsearch.

Итог

• SQL LIKE - для админок и маленьких таблиц.

• Инвертированный индекс - ключ к мгновенному поиску.

• Elasticsearch - стандарт индустрии для полнотекстового умного поиска, логов (помните ELK?) и аналитики.

Мы в MAX max.ru/BookJava

Мы в Telegram t.me/BookJava

Мы в VK vk.com/BookJava


Источник: vk.com

Комментарии: