🔎 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?) и аналитики.
#SystemDesign #Elasticsearch #Search #Architecture #HighLoad
👉 @BookJava