powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Как бы независимое сравнение DB2 и Oracle
25 сообщений из 136, страница 2 из 6
Как бы независимое сравнение DB2 и Oracle
    #37366613
Alexander Ryndin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Mark Barinstein,

А правильно ли я понимаю, что DB2 осуществляет блокировки на уровне страницы? Или это свойство только pureScale? Или я вообще ошибаюсь?
...
Рейтинг: 0 / 0
Как бы независимое сравнение DB2 и Oracle
    #37366621
Senya_L
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Yo.!Mark BarinsteinДа откуда же вы знаете, кисло у IBM с этим, мелко или мягко?
Не упирается оно в "громадный" трафик.
Я уже просил вас, кажется, не писать о том в DB2, о чём вы ни малейшего представления не имеете.

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

Модератор: остальное потер
в следующий раз еще и забаню
...
Рейтинг: 0 / 0
Как бы независимое сравнение DB2 и Oracle
    #37366710
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Mark BarinsteinНу, ораклу надо же как-то по этому поводу высказаться, вот он и пишет.
Хотя надо было задуматься, как это одна и та же архитектура без особых принципиальных различий на мэйнфреймах уже много лет работает (и совсем неплохо работает), а на intel/power будет затыкаться.

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

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

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

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

Mark Barinsteintpc-c же для тестов RAC использовать глупо - база слишком хорошо партиционируется.
Если вы посмотрите, в каком режиме там RAC используется, то в реальной жизни вы вряд ли найдёте системы, где оно в таком виде используется.
какая-нибудь регистрация показаний вполне может быть похожей на tpc-c, но тут было бы очень занятно посмотреть как бы справился purescale. каждая нода RAC в tpc-c свой партишен, который не пересекается с другой нодой, соответственно трафик минимальный и масштабируемость практически линейная. у purescale такой фокус не пройдет, придется дергать локлист на каждый чих. думаю по этому мы никогда не увидим purescale в tpc-c.
...
Рейтинг: 0 / 0
Как бы независимое сравнение DB2 и Oracle
    #37366724
Yo.!Mark Barinsteintpc-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)?
...
Рейтинг: 0 / 0
Как бы независимое сравнение DB2 и Oracle
    #37366727
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
distributed computingИ какой прикол тут от shared disk/everything RAC если хорошая масштабируемость получается только при партишинге данных под каждую ноду и минимальном взаимодействии нодов?
Где тут плюсы от shred disk, cache fusion(shared memory) и distributed computing(shared cpu)?
плюсы в цене решений. RAC тебе может заменить p570 и его дубль за несколько миллионов несколькими x86 машинками, которые будут стоить более чем в 10 раз дешевле. раковые лицензии конечно разрыв сократят, но все равно в разы дешевле выходит.
...
Рейтинг: 0 / 0
Как бы независимое сравнение DB2 и Oracle
    #37366887
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 в параллели одновременно на всех узлах запустить?
...
Рейтинг: 0 / 0
Как бы независимое сравнение DB2 и Oracle
    #37367333
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
все очень красивоУ Oracle очень хорошая маркетинговая политика, выглядит все очень красиво.
У Оракла вообще много чего очень хорошего.
ДБ2 - тоже выглядит красиво - брэнд реальный. Вот тока тут на форуме были мыстли, что для ОЛТП у IBM Информкис его типа вытеснит, а он де в основном под хранилища пойдет. Учитывая, что есть специализированные для хранилищ, которые типа по тестам TPC-H значительно превосходят и Оракла и ДБ2, так и не понятно картина в целом про будущее ДБ2.
...
Рейтинг: 0 / 0
Как бы независимое сравнение DB2 и Oracle
    #37367576
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), мало того последние даже вредны из-за конкуренции за диски и увеличения сетевого трафика.
...
Рейтинг: 0 / 0
Как бы независимое сравнение DB2 и Oracle
    #37367647
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 ведь тоже кластер.
...
Рейтинг: 0 / 0
Как бы независимое сравнение DB2 и Oracle
    #37367688
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
distributed computingЭто не уникальный плюс, это может и shared nothing. Он также дешевле и так же отлично масштабируется при партишинге и минимальном взаимодействии нодов.

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

distributed computingRAC не получает плюсов от 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 имеются. причем не в рекламных буклетиках, а у реальных клиентов. как же так ?
...
Рейтинг: 0 / 0
Как бы независимое сравнение DB2 и Oracle
    #37367745
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Alexander RyndinMark 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
...
Рейтинг: 0 / 0
Как бы независимое сравнение DB2 и Oracle
    #37367776
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Yo.!distributed computingЭто не уникальный плюс, это может и shared nothing. Он также дешевле и так же отлично масштабируется при партишинге и минимальном взаимодействии нодов.

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

distributed computingRAC не получает плюсов от 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 имеются. причем не в рекламных буклетиках, а у реальных клиентов. как же так ?не приведете примеры реальных клиентов-банков?
...
Рейтинг: 0 / 0
Как бы независимое сравнение DB2 и Oracle
    #37367789
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
SergSuperне приведете примеры реальных клиентов-банков?
сходу банк москвы, на сайте оракла целый раздел банковский сектор на RAC помню
...
Рейтинг: 0 / 0
Как бы независимое сравнение DB2 и Oracle
    #37367822
Alexander Ryndin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Yo.!Alexander Ryndin1) У них 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 ядер в сумме :) В общем мутный пример.
...
Рейтинг: 0 / 0
Как бы независимое сравнение DB2 и Oracle
    #37367829
Фотография Ggg_old
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RAC то используют, но выигрыш основной не в масштабировании. а в отказоустойчивости. Для производителя - это клиент RAC, но в деталях есть ньюансы. Об это и говорил. А в итоге крупнейшие западные финансовые институты масштабируются простым и незатейливым способом - покупкой большого железа и в итоге приходят на поклон к великому мэйнфрему.
...
Рейтинг: 0 / 0
Как бы независимое сравнение DB2 и Oracle
    #37367858
Alexander Ryndindistributed 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 и запись разных блоков параллелиться, а запись одного выстраивается в очередь.
У вас просто каша в голове.
...
Рейтинг: 0 / 0
Как бы независимое сравнение DB2 и Oracle
    #37367871
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 почти ничего не стоили?
...
Рейтинг: 0 / 0
Как бы независимое сравнение DB2 и Oracle
    #37367879
Alexander Ryndin2) АБС не масштабируется на RAC? Я здесь не специалист, но, думаю, что большинство online-операций можно разнести на узлы по филиалам .

Это вообще жесть
...
Рейтинг: 0 / 0
Как бы независимое сравнение DB2 и Oracle
    #37367893
Alexander Ryndin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
distributed computingВот у людей ничего из OLTP не тянет RAC.
Ggg_oldк сожалению RAC не дает никаких преимуществ по масштабированию в банковских системах и используется только в основном для отказоустойчивости. Это со слов украиннских АБСо-делов. И не удивительно, Банковские бд плохо логичеки параллелятся, любая транзакция сильно задевает много объектов а базе, данные сильносвязанны.
Кстати не слышно не только про purescale но и за ASE shared cluster, который появился пораньше.
Что на это скажете?Чооорт! Украинские АБСники не смогли заставить работать свою АБС (кстати, про какую АБС идет речь?) на RAC.
А в Вилла-Баджо ЦФТ уже пьют пиво и лапают сисястых девок
...
Рейтинг: 0 / 0
Как бы независимое сравнение DB2 и Oracle
    #37367895
Alexander Ryndin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
узлы RAC разносим по филлиаламAlexander Ryndin2) АБС не масштабируется на RAC? Я здесь не специалист, но, думаю, что большинство online-операций можно разнести на узлы по филиалам .

Это вообще жесть Для тех кто в танке - я говорил про централизованную АБС. Когда одна СУБД обслуживает всю страну.
...
Рейтинг: 0 / 0
Как бы независимое сравнение DB2 и Oracle
    #37367897
Фотография Apex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
узлы RAC разносим по филлиаламAlexander Ryndin2) АБС не масштабируется на RAC? Я здесь не специалист, но, думаю, что большинство online-операций можно разнести на узлы по филиалам .

Это вообще жесть
дурочка из себя корчишь? ну-ну...

Другой дело, что по узлам РАКа можно разнести подключения и пакетные задания, вот как будут выполняться сами операции: изолированно в рамках одного лишь узла или все же потребуется межнодное взаимодействие - это уже вопрос характера приложения.
...
Рейтинг: 0 / 0
Как бы независимое сравнение DB2 и Oracle
    #37367909
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Ggg_oldRAC то используют, но выигрыш основной не в масштабировании. а в отказоустойчивости. Для производителя - это клиент RAC, но в деталях есть ньюансы. Об это и говорил. А в итоге крупнейшие западные финансовые институты масштабируются простым и незатейливым способом - покупкой большого железа и в итоге приходят на поклон к великому мэйнфрему.
что у вы понимаете под масштабируемости ? вы пеняете ораклу, что тот из четырех нод на 8 cpu не уделывает одну железку из 32 cpu ? ну извени, на это глупо было бы рассчитывать.
отказоустойчевость HADR выше кластера, но все равно берут RAC, потому как решение с на RAC дешевле.

2Alexander Ryndin

а откуда "Case Study" ? я в презенташке только картинку с двумя х3850 и пояснение что там по 8 ядер
...
Рейтинг: 0 / 0
Как бы независимое сравнение DB2 и Oracle
    #37367911
Фотография Apex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexander Ryndinузлы RAC разносим по филлиалампропущено...

Это вообще жесть Для тех кто в танке - я говорил про централизованную АБС. Когда одна СУБД обслуживает всю страну.
Обычно с таким подходом добавляется много головняков админам, т.к. нагрузку желательно распределить равномерно и распределение это получается ручное. Есть одна компания, производящая биллинговые системы, так вот они там примерно таким путем и пошли: часть бизнес-процессов на одной ноде, часть на другой, т.к. с их прикладом другого выбора просто не было, иначе не взлетело бы. Они даже протестировали ее на двух узлах Sun M9000 (или что-то вроде того, не помню уже), тестирование было признано успешным. По-моему единственные экстремалы-клиенты, которые и до этого использовали RAC для их биллинга до сих пор остались в гордом одиночестве, доставляя тем самым саппорту биллинго-делов немало головняков, а порой и лулзов.
Так что... чего бы там не говорили, а ПО все равно надо адаптировать для кластерных решений, ибо плохо написанное будет работать еще хуже, чем до этого.
...
Рейтинг: 0 / 0
Как бы независимое сравнение DB2 и Oracle
    #37367929
Alexander Ryndin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Apexузлы RAC разносим по филлиалампропущено...

Это вообще жесть
дурочка из себя корчишь? ну-ну...

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

Но я также не понимаю, почему все так боятся этого межузлового трафика в OLTP? Ведь Cache Fusion на то и придуман, что он гоняет блоки между кэшами узлов по интерконнекту, а не через диск. Поэтому интерконнект должен иметь 1) высокую пропускную способность и 2) низкую задержку. Второе даже важнее. Следовательно, кластер очень сильно выигрывает от использования Infiniband - там задержка на 1 хоп порядка 2 микросекунд проти 500 микросекунд в Ethernet
...
Рейтинг: 0 / 0
Как бы независимое сравнение DB2 и Oracle
    #37367939
Alexander Ryndin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Yo.!2Alexander Ryndin
а откуда "Case Study" ? я в презенташке только картинку с двумя х3850 и пояснение что там по 8 ядер Вот
...
Рейтинг: 0 / 0
25 сообщений из 136, страница 2 из 6
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Как бы независимое сравнение DB2 и Oracle
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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