Это обзор двух проектов аналитических СУБД с открытым исходным кодом, которые развиваются в одном классе задач, но различаются архитектурой, приоритетами и типичными сценариями применения. Ниже — нейтральное сравнение по ключевым аспектам: архитектура и запросный движок, хранение и работа в реальном времени, интеграция с открытыми форматами и lakehouse, производительность, эксплуатация и управление, а также рекомендации по выбору в зависимости от нагрузки.

Исторический контекст и траектории развития

• Проекты связаны общей историей: несколько участников Apache Doris в своё время сделали форк, что положило начало развитию StarRocks.

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

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

Архитектура и движок запросов

• Запросные движки:

  • В StarRocks реализован собственный движок, разработанный «с нуля».

  • В Doris изначально использовался стек на базе идей Apache Impala; со временем он также получил существенные доработки.

• Типовые технологии, поддерживаемые обоими проектами (в актуальных версиях и с разной зрелостью):

  • Векторизованное выполнение для эффективной работы с колонночными данными.

  • Стоимостной оптимизатор (cost-based optimizer) для планирования многотабличных запросов.

  • Конвейерное выполнение (pipeline) для лучшей утилизации многоядерных CPU.

• Практическая разница ощущается в конкретных паттернах JOIN, планировании сложных запросов, устойчивости под конкуренцией и в том, как движки ведут себя на высоких кардинальностях и неравномерном распределении данных.

Хранение и обработка в реальном времени

• Работа с изменяемыми данными:

  • Поддержка таблиц с первичным ключом и операций upsert присутствует; реализация механизмов доставки, индексации и компакций различается.

• Разделение вычислений и хранения:

  • Оба проекта движутся в сторону эффективной работы в облаке; распространён подход «разделение вычислений и хранения», чтобы использовать эластичность объектных стораджей и масштабирование вычислительных пулов.

• Ключевые измерения при оценке:

  • Задержка инкрементальной загрузки до видимости в запросах (ingestion-to-query latency).

  • Нагрузка и периодичность компакций.

  • Стабильность SLA под высокой конкуренцией на смешанных (write+read) сценариях.

Интеграция с открытыми форматами и lakehouse

• Поддержка открытых форматов и прямой работы по схеме «хранилище на озёре данных» (lakehouse) присутствует в обоих проектах.

• Типовые возможности:

  • Внешние каталоги для обращения к озёрам данных и колоночным форматам (например, Parquet/ORC) без обязательной загрузки в собственное хранилище.

  • Материализованные представления с переписыванием запросов (query rewrite) для он-деманд предвычислений.

  • Кэширование данных и метаданных для сглаживания разницы между объектными стораджами и локальным/«горячим» хранением.

  • Управление рабочими нагрузками (workload management) для гетерогенных сценариев.

• Факторы, влияющие на реальную производительность в режиме lakehouse:

  • Организация данных (размер файлов, партиционирование, сортировка, эвристики по «маленьким файлам»).

  • Эффективность pushdown и фильтрации на стороне источника.

  • Политики кэширования и прогрева.

Производительность: на что смотреть при выборе

• Объективные тесты зависят от набора данных и профиля запросов; результаты разных организаций могут сильно различаться.

• Рекомендуемые метрики для пилотирования:

  • Время отклика (p50/p95/p99) при различных профилях конкуренции.

  • Поведение JOIN и агрегаций на больших таблицах (включая многотабличные запросы без предварительной денормализации).

  • Эффективность точечных запросов и полнотекстового поиска (если используется).

  • Задержка от загрузки до доступности в аналитике при upsert и стриминговых сценариях.

  • Пропускная способность загрузки (ingest), объём компакций и накладные расходы на обслуживание.

  • Использование CPU/памяти/сети и воздействие на стоимость инфраструктуры.

Эксплуатация, управление и безопасность

• Кластерное управление и масштабирование: доступны инструменты для горизонтального увеличения ресурсов, балансировки и изоляции нагрузок; набор и глубина функций отличаются версиями.

• Управление доступом: роли и привилегии на объекты каталога/схем/таблиц; интеграция с внешними провайдерами аутентификации может отличаться.

• Наблюдаемость: метрики, профилировщики запросов, трассировка, планы выполнения — важные элементы при эксплуатации и разборе инцидентов.

• Совместимость и экосистема: коннекторы к системам загрузки/стриминга, инструменты миграции, соответствие SQL-диалектам — проверяйте под ваши стек и требования.

Типовые сценарии использования

• Высококонкурентные точечные запросы и полнотекстовый поиск (например, анализ логов):

  • Нередко в подобных задачах рассматривают Apache Doris, в том числе как альтернативу связкам на базе Elasticsearch.

• Сложные аналитические запросы с множественными JOIN и крупными агрегациями:

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

• Real-time аналитика с изменяемыми данными (upsert):

  • Поддерживается в обоих проектах; ключевыми факторами будут задержка до видимости, стабильность под конкуренцией и накладные расходы компакций.

• Интеграция с lakehouse:

  • Оба проекта умеют напрямую запрашивать данные в озёрах; полезно оценить качество переписывания запросов в материализованные представления, кэширование и pushdown на ваших данных.

Практические рекомендации по выбору

• Исходите из доминирующих шаблонов запросов и требований к задержке/свежести данных.

• Проведите POC на ваших данных и инфраструктуре:

  • Репрезентативный набор запросов (включая «тяжёлые» JOIN и агрегации, если они характерны).

  • Реалистичный уровень конкуренции и смешанные read/write сценарии.

  • Проверка режимов lakehouse (если актуально) с вашим разбиением и форматами.

• Сопоставьте эксплуатационные требования:

  • Нужные интеграции, требования к безопасности, удобство администрирования, наблюдаемость.

  • Стоимость владения: ресурсоёмкость, эффективность компрессии, объём компакций и т. п.

Вывод

Оба проекта решают схожие классы задач, но делают акцент на разных типах нагрузок и предлагают отличающиеся реализации ключевых компонентов. Для высококонкурентных точечных запросов и текстового поиска часто рассматривают Apache Doris; для многотабличной аналитики с интенсивными JOIN и агрегированием, а также для сценариев с изменяемыми данными и работой поверх lakehouse, нередко выбирают StarRocks. Окончательный выбор целесообразно делать по результатам собственных тестов на ваших данных и SLO, с учётом эксплуатационных ограничений и стоимости инфраструктуры.