За годы работы администратором баз данных и, в том числе со StarRocks, я накопил значительный опыт, сотрудничая с различными участниками сообщества, и вывел ряд лучших практик. За это время я выделил пять ключевых аспектов, критически важных для работы: развертывание, моделирование данных, загрузка данных, выполнение запросов и мониторинг.
В этой серии из пяти статей я подробно разберу каждый из этих аспектов и поделюсь всем накопленным опытом, чтобы помочь вам достичь оптимальной работы с StarRocks.
ЧАСТЬ 1: Развертывание
Планирование вычислительных ресурсов CPU
При условии, что память и диски не являются узкими местами, производительность аналитических запросов ограничивается вычислительной мощностью CPU. Следовательно, планирование количества кластеров следует начинать с оценки требований к вычислительным ресурсам процессора.
Общие требования к CPU для кластера:
e_core = (scan_rows / cal_rows) / e_rt * e_qps
Наименование переменной
Значение
Пример использования
e_core
Оценка количества ядер процессора (vCPU)
540 ядер
scan_rows
Объем сканируемых данных в типичных онлайн-сценариях
30 миллионов строк
e_qps
Ожидаемое количество запросов в секунду (QPS)
180 запросов в секунду
e_rt
Ожидаемое время отклика
300 миллисекунд
cal_rows
пропускная способность StarRocks (строк/секунду на ядро)
30 миллионов строк в секунду
Вот пример, который мы могли бы рассмотреть:
Объем данных: 360 миллионов строк данных факт-таблицы в год, примерно 1 миллион строк/день;
Типичный сценарий запроса: Соединение данных факт-таблицы за месяц (30 миллионов строк) с небольшой таблицей измерений (десятки тысяч строк) с последующей агрегацией (group by, sum);
Ожидания: Время отклика в пределах 300 мс, пиковая нагрузка около 180 запросов в секунду (QPS).
Оценка нашего примера с StarRocks:
Возможности обработки StarRocks варьируются от 10 до 100 миллионов строк/секунду на ядро. Учитывая, что этот сценарий включает соединение нескольких таблиц, группировку и некоторые относительно сложные функции выражений, мы можем оценить потребность в 3 vCPU, исходя из вычислительной мощности 30 миллионов строк в секунду.
30 миллионов строк / (30 миллионов строк в секунду) / 300 миллисекунд = 3 ядра
При пиковой нагрузке в 180 запросов в секунду (QPS) требования следующие:
30 ядра * 180 = 540 ядер
Таким образом, требуется суммарно 540 vCPU. При условии, что каждая физическая машина имеет 48 виртуальных ядер (vCPU), необходимо примерно 12 физических серверов.
В ходе реального процесса POC, который я проводил, использовались 3 физических сервера с 16 виртуальными ядрами каждый для нагрузочного тестирования. Было достигнуто время отклика 300–500 мс при нагрузке 40 запросов в секунду. В итоге для промышленной эксплуатации было подтверждено использование 7 физических серверов с 48 виртуальными ядрами каждый. Настоятельно рекомендуется проводить POC-тестирование с учетом конкретных сценариев использования.
Каковы были фактические результаты нашего POC? На основании тестовых результатов было рекомендовано развернуть 3 узла FE с 16 ядрами и 64 ГБ памяти каждый, и 7 узлов BE с 48 ядрами и 152 ГБ памяти каждый.
Дополнительные рекомендации:
Чем сложнее запрос и чем больше столбцов обрабатывается в каждой строке, тем меньше строк может быть обработано в секунду при тех же аппаратных ресурсах.
Лучшая "фильтрация условий" в вычислениях (исключение большого объема данных) позволяет обрабатывать больше строк (благодаря внутренним индексным структурам, ускоряющим обработку данных).
Разные типы таблиц значительно влияют на производительность. Приведенная выше оценка основана на таблицах с дублированными ключами. Другие модели предполагают специфическую обработку, что приводит к расхождениям между фактическим и расчетным количеством строк; также партиционирование/бакетирование влияет на производительность запросов.
Для сценариев, требующих сканирования больших объемов данных, производительность дисков также влияет на общую мощность обработки. Использование SSD может значительно ускорить обработку при необходимости.
Базовые настройки окружения
Обязательно: Проверьте настройки окружения в соответствии с документацией StarRocks, уделив особое внимание отключению swap, установке overcommit в 1 и правильной настройке ulimit.
Конфигурация оборудования
Узлы FE
Рекомендуется: 8 vCPU, 32 ГБ памяти
Обязательно: Диск для данных должен быть не менее 200 ГБ, предпочтительно SSD.
Узлы BE (архитектура shared nothing)
Рекомендуется: Соотношение CPU к памяти 1 vCPU: 4 ГБ, минимальная конфигурация для production - не менее 8 ядер и 32 ГБ памяти.
Рекомендуется: Емкость диска на одном узле - около 10 ТБ, диски с данными не должны превышать 2 ТБ на диск, предпочтительно SSD или NVME. При использовании HDD рекомендуется пропускная способность >150 МБ/с, IOPS >500.
Рекомендуется: Соотношение CPU к количеству дисков не должно превышать 4. То есть, если имеется 16 vCPU, количество дисков не должно превышать 4.
Рекомендуется: Однородный кластер (одинаковые характеристики машин для предотвращения узких мест).
Узлы CN (архитектура shared data)
Конфигурация CN в основном аналогична BE, за исключением настройки дисков. В архитектуре shared data данные хранятся в удаленном хранилище, а локальные диски CN используются как кэш для ускорения запросов. Настройте соответствующий объем дискового пространства в соответствии с требованиями к производительности запросов. Планирование развертывания
Обязательно: Минимальный размер кластера в production-среде - 3 FE + 3 BE (рекомендуется развертывать FE и BE на отдельных серверах). Если FE и BE развернуты на одних и тех же серверах, настройте mem_limit в be.conf для резервирования памяти под другие сервисы, например, если общий объем памяти 40 ГБ и FE уже использует 8 ГБ, установите mem_limit=30 ГБ (40-8-2), оставив 2 ГБ для системы.
Обязательно: Обеспечьте высокую доступность FE в production-среде: 1 Leader + 2 Followers. Для увеличения параллелизма чтения можно добавить узлы Observer.
Обязательно: Используйте балансировщик нагрузки для чтения и записи в кластере, обычно применяются Nginx, Haproxy и F5.