Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
 Альтернатива Oracle RAC  [new]
mikkri
Member

Откуда: Лондон, Англия
Сообщений: 2794
Есть ли альтернатива Oracle RAC? Т.е. база данных, которая поддерживает эффективную кластеризацию и масштабирование.
23 янв 09, 13:31    [6726746]     Ответить | Цитировать Сообщить модератору
 Re: Альтернатива Oracle RAC  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

mikkri пишет:
> Есть ли альтернатива Oracle RAC? Т.е. база данных, которая поддерживает
> эффективную кластеризацию и масштабирование.
На сколько я знаю, реальной - нет.

Posted via ActualForum NNTP Server 1.4

23 янв 09, 14:17    [6727194]     Ответить | Цитировать Сообщить модератору
 Re: Альтернатива Oracle RAC  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
keywords:
IBM Informix Dynamic Server 11.50
MACH11

1. MACH 11 - Tell me more about it и дальше по ссылкам

2. Cheetah 2: IDS 11.5 Boosts Informix's "Always On" Reputation

3. Informix Dynamic Server 11: Extending Availability and Replication
23 янв 09, 15:43    [6727916]     Ответить | Цитировать Сообщить модератору
 Re: Альтернатива Oracle RAC  [new]
up
Member

Откуда:
Сообщений: 57
https://www.sql.ru/forum/actualthread.aspx?tid=583282
23 янв 09, 16:18    [6728236]     Ответить | Цитировать Сообщить модератору
 Re: Альтернатива Oracle RAC  [new]
Yo.!
Guest
у информикса это не кластер, там секондари ноды читают грязные данные а пишущие транзакции на главную ноду пересылают DML ... на раз даже если очень прищурится не походит, тут обсуждали:
https://www.sql.ru/forum/actualthread.aspx?bid=29&tid=271249&pg=5#5986900

ЗЫ. мейнфремовский sysplex слегка напоминает RAC.
23 янв 09, 16:49    [6728488]     Ответить | Цитировать Сообщить модератору
 Re: Альтернатива Oracle RAC  [new]
Ggg_old
Member

Откуда: Одесса
Сообщений: 1342
Недавно еще появился Sybase ASE Shared cluster. Но что это за продукт пока нигде не написано.
http://www.sybase.com/files/Product_Overviews/Sybase-ISUG-071707.pdf
23 янв 09, 17:19    [6728683]     Ответить | Цитировать Сообщить модератору
 Re: Альтернатива Oracle RAC  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
Yo.!
у информикса это не кластер, там секондари ноды читают грязные данные а пишущие транзакции на главную ноду пересылают DML ... на раз даже если очень прищурится не походит, тут обсуждали:
https://www.sql.ru/forum/actualthread.aspx?bid=29&tid=271249&pg=5#5986900


Кто его знает, что mikkri подразумевал под "эффективной кластеризацией и масштабированием"...
Поскольку ищет АЛЬТЕРНАТИВУ, значит не всё так пушисто в оРАЙкловской песочнице :).

Могу +1 к сказанному ниже:

onstat
p.s. Я езжу на шевроле , а хочу ездить на БМВ, это не мешает мне хотеть, но есть обьективные обстоятельства по которым я не могу себе позволить ездить на БМВ
23 янв 09, 17:30    [6728763]     Ответить | Цитировать Сообщить модератору
 Re: Альтернатива Oracle RAC  [new]
mikkri
Member

Откуда: Лондон, Англия
Сообщений: 2794
АнатоЛой
Yo.!
у информикса это не кластер, там секондари ноды читают грязные данные а пишущие транзакции на главную ноду пересылают DML ... на раз даже если очень прищурится не походит, тут обсуждали:
https://www.sql.ru/forum/actualthread.aspx?bid=29&tid=271249&pg=5#5986900


Кто его знает, что mikkri подразумевал под "эффективной кластеризацией и масштабированием"...
Поскольку ищет АЛЬТЕРНАТИВУ, значит не всё так пушисто в оРАЙкловской песочнице :).

Могу +1 к сказанному ниже:

onstat
p.s. Я езжу на шевроле , а хочу ездить на БМВ, это не мешает мне хотеть, но есть обьективные обстоятельства по которым я не могу себе позволить ездить на БМВ


Альтернативу Oracle RAC ищу главным образом для понимание, есть ли она. Наши DBA говорят, что Oracle RAC не так хорош, как реклама говорит. Сейчас мы задачу масштабирования решаем покупкой более мощного железа (SUN E2900 -> SUN M5000), но это тупиковый путь. Плюс нет High Availability. Так же собираемся более агрессивно перемещать исторические данные из основной БД в архивную, что уменьшит объем БД с текущих 1Тб+ до более разумных.
23 янв 09, 18:21    [6729133]     Ответить | Цитировать Сообщить модератору
 Re: Альтернатива Oracle RAC  [new]
SERG1257
Member

Откуда:
Сообщений: 2934
mikkri
Наши DBA говорят, что Oracle RAC не так хорош, как реклама говорит.

Верить вообще никому нельзя.

В таком разе альтернатива - DataGuard
23 янв 09, 18:37    [6729218]     Ответить | Цитировать Сообщить модератору
 Re: Альтернатива Oracle RAC  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
Эх, не забудьте после того, как найдёте альтернативу, оценить затраты на портирование приложений под новую СУБД. А то как бы не вышло дороже, чем разница в цене на SUN E2900 и на SUN M5000...
23 янв 09, 18:39    [6729229]     Ответить | Цитировать Сообщить модератору
 Re: Альтернатива Oracle RAC  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
HP takes Informix seriously

HP reference configuration for HP Virtual Server Environment (VSE) and IBM IDS

IBM Informix high availability features with HP MC/Serviceguard Cluster File System on HP-UX
23 янв 09, 18:41    [6729241]     Ответить | Цитировать Сообщить модератору
 Re: Альтернатива Oracle RAC  [new]
mikkri
Member

Откуда: Лондон, Англия
Сообщений: 2794
АнатоЛой
Эх, не забудьте после того, как найдёте альтернативу, оценить затраты на портирование приложений под новую СУБД. А то как бы не вышло дороже, чем разница в цене на SUN E2900 и на SUN M5000...

Что-то мне подсказывает, что отступлений от стандартного SQL у нас мало. Вот особенности реализации транзакций и версионность Oracle - это да. Плюс Oracle - это стратегически правильная платформа по мнению нашего CTO.

Выходит, больше интересно из личных побуждений.

P.s. sql.ru хорош тем, что на любой вопрос дадут внятный ответ. Спасибо!
23 янв 09, 18:50    [6729285]     Ответить | Цитировать Сообщить модератору
 Re: Альтернатива Oracle RAC  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
mikkri,

Есть альтернатива или нет сильно зависит от постановки задачи. Например для определенных задач Data Warehousing вместо RAC можно спокойно использовать Teradata. Это будет в большинстве случаев дороже, но работать будет вполне пристойно. Для задач из этой же области можно использовать Netezza и GreenPlum. Тольк все эти СУБД shared-nothing/MPP. А Оракл RAC это shared-disk.

Для OLTP задач shared-nothing часто не канает. Если надо именно кластер с shared-disk то это либо Oracle RAC либо DB2 EEE на мэйнфрейме.

Есть fedarated архитектура, она тоже отличается от Oracle RAC, в том числе и по области эффективного применения.

То есть "аналогов" в смысле shared-disk DB cluster под Unix/Windows нету, но есть системы способные решать те же задачи на другой архитектуре.
23 янв 09, 20:05    [6729546]     Ответить | Цитировать Сообщить модератору
 Re: Альтернатива Oracle RAC  [new]
mikkri
Member

Откуда: Лондон, Англия
Сообщений: 2794
Зл0й
...

Спасибо большое!

P.s. Мне тут Netezza советовали в команде, которая занимается инжинирингом гридов.
23 янв 09, 23:26    [6730094]     Ответить | Цитировать Сообщить модератору
 Re: Альтернатива Oracle RAC  [new]
StarBlade
Member

Откуда: Хорошо хоть не из МСК
Сообщений: 415
mikkri,

Не сочти за издевательство, но просто грамотно разработанная БД. Ну и соответственно масштабируемое приложение. Зачастую гораздо проще (и дешевле для бизнеса) переделать существующую или купить новую, чем немеряно баксов втюхать и мордоваться в последствии за призрачную мечту/идею не всегда дающую желаемый эффект. Да даже для Дабы сберечь башку идеолога внедрения.
29 янв 09, 09:27    [6751582]     Ответить | Цитировать Сообщить модератору
 Re: Альтернатива Oracle RAC  [new]
mikkri
Member

Откуда: Лондон, Англия
Сообщений: 2794
StarBlade
mikkri,

Не сочти за издевательство, но просто грамотно разработанная БД. Ну и соответственно масштабируемое приложение. Зачастую гораздо проще (и дешевле для бизнеса) переделать существующую или купить новую, чем немеряно баксов втюхать и мордоваться в последствии за призрачную мечту/идею не всегда дающую желаемый эффект. Да даже для Дабы сберечь башку идеолога внедрения.

Ничего не понял :-(
29 янв 09, 16:51    [6754927]     Ответить | Цитировать Сообщить модератору
 Re: Альтернатива Oracle RAC  [new]
dph
Guest
StarBlade

+1

for Mikki
Просто вместо того, что бы наращивать БД, можно оптимизировать приложение, которое с ним работает. По сути, RAC - это масштабирование памяти под не слишком эффективный кэш и масштабирование процессора. И то, и другое - можно перенести на нормальный application layer и масштабировать как хочется.

Что за задачи-то?

P.S. Вообще, чем больше я имею дело с Oracle на больших системах и приличных нагрузках, тем больше прихожу к выводу, что это - одно из наименее эффективных решений с точки зрения бизнеса (хотя и очень эффективное для группы эксплуатации).
29 янв 09, 21:02    [6755873]     Ответить | Цитировать Сообщить модератору
 Re: Альтернатива Oracle RAC  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
dph,

Очередная сказка про то, что Оракл не масштабируется, "поэтому мы быстренько нафигачим тут на С++\Java свои кэши, свои джойны и все у нас будет"
Одно из наименее эффективных решений с точки зрения бизнеса - это иметь дело с дилетантами, которые пытаются решать любые задачи единственным известным им способом. Вот с чего вы взяли, что задача автора может быть эффективно решена с помощью "перенести на нормальный application layer"? Вы ж даже не знаете о какой системе идет речь.

Ну а это вообще шедевры:
mikkri
Сейчас мы задачу масштабированиярешаем покупкой более мощного железа (SUN E2900 -> SUN M5000), но это тупиковый путь.

dph
Просто вместо того, что бы наращивать БД, можно оптимизировать приложение, которое с ним работает. По сути, RAC - это масштабирование памяти под не слишком эффективный кэш и масштабирование процессора. И то, и другое - можно перенести на нормальный application layer и масштабировать как хочется.

Есть такой термин, применительно к информационным системам - масштабируемость. Масштабируемость - это адекватно увеличение производительности ИС при увеличении аппаратной мощности. Система считается хорошо масштабируемой, если производительность возрастает прямо пропорционально увеличению аппаратной мощности. Оракл как СУБД масштабируется очень эффективно, но приложения написанные под него, могут масштабироваться плохо. Точно так же, как и WebLogic - сам по себе этот сервер приложений масштабируется хорошо, но всегда найдутся криворукие му**ки, которые насоздают ботлнеков на ровном месте. И СУБД, и AppServer в обоих случаях не при чем.
Теперь про RAC. RAC - это альтернативное, более дешевое средство повышения производительности. Альтернативное покупке более дорогого железа. Т.е. грубо: если есть 8-х процессорный сервер и два варианта: либо купить один 16-ти процессорный, либо еще один 8-ми процессорный и лицензию на RAC. При это следует понимать, что масштабируемость у RAC ХУЖЕ, чем просто за счет покупки одного более мощного сервера. Т.е. повышать производительность за счет увеличения числа нод нельзя так же эффективно как и за счет более мощных серверов, но зато дешевле и во многих ситуациях может быть весьма выгодным решением. И еще, если приклад написан особенно криво, то RAC может не увеличить производительность ИС вообще.
30 янв 09, 10:26    [6757255]     Ответить | Цитировать Сообщить модератору
 Re: Альтернатива Oracle RAC  [new]
mikkri
Member

Откуда: Лондон, Англия
Сообщений: 2794
Работа приложений с БД сейчас весьма не эффективна, так как на уровне приложения не делается кеширование. В результате если нужны данные транзакции, то они грузятся заново каждый раз. Из-за того, что несколько приложений могут поменять данные в одной и той же таблице, реализация кеширования весьма затруднительна и потребует серьезной переработки приложений.
30 янв 09, 18:08    [6760900]     Ответить | Цитировать Сообщить модератору
 Re: Альтернатива Oracle RAC  [new]
Yo.!
Guest
Apex
При это следует понимать, что масштабируемость у RAC ХУЖЕ, чем просто за счет покупки одного более мощного сервера.

не точная формулировка ;) как раз хохма в том, что масштабируемость RAC сегодня уже "лучше" чем у большой железяки. а если быть точнее то RAC масштабируется дальше, чем железяка. например у SAP есть тест на IBM Power6 на пяти RAC нодах производительность которого заметно опережает самую большую железячку которая на тот момент была у IBM из 32 процессоров.
а вот производительность, это да. из того же теста 4 ноды RAC даст где-то 15% меньшую производительность, чем одна большая железка с тем же кол-вом процессоров что и в четырех нодах RAC.
30 янв 09, 18:56    [6761074]     Ответить | Цитировать Сообщить модератору
 Re: Альтернатива Oracle RAC  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
mikkri
Работа приложений с БД сейчас весьма не эффективна, так как на уровне приложения не делается кеширование. В результате если нужны данные транзакции, то они грузятся заново каждый раз. Из-за того, что несколько приложений могут поменять данные в одной и той же таблице, реализация кеширования весьма затруднительна и потребует серьезной переработки приложений.

Вы в этом уверены? Т.е. все возможные способы оптимизировать это на уровне БД уже точно исчерпаны?
mikkri
реализация кеширования весьма затруднительна и потребует серьезной переработки приложений

Именно, по сути вам приедтся сделать почти тоже самое, что сделал Оракл: т.е. разводить конкурирующие потоки, согласовывать их по чтению и т.д.
30 янв 09, 20:42    [6761261]     Ответить | Цитировать Сообщить модератору
 Re: Альтернатива Oracle RAC  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
Yo.!

не точная формулировка ;) как раз хохма в том, что масштабируемость RAC сегодня уже "лучше" чем у большой железяки. а если быть точнее то RAC масштабируется дальше, чем железяка.

Не, ну понятное дело, если взять саму большую железяку, котору на данный момент способны произвести и поставить рядом РАК из двух таких же железяк - то РАК конечно выиграет
30 янв 09, 20:44    [6761263]     Ответить | Цитировать Сообщить модератору
 Re: Альтернатива Oracle RAC  [new]
dph
Guest
[q]Очередная сказка про то, что Оракл не масштабируется, "поэтому мы быстренько нафигачим тут на С++\Java свои кэши, свои джойны и все у нас будет"
[/q]
Оракл, конечно, масштабируется. И, в некоторых рамках, вполне неплохо. Но, увы, очень дорого.
Дорого по лицензиям, по администрированию, по железу, в конце концов.
И в большинстве прикладных задач есть более дешевые способы масштабирования.

[q]Вот с чего вы взяли, что задача автора может быть эффективно решена с помощью "перенести на нормальный application layer"? Вы ж даже не знаете о какой системе идет речь.[q]
Если использование RAC позволяет масштабировать систему, то использование application layer сделает это, в среднем, не хуже. Так как кэширование и пред/постобработка на уровне application layer - это то же самое увеличение общего числа памяти и процессоров в системе. Только за лицензии платить не надо, но надо платить за разработку и тратить время.
Что выгоднее - решается в каждом конкретном случае. Обычно для длинных проектов выгоднее разработка, для заказных поделок, где время поджимает и за лицензии платит клиент - использование RAC.
Ну, еще есть плохо спроектированная legacy, где кроме оптимизации БД ничего не поможет. Но тут, вроде бы, код свой.
30 янв 09, 23:47    [6761745]     Ответить | Цитировать Сообщить модератору
 Re: Альтернатива Oracle RAC  [new]
А6дуллаh
Member [заблокирован]

Откуда:
Сообщений: 1514
кластерные БД для хранилищ
http://tpc.org/tpch/results/tpch_price_perf_results.asp?resulttype=cluster&version=2%¤cyID=1

кластерные БД для транзакций
тот же источник дает только HP Integrity под Ora 10 - так что, кроме Ora, достойно проходящих TPC БД нет.
есть кастом-решения и много наработок на MySQL, PostgreSQL
3 фев 09, 12:06    [6771550]     Ответить | Цитировать Сообщить модератору
 Re: Альтернатива Oracle RAC  [new]
А6дуллаh
Member [заблокирован]

Откуда:
Сообщений: 1514
Еще для ХД HP в том году сделал NeoView серверы+диски+БД, shared-nothing, как я понял. Ценой сильно ниже Ora+какое-либо серьезное железо при тех же объемах.
3 фев 09, 13:13    [6772199]     Ответить | Цитировать Сообщить модератору
Все форумы / Сравнение СУБД Ответить