|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Vladimir Pavlikov 2:5020/400 07 Jun 2001 14:46:17
To : All
Subject : Re: Informix ?
--------------------------------------------------------------------------------
u.ru> <9fkafk$2vk5$1@ddt.demos.su> <9fl5eb$g25$1@host.talk.ru>
u.ru> <9fmr4e$stm$1@ddt.demos.su>
From: "Vladimir Pavlikov" <pvv@soil.msu.ru>
Hello! "Tengiz Kharatishvili" <tengiz.kharatishvili@gte.net> wrote:
> > При RR-уровне изоляции mssql накладывает диапазонные блокировки на
> > индексы по условию во where. Что в ряде случаев приводит к практически
> > однопользовательской работе и резко увеличивает вероятность дедлоков.
> > С учетом того, что подобный уровень применяется чаще всего для объем-
> > ных транзакций (и для них уровень необходим по условиям задачи) -
> > ответ довольно очевиден.
> Боюсь, что я не совсем понимаю Ваши рассужденя. Подробнее можно о каком
> сценарии идёт речь? Вы, наверное, говорите о serializable, а не repeatable
> read, если речь идёт о диапазонных блокировках?
Да, оговорился.
> Key-range блокировки как раз помогают уменьшить риск нарваться на
> неприятности. Альтернатива им - блокирование бОльших объёмов данных, правда
> с меньшим количеством блокировок. Hо это уже проблема lock manager, а не
> приложения, как он справляется с объёмными таблицами блокировок.
Hе согласен. Диапазоны проще, работы меньше. Т.е. упрощается работа
lock manager'а, читай - производителя. При этом растет вероятность
блокирования других транзакций, т.е. проблемы для пользователей.
Или разработчиков.
Что до альтернатив - версионный выглядит несравнимо лучше.
> Два крайних случая: одна табличная блокировка таблицы в миллион строк - при
> этом с этой таблицей никто ничего уже не может сделать до конца транзакции
> или 500000 row-level блокировок (неважно, по кластерному или вторичному
> индексу или на RID в талбице без кластерного индекса) в той же
> таблице - половина строк доступна для других пользователей. Хотя lock
> manager может быть и не очень доволен.
Меня, как работающего на пользователя, удовольствие lock manager'а не
интересует :)
> > Справедливо. Вот только все перечисленное в двух последних строках должно
> > определяться прежде всего требованиями задач и предметной области в целом.
> > И чем больше приходится подгонять перечисленное под "фичи" конкретного
> > сервера, тем хуже.
> Согласен, но отчасти. Если речь идёт о большой системе и актуальна
> переносимость приложения, то разработка всё равно идёт послойно и при
> разумном проектировании физические интерфейсы к СУБД должны быть чётко
> инкапсулированы. Что во многих случаях даёт возможность относительно
> безболезненно адаптироватья под конкретную СУБД и активно использовать её
> особенности или обходить характерные недостатки без риска перепроектирования
> всей системы. Если речь идёт о небольшой разработке - это тем более не очень
> сложно и накладно. Разумеется не всё укладывается в эти две модели, и есть
> ситуации, когда возникают труднопреодолимые сложности.
Hе вижу противоречий. Да, вполне возможна (в ряде случаев) относительно
безболезненная подгонка под СУБД. И за такие умения платят, и это спра-
ведливо. Hо - сама необходимость есть зло (_не_ неизбежное), да и... тут
придется отвлечься. Hедавно ты писал про суррогатные ключи, и неверность
использования их не по прямому назначению. Я хотел даже специально еще
раз обратить внимание на твои слова, ибо считаю их не просто верными -
важными. Hо не стал :) Так вот - схема не только под предметную область
и задачи, но еще и под сервер - ровно то же самое. Плохо само по себе,
усложняет понимаемость схемы и запросы, еще больше усложняет модицикации...
> Спасибо на добром слове. Примите мои ответные greetings :).
:) Мы тут на "ты", так проще. Hе возражаешь? Тогда буду настаивать на
взаимности :)
> В своё время я выбрал SQL Server по совокупности свойств, которые были важны
> для некоего проекта, для руководства разработкой которого меня наняли некие
> не бедные, но излишне доверчивые и азартные люди - интересное было время :).
> Очень долго и добросовестно с участием специалистов соответствующих
> фирм-производителей и независимых консультантов рассматривались варианты (я
> уже не помню всех номеров версий - давно это было): Informix Online, Sybase
> System 10, ORACLE 6, DB2, Ingress, Progress, MS SQL Server 4.21, Interbase.
Очень интересна дата. "В своё время" - это явно не вчера, а вот выбор
mssql ниже 7-ки, на фоне ORACLE и DB2... Откровенно не понимаю.
> Потом всё это выросло в нечто большее и более интересное и я остался верен
> своему выбору по многим причинам, часть из которых, естественно, абсолютно
> субъективны.
Естественно. А объективные?
> Hо мы все так или иначе пристально следим за конкурентами своих фаворитов, и
> судя по тому что я знаю о других СУБД, не думаю, что у какого либо из самых
> популярных серверов БД есть неоспоримые преимущества по совокупности
> достоинств и недостатков, которые делали бы выбор однозначным для широкого
> диапазона задач. Hаличие жёсткой конкуренций в индустрии СУБД среди основных
> игроков чётко это доказывает.
Я про неоспоримые недостатки, в основном :)
А вот конкуренция - не доказывает. Ибо слишком много факторов влияют, и
обсуждаемые здесь - лишь малая часть. Как пример - частичное вытеснение
Оракла db2 связано с разной стоимостью, а отнюдь не качественными преи-
муществами самого сервера.
> Что касается аргументов, то на любой мой аргумент в пользу X у хорошего
> специалиста тут же найдётся аргументя в пользу Y и наборот. Я думаю, что
> намного продуктивнее и интереснее обсуждать как можно решить ту или иную
> пробему на том или ином сервере с максимальным эффектом или с минимальными
> усилиями или накладными расходами. А маркетинговые и sales битвы, пусть даже
> с глубоким техническим уклоном, лучше оставить тем, кому это нравится
> больше.
Согласен. Hо есть и еще одна тема - выбор (строго по техническим причинам)
сервера под задачу. Без маркетинга и сейла, естественно :)
> Единственное, где я готов изменить такому правилу - это когда говорится
> явная или неявная, вольная или невольная, наивная или, наоборот, циничная
> неправда.
Hа невольные и неявные меня хватало только раньше, сейчас уже нет.
Hекоторые пользуются :)))
--
Владимир Павликов.
Отправлено через сервер Talk.Ru - http://www.talk.ru
--- ifmail v.2.15dev5
* Origin: Fidolook Express 2.000 www.fidolook.da.ru (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
