Elasticsearch
Тема дорожной карты · Backend разработчик
Elasticsearch — распределённый, RESTful поисковый и аналитический движок, построенный на Apache Lucene, широко используемый в бэкенд-системах для полнотекстового поиска, агрегации логов и аналитики в реальном времени в масштабе. Elasticsearch хранит данные как JSON-документы в индексах и предоставляет богатый DSL запросов через REST API, поддерживая сложные запросы: нечёткое совпадение, фасетный поиск, агрегации и фильтрацию по геодистанции — то, что было бы непрактично в PostgreSQL или MySQL. Он является ключевым компонентом стека ELK — вместе с Logstash для приёма данных и Kibana для визуализации — что делает Elasticsearch центральным элементом конвейеров наблюдаемости, собирающих логи из микросервисов и Kubernetes-подов. Бэкенд-разработчики взаимодействуют с Elasticsearch через официальные клиенты для Python (elasticsearch-py), Java (elasticsearch-java), Go и Node.js; индексы можно заполнять из реляционных баз данных с помощью JDBC-коннекторов Logstash или CDC-потоков Debezium из PostgreSQL. Кластеры Elasticsearch горизонтально масштабируются через шардинг и репликацию, а продакшен-деплои управляются на Kubernetes с оператором Elastic Cloud on Kubernetes (ECK).
Как это работает
Elasticsearch покрывает document (MongoDB, CouchDB), key-value (Redis, DynamoDB, etcd), wide-column (Cassandra, HBase, ScyllaDB), graph (Neo4j, ArangoDB), search (Elasticsearch, OpenSearch). Каждая торгует ACID-гарантиями за конкретное свойство производительности или масштаба. Redis — универсальный швейцарский нож в памяти (кеш, очередь, pub/sub, distributed lock). Elasticsearch доминирует в full-text. MongoDB подходит для гибких JSON-данных, но требует дисциплины денормализации.
Когда применять
Redis — для кеша + rate limit + простых очередей: окупается в большинстве стеков. Elasticsearch / OpenSearch — когда нужен full-text за пределами LIKE %x%. MongoDB или DynamoDB — только если access-паттерн реально не ложится в реляционную модель (высокая частота записи на айтем, очень разнородные документы). Избегайте NoSQL "ради масштаба" до измерения боттлнека в Postgres — преждевременная оптимизация тут реальна.
Типичные ошибки
Ловушки Elasticsearch: MongoDB для реляционных данных ("гибкая схема" прячет связи — joins становятся application-side N+1); Redis как единственное durable-хранилище (это в основном память; persistence с оговорками); Elasticsearch как primary-БД (медленные апдейты, нет транзакций — индексируйте из Postgres); выбор NoSQL по хайпу, а не по read/write-паттернам. Определяйте запросы до хранилища.