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

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 с момента создания. Это хорошая тенденция, если конечно обойдется без патентных войн.