Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 12
Vertica Analytic Database v7.2.2-1 (single node)
Привет. Спасибо за статью. Но вот тут совсем нехорошо получается — MPP базу тестировать в однонодовом режиме IMHO не есть правильно. Даже оптимизатор запросов работает в не штатном режиме, ибо заточка у него на распределение обработки данных между нодами.
Привет! Согласен, что тест на 3 нодах, который можно выполнить, используя Vertica Community Edition, был бы интереснее. Но я не смог бы тогда сравнивать с другими БД из моего списка. Exasol, к сожалению, предлагает для бесплатного использования только single node (trial cloud не считаю), Teradata Developer Edition тоже.
Также я не считаю, что 1 нода — это критическое ограничение в моём тесте. Возможно, я продолжу данный тест Vertica на 3-х нодах (например, + 2 ноды и объём данных * 3). В итоге у меня либо получится примерно то же время выполнения, либо худшее, т.к. для данного теста возможно будет сложно подобрать хороший ключ для сегментирования.
Кстати, пользуясь случаем, нигде не находил информации, какую модель (подход) для DWH вы используете в своих проектах (Yota и др.)?
Также я не считаю, что 1 нода — это критическое ограничение в моём тесте. Возможно, я продолжу данный тест Vertica на 3-х нодах (например, + 2 ноды и объём данных * 3). В итоге у меня либо получится примерно то же время выполнения, либо худшее, т.к. для данного теста возможно будет сложно подобрать хороший ключ для сегментирования.
Кстати, пользуясь случаем, нигде не находил информации, какую модель (подход) для DWH вы используете в своих проектах (Yota и др.)?
Мы все используем, в зависимости от задач, требований и боевой обстановки :) Единственное, что у всех моделей ХД одинаково — предпочитаем сначала грузить данные с источников в стейджинговый слой на саму Вертику, а оттуда дальше уже спокойно запросами строить то, что требуется. Так что можно сказать в большинстве случаев вся первичка всегда лежит и доступна в Вертике. Чтобы как то экономить лицензию, потом постепенно первичку по старым годам удаляем или выносим в hive или Vertica SQL On Hadoop (та же Вертика, но на HDFS, там лицензии по количеству нод, а не объемам, удобно для таких целей).
Тем более на таком объеме данных и тем более на таком железе.
Вообще сравнивать скорость выполнения запросов в разных СУБД дело не благодарное — слишком много нюансов. Все аналитические СУБД обрабатывают данные примерно с одинаковой скоростью — все упирается в IO, CPU, алгоритмы компрессии данных, всякие фишки типа предрасчитанных агрегатов и т.д. Физику не обманешь, зато пнули пару рычажков или что-то недонастроили — БД уже тормозит.
Вообще сравнивать скорость выполнения запросов в разных СУБД дело не благодарное — слишком много нюансов. Все аналитические СУБД обрабатывают данные примерно с одинаковой скоростью — все упирается в IO, CPU, алгоритмы компрессии данных, всякие фишки типа предрасчитанных агрегатов и т.д. Физику не обманешь, зато пнули пару рычажков или что-то недонастроили — БД уже тормозит.
Вообще сравнивать скорость выполнения запросов в разных СУБД дело не благодарное — слишком много нюансов
Золотые слова! Я обычно всем, проводящим пилоты и тесты для выбора ХД примерно тоже самое говорю — вы тестируете не СУБД, а железо и команды интеграторов, делающих этот проект. У кого знания/опыта больше, тот СУБД и победил :) Хотите сравнивать СУБД для выбора под свои задачи, так сравнивайте наличие хороших спецов и интеграторов, стоимость владения, функциональную пригодность под свои цели и стабильность работы продукта. По мне Вертика хороша простотой без замороченных нюансов, прозрачностью расчета стоимости владения и вполне богатой функциональностью. Если сложность не пугает или расширения кластера не планируется или функционально те же хранимые процедуры нужны для сохранения исторически сложившихся методик, полно конкурентов, кто будет смотреться выгоднее.
Присоединюсь к недоумению ascrus и добавлю, что в статье есть правильная фраза «В контексте сравнения с Exasol важно отметить, что Vertica не является in-memory базой данных и более того, в Vertica нет буферного пула. То есть БД предназначена в первую очередь для обработки объёмов данных, которые значительно превосходят размер оперативной памяти». Поэтому тест сравнивает апельсины с лимонами :) Но все равно интересно.
Про апельсины и лимоны не соглашусь. Это 2 БД для DWH и аналитики. И если Vertica не IM DB, то Exasol не только IM DB (данные не обязательно должны помещать в память).
Тут как раз встает вопрос объема данных. Проводить adhoc запросы на 1 тб данных, на 10 тб, на 100 тб или на 100 пб. Не только In-memory, да и MPP обычно имеют некий предел, за которым идет резкая деградация скорости, даже при масштабировании кластера. Тут много причин — архитектура сервера, сеть, диски, алгоритмы… у всех есть нюансы. Вертика заточена на анализ объемов данных, которые никак не впихнуть в память для быстрого анализа. На ad-hoc по 100 тб данным один запрос может запросто откушать и 100 гигов памяти, если будет что то сложное, с джойнами и агрегациями больших таблиц. Куда уж тут еще что то в памяти кэшировать, да собственно говоря и зачем. Поэтому на малых объемах сравнивать Вертику с СУБД, заточенными на анализ небольшого объема горячих данных при хранении большого числа данных можно, но смысла большого нет — класс задач не тот для Вертики.
Вот пример — у телекомов «горячие данные» это месяц биллинга, сдр и статистики, в среднем это занимает пару десятков тб. А глубина анализа оперативных данных не менее 3 месяцев. Все это требуется делать в приближенном к реалтайм времени, загрузка данных идет плотная с множества потоков, в одну таблицу непрерывно льется с десятка шлюзов много гб данных. Ни о каком кэшировании данных и речи быть не может, никто не знает, что когда потребуется из такого массивного потока данных. Здесь inmemory и в частности Exasol выглядят не очень подходящим решением и если смоделировать тесты по задачам под данное направление, то они проиграют в нагрузочных тестах и по скорости загрузки и по скорости выполнения параллельных запросов.
Аналогично могу придумать множество задач, где Вертика изначально будет уступать inmemory :)
Вот пример — у телекомов «горячие данные» это месяц биллинга, сдр и статистики, в среднем это занимает пару десятков тб. А глубина анализа оперативных данных не менее 3 месяцев. Все это требуется делать в приближенном к реалтайм времени, загрузка данных идет плотная с множества потоков, в одну таблицу непрерывно льется с десятка шлюзов много гб данных. Ни о каком кэшировании данных и речи быть не может, никто не знает, что когда потребуется из такого массивного потока данных. Здесь inmemory и в частности Exasol выглядят не очень подходящим решением и если смоделировать тесты по задачам под данное направление, то они проиграют в нагрузочных тестах и по скорости загрузки и по скорости выполнения параллельных запросов.
Аналогично могу придумать множество задач, где Вертика изначально будет уступать inmemory :)
Алексей, спасибо за ваши интересные мысли тут! По этому поводу добавлю своих :).
У всех свои объёмы и свои запросы и нужно тестировать именно на своём кейсе. У кого-то 100 Тб, а кому-то и 2-х Гб достаточно. В данном тесте чеки с 12 млн. строк, допустим, это объём для какой-то локальной сети, торгующей бытовой техникой. Если делать аналитикуи на перспективу сразу ставить БД (хотя можно и без), то чем бесплатная неприхотливая Vertica CE на 1 ноде плохой вариант (также как и Exasol)?
"..MPP обычно имеют некий предел..."
Согласен, например, хорошо знакомый вам Sybase IQ.
«сравнивать Вертику с СУБД, заточенными на анализ небольшого объема горячих данных при хранении большого числа данных»
Почему Exasol заточен на анализ небольшого объёма горячих данных? Я этого не писал. На сайте TPC-H есть результаты бенчмарка для 100 Тб (это максимум для tpc-h), в Badoo сейчас около 40 Тб, Тинькофф начинают 2-й этап пилота на десятках Тб (написали в параллельной ветке).
«Вот пример — у телекомов «горячие данные»...»
Успешно внедрённый вами проект на Vertica, вопросов нет.
Здесь inmemory и в частности Exasol выглядят не очень подходящим решением и если смоделировать тесты по задачам под данное направление, то они проиграют в нагрузочных тестах и по скорости загрузки и по скорости выполнения параллельных запросов.
А кто тестировал? Мне, например, не очевидны такие выводы.
"… класс задач не тот для Вертики."
А я бы так не ограничивал задачи для Vertica.В данном тесте переделать модель и соответственно переписать запросы и картина сильно поменяется.
Но оставим объёмы и производительность. В статье ещё внимание уделяется другим моментам. Например, модели данных, которая оказалась не «удобной» для Vertica в данном кейсе. Ещё я оставил за рамками статьи утилизацию ресурсов при выполнении теста. Vertica на джоины и агрегации кушала больше оперативной памяти чем сами данные и в определённых прогонах я получил:
ERROR 3587: Insufficient resources to execute plan on pool general [Timedout waiting for resource request: Request exceeds limits: Memory(KB)...
Движки у Vertica и Exasol явно сильно отличаются и как минимум в определённых случаях Exasol оптимальнее использует ресурсы. Exasol прямо в документации пишут, что не бойтесь нормализации модели, а в Vertica надо с этим аккуратно.
В итоге, я не делал выводов о том, какая БД лучше. Vertica и Exasol — отличные варианты для DWH и аналитики при правильном их использовании, иначе я не писал бы про них столько :).
У всех свои объёмы и свои запросы и нужно тестировать именно на своём кейсе. У кого-то 100 Тб, а кому-то и 2-х Гб достаточно. В данном тесте чеки с 12 млн. строк, допустим, это объём для какой-то локальной сети, торгующей бытовой техникой. Если делать аналитикуи на перспективу сразу ставить БД (хотя можно и без), то чем бесплатная неприхотливая Vertica CE на 1 ноде плохой вариант (также как и Exasol)?
"..MPP обычно имеют некий предел..."
Согласен, например, хорошо знакомый вам Sybase IQ.
«сравнивать Вертику с СУБД, заточенными на анализ небольшого объема горячих данных при хранении большого числа данных»
Почему Exasol заточен на анализ небольшого объёма горячих данных? Я этого не писал. На сайте TPC-H есть результаты бенчмарка для 100 Тб (это максимум для tpc-h), в Badoo сейчас около 40 Тб, Тинькофф начинают 2-й этап пилота на десятках Тб (написали в параллельной ветке).
«Вот пример — у телекомов «горячие данные»...»
Успешно внедрённый вами проект на Vertica, вопросов нет.
Здесь inmemory и в частности Exasol выглядят не очень подходящим решением и если смоделировать тесты по задачам под данное направление, то они проиграют в нагрузочных тестах и по скорости загрузки и по скорости выполнения параллельных запросов.
А кто тестировал? Мне, например, не очевидны такие выводы.
"… класс задач не тот для Вертики."
А я бы так не ограничивал задачи для Vertica.В данном тесте переделать модель и соответственно переписать запросы и картина сильно поменяется.
Но оставим объёмы и производительность. В статье ещё внимание уделяется другим моментам. Например, модели данных, которая оказалась не «удобной» для Vertica в данном кейсе. Ещё я оставил за рамками статьи утилизацию ресурсов при выполнении теста. Vertica на джоины и агрегации кушала больше оперативной памяти чем сами данные и в определённых прогонах я получил:
ERROR 3587: Insufficient resources to execute plan on pool general [Timedout waiting for resource request: Request exceeds limits: Memory(KB)...
Движки у Vertica и Exasol явно сильно отличаются и как минимум в определённых случаях Exasol оптимальнее использует ресурсы. Exasol прямо в документации пишут, что не бойтесь нормализации модели, а в Vertica надо с этим аккуратно.
В итоге, я не делал выводов о том, какая БД лучше. Vertica и Exasol — отличные варианты для DWH и аналитики при правильном их использовании, иначе я не писал бы про них столько :).
Ну я написал не с точки зрения критки. Вы молодец, что провели тесты! Проще всего сидеть и критиковать, значительнее сложнее что то взять и сделать полезное :) Тут мы просто с Сашей Зайцевым немного уточняем, что сложно сравнивать их на таких мелких объемах и аппаратной части. Все добрые и не очень нюансы обоих серверов остались за пределыми теста.
>A БД Exasol отлично справляется и с нормализованной моделью
Нормализованная модель всегда сложнее денормализованной. Т.е. получается оптимизатор запросов в Exasol скорей всего лучше?
В принципе это звучит логично т.к. основная цели вертики считать огромные объемы данных через сотни шард, то большие сложные модели и запросы, которые будут постоянно перебрасывать данные с одной шарды на другую не очень попадают в цель продукта.
А In-Memory базы данных по определению должны иметь лучший оптимизатор, т.к. самая трудоемкая операция в БД это считывание с диска не трубется, то вырваться можно только оптимизировав запрос.
Странно правда почему Оракл в ваших тестах не показывает прорывы оптимизации. По идеи у него самый продуманный и опытный оптимизатор. По сравнению с SQL Server он явно лучше.
Нормализованная модель всегда сложнее денормализованной. Т.е. получается оптимизатор запросов в Exasol скорей всего лучше?
В принципе это звучит логично т.к. основная цели вертики считать огромные объемы данных через сотни шард, то большие сложные модели и запросы, которые будут постоянно перебрасывать данные с одной шарды на другую не очень попадают в цель продукта.
А In-Memory базы данных по определению должны иметь лучший оптимизатор, т.к. самая трудоемкая операция в БД это считывание с диска не трубется, то вырваться можно только оптимизировав запрос.
Странно правда почему Оракл в ваших тестах не показывает прорывы оптимизации. По идеи у него самый продуманный и опытный оптимизатор. По сравнению с SQL Server он явно лучше.
Я думаю, что дело не в оптимизаторе Exasol, а в том, что у него все в памяти. Если при запросе на денормализированной таблице, скорость чтения колонок с диска (да еще при наличии кеша ОС) может не сильно уступать памяти, то при джойнах Вертике приходится лишний раз (разы) походить по диску, собрать таблицы для джойна. И как раз поэтому оптимизатор в Вертике очень важен, чтобы уменьшить заходы на диск (кроме того там есть нюансы, влияющие на эффективность джойнов).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сравнение производительности аналитических СУБД HPE Vertica и Exasol с использованием TPC-H Benchmark