Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 9 10 [11] 12 13   вперед  Ctrl
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
onstat
Guest
Pi


автор
Я где то видел пример с одновременным дебетованием двух счетов,
который для корректного разрешения требует serializable,
что автоматом приводит либо нарушении целосности данных, либо необходимости явного блокирования записи.
Т.Е. чтобы подстраховать целостность данных oracle програмист должен
работать на вашем уровне 1. И запретить распаралеливание, хотя
блокировочник сможет паралелиться на чтении и при этом корректно обработать эту ситуацию.


Dear ASCRUS,
Вы так здорово расписали проблемы блокировочников, и главное - показали решения этих проблем, что остается сказать
БОЛЬШОЕ СПАСИБО!

Но вот что касается версионика - ничего не понял. Какое распаралеливание запретить? Кто это где это читал? Может, не дебетирование двух счетов, а дебетирование одного счета с кредитированием другого в агло-саксонском конто? Так это вроде проблема именно блокировочника!
Простите за бестолковость, но можно ли на примерах?


Я хотел привести пример с одновременным дебетованием счета двумя сессиями, ошибся, признаю.
А вы нам раскажите как избежать нарушения целосности данных
, please


Сесия 1 открывает транзакцию , считывае данные счета.
дебетует его.
Сессия 2 открывает транзацию и берет состояние того-же счета.
(Откуда она его берет? Правильно из сегмента отката. ) И дебетует его.
транзакция 2 комитится.
Транзакция 1 комитится.


с уважением onstat.
1 окт 04, 16:10    [1002703]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Pi
Member

Откуда:
Сообщений: 278
Зл0й
Про "дырки" в последовательности ID вот какая штука:
1. можно требовать чтобы ID присваивались строго по порядку 1,2,3,4,5,...
2. можно допускать 1,4,7,9 и требовать чтобы более поздние ID были больше более ранних
3. можно просто требовать только уникальности ID без каких-то иных ограничений.

Разные задачи - разные требования. В случае 1. ничто, кроме жесткой сериализации в полном соответствии с ANSI-стандартом, не спасет "отца русской демократии". Это тот случай когда от ораклового serializable (который на самом деле snapshot) толку не много. Производительность будет примерно одинаково паршивая, ибо мы фактически исключаем параллельность транзакций.

Варианты 2 и 3 реализуемы на оракловом уровне изоляции snapshot, причем за счет
параллельности транзакций работают быстрее чем 1. То есть, при всех прочих равных (например когда все - в Оракле) 3. быстрее чем 2. быстрее чем 1.

Проблема с блокировщиками в том, что варианты 2. и 3. в них зачастую выполняются так же медленно как и 1. Если предположить что разработчики Оракла не глупее и не умнее других, что первый вариант работает в Оракле и Информиксе (DB2, Sybase, MSSQL) примерно одинаково. Соответственно для реализации 1. все равно какую СУБД брать. Зато для реализации вариантов 2. и 3. предпочтительнее Оракл.

ЗЫ а на самом деле, обычно ставят ту СУБД которая в организации уже есть. Под которую уже есть опытные админы, итп. Надежность и отсутствие "сюрпризов" перевешивает все технические достоинства и недостатки СУБД. Ибо решения принимает менеджмент, которому важнее всего чтобы "не падало".


Такой вот недоуменный (puzzled) вопрос - какая такая сериализация нужна для пунктов 2 и 3 на Oracle? уровень изоляции snapshot? А что, sequence не устраивает? И почему, собственно, вариант 3 быстрее будет на Oracle?

Да и, честно говоря, быстродействие системы будет зависеть от описываемой проблемы только в случае истинно "кривых ручек". Выбор версионник-блокировщик как раз важен в других случаях, например, в случае отчетов из активной базы данных. Обратите внимание, что Microsoft бесплатно сует в версию SQL Server еще и Analyse server. А уж Билла Сами-знаете-какого в непонимании конкуренции обвинить трудно.
1 окт 04, 16:19    [1002751]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
>У Вас, лично, Oracle купленный, а ли краденый?
Я на одном предприятии использую краденый акцес, а на другом как разработчик работаю на бесплатном Oracle. Вот я и думаю, что оба такую маркетинговую политику ведут, чтобы если есть деньги то платили, а если нет то лучше пусть пользуются этим продуктами, чем другими бесплатными или ворованными. Больше спецов по ним будет. А фирма, которая платит выберет продукт у которого больше спецов в округе найдется. Только Oracle откровенно предлагает бесплатный для разработки, а MS якобы против, но их ворованных продуктов полно. Но естественно для эксплуатации оба ворованные, но суть та же. Поэтому ворованность продукта не вызыает у меня моральных страданий - производителю это нужно в стратегических целях.
Может я ошибаюсь?
1 окт 04, 16:40    [1002857]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Рыжий Кот
Member

Откуда: Мягкий Диван; [забанен] Рустамом; [разбанен] П02;
Сообщений: 21678
Pi
Рыжий Кот

По количеству инсталляций лидирует акцец.
З.Ы. Поменьше смотрите рекламу.
Картинка с другого сайта.


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

Это во-первых. А во-вторых, в 80 % случаев вместо Access можно поставить Oracle, из оставшихся (я имею в виду устаревшее железо, нехватку ОЗУ и прочие нищенские траблы) в 15% - MS SQL . Не ставят только потому, что МОЖНО не ставить. А Вы попробуйте продавать билеты на все поезда или все авиарейсы России на Access.

Так что ездите на своем велосипеде, но на форуме автолюбителей лучше помолчите.


В начале моего поста был смайлик.
Извините, что замахнулся на святое - Oracle, сравнив его с Аксесом.
Мой "велосипед" (проект на ASA) едет быстро, а самое главное одновременно в трех странах, операционисты уходят домой в 6, раньше при том же штате уходили в 9.
1 окт 04, 16:54    [1002933]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
автор
у syabase настроек минимум, админ повлиять на процессы в субд практически не может, поэтому и надобность в нем минимальная.
то что эти настройки сделали предефинены и разнесли в 3 субд сути не меняет. что можно настраиват в ASA ? как можно повлиять на скорость конкретной задачи ? добать индекс - все. сравните с ораклом. что есть IQ ? как можно повлиять на скорость запроса ? сравните с ораклом.

А я и не сомневался в таком ответе :) Sybase ничего не делала и никуда ничего не разносила по той простой причине, что у всех 3-х продуктов свои команды, которые кстати между собой в процессе разработки никак на связаны и каждое СУБД движется своим путем.

"Добать" индекс вполне удачное решение для OLTP, там большего и не надо. Что в ASA с успехом и используется. Все остальное о том, что сделано для разруливания запросов в ASA можете смело почитать в доке. Если сказать одной фразой - "разруливанием занимается проектировщик БД на этапе ее проектирования".

Ну а насчет Sybase IQ - хорошо же Вы "читаете" приведенные ссылки, где расписано за счет чего она быстро обрабатывает большие массивы данных и почему в ней не надо влиять на скорость запроса в не зависимости от его селективности, что соотвествующе и приводит к тому, что в ней не нужны люди, которые при критических нагрузках буквально начинают ее держать ручками :) Если Вы думаете, что без вмешательства админа IQ будет выполнять любой сложности и селективности аггрегатные запросы на террабайтной БД дольше стандартного времени отклика системы, то можете считать так дальше, переубеждать Вас никто и не собирается, как впрочем и чего то разьяснять в техническом плане.

автор
на счет прайс перфоменс у mysql он круче ну и что ? мне например не понятно в чем тайный смысл IQ, который в ad hoc ничего показать не может , но при этом требует еще и OLPT сервер, цена которого почему то в price/perfomenc как то не фигурирует ... я понимаю terradata - которая там оракл в 2-3 раза делала.

Интересно, а Вам никогда не приходила в голову мысль, что на сайте tpc.org выложены только те результаты тестов, которые были когда то и кем то проведены и выложены ? Даже на их сайте есть предупреждение, что эти результаты не говорят ни о чем, кроме как о том, что вот на такой то платформе в такой то конфигурации такой то сервер показал такие то результаты и стоимость владения на каждое его подключение составила столько то денег. Я смотрю для Вас этот сайт вроде ветхого завета, что там написано, только то в жизни и существует. Я все как то предпочитаю своими глазами смотреть - вот например, я своими глазами видел IQ на простеньком однопроцессорном PC с 512 RAM - скорость выполнения аггрегированного тяжелого запроса, охватывающего по фильтру миллионы записей - нажимаешь в ISQL кнопочку F5 и сразу же получаешь ответ, даже секунды не проходит и никаких оптимизаций, индексов и ручных настроек :) А еще мне показывали запрос на 8 страничек формата A4, который так же выполнялся за 2-3 секунды по террабайтной БД и опять никакого ручного фактора. Вот тут наглядно и видно, что сервер заточен именно под выполнение аналитических запросов, поэтому он и не проседает и админ ему нужен только для отслеживания политики безопасности и закачки данных с OLTP серверов.
1 окт 04, 17:09    [1003002]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Pi
Member

Откуда:
Сообщений: 278
Scott Tiger
Зл0й
Могу например использовать для генерации id такую штуку как sequence. Масштабироваться будет заметно лучше чем selec max(id)+1 с блокировкой.


Лучше, но нелинейно. Для прокачки больших объёмов данных сиквенсами лучше не пользоваться. В OLTP проблем обычно нет (хотя, может, я не видел OLTP с таким количеством insert-ов в секунду :) ).


А что тогда, собственно? Насколько я помню документацию 7-й версии Oracle (а тогда основная проблема была производительность OLTP), то там рекомендовали вообще не использовать индексов, ну, кроме уникального ключа. Однако ж sequence существовали, к разряду проблемных их не относили, только предлагали их прокэшировать. Ну, и где-то в 8-ке появились инвертные ключи...
1 окт 04, 17:16    [1003041]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Pi
Member

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

А вы нам раскажите как избежать нарушения целосности данных
, please


Сесия 1 открывает транзакцию , считывае данные счета.
дебетует его.
Сессия 2 открывает транзацию и берет состояние того-же счета.
(Откуда она его берет? Правильно из сегмента отката. ) И дебетует его.
транзакция 2 комитится.
Транзакция 1 комитится.

с уважением onstat.


Ну, я делал это по-разному.
Если такое происходит как что-то внутреннее (например, изменение главной книги при отпуске товара), то Сесия 1 открывает транзакцию select...for update [nowait] далее, я думаю понятно.
Если же речь идет о записи в книге отпуска товара (так сказать, заглавный update)
то тут уже могу и так:
Сесия 1 открывает транзакцию , считывае данные счета.
дебетует его....
Транзакция 1 проверяет неизменность строки и в случае ее "стабильности" - комитится.

Парадокс состоит в том, что при некоторых условиях режим serializable на Oracle работает быстрее (sorry за отсутствие ссылки).

А что, MS SQL предлагает что-то другое?

А вот возвращаясь к Вашему же примерчику

автор
SELECT *
FROM Table
UNION ALL
SELECT *
FROM Table;

то все становится на свои места - в Oracle я даже не задумывался над проблемами, о которых Вы рассказали. Я без иронии. Их там, в Oracle , просто нет. А ведь мы еще не дошли до транзакций Read-only...

Искренне Ваш,
любопытствующий Pi
Ктстати, может Вы подскажете мне ответ на этот вопрос
1 окт 04, 17:41    [1003173]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Pi
Member

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

Интересно, а Вам никогда не приходила в голову мысль, что на сайте tpc.org выложены только те результаты тестов, которые были когда то и кем то проведены и выложены ? Даже на их сайте есть предупреждение, что эти результаты не говорят ни о чем, кроме как о том, что вот на такой то платформе в такой то конфигурации такой то сервер показал такие то результаты и стоимость владения на каждое его подключение составила столько то денег.


Как-то со временем у всех выветрилось из головы, что tpc.org тестирует компьютеры, а не софт.
Вендор говорит - у меня сервер лучше вашего, быстрее. А конкуренты - с чего бы это? А вот - смотрите тесты
Только при таком раскладе все на своих местах - и почему базы тестовые такие примитивные (по 5 таблиц), и почему кто-то из вендоров СУБД не играет в эти тесты - и ничего, лица не теряет. Теряет лицо только поставщик железяки
1 окт 04, 17:50    [1003201]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Pi
Member

Откуда:
Сообщений: 278
К моему предыдущему постингу:

Меня тут вот коллеги поправляют- посмотрите на результаты тестов
Какие там компании? Что, там есть Oracle, Sybase, Miscrosoft?
Нет, там - Sun, HP, Dell.
1 окт 04, 17:53    [1003210]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Yo!
Guest
автор
"Добать" индекс вполне удачное решение для OLTP, там большего и не надо.


чтоб получить посредственую скорость - согласен. но админ оракла обычно еще задумывается а не нужно ли разбить на партиции, выяснить какой из 4 видов btree индексов будет более эфективен или лучше bitmap индекс пременить, создать materialized view, какую сволочь ограничить в проце и т.п. я понимаю что в ASA/IQ/ASE этого нет и настраивать соответствено нечего.
нет настроек, нет админа, все логично.

автор
Я все как то предпочитаю своими глазами смотреть - вот например, я своими глазами видел IQ на простеньком однопроцессорном PC с 512 RAM


опять душетрепательные истории :) вы вам верим ... и сами можем в любой момент на 512 RAM любую агрегацию за 1 секунду выдать хоть по сотням терабайтов. почитайте историю историю про то как в 98ом оракл давал милион если кто-то докажет что mssql на TPC-H не в тысячу раз медленее ... в 99 правда похоже отдал, но смысл в том что хранить агрегатные значения в materialized view много ума ненада.
а на счет сказок ... вы тесты давайте, тесты, а сказки детям.

2Pi
в tpc встечаются тесты разных субд на одной и той же железяке + производители субд любят таким тестом гордится у себя на сайте
1 окт 04, 17:56    [1003225]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Pi
Member

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

А вот насчет высказывания "сайбез это для малого бизнеса и с ораклом совершенно не конкурирует" то я скажу наоборот - это Оракл в решениях SMB с Sybase ASA совершенно не конкурирует и проигрывает по всем позициям: цене, требованиям железу, стоимости разрабки и сопровождения решений, администрированию и т.д.


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

Если
Oracle дороже, требовательнее к железу, стоимости разработки, сопровождению и администрированию - то несоменно, что Oracle более тяжелое решение, а Sybase ASA - более легкое. И, соответственно, более пригоден для малого бизнеса

Это вывод сделан на основании Вашего утверждения и аристотелевой логики...
1 окт 04, 18:08    [1003255]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
onstat
Guest
Pi
onstat

А вы нам раскажите как избежать нарушения целосности данных
, please


Сесия 1 открывает транзакцию , считывае данные счета.
дебетует его.
Сессия 2 открывает транзацию и берет состояние того-же счета.
(Откуда она его берет? Правильно из сегмента отката. ) И дебетует его.
транзакция 2 комитится.
Транзакция 1 комитится.

с уважением onstat.


Ну, я делал это по-разному.
Если такое происходит как что-то внутреннее (например, изменение главной книги при отпуске товара), то Сесия 1 открывает транзакцию select...for update [nowait] далее, я думаю понятно.



Вы вынуждены делать так всегда когда собираетесь
что либо делать с записью. А если ее кто то просто читает,
то ваша сессия будет ждать пока читающий отпустит запись(закроет курсор).

Так в чем же преймущество перед блокировочником которому для проведения
этих операций не нужно явно блокировать запись на изменение?


Pi


Если же речь идет о записи в книге отпуска товара (так сказать, заглавный update)
то тут уже могу и так:
Сесия 1 открывает транзакцию , считывае данные счета.
дебетует его....

Транзакция 1 проверяет неизменность строки и в случае ее "стабильности" - комитится.


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

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


Pi


Парадокс состоит в том, что при некоторых условиях режим serializable на Oracle работает быстрее (sorry за отсутствие ссылки).


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

ИХМО Не очень дешевое удовольствие, этот сегмент отката.
И выгода от него сомнительна для вышеперечисленных случаев.


Pi


А что, MS SQL предлагает что-то другое?

А вот возвращаясь к Вашему же примерчику

автор
SELECT *
FROM Table
UNION ALL
SELECT *
FROM Table;

то все становится на свои места - в Oracle я даже не задумывался над проблемами, о которых Вы рассказали. Я без иронии. Их там, в Oracle , просто нет. А ведь мы еще не дошли до транзакций Read-only...


Ну это рассказал не я. И это большая проблема чем проверять
курсор на стабильность.

А давайте дойдем до транзакций Read-only, и там тоже сравним.


С уважением, onstat
1 окт 04, 18:20    [1003292]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Pi
Member

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

P.S. Про криптографию БД и логов не спрашиваю, и так знаю, что в Оракле ее нет :)


ASCRUS, скажите пожалуйста, а в Sybase это есть?

Если есть, то какие преимущества это дает по сравнению с криптографией на уровне операционной системы?

И уж последний вопрос, логически направшивающийся - backup криптографированной базы тоже криптографирован?

Был бы очень благодарен за ответ и за соответсвующие ссылки.

Все так же искренне Ваш
любопытствующий Pi
1 окт 04, 18:28    [1003308]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Pi
Member

Откуда:
Сообщений: 278
onstat
Pi
onstat

А вы нам раскажите как избежать нарушения целосности данных
, please


Сесия 1 открывает транзакцию , считывае данные счета.
дебетует его.
Сессия 2 открывает транзацию и берет состояние того-же счета.
(Откуда она его берет? Правильно из сегмента отката. ) И дебетует его.
транзакция 2 комитится.
Транзакция 1 комитится.

с уважением onstat.


Ну, я делал это по-разному.
Если такое происходит как что-то внутреннее (например, изменение главной книги при отпуске товара), то Сесия 1 открывает транзакцию select...for update [nowait] далее, я думаю понятно.



Вы вынуждены делать так всегда когда собираетесь
что либо делать с записью. А если ее кто то просто читает,
то ваша сессия будет ждать пока читающий отпустит запись(закроет курсор).

Так в чем же преймущество перед блокировочником которому для проведения
этих операций не нужно явно блокировать запись на изменение?

Был вопрос как это сделать - я показал (в надежде, что может, расскажут что интересного еще).
Теперь о преимуществе блокировочника. Его нет. В приведенном случае. Выше в форуме уже четко писалось г-ом ЗлОй - при конкуренции писатель-писатель "всякие йогурты одинаково полезны".
Мне показалось, что Ваша ошибка - в фразе для проведения этих операций не нужно явно блокировать запись на изменение
Нужно! Просто он - блокировщик, - даже прочитать ее не сможет, пока другой не отпустит. А Oracle - сможет.
Я начинал с 7-й версии Oracle и там было хорошо сказано - писатели не блокируют читателей. По умолчанию. А писателей - да, блокируют. А как иначе? Впрочем о Блокировках, модах изоляции и прочих скучных предметах Вы сможет прочитать здесь
1 окт 04, 18:50    [1003349]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Pi
Member

Откуда:
Сообщений: 278
onstat
Pi

Парадокс состоит в том, что при некоторых условиях режим serializable на Oracle работает быстрее (sorry за отсутствие ссылки).

Понятное дело, не нужно тратить ресурсы на перенос
данных в сегмент отката.
ИХМО Не очень дешевое удовольствие, этот сегмент отката.
И выгода от него сомнительна для вышеперечисленных случаев.

С уважением, onstat


Если Вы имеете ввиду под сегментами отката Rollback segement, то я все годы работал с мыслью, что
Oracle8i Concepts

Rollback Segments
Each database contains one or more rollback segments. A rollback segment records the old values of data that were changed by each transaction (whether or not committed). Rollback segments are used to provide read consistency, to roll back transactions, and to recover the database.

Выделено - мною
1 окт 04, 18:57    [1003356]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Pi
Member

Откуда:
Сообщений: 278
onstat
Pi


А что, MS SQL предлагает что-то другое?

А вот возвращаясь к Вашему же примерчику

автор
SELECT *
FROM Table
UNION ALL
SELECT *
FROM Table;

то все становится на свои места - в Oracle я даже не задумывался над проблемами, о которых Вы рассказали. Я без иронии. Их там, в Oracle , просто нет. А ведь мы еще не дошли до транзакций Read-only...


Ну это рассказал не я. И это большая проблема чем проверять
курсор на стабильность.
А давайте дойдем до транзакций Read-only, и там тоже сравним.
С уважением, onstat


Я не совсем понял Ваше замечание И это большая проблема чем проверять
курсор на стабильность
. Поясните, если будет возможность, пожалуйста!

А транзакция Read-only в Oraсle гарантирует согласованность на момент начала транзакции - но! не держит писателей при этом. Как это можно на блокировщике - я не знаю.

Преимущество транзакции Read-only Oraсle - это, естественно, очень сложные запросы к активно работающей базе данных. Без деградации скорости записи в базу.

А что Вы имели в виду?
1 окт 04, 19:03    [1003363]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Pi
Member

Откуда:
Сообщений: 278
Leonid
To Oracle-адепты:
Народ, а чем вы будете крыть, когда Yukon выйдет, где версионность "похитрее", чем версионность в Oracle ;)

А хорошо бы ссылочку!

Может, жизнь прожита зря?
1 окт 04, 19:06    [1003375]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Pi
Member

Откуда:
Сообщений: 278
Зл0й


Можно почесать репу, померить responce time, понять что при достаточно большом объеме транзакций НИКАКАЯ из современных СУБД эту задачу сама по себе не решает. Просто происходит "затык" чисто по записи, даже без чтения. Тогда к СУБД прицепляют внешний монитор транзакций, типа например Tuxedo. И живут долго и счастливо.



Ув-мый г. ЗлОй,
еще со времен работы в КП ВТИ (бывшый Юго-Запад ЭВМ-Комплекс) получил привитую коллегами уверенность, что внешний монитор транзакций очень хорош в разнородных средах, но не в интенсивных - тем более на всего 10 пользователях, как в Вашем примере).
Или это уже не так?
Чтобы не перерывать груды хлама, не бросите ли Вы свою любимую ссылочку по этому вопросу?

Искренне Ваш
любопытствующий Pi
1 окт 04, 19:14    [1003391]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Leonid

To Oracle-адепты:
Народ, а чем вы будете крыть, когда Yukon выйдет, где версионность "похитрее", чем версионность в Oracle ;)

А чего нам беспокоиться? У Оракла тоже есть и хитрая версионнось Workspace Manager с помощью, которой поддерживается многоверсионность таблиц. Не знаю насколько полно это реализует теоретические концепции на этот счет, но пока не сталкивался с задачей где это надо.
1 окт 04, 19:24    [1003406]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Зл0й
Member

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

еще со времен работы в КП ВТИ (бывшый Юго-Запад ЭВМ-Комплекс) получил привитую коллегами уверенность, что внешний монитор транзакций очень хорош в разнородных средах, но не в интенсивных - тем более на всего 10 пользователях, как в Вашем примере).
Или это уже не так?
Чтобы не перерывать груды хлама, не бросите ли Вы свою любимую ссылочку по этому вопросу?


Монитор транзакций удобен в разнородных средах тем, что если мы выполняем транзакцию против нескольких систем, например Oracle и DB2, то он координирует эту распределенную транзакцию. Головная боль о том "как обеспечить чтобы commit прошел в обеих базах или в обеих произошел rollback" уходит. Мы отдали монитору транзакцию а он нам вернул успех/неудачу, гарантируя синхронизацию между Oracle и DB2. Это замечательное свойство монитора транзакций можно использовать для масштабирования "вширь" (scale out). Грубо говоря если одна СУБД не справляется с потоком, мы его разбросаем по нескольким. Есть и другие способы масштабироваться с помощью монитора транзакций, см ниже.

Понятие "хорош" несколько неконкретное, поэтому рассмотрим более конкретные (измеримые) понятия:

Время отклика - время которое проходит от момента когда клиент запустил транзакцию, до момента когда он получил информацию о её успешном (или не успешном) завершении.

Пропускная способность - количество транзакций которое система обрабатывает в еденицу времени.

Максимальная пропускная способность СУБД - максимум транзакций в еденицу времени которые может обработать данная конфигурация (СУБД+железяка+...). Если поток транзакций превышает этот "порог" производительность начинает ухудшаться. Начинается пэйджинг-своппинг и иные проблемы.

Понятно, что пожертвовав временем отклика можно увеличивать пропускную способность. Поставили транзакции в очередь, чем длиннее очередь, тем больше время отклика. Зато, если размер очереди настроен так, что поток транзакций от монитора к СУБД не превышает её "порог", то мы гарантируем пропускную способность вплоть до максимальной.

Эту конструкцию можно представить себе ввиде труб. Поток транзакций - вода. В монитор транзакций входит широченная труба. У СУБД на входе труба, сечение которой = максимальной пропускной способности данной СУБД. Монитор транзакций - бассейн, достаточно большой, чтобы никогда не переполнялся. Вода (транзакции) течет от клиентов через широченную трубу в бассейн (монитор), а оттуда по более узкой трубе в СУБД. В случае масштабирования "вширь" имеем N узких труб и СУБД.

Что до ссылок - советую посмотреть TPC тесты где участвуют мониторы транзакций. Результаты там обычно весьма внушительные.
2 окт 04, 00:50    [1003727]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Небольшой ОФФ на тему "а что если..." и "что мы будем делать когда..."

Во-первых, когда M$ наконец разродится, тогда и посмотрим. Я работал с различными СУБД (Oracle, Informix, DB2, Teradata, MSSQL, MySQL). Сделают клевый MSSQL - будем с ним работать. Разумеется при условии что на нем будут работы за которые будут хорошо платить.

Пока в США расклад такой: Sybase преобладает на восточном побережье, его много в инвестиционных банках. Oracle преобладает на западном побережье. На среднем западе - территория Microsoft. Остальные СУБД не встречаются равномерно, вне зависимости от географии. Естественно при желании можно "нарыть" инсталляции опровергающие мою картинку. Но с высоты "птичьего полета" все выглядит именно так.

Глядя на историю Оракла, думаю что он не будет сидеть "сложа руки" пока M$ будет в муках "рожать" версионник. Думаю к тому моменту Оракл доведет до такой кондиции свой RAC, что сравнивать будут уже Oracle против Teradata. А сравнение Оракла с MSSQL просто будет мало кому интересно.
2 окт 04, 01:04    [1003733]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Pi
ASCRUS

P.S. Про криптографию БД и логов не спрашиваю, и так знаю, что в Оракле ее нет :)


ASCRUS, скажите пожалуйста, а в Sybase это есть?

Если есть, то какие преимущества это дает по сравнению с криптографией на уровне операционной системы?

И уж последний вопрос, логически направшивающийся - backup криптографированной базы тоже криптографирован?

Был бы очень благодарен за ответ и за соответсвующие ссылки.

Все так же искренне Ваш
любопытствующий Pi

Есть только в Sybase Anywhere Studio (ASA) по 128-ключу алгоритмом AES. Криптуются БД, логи, временные файлы во время работы и конечно же бакупы. Если на БД еще включить опцию CHECKSUM PAGE, то так же СУБД будет вести проверки на попытку стороннего изменения данных в БД (ну или сбойный сектор диска). В итоге в ASA получается 3 уровня защиты:
1. Хранение всех мета-данных, в том числе и о пользователях и правах в БД наглухо убирает возможность перенести БД на другую машину с свежеинсталированным СУБД и подключится к ней там под встроенной записью системного администратора (был случай, когда сисадмин в Австралии "забыл" пароль овнера БД - довольно печальным для него случай оказался, так как тут и бакупы ничем для него помочь не могли, хотя сам виноват).
2. Криптография БД по ключу и криптография протокола передачи данных (по Certicom или RSA)
3. Поддержка режима "U.S. Government TCSEC C2 requirements" (есть для всех версий, но официально лицензия выдана на версию 7, которая в свое время и ставилась для правительства).

В других СУБД от Sybase криптографии нет. В DSS сервере Sybase IQ собственный формат хранения данных, где БД полностью хранится в сжатом виде, а по страницам хранятся не записи таблиц, а каждое поле отдельно (фактически перевернули на 90 градусов).Отсюда у него и высокая скорость обработки информации (расжать быстрее, чем считать) и быстрое выполнение аггрегатов (фактически в нем каждая колонка уже сама собой является bitmap индексом и при выполнении аггрегата он уже работает только с нужными колонками, не заботясь особо, сколько их в таблице). Отсюда кстати и медленная скорость записи информации в транзакциях - фактически вставка одной записи с 5 полями означает запись в 5 страниц с их последующим сжатием (а из за сжатия странички в IQ с 64кб начинаются размером). Отсюда и вывод - что Sybase IQ хорош только как читатель (DSS) и ему необходим партнер-писатель (OLTP) и организация процесса периодического переноса информации на него (делаться может 2-мя путями - через выгрузку/загрузку данных в CSV файле или же подлючением OLTP к IQ в качестве удаленного сервера). Самое что мне например нравится в IQ - это то, что в отличие от OLAP не нужно проектировать кубы и преобразовывать информацию. Являясь внешне полноценной РСУБД, он позволяет создать на нем такую же структуру данных, как и у баз данных OLTP, один в один перегружать всю в нее исходную информацию, без какой либо ее предварительной подготовке или аггрегации, а дальше уж сам по ней может обычными запросами обрабатывать и добывать аналитическую информацию. Еще бы они доделали в него поддержку репликаций ASA MobiLink и такая связка стала бы очень удачной - где ASA может в оффлайне удаленно собирать и подготавливать информацию, потом файлом/почтой/ftp/online закатывать изменения в центральное хранилище данных IQ. Сейчас же приходится рядом с IQ ставить промежуточную ASA, репликации идут на нее и уж с нее потом на IQ.

Резюмируя (но не для Yo!, чтобы он снова критиковать не начал) - думаю все согласятся что если рассматривать Оракл (во всяком случае у нас в России), то он очень выгоден для централизованных решений (ставить его по десяткам удаленных точек без администратора как то мало людей соглашалось по моему опыту). Так же Оракл делает ставки на человеческий фактор (администраторов), так как грамотный специалист будет эффективнее AI любой сложности (на текущий момент времени не заглядывая в будующее). Такая архитектура Оракла позволяет все держать в одном месте, одновременно производить в реальном времени сбор и анализ информации, обрабатывать огромные массивы данных и обслуживать одновременно большое кол-во подключений, как читателей, так и писателей.

У Sybase в связке ASA (OLTP) + IQ (DSS) наоборот на лицо стремление к децентрализации и мобилизации решений, где все СУБД - являются автоматами и их архитектура изначально предназначена к работе без человеческого фактора в условиях удаленного функционирования и множеством способов передачи данных (вплоть до тети на поезде с дискеткой). Из за децентрализации получается, что изначально ASA работает с не такими большими по обьему БД и малым кол-вом подключений, что вполне позволяет успешно справлятся с работой. А из за того, что у Sybase IQ нет постоянных транзакций, то есть работает он в основном только как читатель, то соотвествующе это и позволило ему иметь собственную версию формата физического хранения БД, что вкупе с приличным интеллектуальным оптимизатором запросов автоматически ускоряет выполнение запросов без вмешательства человеческого фактора и необходимости ввода квот и ограничений на приоритеты, обьемы выполняемых запросов или кол-во подключений.

Какая из этих схем лучше ? Да никакая - это просто разные схемы и соотвествующе в них участвуют изначально разные СУБД. Их можно сравнивать между собой сколько угодно, но толку от этого будет мало - фичи Оракла не сдались в схеме, предложенной Sybase, фичи Sybase выглядят смешными в схеме работы Оракла. Можно ли сравнивать схемы ? Нет, тоже нельзя, так как для разных задач будет подходить лучше или схема централизации или схема децентрализации. Наш коллега Yo! уже давным давно утверждал, что централ всегда лучше и страшно огорчился, когда узнал, что выделенка оказывается по России еще есть не везде. Его высказывания по поводу КПК тоже были однозначно направлены в сторону аксиомы "или централ или вообще СУБД не нужна". Мне кажется, что он слишком плотно засел в колею "централизованных решений" и выглянуть из нее и оглядеться по сторонам уже не может (или не хочет), что кстати доказывает только то, что он просто никогда не делал децентрализованных решений и ничего более :)
2 окт 04, 09:52    [1003839]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Yo!
чтоб получить посредственую скорость - согласен. но админ оракла обычно еще задумывается а не нужно ли разбить на партиции, выяснить какой из 4 видов btree индексов будет более эфективен или лучше bitmap индекс пременить, создать materialized view, какую сволочь ограничить в проце и т.п. я понимаю что в ASA/IQ/ASE этого нет и настраивать соответствено нечего.
нет настроек, нет админа, все логично.

Если хотите, я Вам могу лично по почте BOL выслать по Sybase ASA и Sybase IQ, чтобы Вы точно могли знать, что они имеют, а что нет. А то неравноценно как то получается - я, прежде чем чего то написать хоть про Sybase, хоть про Оракл, трачу время, ищу информацию в интернете, аргументирую. А Вы просто скандачка рубите фразами, особо не вдумываясь, насколько они соотвествуют действительности.
2 окт 04, 10:55    [1003866]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
ASCRUS

Резюмируя (но не для Yo!, чтобы он снова критиковать не начал) - думаю все согласятся что если рассматривать Оракл (во всяком случае у нас в России), то он очень выгоден для централизованных решений (ставить его по десяткам удаленных точек без администратора как то мало людей соглашалось по моему опыту).

Не все. Способность СУБД поддерживать распределенные БД, т.е. по сути претендовать на название распределенной не определяется возможностью отсутствия администрирования как такового на удаленных точках. Там во главу вопроса ставится прозрачность распределения данных. И у Оракла для этого кое-что есть. Мы ведь создаем информационные системы не для того, чтобы только сократить администрирование. Есть и другие цели, иначе самая лучшая ИС та, которой нет, потому что тогда она точно не нуждается в администрировании. Т.е. нельзя сказать, что Оракл безнадежно проиграл какой-либо из СУБД в достижениях в области распределенной обработки информации. Надо трижды подумать какую СУБД выбрать для таких задач, иначе можно доиграться. А при учете админства лучше ориентироваться на то, каких спецов обитает в достатке, и какой продукт достаточно распространен. Все-таки это более традиционный подход.

У нас на фирме есть проект с распределенной БД. На удаленных точках - в разных частях страны стоят Ораклы и в центре (Центральный офис). Админами там просто кого-то назначили (там даже нет должности АБД). Написали доку с четким указанием что им и как смотреть - тоже не требует особых знаний. Впрочем, многие из них не утруждали себя и ее чтением. Практика показала - отказов в течении 2 лет было не много - около 10. Большинство было связано с сетью - решали админы сетей, хотя обнаруживали АБД.
Хотя до Томаса Кайта и мне - разработчику этой части задачи далеко, а тем админам, некоторые из которых вообще не замарачиваются на чтениях литры или только начали работать с Ораклом - тем более. Т.е. вопросы квалификации админа не критичны. Однако, на одной точке опытный админ, но у него 10 серверов и с другими задачами.

Кроме того, мне не совсем ясно, что значит отсутствие администрирования как такового. Есть теория надежности, согласно, которой любое устройство обязано рано или поздно отказать, и чем сложнее система, тем вероятность отказа увеличивается при прочих равных условиях. А БД все время меняет свое состояние - как минимум увеличивается в объеме. Т.е. какое-то админство не избежно. Те, кто ставят ИС без админства вообще рано или поздно могут быть сильно разочарованы в этой системе.
Впрочем, в том проекте по одному админу (совмещаюему админство с другими обязанностями) и когда он уходит в отпуск, то по сути можно говорить об отсутствии там админа вообще. Оракл достаточно надежен, хотя багов в нем хватает.
Поэтому тут мне совсем ясно про то, что Оракл можно рассматривать только для централизованных решений.



ASCRUS

Так же Оракл делает ставки на человеческий фактор (администраторов), так как грамотный специалист будет эффективнее AI любой сложности (на текущий момент времени не заглядывая в будующее).

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

ASCRUS

Самое что мне например нравится в IQ - это то, что в отличие от OLAP не нужно проектировать кубы и преобразовывать информацию. ... а дальше уж сам по ней может обычными запросами обрабатывать и добывать аналитическую информацию.

Воощето-то это не совсем сравнение с Ораклом. Оракл старется предлагать все известные средства работы с DSS. Среди прочих и OLAP . Там есть даже Data Mining - последние так сказать технологии в этой области, правда не знаю на каком уровне. Просто OLAP наиболее популярен на сегодняшний момент. Там у Оракла свой движек для специальных вычислений. А не нужны, он тоже имеет обычные средства, дополняя их всяким материализованными представлениями, аналитическими функциями запросы SQL. Это просто дает различные возможности проектировщику для различных задач.

ASCRUS

У Sybase в связке ASA (OLTP) + IQ (DSS) наоборот на лицо стремление к децентрализации и мобилизации решений, где все СУБД - являются автоматами и их архитектура изначально предназначена к работе без человеческого фактора в условиях удаленного функционирования и множеством способов передачи данных (вплоть до тети на поезде с дискеткой).

Вообще-то ОРАКЛ шел когда-то по этому пути. У него был Express Server. Но Оракл от этого отказался. А значение человеческого фактора в виде мобильности пользователя, возможно, от этого только уменьшается. Теперь не надо осваивать несколько продуктов. Кроме того, вопрос о том, что приобретать, упростился – все в одном. А при создании БД с помощью мастера можно указать планируется ее использование как OLAP, DSS или и то и другое. Лично мне это много больше нравится.
2 окт 04, 16:07    [1004065]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
автор
Наш коллега Yo! уже давным давно утверждал, что централ всегда лучше и страшно огорчился, когда узнал, что выделенка оказывается по России еще есть не везде. Его высказывания по поводу КПК тоже были однозначно направлены в сторону аксиомы "или централ или вообще СУБД не нужна". Мне кажется, что он слишком плотно засел в колею "централизованных решений" и выглянуть из нее и оглядеться по сторонам уже не может (или не хочет), что кстати доказывает только то, что он просто никогда не делал децентрализованных решений и ничего более :)


Подозреваю, что там где живет Yo! уже давно нет проблем с выделенкой. И стоит это копейки по сравнению с затратами на обслуживание программных решений. Рискуя быть оплеванным, я тоже считаю, что централизованные решения более надежны и эффективны, стоимость обслуживания - ниже. И чем бОльшие объемы данных нужно хранить и обрабатывать - тем больше будет разрыв в пользу централизованного хранения данных. Под ЦХД сейчас уже нужно понимать не единичную базу, а хранение данных в рамках локальной сети.
2 окт 04, 17:55    [1004127]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 9 10 [11] 12 13   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить