Потому что StarRocks данные читает и пишет через один CN. Те имеет явный bottleneck. Хорошие новости - в апрельском релизе в Data Ocean Nova выйдет доработка StarRocks и он сможет читать через JDBC распределено через все доступные CN узлы. Также выйдет коннектор для GreenPlum которые будет читать GP с сегментов через CN узлы распределенно.
Trino есть не в каждой установке клиентской. Не все пользователи делают выбор в пользу этого движка. Держать Trino только для загрузки данных - не эффективно. А Spark есть в 19 из 20 промышленных установок по текущей статистике.
Как человек который работал и с озон и с минио отвечу так - те кто изначально пошел в минио, озон рассматривать не будет.
В Сбербарнке и минио есть помимо озона и успешно эксплуатируется.
Кандидат должен быть таким же высокоприизводительным и не требовательным к железу как минио. Пока что по концепции ближе всего к этому RustFS, но он еще слишком сыроват для серьезного прода.
Автор вроде как рассматривает чисто бесплатные альтернативы без фстэка и прочей казуистики. Платные минио форки и российские есть с веб-мордой и полной поддержкой, если уж на то пошло.
В 2017 году группа китайцев "форкнула" Impala и ушла делать Doris. Мотивация была такой - ходим update delete timeseries? но не хотим идти в Kudu, а хотим в Mesa. Сами разработчики это назвали "идеологическим наследием". В процессе "перехода" перешли на свой собственный формат хранения и оптимизатор и стали shared-nothing СУБД по сути. За эти годы сообщество придумало OTF и они стали стандартом рынка в итоге Дорис начал переобуваться в ОТF форматы и по факту стал теперь догонять Импала в части поддержки открытых форматов.
СтарРокс форкнулся от Дорис в 2020г чтобы тоде уйти в свой формат со своим видением, но чуть раньше чем Дорис поняли что надо ориентироваться на OTF а не свои волшебные форматы.
Очень забавно читать материалы коллег, которые на голубом глазу рассказывают про уникальные векторные вычисления в Старрокс, которые на самом деле он унаследовал от бабушки антилоппы которая их умела в 2013 году.
СтарРокс как движок над S3 в настоящий момент в продакшине можно использовать только на чтение для bi adhoc доступа. ELT точно нет! С локальным стореджем можно жить, но не без приколов.
Какая у вас тут интересная дискуссия получается, коллеги.
Как персона, имеющая прямое отношение у указанным выше ссылкам с полной ответственностью заявляю что смена методики на любую другую не поменяет расклад сил в тестировании. Проверялось неоднократно и на пром данных, и на синтетических тестах и на расчетах ELT и на чем угодно.
Однако, ознакомившись со следующей статье вашего цикла, у меня есть ощущение, что на чем бы вы не обращались к данным, вы упираетесь в инфраструктуру S3. Поэтому, разницы особую можно и не заметить между движками.
Ваш выбор - это ваш выбор. Вы выбирали под своим критерии и значит вам это решение большо подошло. Хоть и переплатили за compute мощности, но зато увереннее себя чувствуете тк можете что то развивать своими силами. Это нормально же.
По поводу Spark. Без него вам нормально пока не выжить, если хотите перейти окончательно на iceberg как на целевой формат. Только Spark может предложить полное реальное работающее обслуживание iceberg формата.
В части StarRocks вы правы только от части - он умеет работать над S3, но не все операции с открытыми форматами данных на нем доступны, о чем умалчивают или не понимают некоторые российские вендоры.
Теперь к внедрениям - в РСХБ нет Lakehouse, есть Hadoop с HDFS без разделения storage и compute.. В БСПБ нет Lakehouse, есть Hadoop c HDFS без разделения storage и compute.
Почему у вас федеративные запросы у Impala желтые, а у StarRocks зеленые? Возможности Impala и Starrocks в части федеративных запросов одинаковые вообще-то.
Тот же вопрос и про Zero-ETL
Все критические компоненты Impala (координатор и внутренний каталог) имеют HA конфигурацию, но у вас отмечено желтым. Trino к слову может иметь только один Coordinator-узел и это является большой проблемой. Поэтому там не то чтобы желтенько быть должно, там красненько.
Почему у вас в Impala нет ACID интересно, когда оно есть?
Почему у вас у Impala нет cloud-native масштабируемости, когда она есть?
К слову про Starrocks: до сих пор нет поддержки Update Delete Megre для Iceberg, поддержка обслуживания iceberg не полная, нет поддержка alter table операций для OTF, и местами доходит до смешного, например - невозможно сделать insert table overwrite над просто секционированной паркетной таблицей.
Не нужно писать материалы, изучая предмет статьи по интернету.
Позвольте объяснить вам свою позицию - На российском рынке присутствуют другие игроки-вендоры, разрабатывающие и продающие свои решения, которые утверждаю что умеют в Starrocks, умеют в Impala, Spark и Trino. У меня нет намерений обучать конкурентов. Это наше конкурентное преимущество - продемонстрировать клиенту не только доработками и улучшениями open source кода, но и уметь решать проблемы, настраивать систему (ПО, окружение, оборудование) на максимальную и стабильную пропускную способность для решения его (клиента) задач. При этом зрелый клиент не выбирает решение по публикациям в интернете, а приглашает всех участников продемонстрировать на практике.
ну вот именно поэтому платформа на одном движке - это проблема либо на старте либо отложенная. Не просто так же в среднем каждый клиент-заказчик использует больше 2х движков.
В нашем решении StaкRocks используется как lakehouse-движок. Это означает что он использует только открытый табличный формат Iceberg и файловый формат хранения. Никаких "индексов starrocks" нет и в помине. Вы путаете Starrocks с использованием проприетарным закрытым родным форматов хранения. Поэтому, к сожалению, ваш комментарий не валидный на 100%.
Владимир, конфигурация тестовых стендов, как и было обещано, указана.
Этого достаточно, чтобы проявив экспертизу и богатый опыт, изучив документацию, через несколько итераций тестирования, прийти к индивидуальным параметрам движков для оптимальной производительности.
Со списком "не ванильных" опций и изменений движков можно ознакомиться на сайте.
Разбудите меня когда CH пройдет хотя бы TPCDS
Они сделали ставку на всё.
Потому что StarRocks данные читает и пишет через один CN. Те имеет явный bottleneck. Хорошие новости - в апрельском релизе в Data Ocean Nova выйдет доработка StarRocks и он сможет читать через JDBC распределено через все доступные CN узлы. Также выйдет коннектор для GreenPlum которые будет читать GP с сегментов через CN узлы распределенно.
Trino есть не в каждой установке клиентской. Не все пользователи делают выбор в пользу этого движка. Держать Trino только для загрузки данных - не эффективно. А Spark есть в 19 из 20 промышленных установок по текущей статистике.
25 гбс на 4 nvme вы по прежнему упёрлись в сеть. По прежнему дальше можно не читать.
4 NVMe Диска и сеть на 10Гб. Дальше можно не читать. Вы просто уперлись в сеть и ваш тест не релевантный
Как человек который работал и с озон и с минио отвечу так - те кто изначально пошел в минио, озон рассматривать не будет.
В Сбербарнке и минио есть помимо озона и успешно эксплуатируется.
Кандидат должен быть таким же высокоприизводительным и не требовательным к железу как минио. Пока что по концепции ближе всего к этому RustFS, но он еще слишком сыроват для серьезного прода.
Автор вроде как рассматривает чисто бесплатные альтернативы без фстэка и прочей казуистики. Платные минио форки и российские есть с веб-мордой и полной поддержкой, если уж на то пошло.
Выборка из 600 чел. Такое надо в заголовок выносить чтобы чувствительные души не общались по результатам прочтения
В 2017 году группа китайцев "форкнула" Impala и ушла делать Doris. Мотивация была такой - ходим update delete timeseries? но не хотим идти в Kudu, а хотим в Mesa. Сами разработчики это назвали "идеологическим наследием". В процессе "перехода" перешли на свой собственный формат хранения и оптимизатор и стали shared-nothing СУБД по сути. За эти годы сообщество придумало OTF и они стали стандартом рынка в итоге Дорис начал переобуваться в ОТF форматы и по факту стал теперь догонять Импала в части поддержки открытых форматов.
СтарРокс форкнулся от Дорис в 2020г чтобы тоде уйти в свой формат со своим видением, но чуть раньше чем Дорис поняли что надо ориентироваться на OTF а не свои волшебные форматы.
Очень забавно читать материалы коллег, которые на голубом глазу рассказывают про уникальные векторные вычисления в Старрокс, которые на самом деле он унаследовал от бабушки антилоппы которая их умела в 2013 году.
СтарРокс как движок над S3 в настоящий момент в продакшине можно использовать только на чтение для bi adhoc доступа. ELT точно нет! С локальным стореджем можно жить, но не без приколов.
Какая у вас тут интересная дискуссия получается, коллеги.
Как персона, имеющая прямое отношение у указанным выше ссылкам с полной ответственностью заявляю что смена методики на любую другую не поменяет расклад сил в тестировании. Проверялось неоднократно и на пром данных, и на синтетических тестах и на расчетах ELT и на чем угодно.
Однако, ознакомившись со следующей статье вашего цикла, у меня есть ощущение, что на чем бы вы не обращались к данным, вы упираетесь в инфраструктуру S3. Поэтому, разницы особую можно и не заметить между движками.
Ваш выбор - это ваш выбор. Вы выбирали под своим критерии и значит вам это решение большо подошло. Хоть и переплатили за compute мощности, но зато увереннее себя чувствуете тк можете что то развивать своими силами. Это нормально же.
По поводу Spark. Без него вам нормально пока не выжить, если хотите перейти окончательно на iceberg как на целевой формат. Только Spark может предложить полное реальное работающее обслуживание iceberg формата.
Там еще и третий тест добавили в Click Bench и тч со сравнением ClickHouse, работающим над S3. https://habr.com/ru/companies/datasapience/articles/978430/
В части StarRocks вы правы только от части - он умеет работать над S3, но не все операции с открытыми форматами данных на нем доступны, о чем умалчивают или не понимают некоторые российские вендоры.
Greetings. You'll also likely appreciate the previous two posts regarding Starrocks :)
Теперь к внедрениям - в РСХБ нет Lakehouse, есть Hadoop с HDFS без разделения storage и compute.. В БСПБ нет Lakehouse, есть Hadoop c HDFS без разделения storage и compute.
Почему у вас федеративные запросы у Impala желтые, а у StarRocks зеленые? Возможности Impala и Starrocks в части федеративных запросов одинаковые вообще-то.
Тот же вопрос и про Zero-ETL
Все критические компоненты Impala (координатор и внутренний каталог) имеют HA конфигурацию, но у вас отмечено желтым. Trino к слову может иметь только один Coordinator-узел и это является большой проблемой. Поэтому там не то чтобы желтенько быть должно, там красненько.
Почему у вас в Impala нет ACID интересно, когда оно есть?
Почему у вас у Impala нет cloud-native масштабируемости, когда она есть?
К слову про Starrocks: до сих пор нет поддержки Update Delete Megre для Iceberg, поддержка обслуживания iceberg не полная, нет поддержка alter table операций для OTF, и местами доходит до смешного, например - невозможно сделать insert table overwrite над просто секционированной паркетной таблицей.
Не нужно писать материалы, изучая предмет статьи по интернету.
Добрый день. Они доступны только клиентам Data Ocean Nova
Позвольте объяснить вам свою позицию - На российском рынке присутствуют другие игроки-вендоры, разрабатывающие и продающие свои решения, которые утверждаю что умеют в Starrocks, умеют в Impala, Spark и Trino. У меня нет намерений обучать конкурентов. Это наше конкурентное преимущество - продемонстрировать клиенту не только доработками и улучшениями open source кода, но и уметь решать проблемы, настраивать систему (ПО, окружение, оборудование) на максимальную и стабильную пропускную способность для решения его (клиента) задач. При этом зрелый клиент не выбирает решение по публикациям в интернете, а приглашает всех участников продемонстрировать на практике.
ну вот именно поэтому платформа на одном движке - это проблема либо на старте либо отложенная. Не просто так же в среднем каждый клиент-заказчик использует больше 2х движков.
StarRocks поддерживает не только Select, но и Insert в Iceberg. Но не поддерживает Update, Merge, Delete.
В нашем решении StaкRocks используется как lakehouse-движок. Это означает что он использует только открытый табличный формат Iceberg и файловый формат хранения. Никаких "индексов starrocks" нет и в помине. Вы путаете Starrocks с использованием проприетарным закрытым родным форматов хранения. Поэтому, к сожалению, ваш комментарий не валидный на 100%.
Владимир, конфигурация тестовых стендов, как и было обещано, указана.
Этого достаточно, чтобы проявив экспертизу и богатый опыт, изучив документацию, через несколько итераций тестирования, прийти к индивидуальным параметрам движков для оптимальной производительности.
Со списком "не ванильных" опций и изменений движков можно ознакомиться на сайте.
Задумывались ли о том чтобы не тащить данные в GP в процесить на озером? Все таки 32 сегмент хоста GP в облаке это дорого