System Design Space
Граф знанийНастройки

Обновлено: 2 марта 2026 г. в 01:10

Elasticsearch: поисковый движок и архитектура

mid

Распределённый поисковый и аналитический движок на базе Apache Lucene: индексы, шардирование, реплики, relevance и near real-time поиск.

Источник

Wikipedia: Elasticsearch

История проекта, ключевая архитектура и место Elasticsearch в экосистеме поиска.

Открыть статью

Официальный сайт

Elastic: Elasticsearch

Продуктовая документация, возможности платформы и практики эксплуатации.

Открыть сайт

Elasticsearch - распределённый поисковый и аналитический движок на базе Apache Lucene. В системном дизайне его обычно используют как отдельный search layer над транзакционной БД: это ускоряет полнотекстовый поиск и фильтрацию, но требует осознанной работы с индексами, консистентностью и стоимостью эксплуатации.

История и контекст

2010

Появление проекта

Elasticsearch создаётся как распределённый REST-движок поверх Apache Lucene.

2012

Формирование ELK-экосистемы

Поисковый слой, лог-пайплайны и визуализация начинают использоваться вместе в едином стеке.

2018

Рост enterprise-сценариев

Платформа широко применяется для лог-аналитики, observability и продуктового поиска.

2021+

Эволюция лицензирования и облака

Активно развиваются managed-предложения и операционные практики для кластеров под высокой нагрузкой.

Ключевые архитектурные элементы

Index -> shard -> replica

Индекс делится на primary shards, для отказоустойчивости добавляются replicas. Это база горизонтального масштабирования.

Кластер и роли нод

Кластер координирует выполнение запросов, хранение данных и ребалансировку шардов между нодами.

Near real-time поиск

Данные становятся доступными для поиска не мгновенно, а после refresh-цикла, что создаёт компромисс между latency и throughput.

Релевантность и ранжирование

Lucene-модель scoring (включая BM25) помогает ранжировать результаты и управлять качеством выдачи.

High-Level Architecture

Ниже схема базового контура Elasticsearch в продуктовой системе: отделённый search layer, pipeline индексации и кластер с primary/replica shard.

Clients and API
Web/mobile appsREST APIQuery DSLKibana
Layer transition
Ingestion layer
CDC / outboxBeats/LogstashBulk APIMapping pipeline
Layer transition
Coordinator layer
Query parsingRoutingScatter/gatherMerge results
Layer transition
Storage and index internals
Primary shardsLucene segmentsInverted indexRefresh/merge
Layer transition
Replication and resilience
Replica shardsShard allocationFailoverRead scale
Layer transition
Cluster operations
ILMSnapshotsAutoscalingMonitoring/alerts

System view

Elasticsearch is usually deployed as a dedicated search and analytics layer over a transactional source of truth.

Search quality

BM25 relevanceAnalyzers + tokenizationSynonyms + boosting

Analytics

AggregationsFacets/filtersTime-series exploration

Operational trade-offs

Near real-time consistencyIndex design costsCluster maintenance

Read / Write Path через компоненты

Ниже интерактивная схема write/read path: как данные попадают в индекс и как запрос проходит через coordinator и shard-ы до финальной выдачи.

Read/Write Path Explorer

Интерактивный разбор прохождения запросов через основные компоненты Elasticsearch.

1
Source DB
OLTP state
2
Ingestion
CDC / outbox
3
Primary Shard
index write
4
Replica Shards
replication
5
Refresh
near real-time
Write path: запись идет через ingestion pipeline в primary shard, затем реплицируется и становится searchable после refresh.

Write path

  1. Сервис записывает событие в source of truth (обычно OLTP БД).
  2. Через CDC/outbox или ingestion-пайплайн документ попадает в индексатор.
  3. Elasticsearch раскладывает документ по primary shard и реплицирует на replicas.
  4. После refresh документ появляется в поисковой выдаче (near real-time).

Когда выбирать Elasticsearch

Хорошо подходит

  • Полнотекстовый поиск в продукте (каталоги, статьи, документация).
  • Observability: поиск по логам, событиям и трассировкам.
  • Сценарии, где важны гибкие фильтры + агрегации + ранжирование.
  • Read-heavy системы с высокой потребностью в быстром поиске.

Стоит избегать

  • Как единственный source of truth для критичных транзакционных данных.
  • OLTP-нагрузка с частыми точечными update/delete и строгими ACID-ожиданиями.
  • Сценарии без полнотекстового поиска, где проще и дешевле обойтись SQL/кэшем.
  • Системы без готовности к операционной поддержке кластера и индексов.

Практика: DDL и DML

Ниже реальные примеры API-запросов, которые обычно обсуждаются в System Design: от создания индекса и управления mapping до записи и поиска документов.

Примеры DDL и DML в Elasticsearch

DDL управляет индексами и mapping, DML работает с документами и поисковыми запросами.

DDL в Elasticsearch - это операции со структурой: создание индекса, настройка шардов/реплик и изменение mapping.

Создание индекса с настройками и mapping

PUT /products-v1

Задаём количество шардов/реплик и типы полей для корректной индексации.

PUT /products-v1
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1
  },
  "mappings": {
    "properties": {
      "name": { "type": "text" },
      "price": { "type": "float" },
      "category": { "type": "keyword" },
      "created_at": { "type": "date" }
    }
  }
}

Добавление нового поля в mapping

PUT /products-v1/_mapping

Можно расширять mapping новыми полями (изменение существующих типов ограничено).

PUT /products-v1/_mapping
{
  "properties": {
    "brand": { "type": "keyword" },
    "is_active": { "type": "boolean" }
  }
}

Алиас для безболезненного переключения версии индекса

POST /_aliases

Паттерн blue/green: переключаем alias с products-v1 на products-v2 без простоя.

POST /_aliases
{
  "actions": [
    { "remove": { "index": "products-v1", "alias": "products" } },
    { "add": { "index": "products-v2", "alias": "products" } }
  ]
}

Связанные материалы

Связанные главы

Чтобы отмечать прохождение, включи трекинг в Настройки

System Design Space

© 2026 Александр Поломодов