Публикация была переведена автоматически. Исходный язык: Русский
Сегодня расскажем вам про один из самых драматичных «разводов» в мире баз данных. О том, как команда китайских инженеров разругалась, а в итоге создала две лучшие OLAP-системы на рынке.
Спойлер: эта история включает в себя юридические войны за торговую марку, философские споры об «истинном пути» разработчика, и урок о том, что иногда конкуренция это хорошо (по крайней мере, для нас, пользователей).
Если вы думаете, что корпоративные драмы бывают только в сериалах HBO — добро пожаловать в мир Open Source - Минус Борвольдс
Часть 1: Как всё начиналось (Baidu это не только китайский поисковик)
В начале 2010-х годов мир больших данных был одержим Hadoop. Все строили свои «озёра данных» и радовались, что можно хранить петабайты информации. Была только одна проблема: когда дело доходило до аналитики, скорость была примерно как у интернета по dial-up.
Инженеры китайского гиганта Baidu (это такой Google, только китайский, если кто-то не знает) решили, что так жить нельзя. Они начали пилить свою собственную аналитическую базу данных под кодовым названием Palo.
К 2017 году штука заработала настолько хорошо, что Baidu обрабатывала на ней петабайты рекламных данных. И тут кто-то принял решение, которое изменит всё: «А давайте откроем код!»
В 2018 году проект передали в Apache Software Foundation под новым именем Apache Doris. Всё как по учебнику: открытый код, сообщество контрибьюторов, демократия и консенсус.
И тут началось самое интересное...
Часть 2: Великий раскол
Представьте себе ситуацию: вы талантливый инженер, видите, как рынок аналитики реального времени растёт на 50% в год, а ваш проект застрял в бюрократии Apache Foundation, где каждое архитектурное решение нужно обсуждать в публичных рассылках неделями.
К 2020 году внутри команды Apache Doris сформировались два лагеря:
- Трудовой Лагерь «Эволюционистов» (будущий VeloDB): «Ребята, давайте не будем ломать то, что работает. У нас Baidu, Meituan, Xiaomi — все на нашем коде сидят. Будем улучшать постепенно, сохраняя совместимость».
- Трудовой Лагерь «Революционеров» (будущий StarRocks): «Старый код это технический долг, который нас похоронит. Нужно переписать движок с нуля! Только чистый лист позволит нам достичь настоящей производительности!»
Это примерно как спор «делать ремонт постепенно» vs «снести всё и построить заново». Оба варианта имеют право на жизнь, но компромисс тут найти сложно и в возможен развод. - Мой дед
Революционеры ушли и основали свою компанию. И тут начался настоящий цирк...кони
Часть 3: Развод, расставашки, всегда печалька
Ушедшая команда выпустила свой продукт под названием...
Да-да, вы всё правильно поняли. Люди форкнули проект Apache Doris и назвали свой коммерческий продукт почти так же. Это примерно как уйти из McDonald's и открыть бургерную «McDonaldz» напротив. Технически другое название, но все всё понимают. - Александр Полоротов
Apache Software Foundation отреагировала предсказуемо: «Ребята, вы серьёзно?» При передаче проекта в фонд все права на торговую марку переходят к Apache. Использование названия «Doris» в коммерческом продукте это прямое нарушение.
Более того, эта ситуация заблокировала выпуск оригинального Apache Doris из инкубатора в статус Top-Level Project. Фонд просто не мог гарантировать чистоту бренда, пока на рынке существовал DorisDB.
В итоге под давлением и угрозой судебных разбирательств компания провела ребрендинг. DorisDB стал StarRocks.
Развод состоялся официально: разные названия (VeloDB и StarRocks), разный код, разные лицензии, разные пути.
Часть 4: Стать лучшей версией себя после развода
Давайте разберёмся, чем же отличаются эти системы по существу.
Ребята из StarRocks переписали ядро на современном C++, сделав ставку на экстремальную производительность в сложных сценариях.
Главный козырь: Мощный оптимизатор для сложных JOIN-ов. Если у вас специфический сценарий, где нужно соединять десятки таблиц на лету без предварительной подготовки, StarRocks это умеет блестяще.
Это решение требует больше ресурсов (особенно памяти) и заточено под одну конкретную задачу быструю аналитику. Это «болид Формулы-1»: невероятно быстрый на треке, но вы не поедете на нём в магазин за хлебом или на дачу по бездорожью.
Команда Doris пошла по пути создания универсального комбайна для данных. Вместо того чтобы фокусироваться только на скорости JOIN-ов, они расширили спектр задач, которые может решать современная база данных.
Ключевые отличия:
- Инвертированные индексы (Inverted Indexes). Это «киллер-фича», которая превращает аналитическую базу в поисковый движок. Вы можете хранить и анализировать логи в той же базе, где лежат бизнес-данные. Не нужно поддерживать отдельный (и дорогой) кластер Elasticsearch. Экономия на инфраструктуре может достигать 5-10 раз.
- Продвинутая работа с обновлениями (Partial Updates). Возможность обновлять только отдельные колонки в широких таблицах, не переписывая строку целиком. Критически важно для AI-систем (Feature Store), где данные обновляются часто и точечно.
- Apache Governance. Стабильность и отсутствие рисков vendor lock-in. Продукт принадлежит фонду, а не одной коммерческой компании, что для многих энтерпрайзов решающий фактор безопасности.
По сути, StarRocks позиционируется как высокопроизводительный движок для сложных запросов, а VeloDB как единая платформа данных, закрывающая задачи аналитики, поиска и AI.
Часть 5: Конкуренция
Помните из «Алисы в Зазеркалье»?
Здесь нужно бежать изо всех сил, чтобы оставаться на месте - Королева
Это идеальное описание того, что происходит между VeloDB и StarRocks последние 5 лет:
- StarRocks выпустила Primary Key Model → Doris ответила Merge-on-Write
- StarRocks внедрила крутой CBO → Doris выкатила Nereids
- Doris добавила инвертированные индексы → StarRocks начала улучшать свои механизмы индексации
К 2026 году по базовому функционалу системы достигли паритета. Но ключевое отличие осталось: VeloDB развивалась как универсальная платформа, а StarRocks как узкоспециализированный движок для одного типа задач.
Вот так раскол и конкуренция, которые казались катастрофой в 2020-м, привели к тому, что обе системы стали лучше.
Но путь VeloDB оказался более практичным для реального бизнеса.
Личное мнение Александра Полоротова.
Эпилог
Обе системы сейчас ломанулись в AI.
Векторный поиск, RAG-архитектуры, интеграция с LLM это новое поле битвы.
VeloDB здесь снова выглядит интереснее: они интегрируют векторный поиск с традиционным полнотекстовым (Hybrid Search).
Это значит, что можно искать и по смыслу (семантически), и по ключевым словам одновременно именно то, что нужно для современных AI-приложений.
История двух братьев-близнецов, которые поссорились и стали конкурентами, продолжается.
Но если вам нужно выбрать сторону прямо сейчас смотрите не на бенчмарки (они меняются каждый месяц), а на то, какая архитектура лучше ложится на ваши бизнес-задачи: узкая специализация или универсальность.
А если нужна помощь с выбором, то вам в компанию Datanomix.pro
© Александр Полоротов, 2026
Публикуется с разрешения автора.
Сегодня расскажем вам про один из самых драматичных «разводов» в мире баз данных. О том, как команда китайских инженеров разругалась, а в итоге создала две лучшие OLAP-системы на рынке.
Спойлер: эта история включает в себя юридические войны за торговую марку, философские споры об «истинном пути» разработчика, и урок о том, что иногда конкуренция это хорошо (по крайней мере, для нас, пользователей).
Если вы думаете, что корпоративные драмы бывают только в сериалах HBO — добро пожаловать в мир Open Source - Минус Борвольдс
Часть 1: Как всё начиналось (Baidu это не только китайский поисковик)
В начале 2010-х годов мир больших данных был одержим Hadoop. Все строили свои «озёра данных» и радовались, что можно хранить петабайты информации. Была только одна проблема: когда дело доходило до аналитики, скорость была примерно как у интернета по dial-up.
Инженеры китайского гиганта Baidu (это такой Google, только китайский, если кто-то не знает) решили, что так жить нельзя. Они начали пилить свою собственную аналитическую базу данных под кодовым названием Palo.
К 2017 году штука заработала настолько хорошо, что Baidu обрабатывала на ней петабайты рекламных данных. И тут кто-то принял решение, которое изменит всё: «А давайте откроем код!»
В 2018 году проект передали в Apache Software Foundation под новым именем Apache Doris. Всё как по учебнику: открытый код, сообщество контрибьюторов, демократия и консенсус.
И тут началось самое интересное...
Часть 2: Великий раскол
Представьте себе ситуацию: вы талантливый инженер, видите, как рынок аналитики реального времени растёт на 50% в год, а ваш проект застрял в бюрократии Apache Foundation, где каждое архитектурное решение нужно обсуждать в публичных рассылках неделями.
К 2020 году внутри команды Apache Doris сформировались два лагеря:
- Трудовой Лагерь «Эволюционистов» (будущий VeloDB): «Ребята, давайте не будем ломать то, что работает. У нас Baidu, Meituan, Xiaomi — все на нашем коде сидят. Будем улучшать постепенно, сохраняя совместимость».
- Трудовой Лагерь «Революционеров» (будущий StarRocks): «Старый код это технический долг, который нас похоронит. Нужно переписать движок с нуля! Только чистый лист позволит нам достичь настоящей производительности!»
Это примерно как спор «делать ремонт постепенно» vs «снести всё и построить заново». Оба варианта имеют право на жизнь, но компромисс тут найти сложно и в возможен развод. - Мой дед
Революционеры ушли и основали свою компанию. И тут начался настоящий цирк...кони
Часть 3: Развод, расставашки, всегда печалька
Ушедшая команда выпустила свой продукт под названием...
Да-да, вы всё правильно поняли. Люди форкнули проект Apache Doris и назвали свой коммерческий продукт почти так же. Это примерно как уйти из McDonald's и открыть бургерную «McDonaldz» напротив. Технически другое название, но все всё понимают. - Александр Полоротов
Apache Software Foundation отреагировала предсказуемо: «Ребята, вы серьёзно?» При передаче проекта в фонд все права на торговую марку переходят к Apache. Использование названия «Doris» в коммерческом продукте это прямое нарушение.
Более того, эта ситуация заблокировала выпуск оригинального Apache Doris из инкубатора в статус Top-Level Project. Фонд просто не мог гарантировать чистоту бренда, пока на рынке существовал DorisDB.
В итоге под давлением и угрозой судебных разбирательств компания провела ребрендинг. DorisDB стал StarRocks.
Развод состоялся официально: разные названия (VeloDB и StarRocks), разный код, разные лицензии, разные пути.
Часть 4: Стать лучшей версией себя после развода
Давайте разберёмся, чем же отличаются эти системы по существу.
Ребята из StarRocks переписали ядро на современном C++, сделав ставку на экстремальную производительность в сложных сценариях.
Главный козырь: Мощный оптимизатор для сложных JOIN-ов. Если у вас специфический сценарий, где нужно соединять десятки таблиц на лету без предварительной подготовки, StarRocks это умеет блестяще.
Это решение требует больше ресурсов (особенно памяти) и заточено под одну конкретную задачу быструю аналитику. Это «болид Формулы-1»: невероятно быстрый на треке, но вы не поедете на нём в магазин за хлебом или на дачу по бездорожью.
Команда Doris пошла по пути создания универсального комбайна для данных. Вместо того чтобы фокусироваться только на скорости JOIN-ов, они расширили спектр задач, которые может решать современная база данных.
Ключевые отличия:
- Инвертированные индексы (Inverted Indexes). Это «киллер-фича», которая превращает аналитическую базу в поисковый движок. Вы можете хранить и анализировать логи в той же базе, где лежат бизнес-данные. Не нужно поддерживать отдельный (и дорогой) кластер Elasticsearch. Экономия на инфраструктуре может достигать 5-10 раз.
- Продвинутая работа с обновлениями (Partial Updates). Возможность обновлять только отдельные колонки в широких таблицах, не переписывая строку целиком. Критически важно для AI-систем (Feature Store), где данные обновляются часто и точечно.
- Apache Governance. Стабильность и отсутствие рисков vendor lock-in. Продукт принадлежит фонду, а не одной коммерческой компании, что для многих энтерпрайзов решающий фактор безопасности.
По сути, StarRocks позиционируется как высокопроизводительный движок для сложных запросов, а VeloDB как единая платформа данных, закрывающая задачи аналитики, поиска и AI.
Часть 5: Конкуренция
Помните из «Алисы в Зазеркалье»?
Здесь нужно бежать изо всех сил, чтобы оставаться на месте - Королева
Это идеальное описание того, что происходит между VeloDB и StarRocks последние 5 лет:
- StarRocks выпустила Primary Key Model → Doris ответила Merge-on-Write
- StarRocks внедрила крутой CBO → Doris выкатила Nereids
- Doris добавила инвертированные индексы → StarRocks начала улучшать свои механизмы индексации
К 2026 году по базовому функционалу системы достигли паритета. Но ключевое отличие осталось: VeloDB развивалась как универсальная платформа, а StarRocks как узкоспециализированный движок для одного типа задач.
Вот так раскол и конкуренция, которые казались катастрофой в 2020-м, привели к тому, что обе системы стали лучше.
Но путь VeloDB оказался более практичным для реального бизнеса.
Личное мнение Александра Полоротова.
Эпилог
Обе системы сейчас ломанулись в AI.
Векторный поиск, RAG-архитектуры, интеграция с LLM это новое поле битвы.
VeloDB здесь снова выглядит интереснее: они интегрируют векторный поиск с традиционным полнотекстовым (Hybrid Search).
Это значит, что можно искать и по смыслу (семантически), и по ключевым словам одновременно именно то, что нужно для современных AI-приложений.
История двух братьев-близнецов, которые поссорились и стали конкурентами, продолжается.
Но если вам нужно выбрать сторону прямо сейчас смотрите не на бенчмарки (они меняются каждый месяц), а на то, какая архитектура лучше ложится на ваши бизнес-задачи: узкая специализация или универсальность.
А если нужна помощь с выбором, то вам в компанию Datanomix.pro
© Александр Полоротов, 2026
Публикуется с разрешения автора.
Поделиться
