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

Правильно я понял, что для снижения межнодового обмена вы (или оракл) рекомендует "сегментировать" данные? То есть на одной ноде одни таблицы, для OLTP-шников, на другой - другие, для отчетников?
Вам это ничего не напоминает?
Если же вы не о том, и таблицы "сегментировать" не предполагается, а предполагается "сегментировать" пприложения/пользователей по нодам, то как это решает проблему межнодового обмена?

Взять, што ли, телекомовский биллинг, и перенести его в DPF с маршрутизацией запросов, ну хоть MQListener'ом....
Будет интересный пример - там и OLTP, и DSS...

Да, по поводу отказоустойчивости RAC'ового решения - надо быть очень осторожным в выборе времени, как там оно называейтся, не охота лезть в доку, таймаутаожидания засбоившей ноды. Надо так умудрится, чтобы "засбоившая" нода вдруг не оказалась живой, после того, как данные перераспределены между оставшимися нодами. И две ноды будут свято уверены, что каждая и есть мастер-нода для данных....
А то так и кирдык данным может наступить.
Дефолтного значения может оказаться мало....
Кажется, у оракла есть более дешевые и надежные способы обеспечения отказоустойчивости, чем RAC, нет?

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

Да, по поводу отказоустойчивости - такого рода проблема есть только у RAC, вернее, у shared disk, потому как если диски совместно не используются, то две ноды не могут управлять одними и теми же данными - так что уровень опастности в выборе timeout немного другой

И какие в остакте имеем технологические преимущества?
Как ни крути - немасштабируемое разведение на бабки.
Надо выждать с годик, и вернутсяя к этому вопросу опять.
Должно быть, многое может изменится.

линейная масштабитруемость еще ни разу небыла показана.
Публиковавшиеся результаты при внимательном рассмотрении оказывались туфтой, притянутой за уши - занижение производительности однор-нодовой конфигурации, и прочие "подгонялки", чтобы показать линейность.
Подождем, пока Антон опубликует результаты.
Хотя, по полиси этого нельзя.
Так что в разговоре кастомеры говорят часто откровенно, про это дерьмо, а вот опубликовать - вряд ли.

да, да, как же, когда оракл проводил сранительный результат SD-Parallel на одной, двух, и четырех нодах, то Average Dialog Response time было распределено очень интересно
на одной ноде 0.81
на двух 1.81
на четырех 1.92

Если к этому добавить загрузку CPU, то кроме как занижение производительности одно-нодовой конфигурации в целях обеспечения линейной масштабируемости это больше ничем объяснить нельзя - там просто меньшу было пользователей, у системы были ресурсы свободные.

Да ладно, это мы уже в маркетинг ударились, а не в технологию.
Антон, при испытании RAC'а проверьте утилизацию CPU в четырех-нодовой конфигурации, процесс LMSn сжирает 12% CPU на каждой ноде.
Интересно было бы глянуть на результат большего кол-ва нод (на двух нодах до 6% на каждой)

ну вот как раз и будет интересно узнать результаты ваших тестов - всегда, когда тесты идут в "живой" компании на "живых" приложениях, это интересно.
И можно построить график масштабируемости ваших приложений на РАКе - 1,2,4,6,8,10 (а нечетное кол-во можно? :) ноды.
Чем больше - тем лучше.
ноды то дешевые шелезяки