ClickHouse или Elasticsearch для логов: поиск и агрегации дают разных победителей

Если в журналах нужно искать точные фразы и получать записи в порядке текстовой релевантности, предпочтительнее Elasticsearch. Если обычный запрос находит сообщения, а затем считает совпадения по службам и времени, преимущество смещается к ClickHouse. Оба движка умеют искать слова в тексте, поэтому граница проходит по требованиям к результату, а не по самому наличию полнотекстового поиска.

При длительном хранении к форме запросов добавляются объём индексированных данных, память и затраты на сбор журналов. Опубликованные сравнения помогают увидеть эти различия, но измеряют разные системы и нагрузки: скорость отдельного движка не равна стоимости всего развёртывания.

Поиск: совпадение слов или фраза с ранжированием

Elasticsearch даёт готовые средства для запросов, в которых важны порядок слов и релевантность найденных сообщений. Документация Elastic по текстовым полям описывает анализ текста, настройки фразового поиска и оценку релевантности. Для имени службы, кода состояния и других структурированных значений предназначен тип keyword; одно значение можно хранить в отдельных представлениях для текстового поиска и группировки.

Последнее различие влияет на схему журнала. Сообщение об ошибке может требовать разбора на слова, а поле службы — сохранения целиком, чтобы подсчёт по службам не превратился в подсчёт отдельных слов. Elasticsearch поддерживает оба представления, но дополнительные возможности индекса занимают место. Для инженера, который просматривает несколько наиболее подходящих записей по неточному описанию сбоя, это осмысленный обмен диска на поисковые функции.

ClickHouse также использует обратный текстовый индекс: слово в нём связано со строками, где оно встречается. Обзор возможностей ClickHouse описывает и поиск последовательности слов через hasPhrase, при котором текстовый индекс помогает предварительно отсечь неподходящие блоки. Поэтому поиск фраз нельзя считать недоступным в ClickHouse; решать нужно по требуемым функциям и задержке конкретных запросов.

Поиск известного идентификатора или сочетания терминов и поиск лучшего ответа на свободно сформулированный запрос предъявляют разные требования. В первом случае важнее быстро отобрать подходящие записи и продолжить анализ. Во втором важны разбор текста, порядок слов и правило ранжирования. Сравнение скорости запросов на отдельные слова не устанавливает победителя для фразового поиска.

Агрегации: когда совпадения нужно посчитать

ClickHouse заметнее выигрывает там, где найденные сообщения становятся входом для группировки. В тесте производителя на журналах OpenTelemetry объём данных достигал 50 млрд строк, а совокупная полнотекстовая аналитическая нагрузка выполнялась в ClickHouse примерно в 2–6 раз быстрее Elasticsearch. Это результат заданного набора запросов к отдельным движкам, а не измерение любой системы сбора логов.

Набор включал извлечение совпавших записей, подсчёты, группировки по службам и временные срезы. Наибольшие разрывы возникали там, где после текстового отбора требовалось сгруппировать много строк; запросы на извлечение отдельных событий показывали более близкие результаты. Причина различия понятна из формы работы: найти несколько записей и пройти по множеству совпадений ради сводки — разные задачи даже при одинаковом поисковом условии.

Измерения проводились на выделенных односерверных конфигурациях с сопоставимыми ресурсами. В них учитывались холодные обращения к данным и повторные запросы после прогрева кеша; средства сбора и интерфейсы наблюдения не входили в измеряемую связку. Таким образом, преимущество относится к проверенной поисково-аналитической нагрузке и её настройкам. Оно не означает, что ClickHouse быстрее выдаст любую отдельную строку или лучше упорядочит ответы по смысловой близости.

Хранение и ресурсы: база данных внутри полного стека

Для большого срока хранения ClickHouse выглядит привлекательным по расходу диска, но сравнивать следует данные с нужными индексами. В дипломной работе Мелардаленского университета от 2024 года исследованные наборы журналов занимали в Elasticsearch в 2–6 раз больше места, чем в ClickHouse внутри SigNoz. Автор связывает разницу, в частности, с дополнительными структурами для подробного поиска по содержимому сообщений.

Здесь измерялись и сопутствующие компоненты. На стороне Elastic Stack работали Filebeat, Logstash, Elasticsearch и Kibana; на стороне SigNoz — сборщик OpenTelemetry, ClickHouse и компоненты обработки и отображения данных. В этом эксперименте SigNoz интенсивнее использовал процессор на коротком отрезке загрузки, а Elastic Stack потреблял больше памяти и дольше обрабатывал журналы. Размер каталога базы показывает лишь часть ресурсов, нужных развёрнутой системе.

У результата есть методическая граница: дипломный эксперимент проходил автономно на одной машине, с несколькими наборами журналов и конфигурациями, близкими к стандартным. Он оценивал загрузку, процессор, память и диск, но не сравнивал задержку поисковых запросов. В сравнении отдельных движков, напротив, измерялись запросы к другому корпусу данных и другим версиям систем. Коэффициенты из этих работ нельзя складывать в общий прогноз экономии.

Сокращение индекса способно уменьшить занятое место, но меняет доступные операции. Если старые журналы должны оставаться пригодными для поиска фраз, нельзя оценивать хранение по конфигурации, в которой ради меньшего размера отключены необходимые поисковые структуры. Если же архив в основном нужен для подсчётов по времени и службам, более компактное представление может оказаться полезнее широких текстовых возможностей.

Матрица выбора для журнальных нагрузок

• Точный поиск и ранжирование. Для запросов, чувствительных к порядку слов, и выдачи по текстовой релевантности предпочтителен Elasticsearch. Для известных слов, кодов и идентификаторов подходит и текстовый индекс ClickHouse; требования к фразам следует оценивать отдельно.
• Массовые агрегации. Когда после отбора нужно считать события по времени, службе или уровню ошибки, сильнее выглядит ClickHouse. Его измеренное преимущество относится прежде всего к запросам, в которых совпадений достаточно много для последующей аналитической работы.
• Длительное хранение. Если главный предел — диск, ClickHouse заслуживает первоочередного рассмотрения вместе с настройками индексирования. Для бюджета полного развёртывания важны также процессор и память сборщиков, обработчиков и интерфейса.

Такой выбор зависит от преобладающего действия с журналом: получить релевантные записи, собрать сводку по множеству событий или долго держать большой корпус доступным для запросов. Эти потребности могут сочетаться, но результат одного теста следует переносить только на сопоставимую форму запроса и сопоставимый состав системы.

Читайте также:

• PostgreSQL или MongoDB: чтение и массовая запись дают разных победителей
• ClickHouse или PostgreSQL: 100 млн событий меняют выбор базы
• Контент-план для TikTok: поиск и аналитика теперь меняют темы после публикации