|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Sergey Prach 2:5020/400 27 Dec 2002 03:16:01
To : Vladimir Pavlikov
Subject : Re: Синхронизация доступа к БД
--------------------------------------------------------------------------------
Hi!
"Vladimir Pavlikov" <pvv@soil.msu.ru> сообщил/сообщила в новостях следующее:
news:auf4jd$3ku$3@host.talk.ru...
> SP> Хорошо, привели пример кода, который будет переводить деньги с
> SP> одного счета на другой и при этом не всегда будет выполнятся как
> SP> единая транзакцияя, но при этом будет гарантировать
> SP> непротиворечивость БД.
>
> "Перевод денег с одного счета на другой" - это _одна_ операция.
> Разумеется, проводится в одной транзакции. Это не "тысячи операций
Так разумеется или желательно?! Второе утверждение как бы ну никак не
поглощает первое?
> в транзакции". Даже как-то странно слышать такое от тебя - это
> же не версионность :), тут у тебя проблем быть не должно.
>
> SP> А ну ка приведи пример реализации моментального SNAPSHOT-а для
> SP> БД в 10-20Гб, или хотя бё что бы он был более эффективен чем
> SP> SERIAZABLE.
>
> "Hукать" дома будешь.
Хорошо, давай без "ну". Володенька, приведи пожалуйста пример реализации
моментального SNAPSHOT-а для БД в 10-20Гб, или хотя бы что бы он был более
эффективен чем SERIALIZABLE, когда модификации подвергаются около 20%
данных.
> SP> До твоей месаги я считал что БД распределяют БД между
> SP> несколькими серверами в виду различных методов работы с данными -
> SP> OLAP и OLTP. А оно оказывается из-за того, что высокий уровень
> SP> изоляции "_крайне_ тяжелый уровень для блокировщиков".
>
> А сейчас считаешь по другому? Жаль - я написал то же самое : корот-
> кие модификации - это OLTP. Длинные отчеты по всей базе - OLAP.
> Hу а то, что блокираторы эту смесь не тянут никак - общеизвестно.
> Ибо сериализация одних просто вырубает других. Где противоречие?
...
> ЗЫ. Сначала безапелляционные утверждения, затем - вопросы... Этот
> симптом прохожу далеко не впервые :)
> ---------------------------------------------
> Владимир Павликов.
Володенька, совместный доступ на модификацию конкурентных даных - это
всегда проблема, хоть для версионников, хоть для блокировочников. И при
решениии этой проблемы всегда одна транзакция погибает. Только у
блокировочника эта одна из транзакций погибает еще только при первой попытке
модифицировать конкурентную область данных. А у блокировочника в момент фазы
комит. Иначе невозможно удерживать БД в непротиворечивом состоянии, это
давным давно доказано как теоретически так и практически.
В свое время, в 70-е была разработана классная машина - БМП-1. Сверху,
на один из уральських HИИ, поступил заказ на разработку аналогчиной техники,
но еще более легкой для десанта. Было разработано два варианта. Приехала
приемная комисия с Москвы, начали гонять. По сухому, в горах обе машины вели
себя практически одинаково, но вот им дали задание пересечь небольшое
болото. Первый вариант пересек метров 20-25 и застрял, а вторая бойко так
проскакала по кочкам метров 700-800, но тоже застряла. Hу вышел генерал и
спрашивает: - ну и какой ваиант берем на вооружение? Все конечно в один
голос: Варинат Б, Б.. А генерал и говорит: - идиоты, эту, что ближе, еще
можна вытащить, а та что в километре от нас - все, капец.
Так вот и в споре про блокировочник и версионник: если в первом одна из
транзакций практически всегда сдыхает, и только в редких случаях (dead
lock) - обе, то в версионнике приведение всех версий в соотвтетстве - всегда
головная боль и всегда довольно большие затраты на дисковый обмен.
--
С уважением,
Сергей Прач
=================
Please, send you private mail to: s_pratch@mail.ru
--- ifmail v.2.15dev5
* Origin: LtawaSoft (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
