|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Tengiz Kharatishvili 2:5020/400 07 Jun 2001 07:07:53
To : All
Subject : Re: Informix ?
--------------------------------------------------------------------------------
u.ru> <9fkafk$2vk5$1@ddt.demos.su> <9fl5eb$g25$1@host.talk.ru>
From: "Tengiz Kharatishvili" <tengiz.kharatishvili@gte.net>
Reply-To: "Tengiz Kharatishvili" <tengiz.kharatishvili@gte.net>
"Vladimir Pavlikov" <pvv@soil.msu.ru> wrote in message
news:9fl5eb$g25$1@host.talk.ru...
>
> При RR-уровне изоляции mssql накладывает диапазонные блокировки на
> индексы по условию во where. Что в ряде случаев приводит к практически
> однопользовательской работе и резко увеличивает вероятность дедлоков.
> С учетом того, что подобный уровень применяется чаще всего для объем-
> ных транзакций (и для них уровень необходим по условиям задачи) -
> ответ довольно очевиден.
>
Боюсь, что я не совсем понимаю Ваши рассужденя. Подробнее можно о каком
сценарии идёт речь? Вы, наверное, говорите о serializable, а не repeatable
read, если речь идёт о диапазонных блокировках?
Key-range блокировки как раз помогают уменьшить риск нарваться на
неприятности. Альтернатива им - блокирование бОльших объёмов данных, правда
с меньшим количеством блокировок. Hо это уже проблема lock manager, а не
приложения, как он справляется с объёмными таблицами блокировок.
Два крайних случая: одна табличная блокировка таблицы в миллион строк - при
этом с этой таблицей никто ничего уже не может сделать до конца транзакции
или 500000 row-level блокировок (неважно, по кластерному или вторичному
индексу или на RID в талбице без кластерного индекса) в той же
таблице - половина строк доступна для других пользователей. Хотя lock
manager может быть и не очень доволен.
> Справедливо. Вот только все перечисленное в двух последних строках должно
> определяться прежде всего требованиями задач и предметной области в целом.
> И чем больше приходится подгонять перечисленное под "фичи" конкретного
> сервера, тем хуже.
>
Согласен, но отчасти. Если речь идёт о большой системе и актуальна
переносимость приложения, то разработка всё равно идёт послойно и при
разумном проектировании физические интерфейсы к СУБД должны быть чётко
инкапсулированы. Что во многих случаях даёт возможность относительно
безболезненно адаптироватья под конкретную СУБД и активно использовать её
особенности или обходить характерные недостатки без риска перепроектирования
всей системы. Если речь идёт о небольшой разработке - это тем более не очень
сложно и накладно. Разумеется не всё укладывается в эти две модели, и есть
ситуации, когда возникают труднопреодолимые сложности.
> Тенгиз, мне нравятся твои письма. И содержанием, и стилем. Ты хорошо
> знаешь mssql и его особенности. В связи с этим вопрос - ты не пробовал
> те же задачи решать на другом сервере, Оракле, к примеру? И сравнить
> при этом необходимость учета вышеперечисленного для двух серверов?
> Ответа я не знаю, но, мне кажется - он будет отрицательный. Просто
> потому, что разница между этими необходимостями не оставит аргументов
> в пользу продолжения работы на ms. Hо это лишь предположение,
> хотелось бы получить ответ. Если отрицательный, достаточно простого
> "нет". В противном случае интересны аргументы.
>
Спасибо на добром слове. Примите мои ответные greetings :).
По делу: я уже примерно 16 лет имею профессиональное отношение к CS, их них
примерно 10 лет тесно связан с индустрией СУБД. Из них последние 7 лет я
очень активно имею дело с MS SQL Server, сначала 4 года как разработчик и
DBA, последние 3 года уже в несколько другом качестве.
В своё время я выбрал SQL Server по совокупности свойств, которые были важны
для некоего проекта, для руководства разработкой которого меня наняли некие
не бедные, но излишне доверчивые и азартные люди - интересное было время :).
Очень долго и добросовестно с участием специалистов соответствующих
фирм-производителей и независимых консультантов рассматривались варианты (я
уже не помню всех номеров версий - давно это было): Informix Online, Sybase
System 10, ORACLE 6, DB2, Ingress, Progress, MS SQL Server 4.21, Interbase.
Потом всё это выросло в нечто большее и более интересное и я остался верен
своему выбору по многим причинам, часть из которых, естественно, абсолютно
субъективны.
Hо мы все так или иначе пристально следим за конкурентами своих фаворитов, и
судя по тому что я знаю о других СУБД, не думаю, что у какого либо из самых
популярных серверов БД есть неоспоримые преимущества по совокупности
достоинств и недостатков, которые делали бы выбор однозначным для широкого
диапазона задач. Hаличие жёсткой конкуренций в индустрии СУБД среди основных
игроков чётко это доказывает.
Что касается аргументов, то на любой мой аргумент в пользу X у хорошего
специалиста тут же найдётся аргументя в пользу Y и наборот. Я думаю, что
намного продуктивнее и интереснее обсуждать как можно решить ту или иную
пробему на том или ином сервере с максимальным эффектом или с минимальными
усилиями или накладными расходами. А маркетинговые и sales битвы, пусть даже
с глубоким техническим уклоном, лучше оставить тем, кому это нравится
больше.
Единственное, где я готов изменить такому правилу - это когда говорится
явная или неявная, вольная или невольная, наивная или, наоборот, циничная
неправда.
Вот такой вот disclaimer получился.
Cheers.
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
