Пакеты поддержки
Техническая поддержка СУБД «Старрокс Про»
Профессиональная техническая поддержка для StarRocks Pro и StarRocks Community
Мы предоставляем единый сервис технической поддержки для продуктов на базе StarRocks. Сервисное покрытие распространяется как на коммерческую СУБД «Старрокс Про», так и на инсталляции нативного StarRocks.
Условия покрытия нативного StarRocks:
Профессиональная техническая поддержка действует для развертываний StarRocks Community, выполненных инженерами нашей компании или соответствующих нашим стандартам конфигурации и развертывания.
Цели сервиса:
Мы предоставляем единый сервис технической поддержки для продуктов на базе StarRocks. Сервисное покрытие распространяется как на коммерческую СУБД «Старрокс Про», так и на инсталляции нативного StarRocks.
Условия покрытия нативного StarRocks:
Профессиональная техническая поддержка действует для развертываний StarRocks Community, выполненных инженерами нашей компании или соответствующих нашим стандартам конфигурации и развертывания.
Цели сервиса:
- Оперативное устранение инцидентов и нештатных ситуаций.
- Консультации по оптимизации производительности кластера.
- Гарантированная стабильность и отказоустойчивость вашей аналитической платформы.
- Снижение операционных рисков и простоев системы.
Сообщество
Стартовая цена:
₽ 120.000/аккаунт
Поддержка через:
- чат
✔ Доступ к базе знаний
✔ Доступ к обновлениям, патчам и "горячим" исправлениям
✔ Выделенный менеджер по техническим вопросам в рабочее время
✔ Доступ к обновлениям, патчам и "горячим" исправлениям
✔ Выделенный менеджер по техническим вопросам в рабочее время
Стартовая цена:
₽ 100.000/ядро
Решение проблемы в режиме 24/7/365
✔ 2-я и 3-я линия поддержки
✔ Доступность 99,5% в течении месяца
✔ Время отклика до 30 минут
✔ Доступ к обновлениям, патчам и "горячим" исправлениям
✔ Выделенный менеджер по техническим вопросам в рабочее время
✔ Максимальное время простоя до 1,5 час/месяц
✔ Плановое обслуживание до 1 часа/месяц в выходные дни
✔ Доступность 99,5% в течении месяца
✔ Время отклика до 30 минут
✔ Доступ к обновлениям, патчам и "горячим" исправлениям
✔ Выделенный менеджер по техническим вопросам в рабочее время
✔ Максимальное время простоя до 1,5 час/месяц
✔ Плановое обслуживание до 1 часа/месяц в выходные дни
Бизнес - 24х7
Стартовая цена:
₽ 60.000/ядро
Решение проблемы в рабочее время
✔ 3-я линия поддержки
✔ Доступность 98,0% в течении месяца
✔ Срок исполнения до 5 рабочих дней
✔ Доступ к обновлениям, патчам и "горячим" исправлениям
✔ Выделенный менеджер по техническим вопросам в рабочее время
✔ Максимальное время простоя до 12 час/месяц
✔ Плановое обслуживание до 5 часа/месяц в выходные дни
✔ Доступность 98,0% в течении месяца
✔ Срок исполнения до 5 рабочих дней
✔ Доступ к обновлениям, патчам и "горячим" исправлениям
✔ Выделенный менеджер по техническим вопросам в рабочее время
✔ Максимальное время простоя до 12 час/месяц
✔ Плановое обслуживание до 5 часа/месяц в выходные дни
Базовая - 8х5
Заявка на приобретение лицензии
Заявка на приобретение лицензии
Заявка на приобретение лицензии
FAQ
Часто задаваемые вопросы
Ответ: Рекомендуется иметь не менее 8 ядер CPU, 16 ГБ оперативной памяти и 100 ГБ свободного места на SSD-диске на каждый узел (BE). Для FE узлов требования скромнее. Точные требования зависят от объема данных и нагрузки. Всегда сверяйтесь с актуальной версией документации.
Ответ: StarRocks поддерживает стандартный протокол MySQL. Вы можете использовать любой MySQL-совместимый клиент или драйвер (например, для Java используйте mysql-connector-java). Строка подключения будет выглядеть так:
jdbc:mysql://<fe_host>:<fe_query_port>/<database>?user=<username>&password=<password>.
jdbc:mysql://<fe_host>:<fe_query_port>/<database>?user=<username>&password=<password>.
Ответ:
- FE (Frontend): Управляет метаданными, координирует подключения клиентов и планирует запросы. Отвечает за DDL-операции (CREATE, DROP, ALTER).
- BE (Backend): Хранит данные, выполняет SQL-запросы (сканирование, агрегация) и операции загрузки данных. Это "рабочие лошадки" кластера.
Ответ: Это стандартная ошибка аутентификации MySQL. Проверьте:
- Правильность логина и пароля.
- Есть ли у пользователя права на доступ к конкретной базе данных (GRANT privileges).
- Указан ли правильный хост в настройках пользователя (если ограничения настроены).
Ответ:
- Duplicate: Для детальных данных, где важна вся строка (например, логи событий, транзакции). Нет агрегации.
- Aggregate: Для метрик и отчетов, где данные предварительно агрегируются (SUM, COUNT, MIN, MAX). Экономит место и ускоряет запросы.
- Unique: Для данных с уникальным ключом, где нужно обновление по последней версии (например, профили пользователей). Работает по модели "обновление-при-загрузке".
Ответ:
- Партиционирование (Partitioning): Разделяет таблицу на логические части (например, по дате). Позволяет использовать Partition Pruning — при запросе за определенный период сканируются только нужные партиции, что сильно ускоряет работу.
- Бакетирование (Bucketing): Распределяет данные внутри партиции по "корзинам" (bucket) на основе хэша от ключевых столбцов. Помогает распределить данные по узлам BE для параллельного выполнения и эффективных джойнов.
Ответ: StarRocks использует концепцию "уникальных ключей" для обновляемых таблиц. Первичный ключ определяется в модели Unique Key или Primary Key (с версии 3.0). Ключ должен быть составлен из колонок, которые однозначно идентифицируют строку. Пример:
sql
CREATE TABLE orders (
order_id BIGINT,
user_id INT,
...,
PRIMARY KEY (order_id)
) UNIQUE KEY (order_id)
DISTRIBUTED BY HASH(order_id) BUCKETS 8;
sql
CREATE TABLE orders (
order_id BIGINT,
user_id INT,
...,
PRIMARY KEY (order_id)
) UNIQUE KEY (order_id)
DISTRIBUTED BY HASH(order_id) BUCKETS 8;
Ответ:
- Проверьте план выполнения запроса с помощью EXPLAIN <your_query>. Ищите полные сканирования таблиц (SCAN) без предикатов.
- Убедитесь, что работают Partition Pruning и Bucket Pruning.
- Проверьте метрики в веб-интерфейсе FE (потребление CPU, память, дисковый I/O на BE).
- Убедитесь, что для частых условий в WHERE и джойнах созданы индексы (Bitmap/Short Key) или используются ключевые колонки.
Ответ: Основные способы:
- Stream Load: Для потоковой загрузки данных из файлов (например, через curl).
- Broker Load: Для высокопроизводительной пакетной загрузки данных из HDFS или облачных хранилищ (S3, GCS).
- Routine Load: Для непрерывного потребления данных из Kafka.
- Insert Into: Для вставки данных напрямую через SQL (подходит для небольших объемов).
- Spark Load: Для загрузки с использованием Apache Spark (подходит для сложных ETL-процессов).
Ответ: Возможные причины:
- Нехватка ресурсов: Проверьте, нет ли нехватки памяти или дискового пространства на BE.
- Проблемы с источником данных: Убедитесь, что BE-узлы имеют доступ к HDFS/S3 и файлы данных существуют.
- Слишком высокий параллелизм: Уменьшите параметр load_parallelism в команде загрузки.
Ответ: Используйте команду EXPORT. Например, для выгрузки в S3:
sql
EXPORT TABLE my_table
TO "s3://my_bucket/export_path/"
WITH BROKER "...";
sql
EXPORT TABLE my_table
TO "s3://my_bucket/export_path/"
WITH BROKER "...";
Ответ: Запрос превысил лимит памяти. Это часто происходит при агрегации больших объемов данных, сложных джойнах или недостаточной сегментации (слишком мало бакетов). Решения: оптимизировать запрос, увеличить партиционирование/бакетирование, или временно увеличить лимит памяти через системную переменную set exec_mem_limit=....
Ответ:
Просмотр: SHOW PROC '/current_queries' или через веб-интерфейс FE.
Завершение: Найдите QueryId зависшего запроса и выполните KILL QUERY "<QueryId>";
Просмотр: SHOW PROC '/current_queries' или через веб-интерфейс FE.
Завершение: Найдите QueryId зависшего запроса и выполните KILL QUERY "<QueryId>";
Ответ:
- Неправильное распределение данных: Убедитесь, что таблицы распределены (DISTRIBUTED BY) по ключу джойна. Это позволяет выполнять "локальные" джойны на BE, без пересылки данных (Shuffle Join).
- Отсутствие фильтрации: Добавьте условия WHERE для уменьшения объема данных до джойна.
- Большая таблица джойнится с большой: Пересмотрите логику запроса. Возможно, нужно предварительно агрегировать одну из таблиц.
Ответ: Materialized Views (MV) в StarRocks автоматически пересчитываются при загрузке данных и используются для ускорения запросов. Создание:
sql
CREATE MATERIALIZED VIEW mv_sales_summary AS
SELECT product_id, date, SUM(sales) as total_sales
FROM sales_table
GROUP BY product_id, date;
sql
CREATE MATERIALIZED VIEW mv_sales_summary AS
SELECT product_id, date, SUM(sales) as total_sales
FROM sales_table
GROUP BY product_id, date;
Ответ:
- Установите и настройте BE на новом хосте (аналогично первоначальной установке).
- Подключитесь к кластеру через MySQL-клиент и выполните: ALTER SYSTEM ADD BACKEND "new_be_host:port";
- Проверьте статус узла: SHOW BACKENDS;. Состояние должно стать Alive.
Ответ:
- Логи FE: По умолчанию в fe/log/. Основные файлы: fe.warn.log, fe.info.log.
- Логи BE: По умолчанию в be/log/. Основные файлы: be.WARNING, be.INFO. Логи содержат временные метки, уровень логирования (INFO, WARN, ERROR) и детали операции. Ищите по ERROR или WARN для диагностики проблем.
Ответ:
- Метаданные FE: Настроить регулярное автоматическое создание снапшотов (включено по умолчанию). Ручной бэкап: ./bin/meta_tool --operation backup --meta_dir=/path/to/fe/meta --image_dir=/path/to/backup.
- Данные BE: Рекомендуется использовать репликацию на уровне хранилища (например, RAID) или регулярные снапшоты файловой системы. Встроенных инструментов для полного бэкапа данных "на лету" нет.
Ответ: Эта ошибка возникает, когда данные в таблице имеют слишком много версий (из-за частых загрузок или сжатия). Это может привести к нехватке памяти. Решение — запустить процесс компакции вручную: ADMIN COMPACT TABLE table_name;. В долгосрочной перспективе стоит пересмотреть частоту загрузки данных.
Ответ: Рекомендуется последовательное обновление (rolling upgrade) для минимизации простоя:
- Остановите один BE узел, обновите его бинарники, запустите.
- Повторите для всех BE узлов.
- Остановите один FE узёл (если у вас несколько), обновите, запустите.
- Повторите для всех FE узлов.
- Всегда проверяйте руководство по обновлению для вашей целевой версии на предмет специфичных шагов.
Связаться с нами
Поддерживаем решения:
Техподдержка:
Отдел продаж:
«СтарРокс Про» — российская команда, которая разрабатывает и поддерживает локализованную версию СУБД StarRocks для отечественных проектов.
Мы делаем полную локализацию интерфейса и запросного слоя, готовим подробную русскоязычную документацию и примеры, адаптируем систему под местные требования по интеграции, безопасности и сопровождению. Предоставляем внедрение, сопровождение, обучение и консалтинг, чтобы ускорить запуск аналитики на больших объёмах данных и снизить риски при эксплуатации в корпоративной инфраструктуре.
Мы делаем полную локализацию интерфейса и запросного слоя, готовим подробную русскоязычную документацию и примеры, адаптируем систему под местные требования по интеграции, безопасности и сопровождению. Предоставляем внедрение, сопровождение, обучение и консалтинг, чтобы ускорить запуск аналитики на больших объёмах данных и снизить риски при эксплуатации в корпоративной инфраструктуре.
О компании «СтарРокс ПРО»:
