Представьте каталог на 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
📲 Мы в MAX
👉@BookJava