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

Откуда:
Сообщений: 4919
Блог
Mark Barinstein,

А правильно ли я понимаю, что DB2 осуществляет блокировки на уровне страницы? Или это свойство только pureScale? Или я вообще ошибаюсь?
25 июл 11, 23:20    [11025634]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
Senya_L
Member

Откуда: Москва
Сообщений: 5381
Yo.!
Mark Barinstein
Да откуда же вы знаете, кисло у IBM с этим, мелко или мягко?
Не упирается оно в "громадный" трафик.
Я уже просил вас, кажется, не писать о том в DB2, о чём вы ни малейшего представления не имеете.

помниться лет 7 назад мне тут точно так же указывали фаны майкрософт, что я "ни малейшего представления" не имею о блокировочниках, расписывая достоинства версионников. a потом майкрософте появился IL snapshot
и заметте, возразить по существу вам нечем ...
Демагог...

Модератор: остальное потер
в следующий раз еще и забаню


Сообщение было отредактировано: 26 июл 11, 00:12
25 июл 11, 23:31    [11025671]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
Yo.!
Guest
Mark Barinstein
Ну, ораклу надо же как-то по этому поводу высказаться, вот он и пишет.
Хотя надо было задуматься, как это одна и та же архитектура без особых принципиальных различий на мэйнфреймах уже много лет работает (и совсем неплохо работает), а на intel/power будет затыкаться.

и нужно признать пишет оракл не в бровь, а в глаз. если задуматься то ничего общего у z/os и luw версий нет. вообще ничего. разные ветки кода, разные года написания, даже языки программирования для написания ядра использовались разные. структуры памяти и буферов разные, даже байтов на лок у них разные. разные стратегии эскалации .. да все там разное.

Mark Barinstein
Спорный вопрос: блокировок - да, конечно больше, но версионнику надо версии блоков передавать по сети, а блокировочнику - нет. И где там трафик будет больше - трудно сказать...

как раз тут у оракла будет преимущество. если измененный блок понадобиться другой ноде, тот тут и ораклу и purescale придется передать блок. причем у дб2 дергая локлист + повисев на локах (к тому же через запись в глобал кеш на CF-ноде). а вот если ораклу понадобиться старая версия блока, которая есть в локальном кеше лазить на другие ноды за модифицированной версией не понадобиться, в отлчие от ...

Mark Barinstein
Кто там из них в продуктиве - не знаю, но похоже, что процесс пошёл, и в этом году мы услышим, что там получается...

в блоге одна запись 10 месяцев назад, похоже он заброшен. сайт поглядим, но с ходу все интересное зарыто. доступны лишь рекламные буклетики ибм, реальных тестов sap-sd parallel по прежнему нет.

Mark Barinstein
tpc-c же для тестов RAC использовать глупо - база слишком хорошо партиционируется.
Если вы посмотрите, в каком режиме там RAC используется, то в реальной жизни вы вряд ли найдёте системы, где оно в таком виде используется.

какая-нибудь регистрация показаний вполне может быть похожей на tpc-c, но тут было бы очень занятно посмотреть как бы справился purescale. каждая нода RAC в tpc-c свой партишен, который не пересекается с другой нодой, соответственно трафик минимальный и масштабируемость практически линейная. у purescale такой фокус не пройдет, придется дергать локлист на каждый чих. думаю по этому мы никогда не увидим purescale в tpc-c.
26 июл 11, 03:17    [11025987]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
distributed computing
Guest
Yo.!
Mark Barinstein
tpc-c же для тестов RAC использовать глупо - база слишком хорошо партиционируется.
Если вы посмотрите, в каком режиме там RAC используется, то в реальной жизни вы вряд ли найдёте системы, где оно в таком виде используется.

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

И какой прикол тут от shared disk/everything RAC если хорошая масштабируемость получается только при партишинге данных под каждую ноду и минимальном взаимодействии нодов?
Где тут плюсы от shred disk, cache fusion(shared memory) и distributed computing(shared cpu)?
26 июл 11, 04:16    [11026005]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
Yo.!
Guest
distributed computing
И какой прикол тут от shared disk/everything RAC если хорошая масштабируемость получается только при партишинге данных под каждую ноду и минимальном взаимодействии нодов?
Где тут плюсы от shred disk, cache fusion(shared memory) и distributed computing(shared cpu)?

плюсы в цене решений. RAC тебе может заменить p570 и его дубль за несколько миллионов несколькими x86 машинками, которые будут стоить более чем в 10 раз дешевле. раковые лицензии конечно разрыв сократят, но все равно в разы дешевле выходит.
26 июл 11, 04:35    [11026011]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
Mark Barinstein,

Почитал вот про Anixter. Очень интересно.

1) У них 3 сервера, которые они объединяют в кластер. А, если я правильно понимаю, pureScale требует выделить как минимум 2 узла под блокировки. Т.е. в их ситуации получился бы 1 рабочий узел и 2 надсмотрщика. Я так понимаю, они вышли из ситуации, отпилив на каждом физическом узле виртуальную машины на 2 ядра и там подняли управление блокировками. 1/3 ядер в кластере у них занимается исключительно блокировками.

2) Что-то я ничего у них не услышал про standby. Они так гордятся отказоустойчивостью своего кластера, что даже не думают создавать резерв в другом датацентре, что наводит на мысль, что от нас что-то скрывают. Как там с поддержкой HADR? Можно какую-нибудь ссылку на официальную документацию?

3) Кстати, как там у pureScale c intra-query parallelism? Можно SELECT сделать, чтобы он по узлам расползся? Ну или индекс в параллели перестроить? Или backup в параллели одновременно на всех узлах запустить?
26 июл 11, 10:20    [11026478]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
все очень красиво
У Oracle очень хорошая маркетинговая политика, выглядит все очень красиво.

У Оракла вообще много чего очень хорошего.
ДБ2 - тоже выглядит красиво - брэнд реальный. Вот тока тут на форуме были мыстли, что для ОЛТП у IBM Информкис его типа вытеснит, а он де в основном под хранилища пойдет. Учитывая, что есть специализированные для хранилищ, которые типа по тестам TPC-H значительно превосходят и Оракла и ДБ2, так и не понятно картина в целом про будущее ДБ2.
26 июл 11, 14:03    [11028142]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
distributed computing
Guest
Yo.!
distributed computing
И какой прикол тут от shared disk/everything RAC если хорошая масштабируемость получается только при партишинге данных под каждую ноду и минимальном взаимодействии нодов?
Где тут плюсы от shred disk, cache fusion(shared memory) и distributed computing(shared cpu)?

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

Это не уникальный плюс, это может и shared nothing. Он также дешевле и так же отлично масштабируется при партишинге и минимальном взаимодействии нодов. RAC не получает плюсов от shared disk, cache fusion(shared memory) и distributed computing(shared cpu). Т.е. вроде технологии и есть, но когда начинается их использование то ни о какой масштабируемости речи не идет.
shred disk - можно обратиться к одному и тому же блоку на диске, но увеличивается очередь, и лучше бы этого не делали
cache fusion(shared memory) - можно обратиться за версией к соседнему ноду, но сетевой трафик и взаимодействие нодов увеличиваются, и лучше бы этого не делали

С одной стороны в АБС - где бы они могли пригодиться они не дают масштабирования.
С другой стороны в хранилищах и системах регистрации можно обойтись и без них, т.к. отлично масштабируется и на shared nothing.
Хранилища и системы регистрации отлично работают без shared disk и cache fusion(shared memory), мало того последние даже вредны из-за конкуренции за диски и увеличения сетевого трафика.
26 июл 11, 15:40    [11029034]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
distributed computing,

Слова не мужа, но юнца. Уж очень категорично. В этом плане даже интереснее разговаривать с коллегами из IBM - уж извините.

1) Если есть возможность применить shared-nothing, то это хорошо. Но область применимости этой технологии практически не пересекается с применимостью shared-disk. Я слабо представляю себе OLTP-систему крупного ритейлера, банка или телеком-оператора, работающую на shared-nothing.

2) АБС не масштабируется на RAC? Я здесь не специалист, но, думаю, что большинство online-операций можно разнести на узлы по филиалам. Пакетные операции также отлично масштабируются за счет intra-query параллелизма.

3) Что касается использования сети, то еще 5 лет назад у нас прекрасно работал кластер из 4х узлов поверх оптики со скоростью 2 Гб. Больше наращивать было тяжело, потому как увеличивалась задержка. В случае использования Infiniband (возьмите ту же Exadata) - латентность резко снижается, а пропускная способность растет до 40 Гб по одному проводу.

4) "можно обратиться к одному и тому же блоку на диске, но увеличивается очередь" - а вы имели дело только с внутренними дисками серверов? Есть такая классная штука - называется хранилище. В них есть flash-кэш и память, которые повышают количество IOPS. В случае той же Exadata - вполне себе 1.500.000 IOPS работает. А Exadata ведь тоже кластер.
26 июл 11, 16:12    [11029290]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
Yo.!
Guest
distributed computing
Это не уникальный плюс, это может и shared nothing. Он также дешевле и так же отлично масштабируется при партишинге и минимальном взаимодействии нодов.

как раз уникальный, потому как в отличие от shared-nothing тянет и реальные OLTP нагрузки, а не только идеально партицированные. т.е. работает у реальных клиентов на реальных OLTP.

distributed computing
RAC не получает плюсов от shared disk, cache fusion(shared memory) и distributed computing(shared cpu). Т.е. вроде технологии и есть, но когда начинается их использование то ни о какой масштабируемости речи не идет.

а если отвлечься от фантазий и трезво взглянуть на реальность ?
http://www.sap.com/solutions/benchmark/pdf/Cert08013.pdf
5 нод в тесте sap-sd, т.е. на вполне реальной задаче. такие же тесты есть OEBS, Зибель, да даже под 1с есть и тесты и реальные клиенты. т.е. в суровой действительности RAC работает и масштабируется на достаточно широком круге задач, чего shared-nothing не дано. отсюда и потуги с pureScale у IBM

distributed computing
С одной стороны в АБС - где бы они могли пригодиться они не дают масштабирования.

что же вы вендоров то не оповестили ? а то кого не возьми - решения под RAC имеются. причем не в рекламных буклетиках, а у реальных клиентов. как же так ?
26 июл 11, 16:29    [11029420]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
Yo.!
Guest
Alexander Ryndin
Mark Barinstein,

Почитал вот про Anixter. Очень интересно.

1) У них 3 сервера, которые они объединяют в кластер. А, если я правильно понимаю, pureScale требует выделить как минимум 2 узла под блокировки. Т.е. в их ситуации получился бы 1 рабочий узел и 2 надсмотрщика. Я так понимаю, они вышли из ситуации, отпилив на каждом физическом узле виртуальную машины на 2 ядра и там подняли управление блокировками. 1/3 ядер в кластере у них занимается исключительно блокировками.

2) Что-то я ничего у них не услышал про standby. Они так гордятся отказоустойчивостью своего кластера, что даже не думают создавать резерв в другом датацентре, что наводит на мысль, что от нас что-то скрывают. Как там с поддержкой HADR? Можно какую-нибудь ссылку на официальную документацию?

3) Кстати, как там у pureScale c intra-query parallelism? Можно SELECT сделать, чтобы он по узлам расползся? Ну или индекс в параллели перестроить? Или backup в параллели одновременно на всех узлах запустить?


1. там всего две ноды субд, третий это апп сервер. на каждой ноде в довесок надсмоторщик
2. HADR не умеет с pureScale, в будущем планируют интегрировать
3. тут можно посмотреть
http://www.oracle.com/technetwork/database/features/availability/cwp-ha-oracle11gr2-db2-9-131679.pdf
26 июл 11, 16:47    [11029585]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Yo.!
distributed computing
Это не уникальный плюс, это может и shared nothing. Он также дешевле и так же отлично масштабируется при партишинге и минимальном взаимодействии нодов.

как раз уникальный, потому как в отличие от shared-nothing тянет и реальные OLTP нагрузки, а не только идеально партицированные. т.е. работает у реальных клиентов на реальных OLTP.

distributed computing
RAC не получает плюсов от shared disk, cache fusion(shared memory) и distributed computing(shared cpu). Т.е. вроде технологии и есть, но когда начинается их использование то ни о какой масштабируемости речи не идет.

а если отвлечься от фантазий и трезво взглянуть на реальность ?
http://www.sap.com/solutions/benchmark/pdf/Cert08013.pdf
5 нод в тесте sap-sd, т.е. на вполне реальной задаче. такие же тесты есть OEBS, Зибель, да даже под 1с есть и тесты и реальные клиенты. т.е. в суровой действительности RAC работает и масштабируется на достаточно широком круге задач, чего shared-nothing не дано. отсюда и потуги с pureScale у IBM

distributed computing
С одной стороны в АБС - где бы они могли пригодиться они не дают масштабирования.

что же вы вендоров то не оповестили ? а то кого не возьми - решения под RAC имеются. причем не в рекламных буклетиках, а у реальных клиентов. как же так ?
не приведете примеры реальных клиентов-банков?
26 июл 11, 16:57    [11029660]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
Yo.!
Guest
SergSuper
не приведете примеры реальных клиентов-банков?

сходу банк москвы, на сайте оракла целый раздел банковский сектор на RAC помню
26 июл 11, 17:00    [11029687]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
Yo.!
Alexander Ryndin
1) У них 3 сервера, которые они объединяют в кластер. А, если я правильно понимаю, pureScale требует выделить как минимум 2 узла под блокировки. Т.е. в их ситуации получился бы 1 рабочий узел и 2 надсмотрщика. Я так понимаю, они вышли из ситуации, отпилив на каждом физическом узле виртуальную машины на 2 ядра и там подняли управление блокировками. 1/3 ядер в кластере у них занимается исключительно блокировками.

1. там всего две ноды субд, третий это апп сервер. на каждой ноде в довесок надсмоторщик
Ну вот фраза из Case Study:
автор
Nine cores per server will be dedicated to DB2 pureScale and two to the IBM DB2 cluster caching facility, which manages the cache and locks.
Вообще странно. 11 ядер в сумме :) В общем мутный пример.
26 июл 11, 17:08    [11029754]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
Ggg_old
Member

Откуда: Одесса
Сообщений: 1342
RAC то используют, но выигрыш основной не в масштабировании. а в отказоустойчивости. Для производителя - это клиент RAC, но в деталях есть ньюансы. Об это и говорил. А в итоге крупнейшие западные финансовые институты масштабируются простым и незатейливым способом - покупкой большого железа и в итоге приходят на поклон к великому мэйнфрему.
26 июл 11, 17:10    [11029773]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
distributed computing
Guest
Alexander Ryndin
distributed computing,

Слова не мужа, но юнца. Уж очень категорично. В этом плане даже интереснее разговаривать с коллегами из IBM - уж извините.

1) Если есть возможность применить shared-nothing, то это хорошо. Но область применимости этой технологии практически не пересекается с применимостью shared-disk. Я слабо представляю себе OLTP-систему крупного ритейлера, банка или телеком-оператора, работающую на shared-nothing.

2) АБС не масштабируется на RAC? Я здесь не специалист, но, думаю, что большинство online-операций можно разнести на узлы по филиалам. Пакетные операции также отлично масштабируются за счет intra-query параллелизма.

3) Что касается использования сети, то еще 5 лет назад у нас прекрасно работал кластер из 4х узлов поверх оптики со скоростью 2 Гб. Больше наращивать было тяжело, потому как увеличивалась задержка. В случае использования Infiniband (возьмите ту же Exadata) - латентность резко снижается, а пропускная способность растет до 40 Гб по одному проводу.

4) "можно обратиться к одному и тому же блоку на диске, но увеличивается очередь" - а вы имели дело только с внутренними дисками серверов? Есть такая классная штука - называется хранилище. В них есть flash-кэш и память, которые повышают количество IOPS. В случае той же Exadata - вполне себе 1.500.000 IOPS работает. А Exadata ведь тоже кластер.

1.
Для OLTP - существуют мейнфреймы, тут RAC вообще не конкурент.
Для DSS - shared nothing.
RAC на обочине эволюции вместе с его нервными пользователями.

2. Не знаете, так спросите у знающих людей
Ggg_old
к сожалению RAC не дает никаких преимуществ по масштабированию в банковских системах и используется только в основном для отказоустойчивости. Это со слов украиннских АБСо-делов. И не удивительно, Банковские бд плохо логичеки параллелятся, любая транзакция сильно задевает много объектов а базе, данные сильносвязанны.
Кстати не слышно не только про purescale но и за ASE shared cluster, который появился пораньше.


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

4. Вы вообще понимаете о чем говорите? Если один и тот же блок хотят записать два раза то время на эти операции будет в 2 раза больше чем записать 1 раз. Как раз таки на SSD это будет очень заметно, т.к. они строятся по внутреннему RAID0 и запись разных блоков параллелиться, а запись одного выстраивается в очередь.
У вас просто каша в голове.
26 июл 11, 17:24    [11029877]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
distributed computing
Guest
Yo.!
distributed computing
Это не уникальный плюс, это может и shared nothing. Он также дешевле и так же отлично масштабируется при партишинге и минимальном взаимодействии нодов.

как раз уникальный, потому как в отличие от shared-nothing тянет и реальные OLTP нагрузки, а не только идеально партицированные. т.е. работает у реальных клиентов на реальных OLTP.

Интересно, какие у вас из OLTP систем тянет RAC: sap-sd, OEBS, зибель, что именно у вас так отлично работает?

Вот у людей ничего из OLTP не тянет RAC.
Ggg_old
к сожалению RAC не дает никаких преимуществ по масштабированию в банковских системах и используется только в основном для отказоустойчивости. Это со слов украиннских АБСо-делов. И не удивительно, Банковские бд плохо логичеки параллелятся, любая транзакция сильно задевает много объектов а базе, данные сильносвязанны.
Кстати не слышно не только про purescale но и за ASE shared cluster, который появился пораньше.

Что на это скажете?

Yo.!
distributed computing
С одной стороны в АБС - где бы они могли пригодиться они не дают масштабирования.

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

Вы так наивны и думаете оракл не мог дать им очень хорошую скидку в рекламных то целях, что им лицензии RAC почти ничего не стоили?
26 июл 11, 17:29    [11029915]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
узлы RAC разносим по филлиалам
Guest
Alexander Ryndin
2) АБС не масштабируется на RAC? Я здесь не специалист, но, думаю, что большинство online-операций можно разнести на узлы по филиалам.

Это вообще жесть
26 июл 11, 17:34    [11029947]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
distributed computing
Вот у людей ничего из OLTP не тянет RAC.
Ggg_old
к сожалению RAC не дает никаких преимуществ по масштабированию в банковских системах и используется только в основном для отказоустойчивости. Это со слов украиннских АБСо-делов. И не удивительно, Банковские бд плохо логичеки параллелятся, любая транзакция сильно задевает много объектов а базе, данные сильносвязанны.
Кстати не слышно не только про purescale но и за ASE shared cluster, который появился пораньше.

Что на это скажете?
Чооорт! Украинские АБСники не смогли заставить работать свою АБС (кстати, про какую АБС идет речь?) на RAC.
А в Вилла-Баджо ЦФТ уже пьют пиво и лапают сисястых девок
26 июл 11, 17:42    [11029995]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
узлы RAC разносим по филлиалам
Alexander Ryndin
2) АБС не масштабируется на RAC? Я здесь не специалист, но, думаю, что большинство online-операций можно разнести на узлы по филиалам.

Это вообще жесть
Для тех кто в танке - я говорил про централизованную АБС. Когда одна СУБД обслуживает всю страну.
26 июл 11, 17:43    [11030001]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
узлы RAC разносим по филлиалам
Alexander Ryndin
2) АБС не масштабируется на RAC? Я здесь не специалист, но, думаю, что большинство online-операций можно разнести на узлы по филиалам.

Это вообще жесть

дурочка из себя корчишь? ну-ну...

Другой дело, что по узлам РАКа можно разнести подключения и пакетные задания, вот как будут выполняться сами операции: изолированно в рамках одного лишь узла или все же потребуется межнодное взаимодействие - это уже вопрос характера приложения.
26 июл 11, 17:45    [11030011]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
Yo.!
Guest
Ggg_old
RAC то используют, но выигрыш основной не в масштабировании. а в отказоустойчивости. Для производителя - это клиент RAC, но в деталях есть ньюансы. Об это и говорил. А в итоге крупнейшие западные финансовые институты масштабируются простым и незатейливым способом - покупкой большого железа и в итоге приходят на поклон к великому мэйнфрему.

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

2Alexander Ryndin

а откуда "Case Study" ? я в презенташке только картинку с двумя х3850 и пояснение что там по 8 ядер
26 июл 11, 17:50    [11030045]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
Alexander Ryndin
узлы RAC разносим по филлиалам
пропущено...

Это вообще жесть
Для тех кто в танке - я говорил про централизованную АБС. Когда одна СУБД обслуживает всю страну.

Обычно с таким подходом добавляется много головняков админам, т.к. нагрузку желательно распределить равномерно и распределение это получается ручное. Есть одна компания, производящая биллинговые системы, так вот они там примерно таким путем и пошли: часть бизнес-процессов на одной ноде, часть на другой, т.к. с их прикладом другого выбора просто не было, иначе не взлетело бы. Они даже протестировали ее на двух узлах Sun M9000 (или что-то вроде того, не помню уже), тестирование было признано успешным. По-моему единственные экстремалы-клиенты, которые и до этого использовали RAC для их биллинга до сих пор остались в гордом одиночестве, доставляя тем самым саппорту биллинго-делов немало головняков, а порой и лулзов.
Так что... чего бы там не говорили, а ПО все равно надо адаптировать для кластерных решений, ибо плохо написанное будет работать еще хуже, чем до этого.
26 июл 11, 17:51    [11030053]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
Apex
узлы RAC разносим по филлиалам
пропущено...

Это вообще жесть

дурочка из себя корчишь? ну-ну...

Другой дело, что по узлам РАКа можно разнести подключения и пакетные задания, вот как будут выполняться сами операции: изолированно в рамках одного лишь узла или все же потребуется межнодное взаимодействие - это уже вопрос характера приложения.
Ну я то об этом и говорю. Если есть возможность локализовать операции и минимизировать взаимодействие между узлами, то это идеально. Вариантов много: каждый регион или каждое подразделение может работать на своем узле. А вот вынесение пакетного задания, если оно изменяет те же данные что и OLTP на другой узел, может и не помочь.

Но я также не понимаю, почему все так боятся этого межузлового трафика в OLTP? Ведь Cache Fusion на то и придуман, что он гоняет блоки между кэшами узлов по интерконнекту, а не через диск. Поэтому интерконнект должен иметь 1) высокую пропускную способность и 2) низкую задержку. Второе даже важнее. Следовательно, кластер очень сильно выигрывает от использования Infiniband - там задержка на 1 хоп порядка 2 микросекунд проти 500 микросекунд в Ethernet
26 июл 11, 18:02    [11030121]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
Yo.!
2Alexander Ryndin
а откуда "Case Study" ? я в презенташке только картинку с двумя х3850 и пояснение что там по 8 ядер
Вот
26 июл 11, 18:09    [11030150]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить