ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Why RAC is wrong for scalability and availability... ню-ню
15 сообщений из 40, страница 2 из 2
  2  все
Why RAC is wrong for scalability and availability... ню-ню
    #33979374
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
Правильно я понял, что для снижения межнодового обмена вы (или оракл) рекомендует "сегментировать" данные? То есть на одной ноде одни таблицы, для OLTP-шников, на другой - другие, для отчетников?
Вам это ничего не напоминает?
Если же вы не о том, и таблицы "сегментировать" не предполагается, а предполагается "сегментировать" пприложения/пользователей по нодам, то как это решает проблему межнодового обмена?

Взять, што ли, телекомовский биллинг, и перенести его в DPF с маршрутизацией запросов, ну хоть MQListener'ом....
Будет интересный пример - там и OLTP, и DSS...
...
Рейтинг: 0 / 0
11.09.2006, 22:38
| Ответить | Цитировать | Написать  
Why RAC is wrong for scalability and availability... ню-ню
    #33979380
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
Да, по поводу отказоустойчивости RAC'ового решения - надо быть очень осторожным в выборе времени, как там оно называейтся, не охота лезть в доку, таймаутаожидания засбоившей ноды. Надо так умудрится, чтобы "засбоившая" нода вдруг не оказалась живой, после того, как данные перераспределены между оставшимися нодами. И две ноды будут свято уверены, что каждая и есть мастер-нода для данных....
А то так и кирдык данным может наступить.
Дефолтного значения может оказаться мало....
Кажется, у оракла есть более дешевые и надежные способы обеспечения отказоустойчивости, чем RAC, нет?
...
Рейтинг: 0 / 0
11.09.2006, 22:43
| Ответить | Цитировать | Написать  
Why RAC is wrong for scalability and availability... ню-ню
    #33979398
Yo.!!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!!
Участник
народ че курим ? или это осадок с выходных ? у одного данные между нодами гоняются, другой задачи разводит.
открою тайну из concepts, каждая нода в RAC имеет прямой достув в файлы данных, поэтому гонять данные между нодами ему совршенно не нужно. между нодами синхронизуется только кеш. и вот я не пойму с какой стати уменьшится межнодовый трафик если будет меньше конкурентных обновлений блоков кеша с разных нод (если разнести задачи репортинга и oltp) ?

2ggv
и с какой стати кирдык будет, клиенты стройно положат на "умершую" ноду и всем будет до пи ... эээ все равно как она себя там чуствует.
...
Рейтинг: 0 / 0
11.09.2006, 22:58
| Ответить | Цитировать | Написать  
Why RAC is wrong for scalability and availability... ню-ню
    #33979410
Фотография Anton Demidov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anton Demidov
Участник
ggvПравильно я понял, что для снижения межнодового обмена вы (или оракл) рекомендует "сегментировать" данные? То есть на одной ноде одни таблицы, для OLTP-шников, на другой - другие, для отчетников?
Вам это ничего не напоминает? Если же вы не о том, и таблицы "сегментировать" не предполагается, а предполагается "сегментировать" пприложения/пользователей по нодам, то как это решает проблему межнодового обмена?
1. предполагается "сегментировать" приложения по нодам
2. Уточню, что не сами таблицы, а их закешированные блоки данных. Которые, кстати, быстрее считать с соседней ноды, чем с диска.
3. Если таблица партицированная (в терминах Оракла) или лежит в нескольких файлах, то, если оптимизатор считает это выгодным, Оракл работает, как ДБ2 - дает каждой ноде свою партицию для обработки. Но это выгодно только для больших запросов.
4. Проблема настройки таймаута существует у любого кластера, если у него есть куда делать failover
5 Yo!!, почитай/вспомни про data blocks consistent/current reads, и поймёшь, когда придется лезть на соседнюю ноду за правильными блоками.
...
Рейтинг: 0 / 0
11.09.2006, 23:18
| Ответить | Цитировать | Написать  
Why RAC is wrong for scalability and availability... ню-ню
    #33979439
Yo.!!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!!
Участник
Anton Demidov
5 Yo!!, почитай/вспомни про data blocks consistent/current reads, и поймёшь, когда придется лезть на соседнюю ноду за правильными блоками.
ыы ? читаю ...

Oracle9i Real Application Clusters Deployment and PerformanceApplications demonstrating high reader/writer conflict rates under disk-based PCM benefit the most from Cache Fusion. Packaged applications also scale more effectively as a result of Cache Fusion. Applications in which OLTP and reporting functions execute on separate nodes may also benefit from Cache Fusion.

Reporting functions that access data from tables modified by OLTP functions receive their versions of data blocks by way of high speed interconnects . This reduces the pinging of data blocks to disk. Performance gains are derived primarily from reduced X-to-S lock conversions and the corresponding reduction in disk I/O for X-to-S lock conversions.
увеличивая трафик между нодами по быстрому интерконекту получаем бенефит. или вы чего-то другое имели ввиду ?
...
Рейтинг: 0 / 0
11.09.2006, 23:52
| Ответить | Цитировать | Написать  
Why RAC is wrong for scalability and availability... ню-ню
    #33979475
Фотография Anton Demidov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anton Demidov
Участник
Yo.!! увеличивая трафик между нодами по быстрому интерконекту получаем бенефит. или вы чего-то другое имели ввиду ? ага, именно это я и имел в виду, см. №2
...
Рейтинг: 0 / 0
12.09.2006, 00:39
| Ответить | Цитировать | Написать  
Why RAC is wrong for scalability and availability... ню-ню
    #33979783
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
То есть, чтобы преодолеть недостатки архитектуры RAC, надо сегментировать кэши, и приложения.
Мда..
То есть громкие заявления о том, что любое приложение будет линейно масштабироватся без переделки уже не действительны, стало быть...
А еще если вспомнить, что ноды предлагается группировать с разнесением данных по ним (ведь есть такая технология? как там это называется?) то несостоятельность синхронизации кэшей ну просто очевидна.

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

И какие в остакте имеем технологические преимущества?
Как ни крути - немасштабируемое разведение на бабки.
Надо выждать с годик, и вернутсяя к этому вопросу опять.
Должно быть, многое может изменится.
...
Рейтинг: 0 / 0
12.09.2006, 09:56
| Ответить | Цитировать | Написать  
Why RAC is wrong for scalability and availability... ню-ню
    #33980038
Фотография SeaGate
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SeaGate
Участник
ggvТо есть громкие заявления о том, что любое приложение будет линейно масштабироватся без переделки уже не действительны, стало быть...
И не были действительны. Где Вы видели такие заявления?
...
Рейтинг: 0 / 0
12.09.2006, 10:59
| Ответить | Цитировать | Написать  
Why RAC is wrong for scalability and availability... ню-ню
    #33980060
Yo.!!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!!
Участник
2ggv
доцент тупой

SeaGate
И не были действительны. Где Вы видели такие заявления?
я видел на http://oracle.com/scalability рядышком с тестами SAP-parallel и OEBS, где красиво показывалась линейная маштабируемость на реальных задачах.
...
Рейтинг: 0 / 0
12.09.2006, 11:05
| Ответить | Цитировать | Написать  
Why RAC is wrong for scalability and availability... ню-ню
    #33980192
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
линейная масштабитруемость еще ни разу небыла показана.
Публиковавшиеся результаты при внимательном рассмотрении оказывались туфтой, притянутой за уши - занижение производительности однор-нодовой конфигурации, и прочие "подгонялки", чтобы показать линейность.
Подождем, пока Антон опубликует результаты.
Хотя, по полиси этого нельзя.
Так что в разговоре кастомеры говорят часто откровенно, про это дерьмо, а вот опубликовать - вряд ли.
...
Рейтинг: 0 / 0
12.09.2006, 11:33
| Ответить | Цитировать | Написать  
Why RAC is wrong for scalability and availability... ню-ню
    #33980501
Yo.!!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!!
Участник
ggvлинейная масштабитруемость еще ни разу небыла показана.
Публиковавшиеся результаты при внимательном рассмотрении оказывались туфтой, притянутой за уши - занижение производительности однор-нодовой конфигурации, и прочие "подгонялки", чтобы показать линейность.
Подождем, пока Антон опубликует результаты.
Хотя, по полиси этого нельзя.
Так что в разговоре кастомеры говорят часто откровенно, про это дерьмо, а вот опубликовать - вряд ли.

http://www.oracle.com/solutions/performance_scalability/sap_8cpu_raclinux.html
2x4-way(3Ghz) xeon RAC делает 1x8way(3Ghz) xeon на db2
какой нехороший IBM специально для RAC занижает свой результат, фу какой

2 x IBM eServer p5 Model 570, 4-way SMP, POWER5, 1.9 GHz, 32 KB(D) + 64 KB(I) L1 cache per processor, 1.92 MB L2 cache and 36 MB L3 cache per 2 processors
2400 юзеров проти 2000 юзеров на 8-way.
http://www.sap.com/solutions/benchmark/pdf/cert3205.pdf
http://www.sap.com/solutions/benchmark/pdf/Cert3305.pdf
и опять IBM, что ж такое ? :) сговор наверно.

http://www.dell.com/downloads/global/power/ps1q06-20050300-Quest.pdf
черт и у dellа линейно, и как так получается ?
...
Рейтинг: 0 / 0
12.09.2006, 12:34
| Ответить | Цитировать | Написать  
Why RAC is wrong for scalability and availability... ню-ню
    #33980624
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
да, да, как же, когда оракл проводил сранительный результат SD-Parallel на одной, двух, и четырех нодах, то Average Dialog Response time было распределено очень интересно
на одной ноде 0.81
на двух 1.81
на четырех 1.92

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

Да ладно, это мы уже в маркетинг ударились, а не в технологию.
Антон, при испытании RAC'а проверьте утилизацию CPU в четырех-нодовой конфигурации, процесс LMSn сжирает 12% CPU на каждой ноде.
Интересно было бы глянуть на результат большего кол-ва нод (на двух нодах до 6% на каждой)
...
Рейтинг: 0 / 0
12.09.2006, 12:58
| Ответить | Цитировать | Написать  
Why RAC is wrong for scalability and availability... ню-ню
    #33985382
Фотография Anton Demidov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anton Demidov
Участник
ggvАнтон, при испытании RAC'а проверьте утилизацию CPU в четырех-нодовой конфигурации, процесс LMSn сжирает 12% CPU на каждой ноде.
Интересно было бы глянуть на результат большего кол-ва нод (на двух нодах до 6% на каждой) Обязательно проверю. Заранее учтите, что тестировать мы будем на своих приложениях, а не синтетические тесты - а они, как всегда, комбинированного OLTP(день)/DSS(ночь) типа.
...
Рейтинг: 0 / 0
13.09.2006, 19:27
| Ответить | Цитировать | Написать  
Why RAC is wrong for scalability and availability... ню-ню
    #33985395
Фотография Anton Demidov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anton Demidov
Участник
Anton Demidovтестировать мы будем на своих приложениях, а не синтетические тесты - а они, как всегда, комбинированного OLTP(день)/DSS(ночь) типа.
они - это наши приложения (прочитал - сам ужаснулся, пойду кофе пить)
...
Рейтинг: 0 / 0
13.09.2006, 19:35
| Ответить | Цитировать | Написать  
Why RAC is wrong for scalability and availability... ню-ню
    #33985503
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
ну вот как раз и будет интересно узнать результаты ваших тестов - всегда, когда тесты идут в "живой" компании на "живых" приложениях, это интересно.
И можно построить график масштабируемости ваших приложений на РАКе - 1,2,4,6,8,10 (а нечетное кол-во можно? :) ноды.
Чем больше - тем лучше.
ноды то дешевые шелезяки
...
Рейтинг: 0 / 0
13.09.2006, 20:53
| Ответить | Цитировать | Написать  
15 сообщений из 40, страница 2 из 2
  2  все
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Why RAC is wrong for scalability and availability... ню-ню
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]