в принципе ничего не может измениться - сама идея RAC провальная.
но это отличный способ перераспределения клиентских расходов с закупок железа на закупки софта
Никому не нужный кластер IBM стоит на более чем 600 узлах (инфа примерно годичной давности)
При чем в последних версиях сильно улучшено межнодовое взаимодействие, что, в прочем, не отменяет необходимости маршрутизации мелких запросов на нужную ноду и распаралелливания крупных, то есть проектирования приложения на работу именно в кластере.

Это техзадание?
Какой вопрос - такой ответ.
Тогда планирую -
1) выбираю бизнес-запросы, которые должны отрабатывать параллельно на всех узлах и скорость выполнения которых критична
2) реализую архитектуру на основе SOA Reference Architecture с ESB , котнретно Advanced ESB
3) маршрутизатор запросов, реализованный в "рамках" ESB направляет запросы, не требующие распараллеливания на ноды, где непосредственно хранятся данные, а остальные на координирующую ноду.

Основные усилия и ресурсы необходимо сосредоточить на описании предметной области с целью определения правильной схемы партиционирования.
"Динамическое" добавление новых "типов" бизнес-запросов обеспечивается классическими возможностями ESB с ее transfor/convert/route.

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

"Милый" Йо, вы будете смеятся (или плакать, кто ж вас знает, но системы, организованные пододным образом начинают появлятся даже в РФ, само собой у крупнейших компаний (мелким то такое нафик не вперлось)

не понял - а при чем тут SAP?
Вы просили спроектировать систему?
Вот вам проект - делайте.
А SAP никоим образом не так сделан, ни коем образом не для партиционирования данных.
Равно как и остальные вами упомянутые программные продукты.
Вы, видимо, так до конца и не разобрались, что не важно, по какой технологии строится кластерное решение, но максимальный выигрыш по производительности возможен только в случае создания специализированного ПО, заточенного на работу в таком кластере. Обратные утверждения суть есть маркетинг.
Да у вас, "милый" йо, по простоте душевной, это не является единственным заблуждением.
Ну а про 1С - это круто! Это да, enterprize level system!
Смешались в кучу кони, люди....

http://www.mysql.com/news-and-events/press-release/release_2006_35.html
вот еще одна enterpize level система.
Скоро на ней ERP c сгавнякают.

"милый" йо - каков вопрос - таков ответ.
А MySQL при всем моем к нему уважении, еще до такого какать и какать.
Вы, как человек отсталый от технологий, еще можете видеть "сходство".
DPF уникально, без переделки приложений подходит для хранилищ (и то, если прининять во внимание, что хранилище - это единая целостная выверенная копия всех данных компании - то требования по безопастности, мониторингу и управлению этими данными должны быть гораздо более строгими в некоторых видах бизнеса, чем у оперативных данных, поэтому не всегда оправданно даже с точки зрения затрат реализация хранилищ на распределенных платформах становится не оправданной), а для OLTP - только с введением промежуточного уровня, слоя, между приложением и базой, слоя с единственной задачей - знать о партиционировании данных, о типах запросов, и на основании этих знаний выполнять маршрутизацию этих запросов.
Введение этого промежуточного слоя, как я уже говорил, наверняка увеличит время отклика на запрос, но зато увеличит общую пропускную способность системы - что поделать, nothing free.
Ясно, что для этого требуется или проектирование системы с нуля, или переделка системы и довольно не слабая. Поэтому как и всегда решение принимается на основе множества критериев, среди которых нужная производительность лишь одна из списка критериев. Еще не факт, что управляемость, администрируемость, и безопастность и прочая RAS (Responsability, Accessability, Serviceability) решения на кластере будет дешевле и проще, чем на SMP.

Мне кажется, нашу бесплодную дискуссию можно закончить за невозможностью достижения хоть какого-то результата.

Yo
давай возьмем ebay.com там в поиске есть:
items (у них categories), stores, members
очень бы хотелось услышать как бы ты это отпартиционировал :) (с учетом что нагрузка/размер такая же как ebay) ?

Опять....
ggvОсновные усилия и ресурсы необходимо сосредоточить на описании предметной области с целью определения правильной схемы партиционирования.
Это что - вы дали описание предметной области???
Ну что же "милый" йо опять на грабли наступает...
По принципу "какой вопрос - такой ответ" получаем "Я бы отпартиционировал по хэш-функции с целью ускорения параллельной оработкой самых важных запросов"

Yo
да еще вопросик, а если мы через какое-то время упераемся в потолок одной из нод, че тогда, перепроиктируем всю задачу снова ?
Чего??? Йо, прежде чем пороть фугню, вы бы хоть почитали.... Чуток...
Нет желания читать - ну и фиг с вами. На чушь смысла отвечать нет.
Таки я настойчиво предлагаю прекратитиь "безобразия" в виду вашей полной невменяемости...
Даю вам возможность восхвалять технологию оракла наедине :)

йо, а вы что - не знали, что партиционирование по нодам в DPF у IBM осуществляется использованием хэш функции, и называется хэш партиционированием?
Всего IBM DB2 поддерживает три типа партиционирования -
- хэш (DPF)
- range
- MDC
при чем range сделан очень красиво, где отсоединение/присоединение партиции в/из таблицы осуществляется без I/O.
MDC вообще без комментариев...
И фраза об увеличении времени отклика при увеличении пропускной способности не имеет никакого отношения к хэш функции... А только к появлению третьего слоя...
У вас туго немного со соображалкой.
Не помню, кто из известных сказал, в переводе на русский -
"нет такой архитектурной проблемы, которую нельзя решить введением дополнительного промежуточного слоя, и нет такой проблемы производительности, которую нельзя решить удалением одного промежуточного слоя"
За дословность и точность не ручаюсь, давно читал
йо, а вы вообще - читаете что-либо, окромя форумов? :)
К сожалению, с завтра и до понедельника вынужден пропасть.

кстати, есть рекомендация использовать кластер DB2 для решения OLTP задач при кол-ве узлов 4+
Это кол-во, где как раз и можно проявить все преимущества технологии.

при технологии оракла это как раз кол-во нод, с которого начинаются реальные проблемы с масштабированием.
Не поэтому ли основное (если не сказать - подавляющее) кол-во ERP на RAC идет на двух узлах? С главной целью - отказоустойчивость?
Вопрос риторический, можно не отвечать.

Anton Demidovтолько в оракле это делает сама БД (Resource Manager) + конфигурирование сетевого подключения - т.е. без промежуточного слоя.

Здесь Антон или немного не разобрался, или сознательно вводит в заблуждение.
Я затронул один вопрос кластерных технологий - межнодовый обмен.
Я показал, как при shared nothing можно свести межнодовый обмен к разумному минимуму.
RAC же есть средство создания межнодового обмена.
Антон, будьте любезны, покажите, как используя RAC можно отправить запрос не начиная транзакции на локальной ноде, на ноду, на которой физически расположены в данный момент интересующие запрос данные. Как "сама БД (Resource Manager) + конфигурирование сетевого подключения - т.е. без промежуточного слоя." это сделают.

Имелась ввиду "хитрая" работа RAC, его так называемое "тройное рукопожатие", хоть оно совсем и не тройное. Обмен между мастер нодой, нодой, которая сейчас имеет данные, и нодой, которая желает работать с данными.