Выделенный сервер для Elasticsearch и ClickHouse: от одного узла к кластеру аналитики

MAATRIX · Выделенные серверы · Статья 18 из 48

Сначала аналитическая система отвечает на вопросы. Потом вопросов становится больше, ответы длиннее, а дашборд начинает задумываться. В какой-то момент появляется предложение «собрать кластер». Оно звучит как готовое решение, хотя пока описывает лишь намерение купить несколько машин и познакомить их между собой.

Выделенный сервер для Elasticsearch или ClickHouse выбирают через характер данных и запросов. Эти системы решают пересекающиеся, но разные задачи, а масштабирование каждой требует своей схемы. Разберём, где полезны ANKH и NECROPOLIS, как считать память и диск и почему несколько процессов на одном хосте ещё не дают независимости от отказа.

Поиск и аналитический скан любят разную работу

Elasticsearch часто используют для поиска по документам, журналам и событиям, фильтрации и агрегаций. Важно, какие поля индексируются, как устроен поиск и сколько данных должно быть доступно быстро. Размер исходного JSON не равен размеру готового поискового индекса.

ClickHouse хорошо подходит для аналитического чтения больших наборов столбцовых данных. Но его эффективность сильно зависит от схемы таблицы, порядка сортировки, фильтров и характера агрегаций. Два запроса к одинаковому числу строк могут читать совершенно разный объём и создавать разные промежуточные структуры.

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

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

Сколько памяти действительно доступно запросам

У Elasticsearch есть JVM heap, память за его пределами и файловый кэш операционной системы. Увеличивать кучу до почти всей RAM обычно неправильно. Современная документация рекомендует для большинства рабочих случаев автоматический подбор heap с учётом роли узла; детали приведены в руководстве Elastic по настройкам.

При ручной настройке Elastic описывает верхнюю границу в 50% доступной узлу памяти и дополнительные ограничения JVM. Это верхняя оценка, а не приказ всегда выделять ровно половину. В контейнере учитывается его доступная память, а при нескольких узлах на общем хосте — их суммарные расходы. Источник — документация JVM settings.

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

Представим условную команду аналитиков. Один тяжёлый отчёт проходит спокойно, но после рассылки ссылки его одновременно открывают несколько человек. Измерение одиночного запроса уже не описывает происходящее. Нужно определить допустимое число параллельных задач и очередь, которая не превращает систему в соревнование за последний гигабайт.

С запасом также учитывают загрузку данных, фоновые слияния и обслуживание. Аналитическая машина редко только отвечает на вопросы: она одновременно принимает новые сведения и приводит хранилище в порядок. Практические симптомы расхода памяти описаны в материале о тяжёлом GROUP BY в ClickHouse.

ANKH, NECROPOLIS и PYRAMID под разные ограничения

ANKH в США за $329 предоставляет Ryzen 7600X с шестью ядрами, 64 ГБ DDR5 и 1 ТБ NVMe. Его можно включить в испытания умеренного аналитического узла, если данные, запросы и обслуживание укладываются в эти ресурсы. Он удобен как конкретная отправная точка, но не как обещание заданного количества событий в секунду.

NECROPOLIS за $529 даёт EPYC 7642 с 48 ядрами, 128 ГБ DDR4 и два NVMe по 1 ТБ. Дополнительная память и возможность выполнять много независимой работы интересны для смешанной аналитической нагрузки. Однако отдельный последовательный этап может не ускориться пропорционально числу ядер.

PYRAMID за $729 содержит два Xeon Silver 4510, суммарно 24 физических ядра, 128 ГБ DDR5 и один NVMe на 1 ТБ. Его проверяют по конкретному движку и профилю запросов. Сам факт двух процессоров или нового поколения памяти не доказывает превосходство над NECROPOLIS, особенно когда ограничение находится в диске.

CARTOUCHE в России предлагает 128 ГБ DDR4, 28 суммарных ядер двух E5-2680 v4 и два SSD по 600 ГБ за $295. Он может быть полезен для пакетных задач с приемлемыми сроками и требованиями к российскому размещению. Но возраст платформы и небольшой объём хранения требуют испытания; автоматически переносить на него результаты современных Ryzen нельзя.

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

Шард увеличивает ёмкость, реплика решает другую задачу

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

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

В ClickHouse репликация настраивается для соответствующих табличных движков и использует координацию. Наличие нескольких серверов и Distributed-таблицы само по себе не означает, что все данные уже имеют независимые копии. Механизм и условия описаны в документации ReplicatedMergeTree.

ClickHouse Keeper обеспечивает координационные функции и может заменять ZooKeeper в поддерживаемой схеме. Его участники тоже требуют продуманного размещения и кворума. Назначение системы объясняет официальный обзор Keeper. Разместить все координационные процессы на одной машине — значит сохранить общий аппаратный риск.

Один NECROPOLIS позволяет создать несколько виртуальных узлов для обучения или разделения ресурсов. Но если физический сервер остановится, остановятся и они. Для отказоустойчивого рабочего кластера нужны независимые узлы, подходящее размещение копий и запас, позволяющий пережить потерю части ресурсов.

Диск нужно считать в состоянии работы и восстановления

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

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

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

У ANKH и PYRAMID указан один терабайт, у NECROPOLIS — два устройства по терабайту. Зеркало на NECROPOLIS оставит примерно ёмкость одного диска; отдельное использование даст больше места, но иную модель отказа. Уровень локального резервирования выбирают вместе с репликацией и независимыми копиями, а не вместо них.

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

Почему сеть появляется в счёте даже у локального отчёта

Распределённый запрос, доставка новых данных, репликация и восстановление создают обмен между узлами. У рассматриваемых тарифов заявлен канал 1 Гбит/с, но наличие отдельной быстрой внутренней сети этим не подтверждено. Условия соединения своих серверов нужно запросить отдельно.

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

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

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

Испытайте вопросы, которые люди действительно задают

Подготовьте набор запросов из повседневной работы: частые фильтры, широкие агрегации, тяжёлые соединения, поиск и отчёты за длинный период. Сохраните реальные особенности распределения данных. Удобный равномерный тест способен скрыть перекосы, из-за которых рабочая система тормозит.

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

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

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

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

ANKH разумно проверять для умеренного старта, NECROPOLIS — при потребности в памяти и параллельной работе, PYRAMID — когда его платформа подтверждает пользу на вашем профиле. Для кластера эти решения умножаются на архитектуру, а не только на число серверов. Хорошая аналитика позволяет доверять и ответу, и времени его появления — даже после того, как один узел перестал отвечать.

Все материалы о выделенных серверах