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

Откуда: Киев, Украина
Сообщений: 2897
Блог
Alexander Ryndin
...расскажите как работает SDS...
А Yo.! расскажет как работает RAC.
Нам всем будет полезно узнать новое.
Ну и для завтравки вот такие вопросы:
1) Является ли решение active-active?
2) Что происходит, если данные изменились на одном узле и еще не были сброшены из кэша на диск и кто-то пытается изменить эти же данные на другом узле?
3) Потребуется ли от администратора какие-то действия при смерти одного узла?


Данный топик появился в результате обсуждения другой темы:
ASA vs MS SQL 2008R2 vs Oracle 11G

Alexander Ryndin
...расскажите как работает SDS...
А Yo.! расскажет как работает RAC.
Нам всем будет полезно узнать новое.


Предложение звучит логично, согласится ли "Yo.!"? :)

Считаю, что "рассказывать" есть смысл в таких случаях:
1) если нет документации. Не наш случай, ссылки приводил, могу привести ещё раз.

2) если не знаю где искать или не нашёл в документации. Бывает. В таких случаях иногда человеку можно и помочь.

3) если непонятна документация. В таких случаях задают конкретные вопросы.

4) если есть знания помимо документации, которые документацию дополняют, либо опровергают. Тут уж, кто на что горазд :)

5) если делается аналитическое сравнение. А вот это оно.

Вот 5-ый вариант можно подготовить с участием специалистов с обеих сторон баррикады :).

То есть сообща готовим типичную "таблицу" для аналитического сравнения.
Заведу здесь даже блог, где можно будет вести текущее состояние аналитического сравнения, а в форуме - обсуждение, предложения и замечания.
В обсуждениях формируем корректный (со сслыками на источники) состав сравниваемых характеристик и формируем корректные ответы (со ссылками на источники). Как, подойдёт?

Обращаю внимание, как "немаркетолог" - договариваемся и фиксируем понятия.
Потому как первое, что захотелось сделать: это попросить ответить на вопросы Alexander Ryndin так сказать со стороны Оракла, чтобы по ответам понять, какую степень детализации ожидает вопрошающий.
Alexander, ответите?
23 дек 11, 16:19    [11816463]     Ответить | Цитировать Сообщить модератору
 Re: Informix SDS и Oracle RAC: давайте сравним  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
Alexander Ryndin
Ну и для завтравки вот такие вопросы:
1) Является ли решение active-active?

1) вопрос "Является ли решение active-active?" может иметь прозрачный смысл для ораклоида (и то не всегда), и я в данном случае прошу уточнить, что вы вкладываете в это понятие...

Alexander Ryndin
2) Что происходит, если данные изменились на одном узле и еще не были сброшены из кэша на диск и кто-то пытается изменить эти же данные на другом узле?

Что Вас интересует: поведение системы с внешней точки зрения (пользователя) или подробное описание того, как сервер будет обрабатывать данную ситуацию с техническими подробностями?
Alexander Ryndin
3) Потребуется ли от администратора какие-то действия при смерти одного узла?

Маркетолог мог бы ответить: "Нет, конечно" .
Я контрольно переспрошу: действия для чего? Сохранится ли без вмешательства админа работоспособность кластера и возможность работы с кластером для клиентов? Connection Manager позволяет настроить правила автоматического определения "смертей" и автоматического восстановления работоспособности кластера.

Вы про это хотели услышать? А что вы можете рассказать про Оракл?
23 дек 11, 16:25    [11816529]     Ответить | Цитировать Сообщить модератору
 Re: Informix SDS и Oracle RAC: давайте сравним  [new]
Yo.!
Guest
да будет флейм беспощадный !
АнатоЛой, имхо вам стоит сначала завести ветку в информикс разделе, что бы вам рассказали или так сказать пережували то, что говориться в документации по SDS. вы явно не понимаете какая печаль приключиться в реальной жизни на реальных системах из-за ограничения использования на SDS уровней изолированности транзакции выше Read Committed. причем это даже не тот Read Committed к которому привыкли пользователи блокировочных, а уровень много слабее. его было бы правильней назвать "хер знает когда но когда-то Committed"
в противовес этому оракловый RAC гарантирует всем транзакциям на любой с любой ноды консистентный набор и все уровни изолированности, в плоть до Serializable. делается это за счет синхронизации буферного кеша всех нод между собой. поскольку блокировки оракл хранит в блоках данных синхронизируются и структуры блокировок между нодами, что и дает возможность ораклу гарантировать корректную работу транзакций. SDS блокировки не умеет синхронизировать и соответственно SDS ноды понятия не имеют о том, что соседние ноды модифицируют данные. отсюда и растут ноги на ограничения по уровням изолированности и невозможность обеспечить да нормальный Read Committed (предлагая в замен "хер знает когда но когда-то Committed" )
23 дек 11, 16:37    [11816634]     Ответить | Цитировать Сообщить модератору
 Re: Informix SDS и Oracle RAC: давайте сравним  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
Для примера прообраз того, что будет в блоге:

Сравниваемые характеристики/Кластер СУБД Informix SDS (IDS 11.70) Oracle RAC ( ? )
1. Функциональность вторичных серверов
1.1. Клиенты могут выполнять запросы на изменение данных на всех серверах Да с ограничениями ???
...
2. Автоматическое реагирование на сбои узла в системе
2.1. Перенаправление клиентов на рабочий узел Да ???
2.2. Восстановление (перезапуск узла) и включение его в кластер ??? ???

Термины:
Т1. Кластер - взаимодействующий набор серверов, созданный с целью повышения отказоустойчивости и масштабируемости решения.

Т2. primary = первичный
Один из узлов кластера, координирующий изменения данных в БД (единственный на момент времени)

Т3. secondary = вторичный
Дополнительные узлы кластера, за счёт ресурсов которых повышается отказоустойчивость и масштабируемость кластера.

Литература:
L1. Informix Dynamic Server 11: Extending Availability and Replication
L2. IBM Informix Flexible Grid: Extending Data Availability
L3. Informix 11.70 Admin's Guide. Shared Disks Secondary Servers
23 дек 11, 16:58    [11816843]     Ответить | Цитировать Сообщить модератору
 Re: Informix SDS и Oracle RAC: давайте сравним  [new]
Yo.!
Guest
АнатоЛой,

первым пунктом должен быть вопрос "Пригоден ли кластер для работы транзакционных систем". после того как вы честно попытаетесь ответить на этот вопрос по SDS, смысла в остальных вопросах типа добавление узла в кластер уже и не останется ...
23 дек 11, 17:27    [11817102]     Ответить | Цитировать Сообщить модератору
 Re: Informix SDS и Oracle RAC: давайте сравним  [new]
ДохтаР
Member [заблокирован]

Откуда: Новоукраинск
Сообщений: 16864
Yo!, тебе снова наступили на больную. мозоль ?

Yo.!

в противовес этому оракловый RAC гарантирует всем транзакциям на любой с любой ноды консистентный набор и все уровни изолированности, в плоть до Serializable.




Этот момент просьба осветить в сравнительной характеристеке более подробно

Какие уровни изолированности транзакций где присутствуют и где отсутствуют и что в какой системе точнее гарантируются
)
23 дек 11, 17:57    [11817324]     Ответить | Цитировать Сообщить модератору
 Re: Informix SDS и Oracle RAC: давайте сравним  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
Yo.!
АнатоЛой, имхо вам стоит сначала завести ветку в информикс разделе, что бы вам рассказали или так сказать пережували то, что говориться в документации по SDS.

Спасибо, "зубы" на месте, жевать умею, чуть-чуть осталось :).

Yo.!
Вы явно не понимаете какая печаль приключиться в реальной жизни на реальных системах из-за ограничения использования на SDS уровней изолированности транзакции выше Read Committed.
причем это даже не тот Read Committed к которому привыкли пользователи блокировочных,
а уровень много слабее. его было бы правильней назвать "хер знает когда но когда-то Committed"


Для меня это пока лишь ваши выводы - "верхний уровень".
На выходных дожую доку - отпишусь :)

И ещё, кто-то предлагает по всей "реальной жизни" и для "всех реальных" систем поменять Oracle на Informix? Dbf-ы живут до сих пор со своими "грехами", Access живёт со своими.
Ну просто непонятно, как реализовывали банковские системы времён dbf без уровня Serializable?! По-моему, вы просто размеры печалек преувеличиваете...

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

"блокировки оракл хранит в блоках данных"
Oracle RAC "платит" за это снижением быстродействия при наложении блокировок по сравнению с вариантом "храним блокировки в оперативной памяти"? Или я неправильно понял выделенное жирным?

Yo.!
SDS блокировки не умеет синхронизировать и соответственно SDS ноды понятия не имеют о том, что соседние ноды модифицируют данные. отсюда и растут ноги на ограничения по уровням изолированности и невозможность обеспечить да нормальный Read Committed (предлагая взамен "хер знает когда но когда-то Committed")


да, у него реализация другая:

The Updatable Secondary server provides an automatic transfer from the
Secondary to the Primary node when an update operation is to be performed.
This is done without taking a distributed lock on the row at the Secondary and the
Primary. Instead, the Primary server uses a form of optimistic concurrency. This
means that the Primary server will consider the update operation only if the
before image is identical between the Primary and the Secondary server. If it is
not, then the server will consider the operation as having encountered a
deadlock type of error and abort the operation.

Это что-ли, вселенская печаль?
23 дек 11, 18:20    [11817480]     Ответить | Цитировать Сообщить модератору
 Re: Informix SDS и Oracle RAC: давайте сравним  [new]
londinium
Member

Откуда: Киев
Сообщений: 1202
автор
Этот момент просьба осветить в сравнительной характеристеке более подробно

И чего там освещать? Сказано - "валите на меня как на мертвого, я за все отвечаю", значит, так и есть, гарантирует.

И коллеги, пожалуйста, расскажите о задачах, где без RAC/SDS жить нельзя
23 дек 11, 18:26    [11817515]     Ответить | Цитировать Сообщить модератору
 Re: Informix SDS и Oracle RAC: давайте сравним  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
londinium
автор
Этот момент просьба осветить в сравнительной характеристеке более подробно

И чего там освещать? Сказано - "валите на меня как на мертвого, я за все отвечаю", значит, так и есть, гарантирует.

И коллеги, пожалуйста, расскажите о задачах, где без RAC/SDS жить нельзя

Какие задачи? Главное, что "RAC пригоден для транзакционных систем, не то что SDS"... .
Если серьёзно: жить без него можно - ибо жили же до того, как они появились. Вопрос в том, что может дать или уже кому-то даёт (пятничные мысли:) неоспоримые преимущества по сравнению с другими решениями. Я сейчас и пытаюсь добраться до сути, мешают ли мне наличие/отсутствие "шашечек" собственно ехать...
Кстати, есть очень интересная статья на эту тему.
23 дек 11, 18:49    [11817600]     Ответить | Цитировать Сообщить модератору
 Re: Informix SDS и Oracle RAC: давайте сравним  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
londinium
И коллеги, пожалуйста, расскажите о задачах, где без RAC/SDS жить нельзя

Если совсем серьёзно:

Пример задачи:
Есть готовая и работающая система на Oracle/Informix.
Бизнес достаточно резко вырос в охвате (удачные инвестиции и "перестаравшиеся" маркетологи).
Вопрос: как с наименьшими затратами выросшую нагрузку на сервера (тупо объём траффика/транзакций прыгнул за год в 3 раза) таки обработать.

Вот тут и появляются варианты, среди которых и RAC/SDS.
А так чтобы жить нельзя... Это к Yo!, наверное...
23 дек 11, 18:57    [11817621]     Ответить | Цитировать Сообщить модератору
 Re: Informix SDS и Oracle RAC: давайте сравним  [new]
londinium
Member

Откуда: Киев
Сообщений: 1202
*страшная ересь
А если купить сервер побольше?
*конец страшная ересь
23 дек 11, 19:06    [11817656]     Ответить | Цитировать Сообщить модератору
 Re: Informix SDS и Oracle RAC: давайте сравним  [new]
экспоненциально от производитель
Guest
londinium
*страшная ересь
А если купить сервер побольше?
*конец страшная ересь

Особенно учитывая что цена растет экспоненциально от производительности, точно страшная ересь.
Это единственная причина по которой нужен RAC, где он оказывается дешевле.
23 дек 11, 19:10    [11817668]     Ответить | Цитировать Сообщить модератору
 Re: Informix SDS и Oracle RAC: давайте сравним  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54850

АнатоЛой
тупо объём траффика/транзакций прыгнул за год в 3 раза) таки обработать.

Вот тут и появляются варианты, среди которых и RAC/SDS.

Вот только... среди которых НЕТ RAC/SDS. Ибо если сервер упёрся в ввод-вывод, то
RAC с его shared storage тупо упрётся туда же. Даже если его менеджер локов не просядет
первым по латентности интерконнекта.

Posted via ActualForum NNTP Server 1.5

23 дек 11, 19:20    [11817699]     Ответить | Цитировать Сообщить модератору
 Re: Informix SDS и Oracle RAC: давайте сравним  [new]
Ggg_old
Member

Откуда: Одесса
Сообщений: 1342
[trollmode on]
RAC/SDS/ASE Shared claster - ересь.
Правльный ответ - IBM Mainframe, ибо нет таких учетных задач, для которых его бы кому-нибудь не хватило. Поэтому все приличные банки, страховые компании, задачи которых не параллелятся на несколько машин т.к. данные сильносвязаны сидят на бигжелезе.
[trollmode off]
23 дек 11, 20:11    [11817877]     Ответить | Цитировать Сообщить модератору
 Re: Informix SDS и Oracle RAC: давайте сравним  [new]
крак
Guest
Dimitry Sibiryakov
Ибо если сервер упёрся в ввод-вывод, то
RAC с его shared storage тупо упрётся туда же. Даже если его менеджер локов не просядет
первым по латентности интерконнекта.
Раз: если сервер уперся в ввод-вывод, то два сервера не упрутся (ибо SAN).
Два: инфинибенд есть хорошее решение для понижения латентности интерконнекта.
24 дек 11, 00:00    [11818574]     Ответить | Цитировать Сообщить модератору
 Re: Informix SDS и Oracle RAC: давайте сравним  [new]
крак
Guest
По табличке в 11816843 по всем пунктам для рак - да.
24 дек 11, 00:02    [11818578]     Ответить | Цитировать Сообщить модератору
 Re: Informix SDS и Oracle RAC: давайте сравним  [new]
RAC в топку
Guest
крак
Dimitry Sibiryakov
Ибо если сервер упёрся в ввод-вывод, то
RAC с его shared storage тупо упрётся туда же. Даже если его менеджер локов не просядет
первым по латентности интерконнекта.
Раз: если сервер уперся в ввод-вывод, то два сервера не упрутся (ибо SAN).
Два: инфинибенд есть хорошее решение для понижения латентности интерконнекта.

Правильно, ставим SAN+Infiniband+Single Instance, а RAC в топку.
В большинстве случаев слабое звено - дисковая подсистема и что толку ноды плодить?
24 дек 11, 00:50    [11818703]     Ответить | Цитировать Сообщить модератору
 Re: Informix SDS и Oracle RAC: давайте сравним  [new]
крак
Guest
RAC в топку,

Дисковая подсистема - слабое звено у горе-архитекторов. В большинстве случаев :D
24 дек 11, 01:07    [11818734]     Ответить | Цитировать Сообщить модератору
 Re: Informix SDS и Oracle RAC: давайте сравним  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54850

крак
Раз: если сервер уперся в ввод-вывод, то два сервера не упрутся (ибо SAN).

А куда ж они денутся? Начнут байты телепатически пересылать и домены силой воли
перемагничивать?..

Posted via ActualForum NNTP Server 1.5

24 дек 11, 01:32    [11818762]     Ответить | Цитировать Сообщить модератору
 Re: Informix SDS и Oracle RAC: давайте сравним  [new]
счастье-архитектор
Guest
крак
RAC в топку,

Дисковая подсистема - слабое звено у горе-архитекторов. В большинстве случаев :D

А у счастье-архитекторов что является слабым звеном?
24 дек 11, 01:35    [11818766]     Ответить | Цитировать Сообщить модератору
 Re: Informix SDS и Oracle RAC: давайте сравним  [new]
крак
Guest
Dimitry Sibiryakov,

Что такое "ввод-вывод на сервере" и как можно в него упереться? Чем он отличается от ввода-вывода в SAN? Тогда, может быть, и ответ на свой конкретный вопрос получишь.
24 дек 11, 02:01    [11818798]     Ответить | Цитировать Сообщить модератору
 Re: Informix SDS и Oracle RAC: давайте сравним  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54850

крак
Что такое "ввод-вывод на сервере" и как можно в него упереться? Чем он отличается от
ввода-вывода в SAN?

Обмен с дисковой системой и внутри неё. И ничем он не отличается от SAN кроме проводка.
Это физика, детка.

Posted via ActualForum NNTP Server 1.5

24 дек 11, 02:34    [11818832]     Ответить | Цитировать Сообщить модератору
 Re: Informix SDS и Oracle RAC: давайте сравним  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
ДохтаР
Yo!, тебе снова наступили на больную. мозоль ?
Yo.!
в противовес этому оракловый RAC гарантирует всем транзакциям на любой с любой ноды консистентный набор и все уровни изолированности, в плоть до Serializable.


Этот момент просьба осветить в сравнительной характеристеке более подробно
Какие уровни изолированности транзакций где присутствуют и где отсутствуют и что в какой системе точнее гарантируются
)
ДохтаР, вы повторяетесь.

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

Ключевым отличием Oracle RAC от остальных кластеров является то, что уровень сервиса для одноузловой конфигурации и многоузловой одинаков - одна и та же транзакционность, одни и те же уровни изолированности, одна и та же надежность (только выше).
24 дек 11, 04:01    [11818909]     Ответить | Цитировать Сообщить модератору
 Re: Informix SDS и Oracle RAC: давайте сравним  [new]
Надежность у синхронного хот-сте
Guest
Alexander Ryndin
Ключевым отличием Oracle RAC от остальных кластеров является то, что уровень сервиса для одноузловой конфигурации и многоузловой одинаков - одна и та же транзакционность, одни и те же уровни изолированности, одна и та же надежность (только выше).

Не ради спора, можете прокомментировать про надежность которая якобы выше у многоузлового RAC, чем одноузлового.
Например известно, что Cache-fusion работает по принципу владения блоками данных, а какой узел конкретным блоком владеет знает таблица GRD. И если измененный блок закомиченной транзакции не успевший сделать flush на диск, находится на одном узле, без копий на других и этот узел упадет, каково поведение RAC?

В чем надежность, что пропадет не 100, как на 1-узловом, а только 50 транзакций на 2х-узловом? Ставить синхронный flush на диск? Писать MAX_COMMIT_PROPOGATION_DELAY = 0? И сильно снизить прозводительность? В общем те же яйца только в профиль.

Надежность выше только у синхронного хот-стендбая, где на каждом узле полная копия буферного кэша не успевшего сброситься(flush) на диск.
24 дек 11, 12:49    [11819199]     Ответить | Цитировать Сообщить модератору
 Re: Informix SDS и Oracle RAC: давайте сравним  [new]
крак
Guest
Dimitry Sibiryakov,

Ты же говоришь, что именно сервер уперся в ввод-вывод. И тут же говоришь про дисковую систему, которая в SAN вынесена на свой уровень. Думай еще, дедуля.
24 дек 11, 14:54    [11819474]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить