Elasticsearch отлично работает в разработке. В продакшене все совсем иначе.

За годы эксплуатации ES-кластеров команды снова и снова натыкаются на одни и те же проблемы. Они всплывают в инцидент-репортах и вопросах на Stack Overflow. В статье собраны 10 самых частых:

» Паузы сборщика мусора JVM, которые запускают каскадные отказы
» Взрыв маппингов из-за полуструктурированных данных
» Математика с шардами, которую нужно угадать заранее (и потом уже не поменять)
» Глубокая пагинация, упирающаяся в жесткий лимит в 10 000 результатов
» Split-brain сценарии при сетевых разделениях
» Сюрпризы eventual consistency («я только что сохранил, но не могу найти»)
» Ошибки в настройке безопасности, которые приводили к массовым утечкам
» Сотни метрик, где понять, какие реально важны, можно только с глубокой экспертизой
» Пайплайны синхронизации данных между Postgres и ES, которые ломаются тихо
» Инфраструктурные затраты, растущие с каждым новым узлом

У всех этих проблем один корень: Elasticsearch — это отдельная система.

Отдельная инфраструктура, отдельная экспертиза, отдельные режимы отказа, отдельные пайплайны.

Теперь, когда BM25 доступен в Postgres через pg_textsearch, поиск можно оставить в основной базе. Без JVM, без шардов, без джобов синхронизации. Одна база, один источник истины.

В блоге разбирается каждая из проблем со ссылками на реальные инциденты и объясняется, как Postgres их избегает

👉 @SQLPortal