Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6   вперед  Ctrl      все
 Re: Поговорим о масштабировании  [new]
DimaR
Member

Откуда:
Сообщений: 1570
vybegallo
Yo!!
2vybegallo

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


Да это я уже понял. Грабель вы еще и издали не видали. Жвль, что действительно специалисты по RAC себя не обнаруживают - хотелось послушать людей от сохи, теоретиков мне и коллеги ЧАЛа больше чем достаточно.


вот тут немного есть:
На сколько эффективен RAC

и тут кое что:
Что лучше 4 однопроцессорных ноды или один 4-х процессорный сервак?
28 авг 05, 14:14    [1823395]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Kostaa
Guest
O RAC, nemnogo: http://info.forbis.lt/pub/home?pnews=7135
28 авг 05, 15:23    [1823435]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
DimaR
Member

Откуда:
Сообщений: 1570
Kostaa
O RAC, nemnogo: http://info.forbis.lt/pub/home?pnews=7135


То что они написали лажа полная, по крайней мере я так буду думать, пока не будет уточнений как тестировали и с чем сравнивали.
28 авг 05, 18:08    [1823521]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
ggv


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



Не говорите ерунды. У нас в ebay все нормально работает и на 6 узлах и более. Не работает у тех, у кого руки не из того места растут. У них и Teradata тоже не масштабируется, и DB2.
30 авг 05, 02:47    [1827112]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
guest11
Guest
злой - не врите
30 авг 05, 11:24    [1827806]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
EugeneS
Member

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

Вы случайно не тот самый ggv который иногда появляется в обсуждениях статей на zdnet.ru?
Уж больно похоже.


2Yo!!
Эка вам маркетинг Oracle голову то задурил?
Остороженей надо.

Что касается темы.
Таки ggv все же более прав.

Что есть RAC?
- это софтверный коммутатор, то есть замена аппаратного коммутатора который используется в больших SMP железках ( кажется начиная с 16
узлов ).
Накой он нужен?
Для того чтобы подерживать когерентность кэшей
в случае c RAC - это SGA - узлов.
в случае с SMP(NUMA) - это кэшы процессора

- обмен блоками памяти в SMP( NUMA) архитектурах осушествляется на уровне страниц памяти, а в случае RAC на уровне блоков.


То есть принцип работы почти один и тот же.
Суть в задержках.
Пока задержки на подержание когерентности кэша в SMP(NUMA) архитектурах ниже , чем в случае с RAC.
Это до тех пор пока Oracle не предъявит доказательств обратного .
Пока у него с этим слабо.

Теперь про доказательства.
Я тоже люблю тесты SAP SD 2.
Найдите там максимальный результат.

Fujitsu PRIMEPOWER 2500, 128-way SMP, SPARC64 V 2.08 GHz, 256 KB L1 cache, 4 MB L2 cache
Solaris/Oracle9i
SAPS = 2116330
http://www.sap.com/solutions/benchmark/pdf/cert1305.pdf


Лучший результат в случае RAC.
4 x AlphaServer ES45 Model 2, 4-way SMP, Alpha EV6.8CB (21264C), 8MB L2C
Tru64/Oracle 9i RAC
SAPS= 60,420
http://www.sap.com/solutions/benchmark/pdf/CERT3102.pdf

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

Только не надо говорить про не сравнимые конфигурации.
Я говорю о результатах достигнутых в результате использования технологии.
И лично для меня RAC - это разводилово клиентов на деньги.
Я думаю тоже самое касается и MSSQL кластера.
30 авг 05, 15:38    [1829225]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Yo!!
Guest
автор
Только не надо говорить про не сравнимые конфигурации.
Я говорю о результатах достигнутых в результате использования технологии.
И лично для меня RAC - это разводилово клиентов на деньги.
30 авг 05, 15:49    [1829269]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Yo!!
Guest
автор
Только не надо говорить про не сравнимые конфигурации.
Я говорю о результатах достигнутых в результате использования технологии.
И лично для меня RAC - это разводилово клиентов на деньги.


ну вот, вы даже сами практически за меня ответ написали, вы сравниваете 16-процесорную систему которую забросили и не развивают уже черт знает сколько и современную 128 процесорную ... вы же не думали что RAC должен был сотварить чудо ??
давайте все же посмотрим что у нас с фактами:
SAP
2x4-way xeon RAC делает db2 на винде
2x4-way IBM eServer p5 Model 570 RAC делает db2 на линух
2x4-way IBM eServer p5 Model 570 RAC проигрывает db2 на aix

TPC-C
RAC на HP Integrity rx5670 Cluster 64P 1,184,893
делает
SQL2005 на HP Integrity Superdome 64P c/s 1,082,203
Oracle на HP Integrity Superdome 1,008,144

OEBS
http://www.oracle.com/apps_benchmark/html/0443A_Report1.html
http://www.oracle.com/apps_benchmark/html/0443A_Report1.html
4х-нодовый кластер вытянул 13020 а smp 15004 при этом ноды у кластера заметно слабее 1.65GHz против 1.9GHz.

т.е. факт в том, что во всех доступных тестах RAC маштабируется как минимум не хуже, в принципе только это я пытался доказать. а вот почему нет RAC-тестов на больших машинах в SAP но есть в TPC-C/TPC-H можно порассуждать/пофантазировать. если у вас есть знания на эту тему было бы интересно услышать.
30 авг 05, 16:20    [1829458]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
Yo!!
автор
Только не надо говорить про не сравнимые конфигурации.
Я говорю о результатах достигнутых в результате использования технологии.
И лично для меня RAC - это разводилово клиентов на деньги.


ну вот, вы даже сами практически за меня ответ написали, вы сравниваете 16-процесорную систему которую забросили и не развивают уже черт знает сколько и современную 128 процесорную ... вы же не думали что RAC должен был сотварить чудо ??

давайте все же посмотрим что у нас с фактами:
SAP
2x4-way xeon RAC делает db2 на винде
2x4-way IBM eServer p5 Model 570 RAC делает db2 на линух
2x4-way IBM eServer p5 Model 570 RAC проигрывает db2 на aix

TPC-C
RAC на HP Integrity rx5670 Cluster 64P 1,184,893
делает
SQL2005 на HP Integrity Superdome 64P c/s 1,082,203
Oracle на HP Integrity Superdome 1,008,144

OEBS
http://www.oracle.com/apps_benchmark/html/0443A_Report1.html
http://www.oracle.com/apps_benchmark/html/0443A_Report1.html
4х-нодовый кластер вытянул 13020 а smp 15004 при этом ноды у кластера заметно слабее 1.65GHz против 1.9GHz.

т.е. факт в том, что во всех доступных тестах RAC маштабируется как минимум не хуже, в принципе только это я пытался доказать. а вот почему нет RAC-тестов на больших машинах в SAP но есть в TPC-C/TPC-H можно порассуждать/пофантазировать. если у вас есть знания на эту тему было бы интересно услышать.



1. Вы забываете что в случае с RAC-ом есть еще
65 x AlphaServer ES45 Model 2, 4-way SMP, Alpha EV6.8CB (21264C) серверов приложений на которые происходит обработка данных.
В случае с SAP SD обработка данных происходит на сервере.
Так что засчитываем 65 процессоров дополнительно или нет ?

2. Просто с замиранием сердца жду чуда.
Покажите результаты SAP SD Parallel с участием RAC где используются хотя бы 64 процессора на стороне сервера СУБД?
Ну а уж если вы покажите мне 100 проц, то я моему восхищению просто не будет границ.
Итак ссылку в студию.
TPC-C не предлагать - это не серьезно.

3. Тесты OEBS - не подходят.
Пояснить почему?


4. Тесты TPC-C,TPC-H по сравнению с SAP-SD.
4.1. Принципиальное отличие в том что SAP-SD -официальный сайзинг который использую при покупке системы на определенное число пользователей.
То есть тест SAP-SD говорит от том что для определенного числа пользователей SAP необходимо такое -то железо.
В случае с TPC-C это просто синтетический тест, слишком далекий от реальных приложений.
4.2. По условиям теста SAP SD тест прекращается если время отклика становится больше 2сек. В случае с TPC-C время отклика никак не ограничивается. То есть если запрос будет выпольнятся 1 час и успешно выполнится , то это нормально он будет учтен , но как вы понимаете это уже не OLTP cистема.
30 авг 05, 16:56    [1829691]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Yo!!
Guest
2EugeneS

1. у меня машинка для игр мощней чем этот 4-way alpha, какой смысл сравнивать этого с новейшими спарками ?
2. нет таких, почему не знаю, но судя по тестам TPC их нет не потому что RAC не может. может потому что 9ка так неможет, может результат некрасивый, может по времени отклика не смогли, не знаю, зачем нам гадать ??
вот почему они на древней 9ке гоняют когда вон 10R2 есть, SAP не сертефицировал ?
3. да, было бы интересно.
4. тут полностью согласен но со своей стороны хочу еще раз сказать, мне не интересно гадать. меня интересуют факты. есть тесты от конкретных производителей по которым можно делать относительные выводы, но делать выводы по alpha vs sparc, 3tier vs 2tier, 4-way vs 64-way для меня уже слишком ...
30 авг 05, 17:42    [1829986]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
Yo!!
2EugeneS

1. у меня машинка для игр мощней чем этот 4-way alpha, какой смысл сравнивать этого с новейшими спарками ?

2. нет таких, почему не знаю, но судя по тестам TPC их нет не потому что RAC не может. может потому что 9ка так неможет, может результат некрасивый, может по времени отклика не смогли, не знаю, зачем нам гадать ??
вот почему они на древней 9ке гоняют когда вон 10R2 есть, SAP не сертефицировал ?
3. да, было бы интересно.
4. тут полностью согласен но со своей стороны хочу еще раз сказать, мне не интересно гадать. меня интересуют факты. есть тесты от конкретных производителей по которым можно делать относительные выводы, но делать выводы по alpha vs sparc, 3tier vs 2tier, 4-way vs 64-way для меня уже слишком ...


2. То-то и оно. Вот когда будет тогда и будем говорить про масштабируемость RAC-ов.
Насчет 10gR2, он всего 2 дней как официально выложен на сайте.

3. Все очень просто. В этом случае Oracle нельзя проконтролировать.
А что делают капиталисты когда они без котроля ? - Беспредельничают.
То же самое касается всех остальных производителей ПО и железа.

4. Факты гласят.
Приемлемых результатов у Oracle RAC - нет.



Теперь что касается сравнений.
В случае с RAC используется сервера приложений. Не так ли?
То есть если мы хотим сравнивать, то правильней было бы взять
1. SMP сервер БД + сервера приложений
2. сервер БД RAC + сервера приложений

Для случае один существует специально тест SAP SD 3.
Идем, смотрим 2002 год выбираем сервер с 16 проц.
Unisys e-@ction Enterprise Server ES7000, 16-processors, Pentium Xeon 1.6 GHz, 256 KB L2 cache, 12 GB main memory
http://www.sap.com/solutions/benchmark/pdf/cert4902.pdf
SAPS = 97580

Объяснять надо, что 1Ghz Alpha -процессор трудносравним по быстродействию с Pentium Xeon 1.6Ghz?
Что получаемся опять почти 2 каратный проигрыш.
Просто в тестах нет серверов с 16 проц от Sun и IBM, но можно даже не сомневаться что результаты там еще лучше.

Такое сравнение подходит?
30 авг 05, 18:19    [1830234]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Yo!!
Guest
автор
3. Все очень просто. В этом случае Oracle нельзя проконтролировать.
А что делают капиталисты когда они без котроля ? - Беспредельничают.
То же самое касается всех остальных производителей ПО и железа.

по этим тестам люди точно также выбирают железо для своих oebs. точно также.

автор
4. Факты гласят.
Приемлемых результатов у Oracle RAC - нет.

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

автор
Теперь что касается сравнений.

вот видите если чуть подумать то разница уже не 35, а 2 раза. а если повнимательней посравнивать современный xeon и alpha времен напалеона ? кеш, шину, i/o я уверен, что разница будет гораздо больше 200% и не в пользу alpha.
30 авг 05, 18:37    [1830322]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
О масштабируемости RAC. Если "затык" по производительности находится на диске (по термонологии Оракла "в базе данных"), например в виде блокировки, то никакая кластеризация этой проблемы не решит. Если же затык в "instance" (по терминологии Оракла) то она решается RAC'ом. Например если вы ожидаете доступа к неким структкрам данных в памяти, доступ к которым синхронизирован, то наличие N узлов и N "комплектов" данной структуры позволяет вам меньше ждать.

В мире DWH делают так: на одном узле живет ETL, на другом процессы считающие summaries и загружающие данные в Data Marts. Столкновения этих процессов друг с другом на диске сводятся к минимуму. Если же у вас борьба за данные на диске или за боркировку, то у вас будут тормозить и Teradata с DB2. Тут надо "в консерватории что-то менять". Для реально больших хранилищ данных при выборе СУБД считают деньги. Если есть site license на Oracle, то его и ставят. Или если жесткие требования по немедленной загрузке данных (tricle feed). В протмном слкчае могут и Teradata поставить. Вопрос упирается в бабки.
31 авг 05, 00:45    [1830868]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
Зл0й
О масштабируемости RAC. Если "затык" по производительности находится на диске (по термонологии Оракла "в базе данных"), например в виде блокировки, то никакая кластеризация этой проблемы не решит. Если же затык в "instance" (по терминологии Оракла) то она решается RAC'ом. Например если вы ожидаете доступа к неким структкрам данных в памяти, доступ к которым синхронизирован, то наличие N узлов и N "комплектов" данной структуры позволяет вам меньше ждать.

Совершенно верно,
только нужна инфраструктура которая подерживает синхронность или коггерентность этих структур.
В случае с RAC-ом это СACHE FUSION, в случае SMP(NUMA) систем это коммутатор, обеспечивающий когерентность памяти.
Собственно многопроцессорные системы потому так дорого и стоят,
потому что этот коммутатор довольно не простя вещь.
Про задержки я писал.
31 авг 05, 10:05    [1831286]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: Поговорим о масштабировании  [new]
Yo.!
Guest
Ну, что Yo! как всегда оказался совершенно прав. в SAP SD Parallel опубликован результат RAC 10g на 5 узлах по 8 Power6 процев. Этот результат опережает на 17% самую навороченую у SAP-SD на данный момент SMP конфигурацию из 64 Itanium на 10g.

http://www.sap.com/solutions/benchmark/pdf/Cert6607.pdf

ЗЫ. всех переживших праздник - С НОВЫМ ГОДОМ !
3 янв 08, 12:01    [5116554]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
onstat-
Member

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



vybegallo

в) второй сервер вполне можно использовать для запросов.

ну так только фоспро не умеет, mssql, sybase и оракл все умеют.




Что бы запустить запрос нужно разрывать синхронизацию.
Разве это можно назвать умеют?

Или всетаки есть способы запуска запроса без остановки наката логов,
поделитесь пожалуйста докой где про это описано.
3 янв 08, 15:47    [5116955]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Yo.!
Guest
onstat-

Что бы запустить запрос нужно разрывать синхронизацию.
Разве это можно назвать умеют?

Или всетаки есть способы запуска запроса без остановки наката логов,
поделитесь пожалуйста докой где про это описано.

дык, вам же там вроде как ответили - вы пытаетесь слать запросы на физический стендбай, а вам нужен логический.
RTFM тут:
http://download-uk.oracle.com/docs/cd/B10501_01/server.920/a96653/considerations.htm#50976
3 янв 08, 16:05    [5116978]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
Yo.!
Ну, что Yo! как всегда оказался совершенно прав. в SAP SD Parallel опубликован результат RAC 10g на 5 узлах по 8 Power6 процев. Этот результат опережает на 17% самую навороченую у SAP-SD на данный момент SMP конфигурацию из 64 Itanium на 10g.

http://www.sap.com/solutions/benchmark/pdf/Cert6607.pdf

ЗЫ. всех переживших праздник - С НОВЫМ ГОДОМ !


а вы что с чем сравниваете ? В SAP SD Parallel with Round robin - ничего, кроме RAC, нет с 2000 года.
В SAP SD Standard Application - лучший результат рвет ваш "рекорд" как тузик грелку, 468000 SAPS супротив 183680.
4 янв 08, 18:21    [5119622]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Yo.!
Guest
Выбегалло

а вы что с чем сравниваете ? В SAP SD Parallel with Round robin - ничего, кроме RAC, нет с 2000 года.
В SAP SD Standard Application - лучший результат рвет ваш "рекорд" как тузик грелку, 468000 SAPS супротив 183680.

так не удивительно RAC единственый из кластеров shared-disk и конкурентов на OLTP задачах у него пока нет. на счет 468000 SAPS эт вы с 3-tier путаете - это другой тест ... но я не удивлен ;)
9 янв 08, 00:12    [5127124]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
onstat-
Member

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

так не удивительно RAC единственый из кластеров shared-disk и конкурентов на OLTP задачах у него пока нет.



Нет не единственный.

IBM Informix v11 тоже может кластеризоваться как shared-disk.
9 янв 08, 10:04    [5127587]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Yo.!
Guest
onstat-

Нет не единственный.

IBM Informix v11 тоже может кластеризоваться как shared-disk.

единственный, в вашем документике речь идет о shared-disk standby,а не кластере. там на секондари ноды можно пускать read only запросики, конечно интересно, но какой прок от этих нод OLTP задаче ?

к стате вопросик, IDS вроде как блокировочник и при чтении раставляет блокировки, как блокировки нод узнают про блокиовки других нод ?
9 янв 08, 11:08    [5127926]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Yo.!
onstat-

Нет не единственный.

IBM Informix v11 тоже может кластеризоваться как shared-disk.

единственный, в вашем документике речь идет о shared-disk standby,а не кластере. там на секондари ноды можно пускать read only запросики, конечно интересно, но какой прок от этих нод OLTP задаче ?


Для разгрузки основной ноды производящей изменения.


Yo.!

к стате вопросик, IDS вроде как блокировочник и при чтении раставляет блокировки, как блокировки нод узнают про блокиовки других нод ?


Да он блокировочник, блокировки хранит только в памяти.
Версия 11 имеет "версионность" глубиной в одну транзакцию.
( Что бы не говорили, что в Informix писатели блокируют читателей (С) не мое).

Описание самого процесса синхронизации блокировок мне пока найти не удалось.
Если у кого есть ссылка на доку где это описано, сам с удовольствием почитаю.
9 янв 08, 15:56    [5129983]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
Yo.!
Выбегалло

а вы что с чем сравниваете ? В SAP SD Parallel with Round robin - ничего, кроме RAC, нет с 2000 года.
В SAP SD Standard Application - лучший результат рвет ваш "рекорд" как тузик грелку, 468000 SAPS супротив 183680.

так не удивительно RAC единственый из кластеров shared-disk и конкурентов на OLTP задачах у него пока нет. на счет 468000 SAPS эт вы с 3-tier путаете - это другой тест ... но я не удивлен ;)


вы нормально ответить можете, что с чем сравниваете ?
9 янв 08, 21:37    [5131602]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
sysmaster
Member

Откуда: moscow_dbs.dat
Сообщений: 452
там на секондари ноды можно пускать read only запросики, конечно интересно, но какой прок от этих нод OLTP задаче ?

Когда Jerry Keesee (Director of the Informix Lab) был в Москве, он сказал, что в будущем будет возможность читать и писать всем нодам в этой схеме.
11 янв 08, 16:46    [5141761]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
up
Member

Откуда:
Сообщений: 57
http://infocenter.sybase.com/help/topic/com.sybase.dc00768_1501/html/ase_ce_ug/ase_ce_ug3.htm
11 янв 08, 18:54    [5142655]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить