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

Не-оракл кастомеры в таких случаях используют HADR (high-availibility data replication).

да наверно mysql/sybase/mssql кастомеры тоже так поступают, это не фича субд, oarcle8 так через атлантику реплицировала еще в 2003-м.

vybegallo

Работает надежней, поскольку а)нет single point of failure - дисковой подсистемы;

продублируйте дисковую подсистему также как это приходится это делать ibm в shared-nothing и будет счастье.

vybegallo

б) можно разнести географически;

нельзя, OLPT загнется. только как файловер.

vybegallo

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

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

преимущество RAC в том что ненадо сразу выкладовать на весь сервер, можно взять 2 ноды и через 2 года добавить еще 2 дешовые ноды, а не брать 32х голового монстра сегодня.
25 авг 05, 01:12    [1815202]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
vybegallo
Guest
Yo!!
vybegallo

Не-оракл кастомеры в таких случаях используют HADR (high-availibility data replication).

да наверно mysql/sybase/mssql кастомеры тоже так поступают, это не фича субд, oarcle8 так через атлантику реплицировала еще в 2003-м.

vybegallo

Работает надежней, поскольку а)нет single point of failure - дисковой подсистемы;

продублируйте дисковую подсистему также как это приходится это делать ibm в shared-nothing и будет счастье.

vybegallo

б) можно разнести географически;

нельзя, OLPT загнется. только как файловер.

vybegallo

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

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

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


1. HADR это таки фича СУБД, вас дезинформировали. Вы, очевидно, под этим термином понимаете что-то свое. Информикс имел эту фичу в незапамятных девяностых, начиная примерно с 6й версии.
2. насчет "нельзя разнести географически, OLTP загнется" - WalMart-у расскажите. Они, дураки, не знают, целый дублирующий центр в другом штате держат. (осторожно, вкрадчиво) - или вы полагаете, что HADR заключается в пересылке логов по мере их заполнения ?
3. HA позволяет использовать достаточно дешевые дисковые массивы, в то время как RAC, как я понял, весьма требователен к оборудованию. Опять повторю - репликация устойчива к катастрофам, а ваши дублированные массивы накроются одним торнадо.
4. И через четыре года вы упретесь в потолок (RAC сертифицирован для max 8 нод, верно ?) при этом ваши 8 нод будут реально давать производительность 5ти. В то время как процессоров доставить много ума не надо, а производительность в SMP растет практически линейно.

Практический вопрос - у вас сколько кластеров в RAC ?
25 авг 05, 01:35    [1815215]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
ggv
Member

Откуда:
Сообщений: 1810
Ну еще Yo неверно понял - нет невозможности построить кластер на DPF, но это не рекомендуется вендором без quality assurance, так как изза межнодовой коммуникации производительность будет ниже SMP box'а (но все-таки при 3 и более нодах этой коммуникации может быть меньше, чем в shared disk, все будет зависеть от распределения данных и запросов)

Далее надо задаться вопросом зачем
Зачем люди делают кластера баз?
1) Достижение производительности недостижимой на SMP box'е
2) Достижение производительности сравнимой с SMP box'ом но из "дешевых" составляющих и достижением меньшей общей стоимости
3) Failover
.........
n) Тщеславие, научный интерес (что впрочем почти одно и то же)
n+1) повышение доходов вендора

Давайте продолжать список
Ну с последним пунктом все ясно
С предпоследним, впрочем, тоже
Failover - не совсем удовлетворительно у всех кластеров. Здесь и снижение производительности, И потребность дублировать общие диски, ноды, (кстати Yo неправильно понял Mutual Takeover) Здесь лучше специализированных решений нет (oracle guard и упоминавшийся HADR informix'a и db2)
1) Для RAC не верно - не достигается такая производительность, здесь наверное и у Yo сомнений нет.
2) Тоже неверно для RAC - совокупная стоимость не будет дешевле. Если у Yo ил и у кого еще есть сомнения - давайте считать. Возьмем трех вендоров (IBM, HP, кто еще?)
И посчитаем для трех ведущих баз общую стоимость включающую и лицензии, и maintenance, и стоимость дисковых подсистем (если они не в составе среверов).

ну
25 авг 05, 09:03    [1815418]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Yo!!
Guest
не знаю что такое HRDF, я посчитал что это что то типа этого http://zdnet.ru/?ID=308209
так можно хоть фокспро реплицировать, но какое отношение это имеет к кластерам ? просто ни чем не примечательный стендбай. давайте вернемся к кластерам.

дальше, в SMP я например не умею пихать 8 процов, где 4 дырки, если вы так умеете - научите.

ЗЫ. а сколько у меня должно быть кластеров ? как гондонов как минимум пачка ?
ЗЗЫ. я с кластерами никогда не работал, но года через 2 похоже прийдется разворачивать.
25 авг 05, 09:15    [1815446]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
ggv
Member

Откуда:
Сообщений: 1810
ну и мантра "поставим две дешевые машинки, а затем еще две дешевые" не катит.
К дешевым машинкам придется ставить недешевые устройства, и от трех и до 4 нод придется согласиться с потерей производительности. Больше четырех нод внедрений все равно нет.
25 авг 05, 09:17    [1815449]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Yo!!
Guest
автор
1) Для RAC не верно - не достигается такая производительность, здесь наверное и у Yo сомнений нет
.

OK, давайте смотреть:

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.
я не уверен что если бы у кластера были бы 1.9GHz, то он бы не обошел smp.

попозже покапаюсь сдесь, может что еще найти можно. и тогда посчитаем цену.
http://www.oracle.com/apps_benchmark/html/results.html
25 авг 05, 09:26    [1815498]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
ggv
Member

Откуда:
Сообщений: 1810
Уважаемый Yo - Oracle заявлял, что у себя в лабе создал 16 нод кластер.
Я сегодня с утра к зеркалу подошел - ну чемпион мира, не меньше.
Давайте опираться на независимые тесты.
Оракл писал о не ограниченной масштабируемости и линейном росте производительности - полная лажа оказалась.

По поводу 8 CPU в четыре дырки - вы таки знаете, и IBM и SUN такое умеют.
Тот же тривиальный SUN B1000 можно проапгрейдить заменой CPU на двухядерный
А еще можно шасси взять и позже платами добивать
Да много вариантов.
У меня на старой работе заменили стариный RS/6000 - просто вернули местному IBM и доплатили. Получили новый. Вариантов куча.
25 авг 05, 09:39    [1815549]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Yo!!
Guest
хорошо, oebs не нравится берем SAP, не суть важно:
http://www.oracle.com/solutions/performance_scalability/sap_8cpu_raclinux.html

2x4-way(3Ghz) xeon RAC делает 1x8way(3Ghz) xeon на db2

SUN на двухядерный ?? это в 2007 чтоли ?
на счет дырок - я слышал что у сана платишь за 4 а они ставят 8 но дизаблят 4. разве не так ?

ЗЫ. а вот у RAC оптерон ноды действительно можно проапгрейдить.
25 авг 05, 09:49    [1815589]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
ggv
Member

Откуда:
Сообщений: 1810
ну вот здесь
http://www50.sap.com/benchmarkdata/sd2tier.asp
и здесь
http://www50.sap.com/benchmarkdata/sd3tier.asp
помогите найти то, на что ссылается oracle.
Я ищу.
25 авг 05, 09:57    [1815630]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
ggv
Member

Откуда:
Сообщений: 1810
Я не нашел.
25 авг 05, 10:00    [1815643]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Yo!!
Guest
ggv
Я не нашел.


тест там где и положено быть кластеру в SD-Parallel

http://www.sap.com/solutions/benchmark/sd1_results.htm
25 авг 05, 11:13    [1816107]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
ggv
Member

Откуда:
Сообщений: 1810
Да, увидел результат RAC на 2 4-way Intel Xeon MP 3GHz - 1350 как и указано на сайте оракла
Но смотрю на
http://www50.sap.com/benchmarkdata/sd2tier.asp
и вижу IBM eServer p5 Model 570, 8-way SMP, POWER5 1.9 GHz, 32 - с результатом 2600
Ну и ?
Чего-то я недопонимаю.
25 авг 05, 11:35    [1816218]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Yo!!
Guest
ggv
Да, увидел результат RAC на 2 4-way Intel Xeon MP 3GHz - 1350 как и указано на сайте оракла
Но смотрю на
http://www50.sap.com/benchmarkdata/sd2tier.asp
и вижу IBM eServer p5 Model 570, 8-way SMP, POWER5 1.9 GHz, 32 - с результатом 2600
Ну и ?
Чего-то я недопонимаю.


вы просто торопитесь и невнимательно смотрите ... посмотрите на строчку выше в SD-Parallel :)

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 юзеров.

а потом смотрим на последние тесты таво же eServer p5 Model 570 на линухе от 06/30/2005 и там обнаруживаем 2000 юзеров.

при этом учитываем что оракл выступает на стареньком 9iRAC, а 10-ка занчительно шустрее.

ЗЫ. я не пытаюсь доказать, что RAC быстрее db2, я показываю что оракловый RAC маштабируется как минимум не хуже чем оракл на SMP.
25 авг 05, 11:49    [1816303]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
ggv
Member

Откуда:
Сообщений: 1810
Да, есть такая строчка.
Только вывод другой - RAC имеет производительность, чем SMP.
К сожалению, нету свежих тестов SAP SD oracle на 8-way SMP - с чем сравнивать?
Ну и опять же - кол-во нод удручает.... Везде 2.

Я таки глядя на архитектуру устройства RAC
https://www.sql.ru/forum/actualfile.aspx?id=1797864
не могу согласится, что производительность будет хотя бы не хуже SMP, а добавлением нод она будет просто катастрофически падать.
Этакое "тройное рукопожатие", да между кучи нод.....

Кстати, есть TTCP - transaction TCP, как раз чтобы избежать "тройного рукопожатия". Интересный проект.
Ну а в shared nothing рукопожатие всегда двойное. Нет?
25 авг 05, 12:08    [1816457]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
ggv
Member

Откуда:
Сообщений: 1810
и зачем смотреть на тест от 06/30/2005
если можно смотреть на тест от 07/13/2004 - 2600 users, Я его выше и упоминал, этот тест,
вот этот вот
IBM eServer p5 Model 570, 8-way SMP, POWER5 1.9 GHz
25 авг 05, 12:12    [1816483]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
ggv
Member

Откуда:
Сообщений: 1810
off-topic, но рядом с темой
Сравним тесты того самого p570 -
07/13/2004 - IBM eServer p5 Model 570, 8-way SMP, POWER5 1.9 GHz - AIX
06/30/2005 - IBM eServer p5 Model 570, 8-way SMP, POWER5 1.9 GHz - SuSe Linux
Ну и результат смотрим....
25 авг 05, 12:15    [1816510]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Yo!!
Guest
что-то я не понимаю куда вы смотрите, я вижу так:

2x4-way xeon RAC делает db2 на винде
2x4-way IBM eServer p5 Model 570 RAC делает db2 на линух
но
2x4-way IBM eServer p5 Model 570 RAC проигрывает db2 на aix

т.е. скорость больше зависит от операционки, чем от кластер/smp.

дальше мы можем смотреть и tpc и oebs benchmarks везде как и заявляет оракл маштабируемость на уровне smp. где-то была картинка как в oebs добавили к 2 нодам еще 2 и получили почти линейную маштабируемость.

так что ваше утверждение
автор
1) Для RAC не верно - не достигается такая производительность, здесь наверное и у Yo сомнений нет.

я считаю в корне неверным.
25 авг 05, 12:25    [1816569]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
ggv
Member

Откуда:
Сообщений: 1810
блажен кто верует. Вера - сильная вещь.
В одной и той же инфе мы видим разное.

Ну посмотрите на абсолютные результаты.
Теперь еще есть сомнения в масштабируемости RAC ?

Ну после просмотра SAP SD уже пожалуй нечего смотреть, технических аргументов тоже уже вряд ли будет, тестов тоже нет. Можно тему закрывать, оставаясь всем при своем мнении.
До следующего интересного топика.
25 авг 05, 12:36    [1816650]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Yo!!
Guest
обождите :)
у вас в обсалютных цифрах разница менее 10% и вы хотите сказать что эта катострофическая потеря ??
если да, то можно взять p5 Model 570 и некластерные тесты tpc и глянуть на разницу между ораклом и db2 + попраку на 9i vs 10gR2 и уверен получим что RAC окажется быстрей чем oracle smp.

и потом у нас еще есть пункт 2:
автор
2) Тоже неверно для RAC - совокупная стоимость не будет дешевле. Если у Yo ил и у кого еще есть сомнения - давайте считать.


вечерком обязательно посчитаем ;)
25 авг 05, 12:51    [1816746]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
ggv
Member

Откуда:
Сообщений: 1810
ну раз обождать......
Вы выдернули мою цитату 1) - она о достижении максимально возможной абсолютной производительности.
Извините за грубость (плохо себя чувствую) но здесь кластера в полной заднице как по TPC-C так и по SAP.
Давайте подождем новых тестов. Вот и MS скоро сделает.
И еще есть интересный тест TPC-App (http://www.tpc.org/tpc_app/default.asp)
Вот интересно будет.
Засим разрешите таки продолжить работу, остальные все молчат, одни мы с вами препираемся без результатно.
25 авг 05, 12:56    [1816791]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
vybegallo
Guest
Yo!!
не знаю что такое HRDF, я посчитал что это что то типа этого http://zdnet.ru/?ID=308209
так можно хоть фокспро реплицировать, но какое отношение это имеет к кластерам ? просто ни чем не примечательный стендбай. давайте вернемся к кластерам.

дальше, в SMP я например не умею пихать 8 процов, где 4 дырки, если вы так умеете - научите.

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


Если вы не знаете, что такое High Availibility Data Replication - то не бросайтесь спорить на эту тему.
Про способы наращивания серверов / обмена серверов с доплатой вам уже рассказали.
Жаль, конечно, что все ваши знания кластеров пока чисто теоретические, а представления об их возможностях почерпнуты из бенчмарков. Хотелось бы поговорить с практиками. Вот, к примеру, что практики пишут в comp.databases.oracle.server :
----
I've done it and the one thing I can tell you is that RAC has what
I call the 'spotlight' effect: It is extremely good at pointing out
very poorly written code. And often with the result that performance
goes down rather than up.
----
bad code is bad code and hurts. But bad code with RAC
is poison.
----
One warning - someone else made the comment that
the manuals say "if is scales on one node it will scale
on RAC". What the manuals actually says is "if it
won't scale on one node it won't scale on RAC".
----
My advice based on my experiences with RAC is never use RAC, if there
is any way how to do the job without it! If you're unable to tune your
single instance database, then on RAC you will not be able to tune it
at all.
----
Here a short general rule of thumb for RAC:

(1) If you need PERFORMANCE - scale vertically (put more cpu's,
memory, etc.) in your database machine.

(2) If you need HIGHAVAILABILITY scale horizontal means - use a cluster.

It is true that if you add cluster nodes instead of scaling vertically -
you will gain some more performance BUT - not as much as scaling
vertically - and at a higher cost (hardware + more administration)
----

В таком вот аксепте
25 авг 05, 21:21    [1818713]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Yo!!
Guest
2vybegallo
умоляю, не нужно встревать в технический разговор с аргументами на уровне детского сада, петька с соседнего двора имел секс со шлюхой и ему не понравилось и он считает, что дрочить лучше. мне действительно на такое нечего ответить.
25 авг 05, 21:55    [1818775]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
vybegallo
Guest
Yo!!
2vybegallo
умоляю, не нужно встревать в технический разговор с аргументами на уровне детского сада, петька с соседнего двора имел секс со шлюхой и ему не понравилось и он считает, что дрочить лучше. мне действительно на такое нечего ответить.


У кого что болит...

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

Кстати, петьки из comp.databases.oracle.server подозрительно дружно утверждают, что RAC ведет себя тем лучше, чем сильнее разграничены данные между нодами. Мне это почему-то напоминает эмуляцию архитектуры "shared nothing" , нет ? Или, думаете, врут петьки, не нужно переписывать приложения и перекраивать базы ?
26 авг 05, 00:37    [1818950]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Yo!!
Guest
2vybegallo

уважаемый, может вы разбираетесь в балете или замечательный собеседник на тему живописи, но разговора по RAC у нас с вами не получется. ну нечего мне ответить о ораспределении даных по нодам ...
26 авг 05, 09:22    [1819229]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
vybegallo
Guest
Yo!!
2vybegallo

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


Да это я уже понял. Грабель вы еще и издали не видали. Жвль, что действительно специалисты по RAC себя не обнаруживают - хотелось послушать людей от сохи, теоретиков мне и коллеги ЧАЛа больше чем достаточно.
26 авг 05, 09:56    [1819359]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить