Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 14 15 16 17 18 [19] 20 21 22 23 .. 26   вперед  Ctrl
 Re: Провал операции Yukon  [new]
Nord
Guest
2 EugeneS
"Сложные запросы обычно на OLTP не гоняют иначе время отклика упадет.
Так что немного мимо."

Сложные для MySQL имелось в виду :)
Хреновый у него опитимизатор :) Только во флейме на эту тему я не участвую :)


"Не сочтите за назойливость , я хочу знать как?"

Ну как, в данном случае просто взять и запросить. Не так уж много сортов пива.

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

Блин, я же специально сказал данные для анализа за большой переиод. Если я хочу проанализировать на сколько процентов поднялись/упали продажи пива за этот месяц по сравнению с предыдущим, то мне НЕ НАДО знать ТОЧНОЕ количество. Ну какая разница 14324 или 14326 в ДАННОМ СЛУЧАЕ ??? Я не предлагаю читать грязные данные для выписки по счетам в банке !!!

"Суть в том , что я технический специалист и мне "success story", до лампочки, мне необходимо наоборт снять всю эту мишуру и докопаться до истины, найти узкие места . И когда наконец это будет найдено, вот тогда вы реально понимаете почему Oracle cтоит 40к за процессор, а не 20к как MSSQL да и еще много чего. "

Ну понятно, что success story маркетинг от любой компании, там все может быть приурашено и может быть не все так гладко проходило. Только не будут банки и прочие серьезные организации (вот говорят СберБанк перешел) внедрять продукт, который их не устраивает. Если SQL server устраивает СберБанк, значит 99% задач в том числе и очень серьезных он может выполнять. Вы думаете в СберБанке не думали о получении согласованных отчетов по большим объемом данных и т.д. Ну может блокировочник работать в серьезных задачах. Не хотите верить, не надо :)


"Ядро ОС , что на них не переключает контекст? Переключает. "

Нет, не переключает !!! Зачем ??? Они спят на объекте синхронизации и не входят в список октивных процессов.

"Ну вообщето Oracle никак не переключает контекст между процессами - это прерогатива ядра ОС. "

Разумеется. Так вот накладные расходы ОС, которые расходуют те же ресурсы сервера, для версионника всегда будут больше.

"Я имею ввиду, что отчет строится используя подтвержденные изменения на момент запуска запроса, а не как в случае с MSSQL берется "то что есть".

Ну естесвенно, отчет строится используя подтвержденные изменения. Строка может измениться после начала транзакции, но не после того как транзакция считала эту строку (если транзакция отчета идет с уровнем repeatable read и выше для получения согласованного отчета). Данные будут не менее согласованными, чем в Oracle и даже могут быть более актуальными.
28 июл 04, 12:02    [841549]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Yo!
Guest
2Nord

Вам пытаются показать что без грязного чтения на одной машине OLPT нельзя получить отчет, в банке у них отдельный сервер для отчетов, т.е. для средней канторы получается 40K - oracle, а для mssql нужно 2 сервера (по 20К) + железо + отсталось mssql по фишкам на 5-10 лет.
28 июл 04, 12:12    [841592]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Nord
Guest
"Вам пытаются показать что без грязного чтения на одной машине OLPT нельзя получить отчет, в банке у них отдельный сервер для отчетов, т.е. для средней канторы получается 40K - oracle, а для mssql нужно 2 сервера (по 20К) + железо + отсталось mssql по фишкам на 5-10 лет."

Эээ...не согласен.
1. Два сервера не часто нужно. В крайнем слачае можно просто рядом другую базу создать. Это же не Oракл :)
2. Два сервера по 2 проца вполне могут быть дешевле 1 сервера в 4 проца.
3. Что вы имеете вообще в виду под средней конторой ? Количесво пользователей, объемы данных, количесво серверов ?
28 июл 04, 12:22    [841637]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Yo!
Guest
если у вас критическая к отклику OLPT задача то на платформе MS вы не можете на этом сервере пускать длинные транзакции (для отчетов) ни при каких условиях, апгрейд железа не спасает. вы обязаны выносить расчет отчетов на отдельный сервер или ditry read.
28 июл 04, 12:32    [841695]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
EugeneS
Member

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

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

Ага.
Блажен кто верует.
Вы когда нибудь пробывали сделать нечто подобное ?
Если бы пробовали, то не говорили бы.

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

Вы видели на сайте Microsoft где бы говорилось о недостаках функциональности продукта ?
Тоже самое на сайте Oracle ?
Никогда и вряд ли увидете.


P.P.S Може всё-таки не будем сравнивать СУБД - какая лучше , какая хуже? Будем сравнивать применение конкретных инструментов для конкретных задач при конкретных условиях? И способы разрешения тех или иных ограничений?
А то получается вопрос: что лучше - яблоки или гвозди?[/quot]

Мы сравниваем функциональность , для того чтобы классифицировать продукт.
Речь не идет о хуже или лучше, речь идет применимости того или иного класса продукта для той или иной задачи.
Возить грунт можно и на пикапе и на Белазе, вопрост что для вас нужнее.
А вот рассказывать , что мол де я обойдусь пикапом, хотя явно нужен как минимум самосвал .... уж извольте .
28 июл 04, 12:46    [841767]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
andsm
Member

Откуда: Москва
Сообщений: 1320
Блог
EugeneS
1.Ну то есть серьезные системы лучше на MSSQL не строить, иначе денег не досчитаться ?
Вот вам пример "Процессинговый центр" у него не бывает ситуации когда он простаивает, поэтому ночь его как вы понимаете не спасет.
2.Агрегирующих таблицы не спасут так же, по причине получаются путем snapshot-а реальных таблиц на определенный моментвремени , а поскольку консистентную копию таблицы на определенный момент времени получить в MSSQL мягко говоря затруднительно, то и агрегирующим таблицам тоже грош цена.
3. О да это возможно выход , только это как бы это сказать дополнительные телодвижения и дополнительный overhead на создание и подержание OLAP БД.

Знаю как устроена одна из процессинговых систем. Сделана на Oracle. Разделена на OLTP-базу, для которой время отклика критично и куда первоначально попадают все данные, и база отчетности - туда данные переносятся из OLTP базы. Всякие отчеты для банков строятся по базе отчетности.. Если Oracle так хорош что все позволяет, то зачем это разделение нужно? - Почему то используется тот же подход который, при хорошем проектировании, нужно использовать для блокировочников.
И еще, про супернадежность Oracle - недавно в одном процессинговом центре база просто легла. На несколько часов. И перед тем как лечь прошло несколько транзакций в которых сняли денег больше чем у них было на счету - хотя все проверки были, все там было написано максимально правильно. Но запросы начали выдавать неверный результат.
28 июл 04, 12:53    [841804]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
Nord
"Вам пытаются показать что без грязного чтения на одной машине OLPT нельзя получить отчет, в банке у них отдельный сервер для отчетов, т.е. для средней канторы получается 40K - oracle, а для mssql нужно 2 сервера (по 20К) + железо + отсталось mssql по фишкам на 5-10 лет."


Nord
1. Два сервера не часто нужно. В крайнем слачае можно просто рядом другую базу создать. Это же не Oракл :)


А это не создаст тот дополнительный overhead про который все время говорите со стороны Oracle?
А на подержку актуальности данный во второй БД?

Nord
2. Два сервера по 2 проца вполне могут быть дешевле 1 сервера в 4 проца.

Так и есть.
28 июл 04, 12:56    [841818]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Nord
Guest
2 EugeneS
"А это не создаст тот дополнительный overhead про который все время говорите со стороны Oracle? "

Сама по себе дополнительная база не создаст overheada.

"А на подержку актуальности данный во второй БД?"

На поддержку актуальности, конечно, ресурсы потребуются.

См. пост andsm в Оракле часто делают также, потому что overhead на поддержание одновременного доступа в Оракле очень не маленький и отчеты по-любому лучше гонять в отдельной базе на отдельном сервере. Оракл может гарантировать маленькое время отклика короткой пишущей транзакции, это его несомненный плюс, однако он достигается большим расходом ресурсов сервера.
28 июл 04, 13:04    [841861]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
EugeneS
Member

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

Знаю как устроена одна из процессинговых систем. Сделана на Oracle. Разделена на OLTP-базу, для которой время отклика критично и куда первоначально попадают все данные, и база отчетности - туда данные переносятся из OLTP базы. Всякие отчеты для банков строятся по базе отчетности.. Если Oracle так хорош что все позволяет, то зачем это разделение нужно? - Почему то используется тот же подход который, при хорошем проектировании, нужно использовать для блокировочников.
И еще, про супернадежность Oracle - недавно в одном процессинговом центре база просто легла. На несколько часов. И перед тем как лечь прошло несколько транзакций в которых сняли денег больше чем у них было на счету - хотя все проверки были, все там было написано максимально правильно. Но запросы начали выдавать неверный результат.

Это разделение делается по другой причине.
Есть так называется Back-Office и Front-Office.
Back-Office отвечает за взаиморасчеты банков с платежной системой.
Front-Office отвечает за авторизацию клиентов и блокировки сумм на остатках.
Так понятней?

Причин почему может умереть Oracle море, ну и о чем это говорит?
Каковы причины были в вашем случае я не знаю , и вы скорей всего тоже.
То с чем сталкивался я - это когда контора вместо того чтобы нанять DBA берет студента, который что-то читал про Oracle.
Результат ,как раз тот что вы описали.

автор
И перед тем как лечь прошло несколько транзакций в которых сняли денег больше чем у них было на счету - хотя все проверки были, все там было написано максимально правильно. Но запросы начали выдавать неверный результат.


Вы о чем , про то что транзакции потеряли при восстановлении?
Я, вам скажу по секрету, что с дебетовой карточки при определенных условиях можно снять больше денег чем на ней есть.
Вопрос только при чем здесь Oracle?
Oracle там только один из инструментов но не единственный на цепочке от банкомата , до счета внутри СУБД.

Вы вообще работали в процессиге?
Сдается нет.
28 июл 04, 13:11    [841890]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
>Причин по которым был затеян переход может быть масса, но это так сказать скрыто от нас, кто ж вам покажет оборотную сторону медали, вот именно оборотной стороной медали я и интересуюсь.
Ну, по крайне мере один из интегральных параметров мы можем вычислить - в целом реализация старой системы была хуже, чем у новой. Потому и поменяли.
>А вот рассказывать , что мол де я обойдусь пикапом, хотя явно нужен как минимум самосвал .... уж извольте .
Если это позволит мне вывезти весь грунт за приемлимое время и обойдется дешевле - буду возить пикапом.
P.S. Мне давеча стену в квартире ломали - делал кладовку. я типа самый умный, давай искать всякие болгарки, камнерезы и т.д. а пришли два тощеньких паренька и за 40 минут 8-ми килограммовой кувалдой раздолбали стену. Мне это обошлось на ~50 баксов дешевле, чем "по правильному" :-)
28 июл 04, 13:14    [841902]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
>То с чем сталкивался я - это когда контора вместо того чтобы нанять DBA берет студента, который что-то читал про Oracle.
Ну дык у MS SQL ситуация то такая же :-) Берем студента (а их много) и он валит любую систему.
только давайте всё-таки сравнивать при прочих одинаковых условиях - нормальное железо, нормальная система, нормальный DBA. А то получается - MS SQL при хорошем проекте - свалится всегда, а Oracle - только если руки у DBA ну очень кривые....

и насчет согласованности - я вполне могу себе представить структуру данных, по которой отчеты будут читаться dirty read'ом и при этом получать буду согласованные данные, не теряя при этом ресурсов на версии и т.п. (т.к. я - адепт MS SQL :-) )
28 июл 04, 13:28    [841958]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Yo!
Guest
автор
потому что overhead на поддержание одновременного доступа в Оракле очень не маленький и отчеты по-любому лучше гонять в отдельной базе на отдельном сервере. Оракл может гарантировать маленькое время отклика короткой пишущей транзакции, это его несомненный плюс, однако он достигается большим расходом ресурсов сервера.


какой оверхед ? смотрите тесты OLPT tpc-c, нет никакого оверхеда.
28 июл 04, 13:28    [841960]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Nord
Guest
2 Yo
"какой оверхед ? смотрите тесты OLPT tpc-c, нет никакого оверхеда"

Ну для начала смотрим, Top Ten TPC-C by Price/Performance. Нету Oracla.
Потом пытаемся найти хоть один достойный результат Oracle до 100.000 tpmC (или 230000 транзакций) в минуту. tpmC - это не количество транзакций в минуту, а так называемый business throughtput, количество транзакций ввода нового товара. Реально этих транзакций 43-45 процентов из общего количества. Опять нету Oracle. У вас есть много систем с более 230.000 транзакций в минуту ???
28 июл 04, 14:00    [842150]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Yo!
Guest
причем тут price ?? мы о оверхеде или как ? зачем ораклу что-то показывать на угрушечной системе в пару сотен транзакций ? этих результатов он добился лет 20 назад, сейчас он показывает милионы транзакций.
28 июл 04, 14:12    [842213]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
Миллионы транзакций показывает и блокировочник DB2.
Причем позиция #4 проигрывает позиции #1 всего 31% производительности. Имея в _4_ раза меньше процессоров.
28 июл 04, 14:18    [842255]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Yo!
Guest
:)
#1 вообще-то кластер (на интеле), а #4 ibm power4+ :) т.е. на каждом чипе по 2 ядра ...
28 июл 04, 14:25    [842293]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
Ну не Power4+, а Power5. Не простой Intel а Intanium2. :)

Не нравится это сравнение.Cравни позиции 6 и 7. Обрати внимание на количество устройств ввода вывода и сколько каждая бд записала в журнал.
28 июл 04, 15:00    [842549]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Yo!
Guest
ну :) оракл то в переди, т.е. на одинаковом железе оракл справляется с OLPT задаче как минимум не хуже, если в 3 раза увелить кол-во контролеров то и лучше. а теперь плавненько переходим на тесты реальных задач SAP ... :)
28 июл 04, 15:11    [842632]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Nord
Guest
Yo!
ну :) оракл то в переди, т.е. на одинаковом железе оракл справляется с OLPT задаче как минимум не хуже, если в 3 раза увелить кол-во контролеров то и лучше. а теперь плавненько переходим на тесты реальных задач SAP ... :)


Ну :) А до этого впереди был MS SQL, а до этого DB/2 :)
Контроллеры денег стоят вообще-то. Хорошие контроллеры очень даже хороших денег :) А если MS SQL в три раза память больше купить так он вообще всех порвет !!! :)
Железа одинакового в TPC-C не бывает. Посмотрите, например, на результаты IBM: для Oracle storage на поллимона дороже.
28 июл 04, 15:22    [842700]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Yo!
Guest
однако он достигается большим расходом ресурсов сервера.

ваши слова ? так вот они не верны, есть немного бОльшее расходывание на I/O в сравнении с блокировочником, какие бонусы это дает тут уже не однократно рассписывали.
28 июл 04, 15:27    [842719]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
Так и запишем???
Для получения производительности Oracle большей по сравнению с Db2 на 1% нужно иметь раза больше в 2 раза котроллеров
28 июл 04, 15:31    [842745]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Yo!
Guest
в 3 :)
чтоб получить бОльшую да, чтоб одинаковую нет. поэтому ibm уже лет 10 приходится ставить рекорды на оракле а не своем db2.
28 июл 04, 15:37    [842769]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Nord
Guest
Упс, не туда глянул :) Всего на 250 тысяч :)
Правда Oracle надо 66 контроллеров, а DB/2 - 26. Причем самое интересное. что одинаковые контролеры стоят для Oracle 2582, а для DB/2 - 3100 :)

Yo!
однако он достигается большим расходом ресурсов сервера.

ваши слова ? так вот они не верны, есть немного бОльшее расходывание на I/O в сравнении с блокировочником, какие бонусы это дает тут уже не однократно рассписывали.


Во-первых, I/O самый дорогой ресурс и есть :)
Во-вторых, дело не только в I/O. А накладные расходы ОС, а расходы на получение старых версий...
28 июл 04, 15:37    [842771]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Nord
Guest
Yo!
в 3 :)
чтоб получить бОльшую да, чтоб одинаковую нет. поэтому ibm уже лет 10 приходится ставить рекорды на оракле а не своем db2.


Довольно странное утверждение :)
Если посмотреть на 2-й результат в топе (и первый среди некластерных) и сравнить его в 6-м на Oracle, то явно видно, что
a) результат DB/2 на 33% лучше
б) соотношение price/performance у DB/2 на 57% лучше
28 июл 04, 15:42    [842796]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
По поводу SAP
AP SD Standard Application Benchmark Results, Three-Tier Internet Configuration
Первые 2 позиции DB2.
28 июл 04, 15:47    [842824]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 14 15 16 17 18 [19] 20 21 22 23 .. 26   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить