Elasticsearch

01Идея: инвертированный индекс

Предметный указатель в книге перечисляет слова и страницы, на которых они встречаются. Инвертированный индекс делает то же для документов: для каждого терма он хранит список ID документов, где он встречается, плюс позиции и частоты. Чтобы найти «red running shoes», Elasticsearch берёт три коротких списка и пересекает или объединяет их, вместо того чтобы читать каждый документ. Релевантность по умолчанию считается по BM25: терм весит больше, если он редок в индексе и част в документе, и меньше — в очень длинных полях. Elasticsearch работает в near real-time: новые документы становятся доступны для поиска после refresh, который по умолчанию происходит каждую секунду.

• Индекс: логическая коллекция документов с одним mapping, как таблица.
• Документ: JSON-объект, единица индексации и поиска.
• Терм: нормализованный токен, полученный анализатором; например, «running» становится «run».

02Mapping и анализаторы

Mapping определяет тип каждого поля. Самое важное различие — text против keyword. Поле text анализируется: разбивается на токены, приводится к нижнему регистру, возможно, стеммится, поэтому оно хорошо для полнотекстового поиска, но не для сортировки или точных фильтров. Поле keyword хранится как одно точное значение — подходит для фильтров, сортировки и агрегаций (бренд, статус, SKU). Часто поле маппят обоими способами через подполе. Анализатор — это pipeline: character filters, tokenizer и token filters (lowercase, стоп-слова, стемминг, синонимы). Выбирайте языковые анализаторы (english, german, russian…) для каждого поля. Задавайте mapping явно: dynamic mapping угадывает типы и часто ошибается.

1PUT /products
2{
3  "settings": { "number_of_shards": 1, "number_of_replicas": 1 },
4  "mappings": {
5    "dynamic": "strict",
6    "properties": {
7      "name":       { "type": "text", "analyzer": "english",
8                      "fields": { "raw": { "type": "keyword" } } },
9      "brand":      { "type": "keyword" },
10      "price":      { "type": "scaled_float", "scaling_factor": 100 },
11      "in_stock":   { "type": "boolean" },
12      "created_at": { "type": "date" }
13    }
14  }
15}

03Запросы: query context и filter context

Поиск использует Query DSL — язык на JSON. Запрос bool комбинирует условия: must и should влияют на оценку релевантности, а filter и must_not только включают или исключают. Фильтры кэшируются и не считают score, поэтому каждое условие «да/нет» (в наличии, бренд, диапазон цены) кладите в filter, а must оставляйте для того, что ввёл пользователь. multi_match ищет по нескольким полям и позволяет бустить одно из них, например name выше description. fuzziness: "AUTO" прощает опечатки. Агрегации выполняются в том же запросе и строят фасеты, например количество по брендам, так что один вызов возвращает и результаты, и фильтры для сайдбара.

1GET /products/_search
2{
3  "query": {
4    "bool": {
5      "must":   { "multi_match": { "query": "red runing shoes",
6                  "fields": ["name^3", "description"], "fuzziness": "AUTO" } },
7      "filter": [
8        { "term":  { "in_stock": true } },
9        { "range": { "price": { "lte": 120 } } }
10      ]
11    }
12  },
13  "aggs": { "brands": { "terms": { "field": "brand", "size": 10 } } },
14  "size": 20
15}

04Кластер, шарды и реплики

Индекс делится на primary-шарды, каждый из которых — самостоятельный индекс Lucene, и у каждого primary могут быть реплики на других узлах. Шарды — это способ, которым Elasticsearch распределяет данные и распараллеливает запросы; реплики дают failover и дополнительную ёмкость на чтение. Запрос расходится на одну копию каждого шарда, каждый возвращает свои лучшие результаты, а координирующий узел их объединяет. Число primary-шардов фиксируется при создании индекса (изменить его можно через split, shrink или reindex), поэтому рассчитывайте его от ожидаемого объёма: рекомендация Elastic — примерно 10–50 GB на шард и не больше примерно 200 миллионов документов. Слишком много крошечных шардов тратят память; несколько огромных долго восстанавливаются.

• Здоровье кластера green: все шарды назначены; yellow: не хватает реплик; red: отсутствует primary.
• Роли узлов: master-eligible, data (hot, warm, cold, frozen), ingest, coordinating, ml.
• Для продакшен-кластера используйте три master-eligible узла, чтобы избежать раздвоения решений.

05Безопасная индексация из приложения

Ваша основная база остаётся источником истины; Elasticsearch — производная копия для поиска. Индексируйте документы пачками через _bulk API, а не одним запросом на документ. Используйте ID из базы как _id в Elasticsearch, чтобы переиндексация была идемпотентной. Для изменений либо ставьте задачу индексации в очередь после каждой записи (outbox или очередь делают это надёжным), либо используйте change data capture. Всегда читайте и пишите через alias, а не через настоящее имя индекса: когда mapping нужно изменить, создайте новый индекс, переиндексируйте в него и атомарно переключите alias. Безопасность включена по умолчанию с 8.0 (TLS и аутентификация), поэтому используйте API-ключ только с теми привилегиями, которые нужны приложению.

1POST /_bulk
2{ "index": { "_index": "products", "_id": "1001" } }
3{ "name": "Trail running shoe", "brand": "acme", "price": 89.9, "in_stock": true }
4{ "index": { "_index": "products", "_id": "1002" } }
5{ "name": "Road running shoe", "brand": "acme", "price": 99.0, "in_stock": false }
6 
7POST /_aliases
8{ "actions": [
9  { "remove": { "index": "products_v1", "alias": "products_live" } },
10  { "add":    { "index": "products_v2", "alias": "products_live" } }
11] }

06Лицензии, OpenSearch и managed-варианты

В 2021 году Elastic перешёл с Apache 2.0 на SSPL и Elastic License, а AWS форкнул последнюю открытую версию в OpenSearch, которым теперь управляет OpenSearch Software Foundation под крылом Linux Foundation. В 2024 году Elastic добавил AGPLv3 как вариант лицензии для исходного кода. У проектов общие корни и большая часть Query DSL, но они разошлись в функциях, плагинах и клиентских библиотеках, поэтому выберите один и используйте его собственный клиент. Варианты хостинга: Elastic Cloud (включая serverless-предложение), Amazon OpenSearch Service или self-managed кластеры на VM или в Kubernetes (с оператором ECK для Elasticsearch).

07Сегменты, refresh, flush и слияния

Внутри каждого шарда Lucene записывает данные в неизменяемые сегменты. Новые документы попадают в буфер в памяти и в translog (журнал упреждающей записи). Refresh (по умолчанию раз в 1 секунду, и только для индексов, по которым недавно искали) превращает буфер в новый доступный для поиска сегмент; flush фиксирует сегменты на диске и обрезает translog. Поскольку сегменты неизменяемы, обновление на деле — это удаление плюс вставка, а удалённые документы физически убираются только когда фоновые слияния объединяют мелкие сегменты в крупные. Для массовой загрузки поставьте refresh_interval в -1 и реплики в 0, загрузите, затем верните оба значения — это может многократно ускорить индексацию. Избегайте частых обновлений отдельных документов с одними и теми же ID: они создают много крошечных сегментов и удалённых документов.

1PUT /products_v2/_settings
2{ "index": { "refresh_interval": "-1", "number_of_replicas": 0 } }
3 
4// ...run the bulk load, then:
5PUT /products_v2/_settings
6{ "index": { "refresh_interval": "1s", "number_of_replicas": 1 } }
7POST /products_v2/_refresh

08Векторный, семантический и гибридный поиск

Elasticsearch 8 и 9 поддерживают поля dense_vector с приближённым kNN-поиском на графах HNSW и квантизацией (int8, int4 и BBQ — бинарная квантизация) для экономии памяти. Тип поля semantic_text идёт дальше: вы подключаете inference endpoint, а Elasticsearch при индексации сам разбивает текст на чанки и создаёт эмбеддинги. Retrievers позволяют объединить обычный BM25-запрос с kNN-запросом через reciprocal rank fusion (RRF), который сливает два ранжированных списка по позициям, а не по сырым оценкам. Гибридный поиск обычно лучше каждого метода по отдельности: ключевые слова ловят точные SKU и названия, векторы — смысл. Измеряйте на размеченном наборе запросов до и после.

1GET /products/_search
2{
3  "retriever": { "rrf": { "retrievers": [
4    { "standard": { "query": { "match": { "name": "waterproof hiking boots" } } } },
5    { "knn": { "field": "name_vector", "k": 20, "num_candidates": 100,
6               "query_vector_builder": { "text_embedding": {
7                 "model_id": "my-embedding-endpoint", "model_text": "waterproof hiking boots" } } } }
8  ] } }
9}

09Глубокая пагинация и стабильная прокрутка

Пагинация через from + size заставляет каждый шард собрать from + size результатов, а координатор — отсортировать их все, поэтому страница 500 очень дорогая; именно поэтому лимит по умолчанию (index.max_result_window) — 10,000 результатов. Для бесконечной прокрутки у пользователей или экспорта используйте search_after с сортировкой, которая заканчивается уникальным tiebreaker, вместе с point in time (PIT), чтобы выборка не сдвигалась, пока приходят новые документы. Старый scroll API всё ещё доступен, но для глубокой пагинации больше не рекомендуется. Для экспорта очень больших наборов результатов рассмотрите параллельные sliced PIT-запросы.

10Эксплуатация кластера: память, уровни и snapshot

Давайте JVM heap не больше примерно половины RAM и держитесь ниже порога compressed pointers (около 30 GB); остальное использует файловый кэш ОС, на который Lucene сильно опирается. Последние версии подбирают размер heap автоматически, и обычно это правильно. Для данных, привязанных ко времени, используйте уровни hot, warm, cold и frozen вместе с ILM, чтобы старые индексы переезжали на более дешёвое хранилище и в итоге удалялись. Регулярно делайте snapshot в объектное хранилище (S3, GCS, Azure) через snapshot lifecycle management; snapshot инкрементальны и являются вашим настоящим бэкапом, потому что реплики не защищают от удаления индекса. Обновляйтесь rolling restart в пределах мажорной версии и проверяйте deprecation API перед мажорными обновлениями.