|
|
|
Как бы независимое сравнение DB2 и Oracle
|
|||
|---|---|---|---|
|
#18+
Mark Barinstein, А правильно ли я понимаю, что DB2 осуществляет блокировки на уровне страницы? Или это свойство только pureScale? Или я вообще ошибаюсь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.07.2011, 23:20 |
|
||
|
Как бы независимое сравнение DB2 и Oracle
|
|||
|---|---|---|---|
|
#18+
Yo.!Mark BarinsteinДа откуда же вы знаете, кисло у IBM с этим, мелко или мягко? Не упирается оно в "громадный" трафик. Я уже просил вас, кажется, не писать о том в DB2, о чём вы ни малейшего представления не имеете. помниться лет 7 назад мне тут точно так же указывали фаны майкрософт, что я "ни малейшего представления" не имею о блокировочниках, расписывая достоинства версионников. a потом майкрософте появился IL snapshot и заметте, возразить по существу вам нечем ...Демагог... Модератор: остальное потер в следующий раз еще и забаню ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.07.2011, 23:31 |
|
||
|
Как бы независимое сравнение DB2 и Oracle
|
|||
|---|---|---|---|
|
#18+
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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2011, 03:17 |
|
||
|
Как бы независимое сравнение DB2 и Oracle
|
|||
|---|---|---|---|
|
#18+
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)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2011, 04:16 |
|
||
|
Как бы независимое сравнение DB2 и Oracle
|
|||
|---|---|---|---|
|
#18+
distributed computingИ какой прикол тут от shared disk/everything RAC если хорошая масштабируемость получается только при партишинге данных под каждую ноду и минимальном взаимодействии нодов? Где тут плюсы от shred disk, cache fusion(shared memory) и distributed computing(shared cpu)? плюсы в цене решений. RAC тебе может заменить p570 и его дубль за несколько миллионов несколькими x86 машинками, которые будут стоить более чем в 10 раз дешевле. раковые лицензии конечно разрыв сократят, но все равно в разы дешевле выходит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2011, 04:35 |
|
||
|
Как бы независимое сравнение DB2 и Oracle
|
|||
|---|---|---|---|
|
#18+
Mark Barinstein, Почитал вот про Anixter. Очень интересно. 1) У них 3 сервера, которые они объединяют в кластер. А, если я правильно понимаю, pureScale требует выделить как минимум 2 узла под блокировки. Т.е. в их ситуации получился бы 1 рабочий узел и 2 надсмотрщика. Я так понимаю, они вышли из ситуации, отпилив на каждом физическом узле виртуальную машины на 2 ядра и там подняли управление блокировками. 1/3 ядер в кластере у них занимается исключительно блокировками. 2) Что-то я ничего у них не услышал про standby. Они так гордятся отказоустойчивостью своего кластера, что даже не думают создавать резерв в другом датацентре, что наводит на мысль, что от нас что-то скрывают. Как там с поддержкой HADR? Можно какую-нибудь ссылку на официальную документацию? 3) Кстати, как там у pureScale c intra-query parallelism? Можно SELECT сделать, чтобы он по узлам расползся? Ну или индекс в параллели перестроить? Или backup в параллели одновременно на всех узлах запустить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2011, 10:20 |
|
||
|
Как бы независимое сравнение DB2 и Oracle
|
|||
|---|---|---|---|
|
#18+
все очень красивоУ Oracle очень хорошая маркетинговая политика, выглядит все очень красиво. У Оракла вообще много чего очень хорошего. ДБ2 - тоже выглядит красиво - брэнд реальный. Вот тока тут на форуме были мыстли, что для ОЛТП у IBM Информкис его типа вытеснит, а он де в основном под хранилища пойдет. Учитывая, что есть специализированные для хранилищ, которые типа по тестам TPC-H значительно превосходят и Оракла и ДБ2, так и не понятно картина в целом про будущее ДБ2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2011, 14:03 |
|
||
|
Как бы независимое сравнение DB2 и Oracle
|
|||
|---|---|---|---|
|
#18+
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.07.2011, 15:40 |
|
||
|
Как бы независимое сравнение DB2 и Oracle
|
|||
|---|---|---|---|
|
#18+
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.07.2011, 16:12 |
|
||
|
Как бы независимое сравнение DB2 и Oracle
|
|||
|---|---|---|---|
|
#18+
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 имеются. причем не в рекламных буклетиках, а у реальных клиентов. как же так ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2011, 16:29 |
|
||
|
Как бы независимое сравнение DB2 и Oracle
|
|||
|---|---|---|---|
|
#18+
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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2011, 16:47 |
|
||
|
Как бы независимое сравнение DB2 и Oracle
|
|||
|---|---|---|---|
|
#18+
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 имеются. причем не в рекламных буклетиках, а у реальных клиентов. как же так ?не приведете примеры реальных клиентов-банков? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2011, 16:57 |
|
||
|
Как бы независимое сравнение DB2 и Oracle
|
|||
|---|---|---|---|
|
#18+
SergSuperне приведете примеры реальных клиентов-банков? сходу банк москвы, на сайте оракла целый раздел банковский сектор на RAC помню ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2011, 17:00 |
|
||
|
Как бы независимое сравнение DB2 и Oracle
|
|||
|---|---|---|---|
|
#18+
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 ядер в сумме :) В общем мутный пример. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2011, 17:08 |
|
||
|
Как бы независимое сравнение DB2 и Oracle
|
|||
|---|---|---|---|
|
#18+
RAC то используют, но выигрыш основной не в масштабировании. а в отказоустойчивости. Для производителя - это клиент RAC, но в деталях есть ньюансы. Об это и говорил. А в итоге крупнейшие западные финансовые институты масштабируются простым и незатейливым способом - покупкой большого железа и в итоге приходят на поклон к великому мэйнфрему. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2011, 17:10 |
|
||
|
Как бы независимое сравнение DB2 и Oracle
|
|||
|---|---|---|---|
|
#18+
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 и запись разных блоков параллелиться, а запись одного выстраивается в очередь. У вас просто каша в голове. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2011, 17:24 |
|
||
|
Как бы независимое сравнение DB2 и Oracle
|
|||
|---|---|---|---|
|
#18+
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.07.2011, 17:29 |
|
||
|
Как бы независимое сравнение DB2 и Oracle
|
|||
|---|---|---|---|
|
#18+
Alexander Ryndin2) АБС не масштабируется на RAC? Я здесь не специалист, но, думаю, что большинство online-операций можно разнести на узлы по филиалам . Это вообще жесть ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2011, 17:34 |
|
||
|
Как бы независимое сравнение DB2 и Oracle
|
|||
|---|---|---|---|
|
#18+
distributed computingВот у людей ничего из OLTP не тянет RAC. Ggg_oldк сожалению RAC не дает никаких преимуществ по масштабированию в банковских системах и используется только в основном для отказоустойчивости. Это со слов украиннских АБСо-делов. И не удивительно, Банковские бд плохо логичеки параллелятся, любая транзакция сильно задевает много объектов а базе, данные сильносвязанны. Кстати не слышно не только про purescale но и за ASE shared cluster, который появился пораньше. Что на это скажете?Чооорт! Украинские АБСники не смогли заставить работать свою АБС (кстати, про какую АБС идет речь?) на RAC. А в Вилла-Баджо ЦФТ уже пьют пиво и лапают сисястых девок ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2011, 17:42 |
|
||
|
Как бы независимое сравнение DB2 и Oracle
|
|||
|---|---|---|---|
|
#18+
узлы RAC разносим по филлиаламAlexander Ryndin2) АБС не масштабируется на RAC? Я здесь не специалист, но, думаю, что большинство online-операций можно разнести на узлы по филиалам . Это вообще жесть Для тех кто в танке - я говорил про централизованную АБС. Когда одна СУБД обслуживает всю страну. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2011, 17:43 |
|
||
|
Как бы независимое сравнение DB2 и Oracle
|
|||
|---|---|---|---|
|
#18+
узлы RAC разносим по филлиаламAlexander Ryndin2) АБС не масштабируется на RAC? Я здесь не специалист, но, думаю, что большинство online-операций можно разнести на узлы по филиалам . Это вообще жесть дурочка из себя корчишь? ну-ну... Другой дело, что по узлам РАКа можно разнести подключения и пакетные задания, вот как будут выполняться сами операции: изолированно в рамках одного лишь узла или все же потребуется межнодное взаимодействие - это уже вопрос характера приложения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2011, 17:45 |
|
||
|
Как бы независимое сравнение DB2 и Oracle
|
|||
|---|---|---|---|
|
#18+
Ggg_oldRAC то используют, но выигрыш основной не в масштабировании. а в отказоустойчивости. Для производителя - это клиент RAC, но в деталях есть ньюансы. Об это и говорил. А в итоге крупнейшие западные финансовые институты масштабируются простым и незатейливым способом - покупкой большого железа и в итоге приходят на поклон к великому мэйнфрему. что у вы понимаете под масштабируемости ? вы пеняете ораклу, что тот из четырех нод на 8 cpu не уделывает одну железку из 32 cpu ? ну извени, на это глупо было бы рассчитывать. отказоустойчевость HADR выше кластера, но все равно берут RAC, потому как решение с на RAC дешевле. 2Alexander Ryndin а откуда "Case Study" ? я в презенташке только картинку с двумя х3850 и пояснение что там по 8 ядер ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2011, 17:50 |
|
||
|
Как бы независимое сравнение DB2 и Oracle
|
|||
|---|---|---|---|
|
#18+
Alexander Ryndinузлы RAC разносим по филлиалампропущено... Это вообще жесть Для тех кто в танке - я говорил про централизованную АБС. Когда одна СУБД обслуживает всю страну. Обычно с таким подходом добавляется много головняков админам, т.к. нагрузку желательно распределить равномерно и распределение это получается ручное. Есть одна компания, производящая биллинговые системы, так вот они там примерно таким путем и пошли: часть бизнес-процессов на одной ноде, часть на другой, т.к. с их прикладом другого выбора просто не было, иначе не взлетело бы. Они даже протестировали ее на двух узлах Sun M9000 (или что-то вроде того, не помню уже), тестирование было признано успешным. По-моему единственные экстремалы-клиенты, которые и до этого использовали RAC для их биллинга до сих пор остались в гордом одиночестве, доставляя тем самым саппорту биллинго-делов немало головняков, а порой и лулзов. Так что... чего бы там не говорили, а ПО все равно надо адаптировать для кластерных решений, ибо плохо написанное будет работать еще хуже, чем до этого. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2011, 17:51 |
|
||
|
Как бы независимое сравнение DB2 и Oracle
|
|||
|---|---|---|---|
|
#18+
Apexузлы RAC разносим по филлиалампропущено... Это вообще жесть дурочка из себя корчишь? ну-ну... Другой дело, что по узлам РАКа можно разнести подключения и пакетные задания, вот как будут выполняться сами операции: изолированно в рамках одного лишь узла или все же потребуется межнодное взаимодействие - это уже вопрос характера приложения.Ну я то об этом и говорю. Если есть возможность локализовать операции и минимизировать взаимодействие между узлами, то это идеально. Вариантов много: каждый регион или каждое подразделение может работать на своем узле. А вот вынесение пакетного задания, если оно изменяет те же данные что и OLTP на другой узел, может и не помочь. Но я также не понимаю, почему все так боятся этого межузлового трафика в OLTP? Ведь Cache Fusion на то и придуман, что он гоняет блоки между кэшами узлов по интерконнекту, а не через диск. Поэтому интерконнект должен иметь 1) высокую пропускную способность и 2) низкую задержку. Второе даже важнее. Следовательно, кластер очень сильно выигрывает от использования Infiniband - там задержка на 1 хоп порядка 2 микросекунд проти 500 микросекунд в Ethernet ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2011, 18:02 |
|
||
|
Как бы независимое сравнение DB2 и Oracle
|
|||
|---|---|---|---|
|
#18+
Yo.!2Alexander Ryndin а откуда "Case Study" ? я в презенташке только картинку с двумя х3850 и пояснение что там по 8 ядер Вот ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2011, 18:09 |
|
||
|
|

start [/forum/topic.php?fid=35&msg=37366724&tid=1552424]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
59ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
61ms |
get tp. blocked users: |
3ms |
| others: | 243ms |
| total: | 401ms |

| 0 / 0 |
