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

Откуда:
Сообщений: 4919
Блог
Apex
... ПО все равно надо адаптировать для кластерных решений, ибо плохо написанное будет работать еще хуже, чем до этого.
С этим никто и не спорит.
26 июл 11, 18:10    [11030154]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
узлы RAC разносим по филлиалам
Guest
Apex
узлы RAC разносим по филлиалам
пропущено...

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

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

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

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

Но тогда возвращаемся опять к вопросу:
если не нужно межнодовое взаимодействие - это shared nothing, пожалуйста разносите узлы по филлиалам
если нужно межнодовое взаимодействие - это мейнфрейм.

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

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

И все приводят в пример хорошо распараллеленные приложения типа сап-сд, зибель и т.д с партишинами под каждую ноду и с отсутствием сетевого взаимодействия, т.е. те в которых почти не используется ни cache fusion, ни shared disk. А вот кто-нибудь может привести пример приложений в которых они используются?
Т.е. где за счет большого сетевого взаимодействия в RAC получалась бы выгода. Вот это было бы действительно интересно и конструктивно.
26 июл 11, 18:21    [11030215]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
узлы RAC разносим по филлиалам
И что же произойдет если вдруг как обычно характер приложения потребует межнодового взаимодействия?
Когда одному из узлов потребуется блок, измененный на другом узле, этот блок будет передан по интерконнекту. Это однозначно быстрее, чем читать с диска.

В чем проблема то?
26 июл 11, 18:23    [11030221]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
сетевое взаимодействие
Alexander Ryndin
Но я также не понимаю, почему все так боятся этого межузлового трафика в OLTP? Ведь Cache Fusion на то и придуман, что он гоняет блоки между кэшами узлов по интерконнекту, а не через диск. Поэтому интерконнект должен иметь 1) высокую пропускную способность и 2) низкую задержку. Второе даже важнее. Следовательно, кластер очень сильно выигрывает от использования Infiniband - там задержка на 1 хоп порядка 2 микросекунд проти 500 микросекунд в Ethernet

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

И все приводят в пример хорошо распараллеленные приложения типа сап-сд, зибель и т.д с партишинами под каждую ноду и с отсутствием сетевого взаимодействия, т.е. те в которых почти не используется ни cache fusion, ни shared disk. А вот кто-нибудь может привести пример приложений в которых они используются?
Т.е. где за счет большого сетевого взаимодействия в RAC получалась бы выгода. Вот это было бы действительно интересно и конструктивно.
Так я ж и приводил 11029290. 4 узла с линейной масштабируемостью.
Нагрузка полностью смешанная - не было никакого ручного секционирования. Детали вот тут. ERP - Axapta, которая, сами понимаете, ну никак не заточена под кластер.
26 июл 11, 18:31    [11030257]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
интерконнекту между филлиалами
Guest
Alexander Ryndin
узлы RAC разносим по филлиалам
И что же произойдет если вдруг как обычно характер приложения потребует межнодового взаимодействия?
Когда одному из узлов потребуется блок, измененный на другом узле, этот блок будет передан по интерконнекту. Это однозначно быстрее, чем читать с диска.

В чем проблема то?

Проблема в том, что по интерконнекту между филлиалами вообще лучше не лазить, ни к шареной памяти, ни к шареным дискам.
Вообще геораспределенная система и общий диск как то нелепо смотрится. Это как айфон использовать для подставки под ножку шкафа.
26 июл 11, 18:32    [11030262]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
интерконнекту между филлиалами
Alexander Ryndin
пропущено...
Когда одному из узлов потребуется блок, измененный на другом узле, этот блок будет передан по интерконнекту. Это однозначно быстрее, чем читать с диска.

В чем проблема то?

Проблема в том, что по интерконнекту между филлиалами вообще лучше не лазить, ни к шареной памяти, ни к шареным дискам.
Вообще геораспределенная система и общий диск как то нелепо смотрится. Это как айфон использовать для подставки под ножку шкафа.
Да при чем здесь геораспределенная система? Я говорю про обычный кластер, в которое каждый филиал работает на своем узле, подключаясь к нему удаленно.
26 июл 11, 18:35    [11030281]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
Yo.!
Guest
узлы RAC разносим по филлиалам
Но тогда возвращаемся опять к вопросу:
если не нужно межнодовое взаимодействие - это shared nothing, пожалуйста разносите узлы по филлиалам

ну покажи нам кто разнес, где shared-nothing кластер под SAP, Axapta, Siebel ну хоть какре нибудь OLTP на shared-nothing ? RAC полно, в любой индустрии, у любого серьезного вендора.

узлы RAC разносим по филлиалам
если нужно межнодовое взаимодействие - это мейнфрейм.

МФ с 9 процами z10 за $7-8 млн дохнет уже там где справляется старенький 8-way спарк с 32 ядрами. у оракла есть сайзинг пакетных заданий Peoplesoft на z10 МФ, price/perfomance ни в какие ворота.
26 июл 11, 19:10    [11030474]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67475
Блог
узлы RAC разносим по филлиалам
Я как потенциальный покупатель хочу понять где эта узкая ниша RAC в которой действительно будут видны её плюсы,

По сравнению с чем?

Если сравнивать с shared none кластером, то самый очевидный плюс, пожалуй, в том, что при вылетании одного из узлов другие могут подхватить его нагрузку.
26 июл 11, 22:59    [11031059]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 5032
Alexander Ryndin
1) У них 3 сервера, которые они объединяют в кластер. А, если я правильно понимаю, pureScale требует выделить как минимум 2 узла под блокировки. Т.е. в их ситуации получился бы 1 рабочий узел и 2 надсмотрщика. Я так понимаю, они вышли из ситуации, отпилив на каждом физическом узле виртуальную машины на 2 ядра и там подняли управление блокировками. 1/3 ядер в кластере у них занимается исключительно блокировками.
Судя по той ссылке, которую я привёл, там 2 8-ядерных сервера под db2. Т.к. виртуализация на intel пока не поддерживается, как рекомендуется и как возможно на power, то там на каждом сервере одна ОС и внутри запущено по 1-му узлу (member) DB2 и по 1-му CF - на одном первичный, на другом - вторичный. CF привязан к 2-м ядрам, чтоб узлу не мешался.
Alexander Ryndin
2) Что-то я ничего у них не услышал про standby. Они так гордятся отказоустойчивостью своего кластера, что даже не думают создавать резерв в другом датацентре, что наводит на мысль, что от нас что-то скрывают. Как там с поддержкой HADR? Можно какую-нибудь ссылку на официальную документацию?
Поддержка HADR в pureScale планируется в следующей версии.
Пока либо репликация, либо geographically dispersed DB2® pureScale™ cluster (GDPC)
Alexander Ryndin
3) Кстати, как там у pureScale c intra-query parallelism? Можно SELECT сделать, чтобы он по узлам расползся? Ну или индекс в параллели перестроить? Или backup в параллели одновременно на всех узлах запустить?
Если "intra-query parallelism" - это возможность выполнять 1 запрос на нескольких узлах одновременно, то нет. Да и не нужно это в oltp системах.
Про индексы и backup - не уверен, но по-моему нет.
26 июл 11, 23:39    [11031181]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 5032
Alexander Ryndin
А правильно ли я понимаю, что DB2 осуществляет блокировки на уровне страницы? Или это свойство только pureScale? Или я вообще ошибаюсь?
На уровне строк.
В pureScale есть дополнительная т.н. P-блокировка страницы, которая никак на транзакции не влияет, и введённа только для того, чтоб в страницу одновременно более одного узла не производило физической записи. Блокировка освобождается, как только физическое изменение страницы узлом завершилось.
26 июл 11, 23:48    [11031224]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 5032
softwarer
узлы RAC разносим по филлиалам
Я как потенциальный покупатель хочу понять где эта узкая ниша RAC в которой действительно будут видны её плюсы,

По сравнению с чем?

Если сравнивать с shared none кластером, то самый очевидный плюс, пожалуй, в том, что при вылетании одного из узлов другие могут подхватить его нагрузку.
В shared-nothing кластерах можно сконфигурировать standby машины, которые тоже могут подхватывать нагрузку отказавших узлов.
У IBM в хранилищах так и сделано, когда все серверы разбиваются на группы по 5 или более машин, и в каждой группе по 1-му standby, готовому подхватить нагрузку любого из отказавших в группе серверов.
Кроме того, и mutual takeover тоже можно сконфигурировать.
26 июл 11, 23:56    [11031251]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
Yo.!
Guest
на счет RDMA - в 11g появился протокол RDS v2 (OFED 1.2.5) под Linux который прямо с IB уровнем работает. как я понимаю полный аналог тому, что в pureScale. Throughput дает лишь на пару процентов выше: с 696 mb/s новый протокол дает 746 mb/s, лишь проц чуть меньше кушает - 11.8% до 5.2 (CPU utilization per core per 100MB/s in-flow)

http://members.infinibandta.org/old_content/events/IBTATechForum08_/IBTA_TechForum_08_Agenda/8_Oracle_Database_and_InfiniBand_Technology_presentation.pdf
27 июл 11, 21:01    [11036500]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
Yo.!
Guest


К сообщению приложен файл. Размер - 40Kb
27 июл 11, 21:02    [11036502]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67475
Блог
Mark Barinstein
В shared-nothing кластерах можно сконфигурировать standby машины,

В том-то и дело, что standby. Это само собой, но рак в силу своей архитектуры "естественно" подхватывает нагрузку на основные машины.

Mark Barinstein
Кроме того, и mutual takeover тоже можно сконфигурировать.

Вот этого уже не совсем представляю.
27 июл 11, 22:42    [11036745]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 5032
Yo.!
на счет RDMA - в 11g появился протокол RDS v2 (OFED 1.2.5) под Linux который прямо с IB уровнем работает. как я понимаю полный аналог тому, что в pureScale.
Ничего подобного.
RDS - сокетный протокол, требующий прерываний.
uDAPL - не требует.
См. дискуссию тут.
27 июл 11, 22:59    [11036786]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 5032
softwarer
Mark Barinstein
Кроме того, и mutual takeover тоже можно сконфигурировать.

Вот этого уже не совсем представляю.
Это когда, например, есть 2 сервера, 1-й обслуживает ноды 0-3, 2-й: 4-7.
Вместо того, чтоб держать 3-й standby сервер, готовый подхватить ноды любого из первых 2-х, эти 2 сервера настраиваются так, чтобы подхватить нагрузку друг друга.
Минус тут в том, что производительность кластера падает при отказе одного из серверов, поэтому такая конфигурация редко используется.
27 июл 11, 23:05    [11036799]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
Yo.!
Guest
Mark Barinstein
Ничего подобного.
RDS - сокетный протокол, требующий прерываний.
uDAPL - не требует.
См. дискуссию тут.

какие сокеты на IB access layer ? сокты двумя уровнями выше
27 июл 11, 23:12    [11036817]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67475
Блог
Mark Barinstein
эти 2 сервера настраиваются так, чтобы подхватить нагрузку друг друга.

Я не очень представляю себе, как "горячей" базе можно сказать подхватить заодно другую базу. Но хорошо, если так.

Mark Barinstein
Минус тут в том, что производительность кластера падает при отказе одного из серверов, поэтому такая конфигурация редко используется.

Ну, если грубо, то она падает до того значения, которое в случае конфигурации "со стендбаем" имеет постоянно.
27 июл 11, 23:18    [11036841]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 5032
Yo.!
какие сокеты на IB access layer ? сокты двумя уровнями выше
Вы это ... свои ссылки-то сами читаете?

Стр. 7-9:

What is RDS?

Vision Statement
• A low overhead, low latency, high bandwidth, ultra reliable, supportable, IPC protocol and transport system
• Which matches Oracle’s existing IPC models for RAC communication
• Optimized for transfers from 200 bytes to 8 MB

Goals and Objectives
• Support for a reliable datagram IPC
Based on Socket API
• Minimal code change / testing for Oracle
• Runs over InfiniBand, 10 Gig Ethernet, and iWARP
27 июл 11, 23:23    [11036864]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 5032
softwarer
Mark Barinstein
эти 2 сервера настраиваются так, чтобы подхватить нагрузку друг друга.

Я не очень представляю себе, как "горячей" базе можно сказать подхватить заодно другую базу. Но хорошо, если так.

Это одна база.
Ноды - части этой базы.
В shared nothing, грубо говоря, каждая нода имеет свою дисковую подсистему и обслуживается своим набором процессов.
Нет ничего особо сложного в том, чтоб, скажем, к 2-м севрерам физически подключить дисковые подсистемы обоих серверов, соотв. образом настроить кластерное ПО, чтоб при обнаружении отказа управление ресурсами отказавшего сервера переключалось на другой (монтировались файловые стистемы, поднимались виртуальные IP, запускались соотв. процессы и т.д.).
softwarer
Mark Barinstein
Минус тут в том, что производительность кластера падает при отказе одного из серверов, поэтому такая конфигурация редко используется.

Ну, если грубо, то она падает до того значения, которое в случае конфигурации "со стендбаем" имеет постоянно.
Нет.
В случае со standby производительность не падает, ведь в норме standby не обслуживает запросы.
Ну, если, конечно, в HA группе будет более одного одновременного отказа.
27 июл 11, 23:41    [11036943]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
Yo.!
Guest
Mark Barinstein
Вы это ... свои ссылки-то сами читаете?

мне уже начинать издеваться ? как думаешь как RDC расшифровывается ?
27 июл 11, 23:48    [11036979]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
Yo.!
Guest
RDS имелось ввиду
27 июл 11, 23:49    [11036988]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67475
Блог
Mark Barinstein
Нет ничего особо сложного в том, чтоб, скажем,

Физически - да. Логически - посложнее. Но хорошо, если эта задача решена.

Mark Barinstein
Нет. В случае со standby производительность не падает, ведь в норме standby не обслуживает запросы.

О том и речь. Грубо говоря, если стоят три одинаковые железки, то в раке производительность 3X, и в случае отказа она падает до 2X (ну на деле, конечно, до 2X+-Y). Ну а со стендбаем производительность изначально 2X и потому при отказе она "не падает".
27 июл 11, 23:51    [11036997]     Ответить | Цитировать Сообщить модератору
 Re: Как бы независимое сравнение DB2 и Oracle  [new]
RDS still cost a CPU interrupt
Guest
Yo.!
на счет RDMA - в 11g появился протокол RDS v2 (OFED 1.2.5) под Linux который прямо с IB уровнем работает. как я понимаю полный аналог тому, что в pureScale. Throughput дает лишь на пару процентов выше: с 696 mb/s новый протокол дает 746 mb/s, лишь проц чуть меньше кушает - 11.8% до 5.2 (CPU utilization per core per 100MB/s in-flow)

http://members.infinibandta.org/old_content/events/IBTATechForum08_/IBTA_TechForum_08_Agenda/8_Oracle_Database_and_InfiniBand_Technology_presentation.pdf

На дату May 13th, 2011 7:08 pm некий Kevin Closson говорит, кстати а кто он такой напомните?
http://www.dbms2.com/2011/05/06/db2-oltp-scale-out-purescale/
Kevin Closson
Infiniband RDMA transfers still cost a CPU interrupt.

И говорит он уже об этом после улучшений в OFED 1.5.1, а не в ваших OFED 1.2.5.
И он очень удивляется, что у IBM реализовано без прерываний и даже говорит им браво.
автор
If they are, that’s cool–I’d be surprised.

Кто из вас нагло врет?

RDS по определению не без прерываний в буквальном смысле. И это крест оракла который не даст нормально масштабироваться RAC.
28 июл 11, 03:32    [11037362]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить