Информационный поиск
Search Infrastructure at Scale
Хранение всего индекса Google на SSD стоило бы 2 трлн долларов. Tiering позволяет держать 1% горячих данных на SSD, 99% - на дешёвом хранилище. Это и делает Google Search экономически возможным.
- **Новостные порталы:** hot индекс для breaking news (refresh=1s, SSD), archive индекс для старых статей (frozen tier, S3) - разница в стоимости хранения 50x
- **E-commerce поиск:** Shopify федерирует product search, inventory search и semantic search в единый API - каждый источник с отдельным scaling
- **Enterprise search:** Microsoft Search объединяет SharePoint, Exchange, Teams, GitHub в одну строку поиска через федерацию с нормализацией scores
Tiering: горячие и холодные индексы
Google хранит 130 трлн страниц, но запросы к статьям двухлетней давности встречаются редко. Tiering разделяет индекс по частоте обращений: горячий tier (hot) - свежие и популярные документы на SSD с большим RAM; тёплый tier (warm) - документы за последние месяцы на HDD; холодный tier (cold/frozen) - архив на объектном хранилище (S3) с загрузкой по требованию. Экономия на инфраструктуре достигает 70-80%.
Elasticsearch ILM (Index Lifecycle Management) автоматически перемещает индексы между тирами по правилам: age > 7d -> warm, age > 30d -> cold. Frozen tier хранит данные в S3, шарды монтируются при запросе - latency секунды вместо миллисекунд, но стоимость хранения минимальна.
Почему frozen tier в Elasticsearch имеет latency в секунды, а не в миллисекунды?
Кэширование результатов поиска
Поисковый трафик подчиняется закону Ципфа: 1% запросов составляет 50% трафика. Google кэширует результаты по 100 мс - даже такое короткое окно даёт кратное снижение нагрузки. Уровни кэша: (1) query cache - результаты фильтров на уровне шарда, (2) request cache - результаты агрегаций, (3) application-level cache - Redis с результатами топовых запросов, (4) CDN-кэш для публичного поиска.
Elasticsearch request cache инвалидируется при каждом refresh (по умолчанию каждую секунду). Для стабильных данных (архивный контент, каталоги) можно увеличить refresh_interval до 30-60 секунд - кэш живёт дольше, hit rate растёт. Приложительный кэш через Redis: TTL 60-300 секунд для trending-запросов.
Почему request cache в Elasticsearch инвалидируется при каждом refresh?
Freshness: видимость новых документов
Новость, опубликованная минуту назад, должна быть в поиске немедленно - но refresh каждую секунду убивает throughput индексации. Near Real-Time (NRT) поиск в Elasticsearch: документы видимы через 1 секунду после индексации (один refresh interval). Для breaking news допустимо принудить refresh вручную - но это дорогостоящая операция при высокой нагрузке.
Разные данные требуют разного freshness SLA: новости - секунды, e-commerce каталог - минуты, архивный контент - часы. Архитектурный паттерн: отдельный 'hot' индекс для свежего контента (refresh=1s), 'main' индекс для остального (refresh=30s), federation объединяет результаты.
Почему при bulk индексации рекомендуется отключать refresh_interval и выполнять явный refresh в конце?
Федерация и мульти-кластерный поиск
Google поиск объединяет результаты из web-индекса, новостей, изображений, видео, карт, knowledge graph - это федерация. В enterprise контексте: несколько Elasticsearch кластеров в разных регионах, или разные поисковые системы (ES + Solr + специализированный vector search). Координатор агрегирует результаты, нормализует scores и мержит с учётом бизнес-правил.
Cross-cluster search (CCS) в Elasticsearch позволяет отправить один запрос на несколько кластеров. Проблема: score normalization - BM25 score из разных индексов несравним напрямую (разные IDF, разная длина документов). Решение: нормализация к [0,1] или rank-based fusion.
Федерация нескольких поисковых систем сложнее одного большого кластера
Для больших систем федерация часто проще в эксплуатации: каждый кластер независим, домен имеет отдельный lifecycle, отказ одного источника не роняет всю систему
Один огромный кластер - единая точка отказа с централизованным управлением. Федерация позволяет разным командам владеть своими индексами, применять разные стратегии freshness и scaling, и постепенно мигрировать на новые технологии (vector search) без полного переписывания
Почему BM25 scores из разных Elasticsearch индексов нельзя сравнивать напрямую при федерации?
Ключевые идеи
- **Tiering:** hot/warm/cold тиры по частоте обращений - SSD для горячего, S3 для холодного, экономия до 80% на инфраструктуре
- **Кэш + freshness:** app-level cache через Redis для топ-запросов; refresh_interval баланс между свежестью и throughput; bulk без refresh = один сегмент вместо сотни
- **Федерация:** cross-cluster search + score normalization + rank fusion объединяют гетерогенные индексы без единой точки отказа
Связанные темы
Search infrastructure at scale строится поверх базовых концепций distributed search:
- Distributed Search: Elasticsearch — Tiering и federation - следующий уровень после базового кластера с шардированием и репликацией
- Ранжирование и релевантность — Score normalization при федерации требует понимания BM25 и алгоритмов ранжирования
Вопросы для размышления
- Frozen tier снижает стоимость хранения в 50 раз, но latency вырастает до секунд. Для каких пользовательских сценариев такой tradeoff приемлем - а для каких нет?
- Score normalization при федерации теряет семантику оригинального score. Какие альтернативные подходы к мержу результатов из разных источников существуют и когда они предпочтительнее?
- Federated search позволяет разным командам владеть своими индексами. Как бы организовали governance для такой системы, чтобы общее качество поиска не деградировало?