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

Откуда: Санкт-Петербург
Сообщений: 11
Итак. Разрабатывается программно-аппаратный комплекс. Рабочих мест около 200. Режим работы круглосуточный 365 дней в году. Огромный поток мультимедийных файлов размером от 500Kb до нескольких Gb. Общий объем базы в несколько десятков гигабайт, так как вероятно не вся мультимедиа будет храниться в базе. Общий объем хранилища на старте больше 10 террабайт, планируется развивать до сотни. Однозначно кластеризация по отказоустойчивости и по обработке информации.
Деньги на проект есть.

Планируем UNIX-подобную ОС и Oracle. К тому же у нас есть положительный опыт работы Oracle на другой подобной системе.
Предлагаемый нам подрядчик начал ныть, что нам необходим исключительно MS Windows и MS SQL. Еще и "маркетологи" всякие набежали, рассказывают про стоимость владения, соотношение цена/качество, супер предложения от майкрософта.
Главное: Если комплекс будет тормозить или глючить, то бить будут не по нашему карману, а по телу и сурово. :( Т.к. повторяюсь деньги на проект есть.
Вопрос: Разве MS способен на подобное? Интересны аргументы "за" и "против".

Спасибо за внимание.

P.S. Лично у меня Oracle вызывает значительно большее доверие.
P.P.S. Эмоциональные аргументы не интересны, т.к. я и сам на такое способен ;)
3 дек 04, 02:40    [1154551]     Ответить | Цитировать Сообщить модератору
 Re: Кластерная реализация. Проблема: Oracle или MS SQL?  [new]
judge
Администратор

Откуда: SQL.ru
Сообщений: 6042
Блог
Для оценки таких вещей хорошо бы знать о распределении планируемой нагрузки на сервер БД (насколько сложны выполняемые запросы, как часто они выполняются, необходимо ли осуществлять поиск по содержимому файлов и т.п.)

Вы уверены что хотите хранить сами файлы в БД? Возможно имеет смысл обойтись простым файлохранилищем? (IBM, EMC, StorageTek, Pinnacle, Sun,...)

При таких объемах, не забудте учесть пропускную способность сети, т.к. это тоже часто бывает проблемным местом.

Если не секрет - это система для радио/теле канала?

Alex
3 дек 04, 03:03    [1154556]     Ответить | Цитировать Сообщить модератору
 Re: Кластерная реализация. Проблема: Oracle или MS SQL?  [new]
Chaster
Member

Откуда: Санкт-Петербург
Сообщений: 11
автор
Для оценки таких вещей хорошо бы знать о распределении планируемой нагрузки на сервер БД (насколько сложны выполняемые запросы, как часто они выполняются, необходимо ли осуществлять поиск по содержимому файлов и т.п.)

Запросы вряд ли будут сложными, но их будет очень много.

автор
Вы уверены что хотите хранить сами файлы в БД? Возможно имеет смысл обойтись простым файлохранилищем? (IBM, EMC, StorageTek, Pinnacle, Sun,...)

Все слишком сложно для чисто файлохранилища.
1) Сюда же прикручен свой документооборот.
2) Фрагменты мультимедии постоянно обрабатываются операторами с применением документооборота.
3) Безопасность доступа к данным.
4) На эту базу еще прикручено управление специализированным оборудованием доставки мультимедийной информации, т.е. время отклика критично.

автор
При таких объемах, не забудте учесть пропускную способность сети, т.к. это тоже часто бывает проблемным местом.

Это все уже посчитано: 100/1000 Ethernet + 2Gb fibre channel и все в порядке.
3 дек 04, 03:33    [1154560]     Ответить | Цитировать Сообщить модератору
 Re: Кластерная реализация. Проблема: Oracle или MS SQL?  [new]
Ааз
Member

Откуда: Москва/Протвино
Сообщений: 4274
Привет

Не могу похвастаться знанием MS SQL. Oracle'иными кластерами интересуюсь долго (с версии 7.3.2.3) и всерьез (см. Семинар "Технологии Oracle9i RAC"). Есть несколько соображений и вопросы.

Соображения таковы:
1. Главный вопрос - нужно ли хранить сами мультимедийные(ММ) данные в БД. Если НЕ НУЖНО - получаем относительно небольшую по меркам Oracle и где-то среднюю/большую по меркам MS SQL базу - 10-100 Gb + 200 юзеров.

2. Хранение ММ данных в БД может быть необходимо по различным причинам, например:
- централизованная (aka упорядоченная) обновляемость, ограничение доступа и т.п.
- необходимость поиска по СОДЕРЖИМОМУ ММ
- внешний интерфейс - типа, работаем только через средства БД, не имея других средств доступа к серверу (iNET)

3. Если необходимо редактировать multimedia в БД - похоже, у Oracle наворотов и фич побольше.

4. Разница в кластерных решениях от MS и Oracle в том, что MS придерживается технологии "share nothing", а Oracle - "share disks". Т.е. в случае выхода из строя одного из узлов MS SQL кластера вы лишаетесь доступа к части данных, которые обслуживались этим узлом. У Oracle смерть узла почти безболезненна, зато если полетели общие диски... Гхмм.

Вопросы:
1. Judge поднял хороший вопрос - нужен ли поиск по содержимому ММ-данных. Имеется ввиду не "описаловка". Ответа пока не прозвучало.
2. Насколько критично время недоступности? Для Oracle в случае сбоя одного из узлов жизнь на других замирает на 10-30-??? секунд (зависит от числа узлов) на реконфигурацию. Потом "счастливчики" (те, кто был подключен не к сбойному экземпляру) продолжают работать как будто сбоя и не было. "Калекам" проще пересоединиться. Если речь не идет о 10-ках секунд/минутах недоступности, то DataGuard (aka Standby) может быть более адекватен.

Для затравки хватит, пожалуй. HTH

Всего
--
Andrei Kriushin (Oracle8/8i/9i OCP DBA), RDTEX J.S.C.
Disclaimer: Opinions are of my own and not necessar(-il)y...
3 дек 04, 04:12    [1154568]     Ответить | Цитировать Сообщить модератору
 Re: Кластерная реализация. Проблема: Oracle или MS SQL?  [new]
c127
Guest
Раз деньги на проект есть, то в чем вопросы? Единственный аргумент в пользу мелклософта это цена. Да и то еще нужно посчитать.

Ставьте оракл и юних и это гарантированно будет работать, если Ваша задача вообще рашаема. Тем более что есть опыт работы с ораклом и юнихом. И по телу бить не будут. Здоровье дороже.
3 дек 04, 04:26    [1154572]     Ответить | Цитировать Сообщить модератору
 Re: Кластерная реализация. Проблема: Oracle или MS SQL?  [new]
Ааз
Member

Откуда: Москва/Протвино
Сообщений: 4274
Chaster
Предлагаемый нам подрядчик
Гхммм... А конкурс какой объявить? И если Oracle'овые маркетроиды еще не понабежали - просто по неиформированности. Скажи куды бечь - я натравлю ;-)
3 дек 04, 04:35    [1154576]     Ответить | Цитировать Сообщить модератору
 Re: Кластерная реализация. Проблема: Oracle или MS SQL?  [new]
Yo!
Guest
у оракла можно blobы хранить не только в табличке но и в файловой системе.

>Вопрос: Разве MS способен на подобное? Интересны аргументы "за" и "против".

в принципе кажется у мс кластера можно было сделать резервную ноду и если одна из нод мс кластера падает то эта резервная может ее заменить ... но этот фокус кажется только админ ручками может провернуть. т.е. за 30 сек не получится ...

>Главное: Если комплекс будет тормозить или глючить, то бить будут не по нашему карману, а по телу и сурово.

короче получить в пах на мс у вас гораздо выше ... так что думайте насколько вам интересно это проверять :)
3 дек 04, 10:32    [1155119]     Ответить | Цитировать Сообщить модератору
 Re: Кластерная реализация. Проблема: Oracle или MS SQL?  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
http://www.ibm.com/ru/software/data/tools.html
3 дек 04, 10:43    [1155175]     Ответить | Цитировать Сообщить модератору
 Re: Кластерная реализация. Проблема: Oracle или MS SQL?  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
. Разница в кластерных решениях от MS и Oracle в том, что MS придерживается технологии "share nothing", а Oracle - "share disks". Т.е. в случае выхода из строя одного из узлов MS SQL кластера вы лишаетесь доступа к части данных, которые обслуживались этим узлом. У Oracle смерть узла почти безболезненна, зато если полетели общие диски... Гхмм.

MS-овский кластер также разделяет общие ресурсы, и при смерти одной ноды вы переключаетесь в течение 2 минут на резервную. Никакие данные никуда не пропадают (откуда такая инфа вообще??), они общие для обеих нод и лежат отдельно в корзине.

Вообще получается пофиг, на чем делать. И то и то равнозначно. И 200 юзеров - фигня. И объем фигня - у нас MS SQL под 50 гиг, нет проблем никаких, на сайте одновременно под 300 человек без тормозов сидят.

Так что решайте политические проблемы.
Правда есть непонятки в них:
автор
Предлагаемый нам подрядчик начал ныть, что нам необходим исключительно MS Windows и MS SQL. Еще и "маркетологи" всякие набежали, рассказывают про стоимость владения, соотношение цена/качество, супер предложения от майкрософта.

Так кто кому делает? Вы кому-то, или кто-то для вас? Подрядчик - чего подрядчик? Или все-же заказчик? Определитесь уж. Потому как кто платит, то и заказывает музыку. Хотите юникс - сказали и послали подальше. Они хотят винду - значит чего сказали, того и делайте. Кто из вас программирует то систему?

автор
Главное: Если комплекс будет тормозить или глючить, то бить будут не по нашему карману, а по телу и сурово.

Почему? Пропишите ваше мнение, сделайте нормально договор - и все будет нормально.
автор
Вопрос: Разве MS способен на подобное? Интересны аргументы "за" и "против".

Способен практически на то же, что и Оракл. За некоторыми небольшими исключениями.

-- Tygra's --
3 дек 04, 12:01    [1155669]     Ответить | Цитировать Сообщить модератору
 Re: Кластерная реализация. Проблема: Oracle или MS SQL?  [new]
Ааз
Member

Откуда: Москва/Протвино
Сообщений: 4274
gardenman
http://www.ibm.com/ru/software/data/tools.html

Звонок в дверь. Мужик (с бодунища) открывает дверь, а там весь такой Зеленый...
М. - Ты хто?
З. - Я твой "пии...п...сец"
М. - Ну и что?
З. - Ну и всё.
3 дек 04, 12:07    [1155696]     Ответить | Цитировать Сообщить модератору
 Re: Кластерная реализация. Проблема: Oracle или MS SQL?  [new]
Ааз
Member

Откуда: Москва/Протвино
Сообщений: 4274
tygra
Никакие данные никуда не пропадают (откуда такая инфа вообще??), они общие для обеих нод и лежат отдельно в корзине.
Упппссс. Не будите во мне зверя ;-). Разве я говорил про "пропадают"?
Ааз
вы лишаетесь доступа к части данных, которые обслуживались этим узлом
Корректнее было бы "временно лишаетесь". Типа, пока замену игрока не произведут. Просто у Oracle все данные доступны всем живущим :) или недоступны никому :(

С остальным - согласен. Если БД, конечно, в пределах сотни-другой Gb (это стрельба по MS SQL ;-) ).
3 дек 04, 12:18    [1155765]     Ответить | Цитировать Сообщить модератору
 Re: Кластерная реализация. Проблема: Oracle или MS SQL?  [new]
Yo!
Guest
>Способен практически на то же, что и Оракл. За некоторыми небольшими исключениями.

ага :) только исключение состоит в том как мс кластер нагрузку балансирует. там кажется была 2 вариаента - или таблички по кластерам админ размазывает .. т.е. админ должен обладать нехилым даром предвиденья или сервер их размазывет сам хеш функцией, что тоже очень весело когда запросы постоянно бегают по нодам.
3 дек 04, 12:23    [1155805]     Ответить | Цитировать Сообщить модератору
 Re: Кластерная реализация. Проблема: Oracle или MS SQL?  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
Собственно вопрос.
А зачем вам кластер?
Oracle Data Guard может оказаться вполне достаточно.
Лично мое мнение по поводу кластеринга, что от Oracle что от Microsoft - "много помпы и очень слабо с доказательствами быстродействия причем в случае с Microsoft помпы больше".

Мое субективное мнение.

MS кластер (shared-nothing )
Достоинства:
- может работать хорошо, в случае если задача очень хорошо параллелится.
- сравнительно некритичен ( относительно конечно ) к аппаратному обеспечению и потому дешев.

Недостатки:
( собственно это почти тоже самое что партиция в Oracle просто сегменты партиции хранятся на разных узлах).
- проблемы балансировки в случае если например запросов по одному диапазону больше чем по другому, то есть одна нода гуляет, другая перегружена.
- учитывая первый пункт, можно говорить о дополнительных админ. расходах на сопровождение.
- выход одной ноды - это недоступность части данных, но для пользователя это без разницы ( если он не может получить доступ к актуальным данным. То есть требуется дубляж нод.
- Отсутствуют доказательства использования в приложениях под большой нагрузкой. Например тесты TPC-C есть, а тестов SAP-SD -нет. То есть с одной стороны в тепличных условиях работает, а в серьезных приложениях нет.

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


Oracle RAC ( shared-disk)
Достоинства:
- присутсвует балансировка нагрузки между узлами
- динамическая реконфигурация узлов.
- присутствует возможность сохранения контекста сесси и возобновление ее работы на другом узле.
- наличие CacheFusion улучшает возможности разнесения нагрузки по нодам.
- как поет реклама от Oracle возможно использование "дешевого" аппаратного обеспечения.

Недостатки:
- просто непомерная стоимость +25% к стоимости лицензий + требование иметь процессорную лицензию на Oracle EE ( 40к на проц ).
- Динамическое добавление узлов конечно классный вариант, но а как насчет динамического балансирования ввода-вывода? Возможно? Впринципе да, скажем для устройств класcа EMC.
- Произодительность кластера целиком зависит от производительности Интерконнекта.
- как и в случае с MS практически очень мало, но они хотя бы присутсвуют.
Опустим тесты TPC-C и рассмотрим тесты SAP.
Для 2-х узлового RAC( каждый узел 4 проц ) SAPS - 6,770
[url=http://]www50.sap.com/benchmark/PDF/Cert3804.pdf [/url]
Для примера возьмем 8 проц сервер SAPS - 7,530
http://www50.sap.com/benchmark/PDF/Cert3804.pdf
Разница (1- 6,770/7,530)*100 = 10%
Что будет скажем если узлов будет не 2 а 4 или 8 можно только догадываться.

Можно еще конечно добавить, но устал набирать.
Таким образом в случае с RAC мы влетаем на деньги по стоимости лицензий на Oracle.
Например если сравнить RAC с SMP системой, то единственное место где "можно сэкономить" - это узлы кластера ( они сравнительно дешевы), по сравнению с цельной SMP железкой.
Дисковая стойка должна быть как минимум того же типа и тех же возможностей что и в случае с SMP cистемой.
Явное преймущество SMP железки - возможность воспользоваться PQO.
Недостаток SMP - большие первоначальные затраты, ибо вариант докупки проц. в последствии возможен, но это тоже "развод на деньги" но уже со стороны производителя аппаратного обеспечения.
3 дек 04, 13:21    [1156155]     Ответить | Цитировать Сообщить модератору
 Re: Кластерная реализация. Проблема: Oracle или MS SQL?  [new]
Андрей Прохоров
Member

Откуда:
Сообщений: 146
Ааз

gardenman
http://www.ibm.com/ru/software/data/tools.html

Звонок в дверь. Мужик (с бодунища) открывает дверь, а там весь такой Зеленый...
М. - Ты хто?
З. - Я твой "пии...п...сец"
М. - Ну и что?
З. - Ну и всё.

Вероятно, это была попытка обратить внимание на Content Manager
3 дек 04, 13:25    [1156186]     Ответить | Цитировать Сообщить модератору
 Re: Кластерная реализация. Проблема: Oracle или MS SQL?  [new]
Yo!
Guest
автор
- просто непомерная стоимость +25% к стоимости лицензий + требование иметь процессорную лицензию на Oracle EE ( 40к на проц ).


они там сильно скидывали цены и у 10ки standart edition RAC чуть ли не бесплатно и в комплекте.

https://www.sql.ru/forum/actualthread.aspx?tid=89105
3 дек 04, 13:32    [1156227]     Ответить | Цитировать Сообщить модератору
 Re: Кластерная реализация. Проблема: Oracle или MS SQL?  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
Yo!
автор
- просто непомерная стоимость +25% к стоимости лицензий + требование иметь процессорную лицензию на Oracle EE ( 40к на проц ).


они там сильно скидывали цены и у 10ки standart edition RAC чуть ли не бесплатно и в комплекте.

https://www.sql.ru/forum/actualthread.aspx?tid=89105


Oracle Database 10g Standard Edition is suitable for medium-sized business environments and includes Oracle's Real Application Cluster capabilities to provide protection against hardware and server failures. It's easy to install, configure, complete with it's own cluster-ware, storage management and other self-managing capabilities. With Oracle Database 10g Standard Edition, your applications can take advantage of the proven performance, security and reliability of Oracle on single or clustered servers up to four processors. It also provides complete upward compatibility with Oracle Database 10g Enterprise Edition.
3 дек 04, 13:40    [1156274]     Ответить | Цитировать Сообщить модератору
 Re: Кластерная реализация. Проблема: Oracle или MS SQL?  [new]
Yo!
Guest
> on single or clustered servers up to four processors.

зато за $5K, а не $40K да и если нада больше чем 4 проца $40K это копейки по сравнению со стоимостью железа.
3 дек 04, 14:12    [1156417]     Ответить | Цитировать Сообщить модератору
 Re: Кластерная реализация. Проблема: Oracle или MS SQL?  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
Yo!
> on single or clustered servers up to four processors.

зато за $5K, а не $40K да и если нада больше чем 4 проца $40K это копейки по сравнению со стоимостью железа.


Ну
во-первых не $5к, а $15к.
5к - это для standart edition one, а это не одно и тоже.
Разница в типах лицензий.

во-вторых:

Возьмем 2х узловой кластер на 4х проц хостах и сравним его с 8 проц. хостом.

Получаем для RAC:
в минимальном случае:
Oracle 9iEE = 2x4*25*800 = 160k
RAC option = 2x4*25*400 = 80к
============================
Итого = 240к ( это если ребята из Oracle вам позволят так сделать).

в реальности похожей на правду.
Oracle 9iEE = 2x4*40k= 320k
RAC option = 2x4*20k = 160к
=====================
Итого: 480к

Для простого 8 проц SMP-сервера:
минимум
Oracle 9iEE = 8*25*800 = 160k
максимум
Oracle 9iEE = 8*40k= 320k

Ваши потери в случае с RAC
минимум: 80к
максимум: 160к
И все это на ровном месте.

Это мы еще не учитываем тот факт, что RAC конфигурация потребует больше ресурсов (а следовательно и лицензионных отчислений ) для подержания фиксированного кол-ва коннектов чем SMP?

Так убедительно?
3 дек 04, 15:59    [1156813]     Ответить | Цитировать Сообщить модератору
 Re: Кластерная реализация. Проблема: Oracle или MS SQL?  [new]
Yo!
Guest
на счет $15K да эт я промахнулся, но на счет SMP и RAC не понял зачем сравнивать теплое с мягким ?
3 дек 04, 16:26    [1156978]     Ответить | Цитировать Сообщить модератору
 Re: Кластерная реализация. Проблема: Oracle или MS SQL?  [new]
DimaR
Member

Откуда:
Сообщений: 1570
to EugeneS
А какая разница в цене между 4x и 8x процессорной железякой?
3 дек 04, 16:34    [1157023]     Ответить | Цитировать Сообщить модератору
 Re: Кластерная реализация. Проблема: Oracle или MS SQL?  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
Yo!
на счет $15K да эт я промахнулся, но на счет SMP и RAC не понял зачем сравнивать теплое с мягким ?


А почему нет?
Приведите аргументы ?
3 дек 04, 16:34    [1157026]     Ответить | Цитировать Сообщить модератору
 Re: Кластерная реализация. Проблема: Oracle или MS SQL?  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
DimaR
to EugeneS
А какая разница в цене между 4x и 8x процессорной железякой?


Давайте может рассмотрим конкретный пример?
3 дек 04, 16:44    [1157083]     Ответить | Цитировать Сообщить модератору
 Re: Кластерная реализация. Проблема: Oracle или MS SQL?  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
EugeneS
DimaR
to EugeneS
А какая разница в цене между 4x и 8x процессорной железякой?


Давайте может рассмотрим конкретный пример?


Пример с ценами с сайта [url=http://]hp.com[/url]:
4 проц сервер

DL580 ProLiant DL580 G2 Intel® Xeon™ Processor MP at 3.00GHz/4MB (2P Model)
RAM = 16GB
System price $50,858.001


8 проц

ProLiant DL740 Intel® Xeon™ Processor MP at 3.00GHz/4MB, 4GB (4P Model)
RAM=32GB
System price $89,963.001

В обоих случаях стоимость дисковой системы не учитывается.
3 дек 04, 16:58    [1157144]     Ответить | Цитировать Сообщить модератору
 Re: Кластерная реализация. Проблема: Oracle или MS SQL?  [new]
Yo!
Guest
ну вопервых на некоторых задачах RAC может быть эфективней, т.е. обслуживать бОльше юзеров, а значит дешевле (C) Oracle
во вторых ноды можно разнести хотябы по этажам, что некисло увеличивает живучесть системы.
в третих гибкость - чтоб обслужить еще 100 юзеров мне не нада вбухивать еще $100K в очередную железку.
3 дек 04, 17:29    [1157238]     Ответить | Цитировать Сообщить модератору
 Re: Кластерная реализация. Проблема: Oracle или MS SQL?  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
Вообще-то давно известно что хранить multimedia данные в БД не всегда эффективно. Что вы будете делать с файлами более 2 GB влюбой БД. Вам придется их резать.
Например такие файловые системы как GPFS поддерживают конкурентный доступ к файлам. То бишь один пишет другой читает. Для видео это очень актуально.
Большинство систем (не все) по хранению мультимедиа состоят из двух частей.

1. метаинформация об объекте - РСУБД
2. файловая системы, ленты, оптика для хранения объектов.

Вы можете создать такую сами или купить.
3 дек 04, 17:59    [1157313]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить