Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Why RAC is wrong for scalability and availability... ню-ню  [new]
herr
Guest
Спецы Oracle, опровергните или потвердите на сколько это правда :)

OLTP Databases: Optimal Solutions for Today’s Business Needs

...
- Why RAC is wrong for scalability and availability
...ну только 1 час времени надо что-бы прослушать это :)

http://www.bulldogsolutions.net/IBMDB2/IBD09122006/index.aspx?bdls=6013
4 сен 06, 15:42    [3090203]     Ответить | Цитировать Сообщить модератору
 Re: Why RAC is wrong for scalability and availability... ню-ню  [new]
Yo.!!
Guest
дык а ты ожидал, что они честно признаются, что их кластер никому не нужен и RAC рулит ? :)
а тему уже обсасывали
https://www.sql.ru/forum/actualthread.aspx?tid=210788
4 сен 06, 15:53    [3090262]     Ответить | Цитировать Сообщить модератору
 Re: Why RAC is wrong for scalability and availability... ню-ню  [new]
herr
Guest
ожидаю... :)

дык год назад это было
сколько воды протекло :)
4 сен 06, 16:00    [3090325]     Ответить | Цитировать Сообщить модератору
 Re: Why RAC is wrong for scalability and availability... ню-ню  [new]
ggv
Member

Откуда:
Сообщений: 1810
в принципе ничего не может измениться - сама идея RAC провальная.
но это отличный способ перераспределения клиентских расходов с закупок железа на закупки софта
Никому не нужный кластер IBM стоит на более чем 600 узлах (инфа примерно годичной давности)
При чем в последних версиях сильно улучшено межнодовое взаимодействие, что, в прочем, не отменяет необходимости маршрутизации мелких запросов на нужную ноду и распаралелливания крупных, то есть проектирования приложения на работу именно в кластере.
4 сен 06, 16:28    [3090566]     Ответить | Цитировать Сообщить модератору
 Re: Why RAC is wrong for scalability and availability... ню-ню  [new]
Yo.!!
Guest
да :) а спроэктируйте мне пожалуйста ERP задачку на таком "кластере"
4 сен 06, 16:34    [3090610]     Ответить | Цитировать Сообщить модератору
 Re: Why RAC is wrong for scalability and availability... ню-ню  [new]
ggv
Member

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

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

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

"Милый" Йо, вы будете смеятся (или плакать, кто ж вас знает, но системы, организованные пододным образом начинают появлятся даже в РФ, само собой у крупнейших компаний (мелким то такое нафик не вперлось)
4 сен 06, 16:56    [3090772]     Ответить | Цитировать Сообщить модератору
 Re: Why RAC is wrong for scalability and availability... ню-ню  [new]
Yo.!!
Guest
да ? появляются ? а можно хоть ссылочку на пресрелиз внедрения такого чудо shared-nothing кластера ? там SAP, Navision, может Peoplesoft ну хотя бы 1С. :)
как-то ibm на SAP тушуется публиковать тесты на shared-nothing ...
4 сен 06, 17:06    [3090830]     Ответить | Цитировать Сообщить модератору
 Re: Why RAC is wrong for scalability and availability... ню-ню  [new]
ggv
Member

Откуда:
Сообщений: 1810
не понял - а при чем тут SAP?
Вы просили спроектировать систему?
Вот вам проект - делайте.
А SAP никоим образом не так сделан, ни коем образом не для партиционирования данных.
Равно как и остальные вами упомянутые программные продукты.
Вы, видимо, так до конца и не разобрались, что не важно, по какой технологии строится кластерное решение, но максимальный выигрыш по производительности возможен только в случае создания специализированного ПО, заточенного на работу в таком кластере. Обратные утверждения суть есть маркетинг.
Да у вас, "милый" йо, по простоте душевной, это не является единственным заблуждением.
Ну а про 1С - это круто! Это да, enterprize level system!
Смешались в кучу кони, люди....
4 сен 06, 17:13    [3090886]     Ответить | Цитировать Сообщить модератору
 Re: Why RAC is wrong for scalability and availability... ню-ню  [new]
ggv
Member

Откуда:
Сообщений: 1810
http://www.mysql.com/news-and-events/press-release/release_2006_35.html
вот еще одна enterpize level система.
Скоро на ней ERP c сгавнякают.
4 сен 06, 17:14    [3090901]     Ответить | Цитировать Сообщить модератору
 Re: Why RAC is wrong for scalability and availability... ню-ню  [new]
Yo.!!
Guest
ggv, вы удивительно точно поняли мой намек, ваше "проэктирование" это один в один "кластер" от mysql, т.е. кроме модного слова "кластер"/SOA там ничего нет.

ggv
Основные усилия и ресурсы необходимо сосредоточить на описании предметной области с целью определения правильной схемы партиционирования.

это, как изобретете "правильную" схему за Филдса/Нобелевской не забудьте сходить, ага ;)
4 сен 06, 17:25    [3090987]     Ответить | Цитировать Сообщить модератору
 Re: Why RAC is wrong for scalability and availability... ню-ню  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
Кстати насколько я помню RAC не сертифицирован под SAP R/3
так же как и DB2 DPF. DB2 DPF сертифицированно под SAP BW, Oracle вроде собирался получить такую сертификацию
4 сен 06, 18:02    [3091203]     Ответить | Цитировать Сообщить модератору
 Re: Why RAC is wrong for scalability and availability... ню-ню  [new]
ggv
Member

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

Мне кажется, нашу бесплодную дискуссию можно закончить за невозможностью достижения хоть какого-то результата.
5 сен 06, 12:25    [3093916]     Ответить | Цитировать Сообщить модератору
 Re: Why RAC is wrong for scalability and availability... ню-ню  [new]
Yo.!!
Guest
вот загадочная русская душа, ты уже 3й кто от премии Филдса отказывается :) но может ради любви к искуству все же поделешся магическими знаниями ?

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

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

да еще вопросик, а если мы через какое-то время упераемся в потолок одной из нод, че тогда, перепроиктируем всю задачу снова ?
5 сен 06, 12:54    [3094154]     Ответить | Цитировать Сообщить модератору
 Re: Why RAC is wrong for scalability and availability... ню-ню  [new]
ggv
Member

Откуда:
Сообщений: 1810
Yo

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

Опять....
ggv
Основные усилия и ресурсы необходимо сосредоточить на описании предметной области с целью определения правильной схемы партиционирования.

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

Yo

да еще вопросик, а если мы через какое-то время упераемся в потолок одной из нод, че тогда, перепроиктируем всю задачу снова ?

Чего??? Йо, прежде чем пороть фугню, вы бы хоть почитали.... Чуток...
Нет желания читать - ну и фиг с вами. На чушь смысла отвечать нет.
Таки я настойчиво предлагаю прекратитиь "безобразия" в виду вашей полной невменяемости...
Даю вам возможность восхвалять технологию оракла наедине :)
5 сен 06, 13:33    [3094397]     Ответить | Цитировать Сообщить модератору
 Re: Why RAC is wrong for scalability and availability... ню-ню  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
Ничего, что я вмешиваюсь в ваш диалог?

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

Технические ньюансы вы уже хорошо обсудили.


--
Антон
Per rectum ad astrum
5 сен 06, 20:45    [3096764]     Ответить | Цитировать Сообщить модератору
 Re: Why RAC is wrong for scalability and availability... ню-ню  [new]
Sergey Ch
Member

Откуда: Благовещенск
Сообщений: 8894
Anton Demidov
IBM традиционно упирает на продажу железа ...

На сегодня IBM уже избавился от многих "железных" подразделений и сконцентрировал свои усилия на производстве софта под заказ, его сопровождении а так-же поставку крупных бизнес - решений... Сегодня IBM делает основную часть дохода за счет программного обеспечения...
5 сен 06, 21:17    [3096804]     Ответить | Цитировать Сообщить модератору
 Re: Why RAC is wrong for scalability and availability... ню-ню  [new]
Yo.!!
Guest
да .. уел ты меня ggv :) маладца. по хешу я не догадался, главное и придратся не к чему, ведь предупредил
ggv
наверняка увеличит время отклика на запрос, но зато увеличит общую пропускную способность системы - что поделать, nothing free

а главное начинал то как хорошо: "выбираю бизнес-запросы, SOA, ESB", а тут хлабысь - по хешу ... ну OK, так и запишем - фокусник (C)

2Anton Demidov
разница не в подходах, разница в результатах, RAC крутится у реальных клиентов реальные ERP задачи, участвует в промышленых тестах sap/tpc, а ibm'овский только специфичные задачи, где запрсы хорошо раскладываются на ноды.
5 сен 06, 21:32    [3096829]     Ответить | Цитировать Сообщить модератору
 Re: Why RAC is wrong for scalability and availability... ню-ню  [new]
ggv
Member

Откуда:
Сообщений: 1810
йо, а вы что - не знали, что партиционирование по нодам в DPF у IBM осуществляется использованием хэш функции, и называется хэш партиционированием?
Всего IBM DB2 поддерживает три типа партиционирования -
- хэш (DPF)
- range
- MDC
при чем range сделан очень красиво, где отсоединение/присоединение партиции в/из таблицы осуществляется без I/O.
MDC вообще без комментариев...
И фраза об увеличении времени отклика при увеличении пропускной способности не имеет никакого отношения к хэш функции... А только к появлению третьего слоя...
У вас туго немного со соображалкой.
Не помню, кто из известных сказал, в переводе на русский -
"нет такой архитектурной проблемы, которую нельзя решить введением дополнительного промежуточного слоя, и нет такой проблемы производительности, которую нельзя решить удалением одного промежуточного слоя"
За дословность и точность не ручаюсь, давно читал
йо, а вы вообще - читаете что-либо, окромя форумов? :)
К сожалению, с завтра и до понедельника вынужден пропасть.
5 сен 06, 21:57    [3096852]     Ответить | Цитировать Сообщить модератору
 Re: Why RAC is wrong for scalability and availability... ню-ню  [new]
ggv
Member

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

при технологии оракла это как раз кол-во нод, с которого начинаются реальные проблемы с масштабированием.
Не поэтому ли основное (если не сказать - подавляющее) кол-во ERP на RAC идет на двух узлах? С главной целью - отказоустойчивость?
Вопрос риторический, можно не отвечать.
5 сен 06, 22:15    [3096870]     Ответить | Цитировать Сообщить модератору
 Re: Why RAC is wrong for scalability and availability... ню-ню  [new]
Yo.!!
Guest
ggv
йо, а вы что - не знали, что партиционирование по нодам в DPF у IBM осуществляется использованием хэш функции, и называется хэш партиционированием?

знал, я не думал, что вы, уважаемый, начнете прикидыватся таким лаптем :)

ggv
при чем range сделан очень красиво, где отсоединение/присоединение партиции в/из таблицы осуществляется без I/O.

во-во, я и думал как красиво вы обламаетесь с range ;)

ggv
йо, а вы вообще - читаете что-либо, окромя форумов? :)

когда на sql.ru тихо, я достаю женские романы, они мне заменяют этот раздел :)
5 сен 06, 22:28    [3096882]     Ответить | Цитировать Сообщить модератору
 Re: Why RAC is wrong for scalability and availability... ню-ню  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
Все читаем мнение ведущих оракловедов по этому вопросу. Подчеркну, что это практики, использующие кластеры оракла в продакшине.
ggv был в чем-то прав, но как всегда в последнее время, он увяз в грызне и зерно истины как-то быстро затерялось.

Кстати, обратите внимание, что РАК позволяет сделать распределение нагрузки в стиле DB2:
ggv
для OLTP - только с введением промежуточного уровня, слоя, между приложением и базой, слоя с единственной задачей - знать о партиционировании данных, о типах запросов, и на основании этих знаний выполнять маршрутизацию этих запросов.
только в оракле это делает сама БД (Resource Manager) + конфигурирование сетевого подключения - т.е. без промежуточного слоя.

--
Антон
Per rectum ad astrum
7 сен 06, 00:25    [3102306]     Ответить | Цитировать Сообщить модератору
 Re: Why RAC is wrong for scalability and availability... ню-ню  [new]
ggv
Member

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

Здесь Антон или немного не разобрался, или сознательно вводит в заблуждение.
Я затронул один вопрос кластерных технологий - межнодовый обмен.
Я показал, как при shared nothing можно свести межнодовый обмен к разумному минимуму.
RAC же есть средство создания межнодового обмена.
Антон, будьте любезны, покажите, как используя RAC можно отправить запрос не начиная транзакции на локальной ноде, на ноду, на которой физически расположены в данный момент интересующие запрос данные. Как "сама БД (Resource Manager) + конфигурирование сетевого подключения - т.е. без промежуточного слоя." это сделают.
11 сен 06, 09:25    [3116956]     Ответить | Цитировать Сообщить модератору
 Re: Why RAC is wrong for scalability and availability... ню-ню  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
ggv

как используя RAC можно отправить запрос не начиная транзакции на локальной ноде, на ноду, на которой физически расположены в данный момент интересующие запрос данные.

Не совсем ясно в каком смысле "на которой физически расположены в данный момент интересующие запрос данные". Разве они не в БД, которая одна для всех нод? Или там кажный нод имеет свои диски? Ведь кластер означает общие диски для нод? Или что имелось в виду?
11 сен 06, 09:46    [3117022]     Ответить | Цитировать Сообщить модератору
 Re: Why RAC is wrong for scalability and availability... ню-ню  [new]
ggv
Member

Откуда:
Сообщений: 1810
Имелась ввиду "хитрая" работа RAC, его так называемое "тройное рукопожатие", хоть оно совсем и не тройное. Обмен между мастер нодой, нодой, которая сейчас имеет данные, и нодой, которая желает работать с данными.
11 сен 06, 10:00    [3117072]     Ответить | Цитировать Сообщить модератору
 Re: Why RAC is wrong for scalability and availability... ню-ню  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
ggv
Имелась ввиду "хитрая" работа RAC, его так называемое "тройное рукопожатие", хоть оно совсем и не тройное. Обмен между мастер нодой, нодой, которая сейчас имеет данные, и нодой, которая желает работать с данными.
Я имел в виду одну из рекомендаций для РАКов - назначать OLTP пользователей на одну ноду (группу нод), а отчетников - на другую. Как другой вариант при наличии нескольких приложений - раскидываем пользователей по нодам в зависимости от приложения. Таким образом мы уменьшим межнодовый трафик. Можно сделать сегментацию по отделам (скажем на заводе есть отделы тех. контроля, хим. лаболатории, ОК, бухгалтерия - то есть БД общая, но массированное использование таблиц специфическое для своего отдела). Прошу заметить, что такая раскладка не влияет на надёжность, так как TAF (Transparent Application Failover) никто не отменял.

P.S.
У меня на работе принято решение по переводу всех местных баз на RAC - так что появится возможность самому поучаствовать в ракостроении. Кстати, DB2 LUW у нас тоже есть и их тоже будут тестировать на предмет применимости кластерности, но это для другого, не моего продукта и в лучшем случае я увижу лишь результаты.
11 сен 06, 20:46    [3121272]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить