Комментарии 7
Как нетактично вы убрали все настройки jvm для trino и impala, покажите их народу, пожалуйста...
Извините, что и где я убрал?!
По условиям тестирования при одновременном запуске 80 и 190 (да и там где 10 ) запросов не должно быть ошибок. Все запросы должны завершиться успешно. По обеим движкам проводилось несколько итераций тестирования при которых подбирались: размер очереди, уровень параллелизма, объем памяти, выделены движку и его окружению от общего объема K8S worker'a. В протоколе фиксировался лучший результат среди всех итераций и в протокол вносилась конфигурация K8S worker'ов, ведь именно за них мы платим в конечном итоге.
Проблема Trino и его окружения при такой нагрузке как раз в том что не получится как Impala выделить 90-95% RAM на узле и продолжать работать без падений. Нужно либо очередь запросов больше ограничивать, либо "отрезать" больше на накладные расходы вроде JMV. Вот мы в тесте такой баланс и нашли и зафиксировали в протоколе.
Какова методика тестирования? Какая схема данных? Где SQL запросы? Где конфиг файлы систем? Были ли эксперты по тюнингу каждой системы? и т.п.
За такими цифрами должен лежать отчет на 100500 страниц, а так это просто не очень хорошо пахнущая самореклама как в анекдоте получается:
Старенький дедушка приходит к врачу:
— Доктор, мне нужна ваша помощь, у меня проблемы с потенцией. Могу со своей бабкой только три раза в неделю.
— И сколько ж вам лет, — спрашивает врач.
— 85.
— Так вы, голубчик, половой гигант, — изумляется доктор.
— Но доктор, моему соседу тоже 85, и он рассказывает, что у них с бабкой секс ежедневно.
— Голубчик, так вы тоже рассказывайте!
В тексте написано что методику тестирования можно получить по запросу. Не видел вашего запроса, извините. Он был? Собственно к тексте указано что все системы настраивались ("тюнились") на оптимальную производительность экспертами (без кавычек). Не верить и не доверять - ваше право. Только прежде чем ставить под сомнение, хорошо бы само попробовать и поделиться своим опытом, а не анекдоты рассказывать.
Также к тексте написано что будут опубликованы результаты TPC-DS как методики понятной всем. Опубликованы они будут со всеми конфигами чтобы любой мог воспроизвести и сравнить.
Отчет на 100500 страниц предоставляется тому кто тестирование заказывает. Я тестированием и проектной работой на MPP-системах с 2013г занимаюсь и в саморекламе не нуждаюсь.
Публикацию Вами результатов TPC-DS в описанном Вами формате безусловно приветствую и буду ждать.
Я прихожу на хабр за информацией. Ваша статья содержит цифры в отрыве о того как они получены и без объяснения почему. Какую информацию я должен вынести из статьи?! Что очередной вендор показал свою систему в выгодном свете?! Я таких тестов видел примерно от каждого первого вендора.
Я даже не могу сделать выводы, о задачах где данные системы показывают свое превосходство и самое главное для меня, почему, как это следует из архитектуры систем?
Если для чтения и понимания статьи нужно запросить у Вас дополнительную информацию, то зачем мне такая статья.
Запросы Методика проведения тестирования_запросы.docx — Яндекс Диск
Не понятно что я должен показывать в выгодном свете, как представитель вендора у которого есть все три решения, простите. Моя задача скорее помочь сделать правильный выбор.
Объяснение "почему так" есть в материале. Но, обычно, профессионалы не доверяют тому что пишут в интеренете (по крайней мере я так поступаю) и обращаются к официальной документации и обязательно проверяют все самостоятельно. Вы же не станете утверждать что если бы я привел достаточно, по вашему мнению, аргументов вы бы просто приняли это на веру?
Половина материала посвящена тому, как не попасть на уловки вендоров которые очень любят тестировать так чтобы выставлять решение в выгодном для себя свете. Если вы прочитали первую половину и подвергаете сомнению мои примеры, то значит вы правильно усвоили материал :) Теперь проверяйте сами или с нами
Тестирование систем и движков массивно-параллельных вычислений. Сравнение Impala, Trino и GreenPlum