Comments 14
Боже упаси использовать вертику. Сейчас ищем интенсивно альтернативу, такой глючный продукт еще поискать нужно.
А аргументы можно написать? На текущий момент данная БД очень сильный инструмент…
Она сильный инструмент потому, что изначально была основана на Postgres. Относительно проблем, их за четыре года експлуатации насобирался целый воз. Из самого недавнего что вылезало:
— восстановление базы из бекапа требует не просто такой же конфигурации кластер, а идентичный, вплоть до IP адресов, благо хоть на Мак адрес не опираются.
— полная не совместимость одной версии с другой. Надавний минорный апдейт с 7.1 до 7.2 сделал все бекапы непригодными. Инкрементальный бекап отпал, начало снова зажовывать в бекап все ТБайты базы…
— отличие в минорной версии драйверов делает их непригодными. Про обратную совместимость вообще нет смысла говорить. К примеру нельзя возпользоваться vsql клиентом для подключения к предыдущим версиями, иногда для поддержки приходилось рыскать чтобы найти старый какой нибудь vsql чтобы подключиться к базе.
— Кафка это вообще парад счастья, тут можно даже не перечислять. Вместо того чтобы обновлять позицию в очереди, они умудряются зафлудить таблицу десятками тысяч записей. Исходные данные, один топик, одна флекс таблица. Данных прошло через кафку порядка 2 тысяч сообщений. При этом вертика умудрилась зафлудить таблицу свою системную в 10 тысяч записей за два выходных.
Такое сырое и абсолютно не корпоративное добро еще поискать нужно. Сейчас, с покупкой HP, их хотя бы приводят к чему то, потому что до покупки был совсем мрак.
— восстановление базы из бекапа требует не просто такой же конфигурации кластер, а идентичный, вплоть до IP адресов, благо хоть на Мак адрес не опираются.
— полная не совместимость одной версии с другой. Надавний минорный апдейт с 7.1 до 7.2 сделал все бекапы непригодными. Инкрементальный бекап отпал, начало снова зажовывать в бекап все ТБайты базы…
— отличие в минорной версии драйверов делает их непригодными. Про обратную совместимость вообще нет смысла говорить. К примеру нельзя возпользоваться vsql клиентом для подключения к предыдущим версиями, иногда для поддержки приходилось рыскать чтобы найти старый какой нибудь vsql чтобы подключиться к базе.
— Кафка это вообще парад счастья, тут можно даже не перечислять. Вместо того чтобы обновлять позицию в очереди, они умудряются зафлудить таблицу десятками тысяч записей. Исходные данные, один топик, одна флекс таблица. Данных прошло через кафку порядка 2 тысяч сообщений. При этом вертика умудрилась зафлудить таблицу свою системную в 10 тысяч записей за два выходных.
Такое сырое и абсолютно не корпоративное добро еще поискать нужно. Сейчас, с покупкой HP, их хотя бы приводят к чему то, потому что до покупки был совсем мрак.
Еще в копилку из недавнего.
— Copy Cluster ведет себя отвратительно. Он нам скопировал кластер, но в нем какие то данные отсутствовали. Мы долго не понимали в чем проблема, оказалось нужно просто раз 10 запустить его, чтобы оно наконецто докопировало все данные.
— Copy Cluster ведет себя отвратительно. Он нам скопировал кластер, но в нем какие то данные отсутствовали. Мы долго не понимали в чем проблема, оказалось нужно просто раз 10 запустить его, чтобы оно наконецто докопировало все данные.
Full Backup Restore to an Alternate Cluster — разве не позволяет восстановить бакуп на другой кластер, естественно с таким же количеством нод, но другими сетевыми адресами?
По поводу дров и vsql меня тоже всегда удивляло, что новые версии дров не видят старые версии БД. Однако в обратку все работает замечательно, старые дрова работают с новыми версиями кластера, мне лично этого вполне хватает, какой вас смысл постоянно на новые дрова переводить софт, если старые работают?
Ну а Кафка… только от нас кейсов для наших клиентов к ТП Вертики открыто несколько штук. Мы с HP совместно работаем над решением проблем, очень надеемся, восьмая версия их закроет.
P.S. Я работал с Вертикой «до» покупки и «после». Насчет «мрака» не согласен. Функциональности было тогда меньше, интеграции с продуктами никакой, но зато все работало как швейцарские часы. Зря вы на команду инженеров Вертики так. И тех поддержка тогда напрямую работала, я мог списаться с разработчиками и быстро узнать/решить проблему чуть ли не в Скайпе. Сейчас все это идет через линии поддержки и прямой связи до разработчиков мы получаем очень редко, хотя все таки получаем.
По поводу дров и vsql меня тоже всегда удивляло, что новые версии дров не видят старые версии БД. Однако в обратку все работает замечательно, старые дрова работают с новыми версиями кластера, мне лично этого вполне хватает, какой вас смысл постоянно на новые дрова переводить софт, если старые работают?
Ну а Кафка… только от нас кейсов для наших клиентов к ТП Вертики открыто несколько штук. Мы с HP совместно работаем над решением проблем, очень надеемся, восьмая версия их закроет.
P.S. Я работал с Вертикой «до» покупки и «после». Насчет «мрака» не согласен. Функциональности было тогда меньше, интеграции с продуктами никакой, но зато все работало как швейцарские часы. Зря вы на команду инженеров Вертики так. И тех поддержка тогда напрямую работала, я мог списаться с разработчиками и быстро узнать/решить проблему чуть ли не в Скайпе. Сейчас все это идет через линии поддержки и прямой связи до разработчиков мы получаем очень редко, хотя все таки получаем.
Нет, требуют идентичные адреса. Абсурдно, нельзя рядом в той же сети поставить такой же кластер.
Проблема с софтом была в том что из-за обратной несовместимости одно тянуло другое. К примеру, захотели использвать кафку, оно потребовало за собой вертику обновить, отвалились тогда дрова на клиентах везде. Хотя, что той кафки то, читаешь из очереди, обновляешь позицию, ложат в базу тем же COPY. Это вообще никаких обновлений не должно требовать. Там еще проявилась потом проблема, у нас не смогло слинковать очередь из Кафки с Таблицей. Вываливалось на уровней драйвера, хотя потом такой же линк только итеративно с alter таблицы сработал.
По поводу до, работало как часы потому, что Postgres за основу там был. Но нормальных тулзов для администрирования там не было, сейчас кое-что со скрипом начинает зарождаться.
Я думаю что список может быть куда длинней, это я по памяти написал то, что наш системщик выкопал. Но каждый раз при словах, что нужно что-то сделать с вертикой, у него нервный тик начинается :) Хотя всегда рад поделать что-нибудь для других реляционных баз.
Проблема с софтом была в том что из-за обратной несовместимости одно тянуло другое. К примеру, захотели использвать кафку, оно потребовало за собой вертику обновить, отвалились тогда дрова на клиентах везде. Хотя, что той кафки то, читаешь из очереди, обновляешь позицию, ложат в базу тем же COPY. Это вообще никаких обновлений не должно требовать. Там еще проявилась потом проблема, у нас не смогло слинковать очередь из Кафки с Таблицей. Вываливалось на уровней драйвера, хотя потом такой же линк только итеративно с alter таблицы сработал.
По поводу до, работало как часы потому, что Postgres за основу там был. Но нормальных тулзов для администрирования там не было, сейчас кое-что со скрипом начинает зарождаться.
Я думаю что список может быть куда длинней, это я по памяти написал то, что наш системщик выкопал. Но каждый раз при словах, что нужно что-то сделать с вертикой, у него нервный тик начинается :) Хотя всегда рад поделать что-нибудь для других реляционных баз.
> Нет, требуют идентичные адреса. Абсурдно, нельзя рядом в той же сети поставить такой же кластер.
Наверное, вы имеете ввиду, что вертика требует идентичные адреса для interconnect/control. На мой взгляд, это мелкое неудобство, поскольку public может быть любым, а interconnect/control все равно должен быть от public отделен ( да и пошире ему сеть нужна 10Gb). Мы у себя разруливаем это через VLAN-ы.
Наверное, вы имеете ввиду, что вертика требует идентичные адреса для interconnect/control. На мой взгляд, это мелкое неудобство, поскольку public может быть любым, а interconnect/control все равно должен быть от public отделен ( да и пошире ему сеть нужна 10Gb). Мы у себя разруливаем это через VLAN-ы.
«Вы не любите кошек? Вы просто не умеете их готовить» (с)
Для начала замечу, что HP купили Вертику в 2011 (когда у Вертики уже были сотни счастливых корпоративных клиентов в US), то есть Вы все время работали с HP-шной уже версией и багами. После покупки основные разработчики, получив хорошие деньги, разбежались, и не удивительно, что в новой (относительно core Vertica) функциональности находят не мало проблем. На то она и новая.
Еще замечу, что от PostreSQL там только диалект SQL и вроде некоторые вещи, связанные с планировщиком запросов. Вертика выросла из http://db.lcs.mit.edu/projects/cstore/. Поэтому говорить о «Postgres за основу» — это несколько неправда. Вертиковцы бы очень обиделись :)
Вертиковский подход к бекапам отличается от традиционного. Если внимательно почитать документацию и это осознать, то проблем не будет. Во-первых, при грамотной конфигурации у управлении кластером бекап в принципе не сильно нужен. За шесть лет промышленной эксплуатации нам ни разу не пришлось использовать бекап (и ни разу данные, конечно же, не были потеряны), хотя мы меняли сервера, кластеры, датацентры и пр. Во-вторых, бекап делается на уровне файловой системы (банальным rsync), из чего логично вытекают ограничения на идентичный кластер и т.д. (зачем восстанавливать бекап в неидентичный кластер — я не очень понимаю, и не уверен, что у других распределенных RDBMS тут сильно лучше).
> Я думаю что список может быть куда длинней, это я по памяти написал то, что наш системщик выкопал. Но каждый раз при словах, что нужно что-то сделать с вертикой, у него нервный тик начинается :)
Может быть, стоит сменить не БД, а системщика? Честно, менее проблемной базы я не встречал, а мне пришлось поработать с большинством крупных. А уж «вес» проблем по отношению к достоинствам и вовсе минимален.
Впрочем, я свое мнение не навязываю, просто делюсь. Мы тоже пробуем переехать с Вертики, но отнюдь не из-за технических проблем.
Для начала замечу, что HP купили Вертику в 2011 (когда у Вертики уже были сотни счастливых корпоративных клиентов в US), то есть Вы все время работали с HP-шной уже версией и багами. После покупки основные разработчики, получив хорошие деньги, разбежались, и не удивительно, что в новой (относительно core Vertica) функциональности находят не мало проблем. На то она и новая.
Еще замечу, что от PostreSQL там только диалект SQL и вроде некоторые вещи, связанные с планировщиком запросов. Вертика выросла из http://db.lcs.mit.edu/projects/cstore/. Поэтому говорить о «Postgres за основу» — это несколько неправда. Вертиковцы бы очень обиделись :)
Вертиковский подход к бекапам отличается от традиционного. Если внимательно почитать документацию и это осознать, то проблем не будет. Во-первых, при грамотной конфигурации у управлении кластером бекап в принципе не сильно нужен. За шесть лет промышленной эксплуатации нам ни разу не пришлось использовать бекап (и ни разу данные, конечно же, не были потеряны), хотя мы меняли сервера, кластеры, датацентры и пр. Во-вторых, бекап делается на уровне файловой системы (банальным rsync), из чего логично вытекают ограничения на идентичный кластер и т.д. (зачем восстанавливать бекап в неидентичный кластер — я не очень понимаю, и не уверен, что у других распределенных RDBMS тут сильно лучше).
> Я думаю что список может быть куда длинней, это я по памяти написал то, что наш системщик выкопал. Но каждый раз при словах, что нужно что-то сделать с вертикой, у него нервный тик начинается :)
Может быть, стоит сменить не БД, а системщика? Честно, менее проблемной базы я не встречал, а мне пришлось поработать с большинством крупных. А уж «вес» проблем по отношению к достоинствам и вовсе минимален.
Впрочем, я свое мнение не навязываю, просто делюсь. Мы тоже пробуем переехать с Вертики, но отнюдь не из-за технических проблем.
Тут я присоединюсь к Саше. Работаю с Вертикой с 2010 года, одна из самых беспроблемных СУБД, если не считать последние года и фишечки. Тут делаем проще, как и с классическими СУБД — не сразу их начинаем использовать, а ждем некоторое количество патчей. Да собственно говоря и фишечки то они сторонние — неужели кто то мешает самостоятельно разработать свое ПО, которое в реалтайм будет осуществлять захват с той же Кафки и лить данные в Вертику. Делается просто. Зато под конкретно заточенную задачу работает всяко лучше, чем универсальные «коннекторы». Это в принципе к любому СУБД относится. Здесь разве что коннекторы Хадупа у Вертики рулят, так как позволяют закачивать данные с HDFS многопоточно ноды к нодам, с кластера MPP в кластер MPP.
Я бы тоже, наверное, решил, что стоит сменить системщика, но к сожалению его многолетний опыт работы в HIPPA compliant компаниях, а также работа с U.S. Securities and Exchange Commission над разнообразными расследованиями не позволяют пока мне усомнится в нем.
Бекап через rsync это прекрасно, но это по сути и есть отсутствие нормального бекапа. Случаев когда нужен нормальный бекап уйма, начиная от возможности разворачивать на других платформах, до банального второго кластера рядом с основным, когда нужно тестировать нагрузку перед использованием новой версии ПО (клонирование данных и отправка по двум адресатам).
Плюрализм мнений это хорошо.
Бекап через rsync это прекрасно, но это по сути и есть отсутствие нормального бекапа. Случаев когда нужен нормальный бекап уйма, начиная от возможности разворачивать на других платформах, до банального второго кластера рядом с основным, когда нужно тестировать нагрузку перед использованием новой версии ПО (клонирование данных и отправка по двум адресатам).
Плюрализм мнений это хорошо.
такой глючный продукт еще поискать нужно.
Ну я совершенно не согласен с такой постановкой утверждения. Кроме багов с Кафкой я никаких других в области работы самого сервера, а так же с Хадупом или Флексом не сталкивался. А про Кафку я поэтому и написал в статье. Так что примеры в студию :)
Какие варианты рассматриваете?
Sign up to leave a comment.
Обзор HPE Vertica 8 (Frontloader)