Ну я написал не с точки зрения критки. Вы молодец, что провели тесты! Проще всего сидеть и критиковать, значительнее сложнее что то взять и сделать полезное :) Тут мы просто с Сашей Зайцевым немного уточняем, что сложно сравнивать их на таких мелких объемах и аппаратной части. Все добрые и не очень нюансы обоих серверов остались за пределыми теста.
Тут как раз встает вопрос объема данных. Проводить adhoc запросы на 1 тб данных, на 10 тб, на 100 тб или на 100 пб. Не только In-memory, да и MPP обычно имеют некий предел, за которым идет резкая деградация скорости, даже при масштабировании кластера. Тут много причин — архитектура сервера, сеть, диски, алгоритмы… у всех есть нюансы. Вертика заточена на анализ объемов данных, которые никак не впихнуть в память для быстрого анализа. На ad-hoc по 100 тб данным один запрос может запросто откушать и 100 гигов памяти, если будет что то сложное, с джойнами и агрегациями больших таблиц. Куда уж тут еще что то в памяти кэшировать, да собственно говоря и зачем. Поэтому на малых объемах сравнивать Вертику с СУБД, заточенными на анализ небольшого объема горячих данных при хранении большого числа данных можно, но смысла большого нет — класс задач не тот для Вертики.
Вот пример — у телекомов «горячие данные» это месяц биллинга, сдр и статистики, в среднем это занимает пару десятков тб. А глубина анализа оперативных данных не менее 3 месяцев. Все это требуется делать в приближенном к реалтайм времени, загрузка данных идет плотная с множества потоков, в одну таблицу непрерывно льется с десятка шлюзов много гб данных. Ни о каком кэшировании данных и речи быть не может, никто не знает, что когда потребуется из такого массивного потока данных. Здесь inmemory и в частности Exasol выглядят не очень подходящим решением и если смоделировать тесты по задачам под данное направление, то они проиграют в нагрузочных тестах и по скорости загрузки и по скорости выполнения параллельных запросов.
Аналогично могу придумать множество задач, где Вертика изначально будет уступать inmemory :)
Вообще сравнивать скорость выполнения запросов в разных СУБД дело не благодарное — слишком много нюансов
Золотые слова! Я обычно всем, проводящим пилоты и тесты для выбора ХД примерно тоже самое говорю — вы тестируете не СУБД, а железо и команды интеграторов, делающих этот проект. У кого знания/опыта больше, тот СУБД и победил :) Хотите сравнивать СУБД для выбора под свои задачи, так сравнивайте наличие хороших спецов и интеграторов, стоимость владения, функциональную пригодность под свои цели и стабильность работы продукта. По мне Вертика хороша простотой без замороченных нюансов, прозрачностью расчета стоимости владения и вполне богатой функциональностью. Если сложность не пугает или расширения кластера не планируется или функционально те же хранимые процедуры нужны для сохранения исторически сложившихся методик, полно конкурентов, кто будет смотреться выгоднее.
Мы все используем, в зависимости от задач, требований и боевой обстановки :) Единственное, что у всех моделей ХД одинаково — предпочитаем сначала грузить данные с источников в стейджинговый слой на саму Вертику, а оттуда дальше уже спокойно запросами строить то, что требуется. Так что можно сказать в большинстве случаев вся первичка всегда лежит и доступна в Вертике. Чтобы как то экономить лицензию, потом постепенно первичку по старым годам удаляем или выносим в hive или Vertica SQL On Hadoop (та же Вертика, но на HDFS, там лицензии по количеству нод, а не объемам, удобно для таких целей).
Привет. Спасибо за статью. Но вот тут совсем нехорошо получается — MPP базу тестировать в однонодовом режиме IMHO не есть правильно. Даже оптимизатор запросов работает в не штатном режиме, ибо заточка у него на распределение обработки данных между нодами.
Вы явно что то путаете. В Вертике лицензирование ведется только по объему данных. Никаких серверов, ядер и прочих железных ограничений там нет. Можно скачать бесплатную полнофункциональную коммунити версию на 3 нодовый кластер размером БД до 1 тб и вполне себе официально бесплатно на огромных скоростях крутить базу данных :)
Могу порекомендовать Вам обратиться в представительство местное HPE и узнать цену GPL с учетом скидки, что Вам могут предложить. Насколько я знаю, на фоне промышленных конкурентов у Vertica цена на порядок ниже выходит во многих случаях.
Тут я присоединюсь к Саше. Работаю с Вертикой с 2010 года, одна из самых беспроблемных СУБД, если не считать последние года и фишечки. Тут делаем проще, как и с классическими СУБД — не сразу их начинаем использовать, а ждем некоторое количество патчей. Да собственно говоря и фишечки то они сторонние — неужели кто то мешает самостоятельно разработать свое ПО, которое в реалтайм будет осуществлять захват с той же Кафки и лить данные в Вертику. Делается просто. Зато под конкретно заточенную задачу работает всяко лучше, чем универсальные «коннекторы». Это в принципе к любому СУБД относится. Здесь разве что коннекторы Хадупа у Вертики рулят, так как позволяют закачивать данные с HDFS многопоточно ноды к нодам, с кластера MPP в кластер MPP.
Full Backup Restore to an Alternate Cluster — разве не позволяет восстановить бакуп на другой кластер, естественно с таким же количеством нод, но другими сетевыми адресами?
По поводу дров и vsql меня тоже всегда удивляло, что новые версии дров не видят старые версии БД. Однако в обратку все работает замечательно, старые дрова работают с новыми версиями кластера, мне лично этого вполне хватает, какой вас смысл постоянно на новые дрова переводить софт, если старые работают?
Ну а Кафка… только от нас кейсов для наших клиентов к ТП Вертики открыто несколько штук. Мы с HP совместно работаем над решением проблем, очень надеемся, восьмая версия их закроет.
P.S. Я работал с Вертикой «до» покупки и «после». Насчет «мрака» не согласен. Функциональности было тогда меньше, интеграции с продуктами никакой, но зато все работало как швейцарские часы. Зря вы на команду инженеров Вертики так. И тех поддержка тогда напрямую работала, я мог списаться с разработчиками и быстро узнать/решить проблему чуть ли не в Скайпе. Сейчас все это идет через линии поддержки и прямой связи до разработчиков мы получаем очень редко, хотя все таки получаем.
Ну я совершенно не согласен с такой постановкой утверждения. Кроме багов с Кафкой я никаких других в области работы самого сервера, а так же с Хадупом или Флексом не сталкивался. А про Кафку я поэтому и написал в статье. Так что примеры в студию :)
Расскажите, как, например, Vertica, справляется с real-time аналитикой? Я отвечу за вас: плохо.
Отлично справляется. У нас пару клиентов за бугром, кто в реалтайме считает клики в банерных сетях прямо на Вертике. У них задержка более 0.3 сек на ответ запросу уже считается ужасом ужасным :)
Статья вполне в тему кстати. Вчера был на OSP форуме по BigData. Не смотря на тучу клевых технологий и очень интересной информации, из выступающих только двое докладчиков назвали объемы своих «BigData» в проде. У СБ Контура в HBase 1 тб, а у классического OLTP на базе Ред БД у приставов крутится ряд БД, соединенных обычным App сервером под 100 тб. Из личного опыта так же — у нас на вполне себе обычной релляционной Vertica крутятся базы по 75 тб и у моих друзей в Штатах и более объемом на Терадате, а мне каждый раз с секретным видом сообщают о том, что на очередном NoSQL или Hadoop у кого то есть база аж 20-30 тб :) Кстати помимо распределенности, аналитических функций и прочих очень полезных мегавещей есть один больной нюанс, о котором забывают любители новых технологий. Это тупо оптимизация и администрирование сверх больших объемов данных. На Вертике, ГП или Терадате выглядит все это вполне себе культурненько, а про HDFS и NoSQL столько чудесных историй слышал при больших объемах, так сказать «нюансы» :)
P.S. Кстати потопчусь по графовым базам, вспоминая опять же вчерашний форум по Бигдате. Есть круг применения у них клевый, но аналитика упаси господь в этот круг не входит. Показали мне вчера на презе по OrientDB как круто в него CDR можно грузить и быстро по абоненту находить его номера, используемые БС и звонки. Запустил я в голове простой запрос за полгода выдать всех абонентов, у которых ежедневно звонков выходило менее, чем на 2 минуты, пробежался по графам БД презы и завис… пробежать все это по графам жесть жестяная, а строить на каждый чих рассчитываемую витрину, это места на дисках не напасешься и скорости записи потеряешь. Как бы в таблицах CDR в сутки у не слишком большого оператора лямов 200 записей прибывает минимум, за полгода для рангового анализа объемы неплохие так получаются.
Полировать — это сильно сказано. Когда мы последний раз пытались написать свой (!) ридер паркетовский файлов из HDFS с помощью Vertica UDF, внезапно оказалось, что Vertica вообще не умеет парсить бинарные данные и пытается перевести из «битой» кодировки в «нормальный UTF-8». Бинарные данные в UTF-8, ага.
Поправлю Вас. Вертика поддерживает ORC и PARQUET, пример прямо с доки:
=> CREATE EXTERNAL TABLE tableName (columns)
AS COPY FROM path ORC;
=> CREATE EXTERNAL TABLE tableName (columns)
AS COPY FROM path PARQUET;
Гм, вроде статья про хранилища данных, а не хранение больших объемов, в том числе видео роликов :)
Википедия нам говорит, что хранилища данных, это:
Храни́лище да́нных (англ. Data Warehouse) — предметно-ориентированная информационная база данных, специально разработанная и предназначенная для подготовки отчётов и бизнес-анализа с целью поддержки принятия решений в организации. Строится на базе систем управления базами данных и систем поддержки принятия решений.
То бишь да, конкретная боль, конкретно про хранилища данных. Мне вот эта конкретная боль близка, работаем хранилищами и конкретно нас волнуют заказчики, которых не волнуют архитектура, аналитики, программисты и т.д. Волнуют как раз тем, что они выдают возглас «Вперед к светлому будущему КХД», ничего не зная про онное, сколько нервов, ресурсов и времени на поход к светлому будущему затрачивается и каков процент наступления этого самого будущего :)
Автор в самом начале первой статьи пишет, что все IMHO исходя из личного опыта :) Я многие вещи написанные здесь вижу, как подтверждение своего опыта о том, что понятие архитектура видится и слышится везде по разному и у разных заказчиков и разных проектов имеет чуть ли не противоположные смысловые нагрузки. Поэтому лично я приветствую эту статью, как повод обобщить и обозначить дальнейшее обсуждение этой не легкой то в общем темы. Уверен, что эти статьи вводная часть и дальнейшие статьи уже будут по конкретному опыту автора, с привязкой к мыслям и терминологии, обозначенных здесь.
Привет, полностью согласен :) Очень приятно видеть развитие софта в том, что нужно конкретно ИТ, а не маркетинговые шашечки. Еще бы вот в новой версии индусов в саппорте проапгрейтили на русских и была бы вообще красота. Жалко это не в силах команды разработчиков Вертики.
>>>Хадуп встроен в Vertica
Немного не точно сказали. Коннекторы (дрова) Вертики для Хадупа раньше отдельным пакетом ставились, а теперь при инсталяции сервера автоматически ставятся. Самого Хадупа Вертике нет, как и раньше Хадуп нужно ставить отдельным инстансом, хотя конечно никто не запрещает его поставить на те же ноды, что и Вертика, но я в этом большого смысла не вижу — им придется разделять ресурсы на нодах, когда Вертика выполняет какие то массивные запросы, то Хадупу придется тяжеловато по памяти, дискам и сетевой активности, Вертика у него все может отобрать ;)
Насчет лицензий честно говоря не понял — коннекторы к Хадупу у Вертики входят в штатную комплектацию, лицензировать их не нужно вроде.
>>>сам по себе ANSI SQL прям такой уж киллер-фичей не является
Я с Вами категорически не соглашусь. ANSI SQL это залог того, что все BI системы будут работать с этим СУБД. В Vertica за вычетом рекурсивных запросов полная совместимость с ANSI SQL, вплоть до аналитических оконных функций. Кому нужно аналитическое хранилище данных, если в нем ничего нельзя анализировать просто и быстро? Аналитикам проще взять Tableau, чем писать код к штуке, которая не поддерживает все накопленное богатство SQL.
Поэтому я и говорю, это из разных пьес, ScyllaDB сами же себя конкурентом Кассандре заявляют, а Кассандра другие задачи имеет и решает, там никто групповые запросы с сотнями миллионами и даже миллиардами записей в группировках и подзапросами делать не будет :)
Вот пример — у телекомов «горячие данные» это месяц биллинга, сдр и статистики, в среднем это занимает пару десятков тб. А глубина анализа оперативных данных не менее 3 месяцев. Все это требуется делать в приближенном к реалтайм времени, загрузка данных идет плотная с множества потоков, в одну таблицу непрерывно льется с десятка шлюзов много гб данных. Ни о каком кэшировании данных и речи быть не может, никто не знает, что когда потребуется из такого массивного потока данных. Здесь inmemory и в частности Exasol выглядят не очень подходящим решением и если смоделировать тесты по задачам под данное направление, то они проиграют в нагрузочных тестах и по скорости загрузки и по скорости выполнения параллельных запросов.
Аналогично могу придумать множество задач, где Вертика изначально будет уступать inmemory :)
Золотые слова! Я обычно всем, проводящим пилоты и тесты для выбора ХД примерно тоже самое говорю — вы тестируете не СУБД, а железо и команды интеграторов, делающих этот проект. У кого знания/опыта больше, тот СУБД и победил :) Хотите сравнивать СУБД для выбора под свои задачи, так сравнивайте наличие хороших спецов и интеграторов, стоимость владения, функциональную пригодность под свои цели и стабильность работы продукта. По мне Вертика хороша простотой без замороченных нюансов, прозрачностью расчета стоимости владения и вполне богатой функциональностью. Если сложность не пугает или расширения кластера не планируется или функционально те же хранимые процедуры нужны для сохранения исторически сложившихся методик, полно конкурентов, кто будет смотреться выгоднее.
Привет. Спасибо за статью. Но вот тут совсем нехорошо получается — MPP базу тестировать в однонодовом режиме IMHO не есть правильно. Даже оптимизатор запросов работает в не штатном режиме, ибо заточка у него на распределение обработки данных между нодами.
По поводу дров и vsql меня тоже всегда удивляло, что новые версии дров не видят старые версии БД. Однако в обратку все работает замечательно, старые дрова работают с новыми версиями кластера, мне лично этого вполне хватает, какой вас смысл постоянно на новые дрова переводить софт, если старые работают?
Ну а Кафка… только от нас кейсов для наших клиентов к ТП Вертики открыто несколько штук. Мы с HP совместно работаем над решением проблем, очень надеемся, восьмая версия их закроет.
P.S. Я работал с Вертикой «до» покупки и «после». Насчет «мрака» не согласен. Функциональности было тогда меньше, интеграции с продуктами никакой, но зато все работало как швейцарские часы. Зря вы на команду инженеров Вертики так. И тех поддержка тогда напрямую работала, я мог списаться с разработчиками и быстро узнать/решить проблему чуть ли не в Скайпе. Сейчас все это идет через линии поддержки и прямой связи до разработчиков мы получаем очень редко, хотя все таки получаем.
Ну я совершенно не согласен с такой постановкой утверждения. Кроме багов с Кафкой я никаких других в области работы самого сервера, а так же с Хадупом или Флексом не сталкивался. А про Кафку я поэтому и написал в статье. Так что примеры в студию :)
Отлично справляется. У нас пару клиентов за бугром, кто в реалтайме считает клики в банерных сетях прямо на Вертике. У них задержка более 0.3 сек на ответ запросу уже считается ужасом ужасным :)
P.S. Кстати потопчусь по графовым базам, вспоминая опять же вчерашний форум по Бигдате. Есть круг применения у них клевый, но аналитика упаси господь в этот круг не входит. Показали мне вчера на презе по OrientDB как круто в него CDR можно грузить и быстро по абоненту находить его номера, используемые БС и звонки. Запустил я в голове простой запрос за полгода выдать всех абонентов, у которых ежедневно звонков выходило менее, чем на 2 минуты, пробежался по графам БД презы и завис… пробежать все это по графам жесть жестяная, а строить на каждый чих рассчитываемую витрину, это места на дисках не напасешься и скорости записи потеряешь. Как бы в таблицах CDR в сутки у не слишком большого оператора лямов 200 записей прибывает минимум, за полгода для рангового анализа объемы неплохие так получаются.
Поправлю Вас. Вертика поддерживает ORC и PARQUET, пример прямо с доки:
Википедия нам говорит, что хранилища данных, это:
Храни́лище да́нных (англ. Data Warehouse) — предметно-ориентированная информационная база данных, специально разработанная и предназначенная для подготовки отчётов и бизнес-анализа с целью поддержки принятия решений в организации. Строится на базе систем управления базами данных и систем поддержки принятия решений.
То бишь да, конкретная боль, конкретно про хранилища данных. Мне вот эта конкретная боль близка, работаем хранилищами и конкретно нас волнуют заказчики, которых не волнуют архитектура, аналитики, программисты и т.д. Волнуют как раз тем, что они выдают возглас «Вперед к светлому будущему КХД», ничего не зная про онное, сколько нервов, ресурсов и времени на поход к светлому будущему затрачивается и каков процент наступления этого самого будущего :)
Немного не точно сказали. Коннекторы (дрова) Вертики для Хадупа раньше отдельным пакетом ставились, а теперь при инсталяции сервера автоматически ставятся. Самого Хадупа Вертике нет, как и раньше Хадуп нужно ставить отдельным инстансом, хотя конечно никто не запрещает его поставить на те же ноды, что и Вертика, но я в этом большого смысла не вижу — им придется разделять ресурсы на нодах, когда Вертика выполняет какие то массивные запросы, то Хадупу придется тяжеловато по памяти, дискам и сетевой активности, Вертика у него все может отобрать ;)
Насчет лицензий честно говоря не понял — коннекторы к Хадупу у Вертики входят в штатную комплектацию, лицензировать их не нужно вроде.
Я с Вами категорически не соглашусь. ANSI SQL это залог того, что все BI системы будут работать с этим СУБД. В Vertica за вычетом рекурсивных запросов полная совместимость с ANSI SQL, вплоть до аналитических оконных функций. Кому нужно аналитическое хранилище данных, если в нем ничего нельзя анализировать просто и быстро? Аналитикам проще взять Tableau, чем писать код к штуке, которая не поддерживает все накопленное богатство SQL.
Поэтому я и говорю, это из разных пьес, ScyllaDB сами же себя конкурентом Кассандре заявляют, а Кассандра другие задачи имеет и решает, там никто групповые запросы с сотнями миллионами и даже миллиардами записей в группировках и подзапросами делать не будет :)