Эх, больше рекламных слоганов, чем усовершенствований. "Большее сжатие данных" это конечно круто звучит, но я бы предпочел увидеть в анонсе увидеть следующие пункты:
1. Убрали монопольную запись в таблицу одной сессией
2. Сделали партиционирование индексов
3. Изменили лицензирование с ядер на занимаемое БД пространство

Ну а насчет преимуществ два-в-одном против MPP тоже как то натянуто звучит. У меня например, сейчас Вертика на трех простеньких серверах 6 тб сжатую базу крутит (это 12 тб исходной информации). В фактовых таблицах от 1 до 15 лярдов записей, к ним постоянно идут запросы разной сложности, плюс джобы в реалтайм постоянно грузят информацию и считают агрегаты. Все это живет, откликается и никого не заставляет долго ждать. До тучи в Вертику каждый день вливается поллярда записей, чтобы агрегировать и отдать MS AS для куба (чтобы он не думал по сто лет). Тяжеловато конечно уже серверам, будем расширять кластер - доставим сервера под Вертику, пропишем узлы, сервер не останавливаясь в фоне проведет ребалансировку данных на новые узлы и все станет еще быстрее работать, причем с точки зрения лицензирования мы никому ничего доплачивать не должны. Так что, распределенная обработка данных, зеркалирование и прочее что есть у MPP как то уж подозрительно в анонсе чуть ли не "недостатками" MPP обозвали маркетологи совсем зазря.

автор У Вас же, как описано, это практически стейджинг какой-то :) а не ДВХ.
Прошу прощения, но у меня вообще ничего не описано. Просто приведен пример, что до тучи наше хранилище некоторыми подразделениями ИТ в том числе как стейджинг используется для ускорения загрузок кубов в МС и расчетов в Оракл.

По цене лицензия Вертики на 30 тб исходных данных с любым количеством серверов в кластере будет ощутимо дешевле лицензии на 2 сервера IQ по 12 ядер с мультиплексом и прочими опциями. Причем стоит учесть, что чисто физически эти 2 сервера не протянут такой объем, если много сессий и кэширование с индексами и партициями не поможет, а значит придется на IQ еще сервера лицензии покупать, чтобы доставить сервера.

Насчет партиций тоже не все так однозначно. С одной стороны они разделяют данные, ускоряя доступ, но если запрос должен охватить данные по измерениям без участия полей партиций, то толку от них ноль.здесь как раз помогает распределенное хранение данных. Что в том же Map Reduce используется — представляю себе, сколько бы пришлось ждать ответ от Гугла, если бы он все данные на одном дисковом хранилище хранил :)

Ладно, извиняюсь за спам. Вертику не как рекламу,а больше как пример привел того, что будущее хранилищ данных IMHO все таки MPP, убедился на личном опыте. Если есть вопросы, можно задать их по почте или аське.

bmv_rusКостя_1, АСКРУС.

Давайте более предметно, а то иначе это выглядит как банальная реклама - сколько стоит Вертика на 30 тб исходных данных с любым количеством серверов в кластере по General Price от HP.

Можно в личку.
Извините, но я не собираюсь на форуме Sybase делать тему IQ vs Vertica, все что я в привел в пример с Вертики это перечисление недостатков IQ с концепцией "два в одном" на фоне MPP архитектуры. И Вам не советую начинать здесь сравнения проводить, для этого есть форум Сравнение СУБД. Ну а с учетом того, что Вертика в РФ и на Европейском континенте первый запущенный в продакшн проект имеет у нас, вообще и в сравнении тему заводить не стоит, так как опыт реальной эксплуатации на терабайтах данных на скуль.ру имеется только у меня и Vovaka.

Хотите сравнить цены, обращайтесь в Sybase и HP, хотя подозреваю обе конторы на текущем этапе интеграции Sybase с SAP и Vertica с HP еще сто раз будут думать и переигрывать лицензионную политику.

Ну а насчет лицензирования объемов я твердо уверен, что для BigData это верный путь. Сервера сейчас достаточно дешевые, обработка больших данных не должна зависеть от лицензии, в любой момент возрастают нагрузки и требуется нарастить кластер новыми серверами, чтобы не просела производительность. Почему я за это должен платить, не понимаю - если мне нужна скорость обработки и в я кластер ставлю сто 16 ядерных серверов, с текущей лицензионной политикой IQ легче будет Терадата купить и не парить мозг. А объем штука статичная - если хранилище прирастает из расчета 10 тб в год, можно спокойно прикупить 30 тб и к концу 3 года уже решить, сколько еще потребуется лицензии, что требуется хранить, а что можно и перевести из хранилища в архивы.

А что хи—хи? Объем прироста данных спрогнозировать гораздо проще и надежнее, чем нагрузки потребления данных. Число источников данных растет медленно, а вот количество пользователей хранилища и тяжести аналитических запросов может критически измениться в любой момент. Сегодня с хранилищем работает через САП 50 пользователей, а завтра другое подразделение компании покупает Tableau и на хранилище начинают сыпаться новые тяжелые запросы. И если для любого бизнеса и так понятно, что нужно докупить железо, то вот им объяснить, зачем его еще надо лицензировать, будет сложно. Другое дело объем - тоже логично и понятно, база выросла за года, нужно принять решение, убрать информацию в архив или нужно расширить объем хранилища, старая информация нужна.

Тоже самое касается и апгрейда серверов хранилища, решили поменять сервер на более современный, ядер естественно больше, руководство узнает что надо доплачивать лицензию и с большой вероятностью апгрейд накроется медным тазом.

Юр, стоек нет, есть локальные диски, на которых и лежит база. На каждом сервере лежит его часть базы + зеркало соседнего сервера. Можно включить режим двойного зеркалирования, когда каждый сервер еще хранит зеркало предыдущего и следующего сервера кластера по цепочке, но мы решили, что это уже избыточно.

moris, в MPP СУБД изначально база равномерно распределяется между всеми серверами кластера, это называется сегментацией данных. Естественно это все происходит на физическом уровне, для клиентской сессии это одна БД и она просто посылает к ней запрос. Далее СУБД самостоятельно запускает параллельное выполнение запроса на всех серверах кластера, которые над своей частью данных выполняют работы по фильтрации, объединению, группировки и сортировке данных, обмениваясь при этом порциями промежуточных данных по сети, далее результаты собираются на сервере, с которого сессия вызвала запрос, допиливаются до окончательного вида и отдаются сессии.

С джойнами все тоже самое - или если данные присоединяемых таблиц лежат по ключам рядом с основными данными, они сцепливаются локально на всех серверах или же происходит обмен данными по ним между серверами для проведения присоединения. Если СУБД видит выгоду, то он может нужные колонки мелких присоединяемых таблиц просто реплицировать по всем узлам, чтобы потом по хешу быстро их сцепить. Так же можно самостоятельно управлять сегментацией данных, указывая перечисления полей через хеширование, по которому можно определить распределение данных между серверами. Для мелких таблиц можно явно указать отключить сегментирование и их копия будет хранится на каждом из узлов кластера.

В общем там все не так примитивно, как ты думаешь, оптимизатор показывает высший пилотаж, рассчитывая план запроса так, чтобы ноды кластера как можно больше работ выполнили локально, минимизировав их общение по сети. В принципе в современных MPP это все успешно решено и такие операции, как джойны, группировки и union на больших таблицах шустро работают. Понятное дело, что с непривычки после классических СУБД можно наломать не мало дров, даже партиционирование вообще имеет другой смысл и другое назначение, чем в привычном понимании. Даже колоночное хранение сжатых данных казалось бы принципы те же, а вот реализация разная, в итоге и работа оптимизатора здорово отличается и при проектировании структур это учитывать стоит.

На самом деле с MPP выжать очень много можно, если понимать и уметь. Распределенное хранение и обработка данных гарантируют равномерные нагрузки на все сервера кластера, всегда работают все, простоев нет. Это дает горизонтальную масштабируемость - добавляем новый сервер в кластер, данные кластера ребалансируются равномерно на новое кол-во серверов, а значит на один сервер его объем локальных данных уменьшается, а ядер и памяти для параллельной обработки запроса увеличивается. Ну и дискового пространства для хранения данных прирастает. Локальные диски очень быстры, нодам не требуется сетевой доступ для чтения и записи данных, данные хранятся в виде блоков в сжатом поколоночном отсортированном виде, каждый блок содержит свою информацию о том, что лежит внутри него. В итоге не требуются и индексы как дополнительные структуры для повышения скорости доступа к данным. Они насколько я знаю есть только у GreenPlum, но и то оставлены как пережиток прошлого, при проектировании ими никто не пользуется.

Ну и если уж говорить о PlexQ, то с одной стороны оно конечно здорово, что я могу определить группы серверов, занимающихся различной нагрузкой и разными задачами. С другой стороны, получается, что все это дело надо реконфигурировать в случае изменения задач, нагрузок или изменения технической части. В MPP все просто - всегда работают все, поэтому если нагрузки повышаются, они равномерно повышаются на все сервера кластера. Если добавляем новые сервера в кластер, повышается производительность работы всего кластера. Если вдруг один сервер стал недоступен для кластера, общая производительность кластера падает, так как один из его серверов начинает выполнять работу за двоих, но это не так значительно, чтобы все стало тормозить. Еще такой момент я обратил внимание, что например в Vertica оптимизатор никогда не использует зеркало соседнего сервера, хотя вот оно, казалось бы, лежит рядом, бери и пользуйся для ускорения. В PlexQ же получается так как физически база лежит в одном месте и все сервера ее читают, то это же какие затраты и издержки на то, чтобы одновременно всем серверам лезть к стойке за информацией и при этом синхронизировать свои действия, чтобы каждый четко прочитал только нужный кусок и не было дублирования обработки информации между серверами. Фактически это получается этакий виртуальный MPP, где все делают вид, что владеют своей частью данных и в масс параллельной обработке ее используют. Получается, что при использовании PlexQ теряется одно из главных преимуществ IQ - простота администрирования. За группами серверов надо следить, продумывать какие нагрузки как лучше распределять, если прибавилось подключений или потяжелели запросы, нужно переконфигурировать группы серверов, добиваясь лучшей производительности ... то есть появляется понятие тюнинга, что совсем не было в старом добром IQ.

Ну и вот тоже мне не понятна фраза из статьи про IQ:
Используя MPP-архитектуру с полным разделением ресурсов, платформа распределенной обработки запросов PlexQ в составе Sybase IQ 15.3 превосходит традиционные MPP-архитектуры без разделения ресурсов в части параллелизма, качества обработки произвольных запросов самообслуживания и независимого горизонтального масштабирования вычислительных мощностей и мощностей хранения.
Не могу понять, почему здесь говорится, что у MPP нет разделения ресурсов. У MPP есть понятие workload, можно замечательно по пулам ресурсов провести разделение по приоритетам по использованию процессорного времени и памяти, раскидав на эти пулы пользователей. Описанный пул ресурсов работает для всех серверов кластера, но это и понятно - в коллективной работе серверов совсем не желательно, чтобы кто то тормозил, а кто то работал быстрее. Иначе кто отработал быстрее будет ждать остальных, кто работает дольше. Кстати поэтому и предъявляются требования, чтобы данные равномерно хранились на серверах без перекосов по объемам и чтобы сессии работали через балансировщик подключений и к серверам кластера так же равномерно разбрасывались пользовательские сессии.

В общем по мне, так PlexQ что то смахивает на этакую многовекторность - мы типа и в одном месте данные храним, но и обрабатываем их частями отдельно. Сложновато по архитектуре получается организовать такую синхронизацию работы серверов, а я сторонник принципа чем проще тем лучше. Как минимум управлять проще и багов обычно меньше ;)

bmv_rusmoris

Ну вот, у ASCRUS такая складная история получалась, уэе начали уверовать, а ты возьми да развей ))
Вы кому то что то хотите доказать или утверждаете что я хочу кому то что то доказать?

moris, спасибо за ликбез. То, что Вы написали, чистой воды MPP, плюс минус особенности реализации. Не очень тогда понятно, почему Sybase считает, что их решение эффективнее прочих реализаций.

Я еще раз повторюсь для bmv_rus - я не считаю, что IQ уступает остальным, мне кажется не удобной политика лицензирования. А все остальное познается только на практическом опыте, у меня нет такого опыта в IQ, чтобы сравнить с тем решением, с которым я сейчас работаю. У нас в силу требований проекта первым в списке шла способность многопоточной записи множества сессий в реалтайме (сбор статистики с множества устройств), поэтому IQ не рассматривался. Все просто.

Спасибо, конечно интересно. Многое схожее по решениям с тем, что есть у MPP, но есть много и разного. Под разные задачи это выливается и в плюсы и в минусы тоже (это конечно если не учитывать еще квалификацию разработчиков и считать, что они хранилище строят максимально оптимально). Насчет опасности неравномерного распределения данных у MPP соглашусь на все 100. Реально, когда запускаешь на проектирование хранилища разработчиков, привыкших к классическим реализациям сервера, они много чего наворотят такого, что потом их хочется пристрелить. Это самая ахилесова пята MPP, причем самое печальное, что из за таких перекосов в одной таблице фактов просядет производительность всего кластера. Здесь IQ вне конкуренции по простоте проектирования эффективных хранилищ.

Остальные перечисленные недостатки отлично демонстрируют конкуренты Vertica (GP и Netezza), но не она ;) Все таки «папа» Стоунбрейкер человек с большом опытом создания СУБД и он максимально учел все достоинства и недостатки существующих решений. Смотрю есть и моменты заимствования решений от IQ, есть и наоборот недавно появившиеся в IQ фичи, которые были ноу хау в Vertica с момента создания. Это хорошая тенденция, если конечно обойдется без патентных войн.