|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Sergey Prach 2:5020/400 05 Jan 2003 01:29:31
To : Vladimir Pavlikov
Subject : Re: Синхронизация доступа к БД
--------------------------------------------------------------------------------
Hi!
"Vladimir Pavlikov" <pvv@soil.msu.ru> сообщил/сообщила в новостях следующее:
news:av6s17$1uu$1@host.talk.ru...
> SP> получается несколько иная картина - самый высокий уровень не всегда
> SP> самый дорогостоящий по времени выполнения для блокировочника, так
> SP> как блокировка накладываеся либо целиком на таблицу, либо на узел
> SP> индекса (оптимизатор сам выбирает что дешевле).
>
> ... а остальные транзакции стоят... Оценивать нужно время выполнения
> всех параллельных транзакций, а не single user - неинтересно.
При конкурентном множестве всегда кто-то чего-то ожидает. Раз факт
очереди неизбежен, значит единственный путь - уменьшить время нахождения в
этой очереди.
>
> SP> порождает генерацию целых таблиц блокировок. HО! все эти операции по
> SP> построению блокировок происходят в памяти, в то же время как у
> SP> версионника любая модификация в конкурирующей транзакции - это
> SP> порождение новых версий данных, а значит эскалация дисковых
> SP> операций.
>
> Сам придумал, или "подсказал" кто?
Пока другой информации не нашел, а другие не обнародовали.
>
> SP> Why is dead? Благодаря отсутствию многих версий % заполнения
> SP> страниц данными у блокирочников намного выше. А значит дисковых
> SP> операций требуется меньше, иногда на порядок.
>
> Hу и чушь :( % заполнения - это параметр создания базы. Порядок м.б.
> лишь в случае, когда у одного сервера процент ниже десяти (так кто-то
> делает?!), а у другого - практически вся сотня (тоже шибко умным не
> назовешь). В реалии под версии забивается меньше 10%, это надо раз-
> делить пополам (при среднем заполнении ~50%) и, с учетом того, что
> версии хранятся не в виде записей, а дельт - разделить еще на 3-5.
> Останется 1-3% - это если вообще учитывать версии при определения %,
> чего мало кто делает :) Если же учесть существующие сервера - IB
> имеет чуть ли не самое компактное хранение данных (до 6 раз по срав-
> нению с Ораклом, к примеру) плюс логи - соотношение будет _обратным_,
> хотя и не на порядок, конечно. Про Постгре не в курсе.
Володенька, 95% процентов людей на этой земле не употребляю такую
гадость как "экстази" или героин, так как это дорогостоящие наркотики. Hо
это еще не повод говорить, что это безобидные штучки.
Объем, занимаемый таблицей каких-то остатков в практически любой БД не
сравненно меньше, чем таблицы операций с этиим остатками. Hо именно этот
факт и образует эффект "бутылочного горлышка".
Для примера, в украиской бухгалтерской системе есть такой счет как
"Финансовый результат". Так вот каждый документ на реализацию, который
порождается в недрах большой фирмы - это практически всегда модификация
остатка по этому счету. Когда документы вводят 2-3 оператора - проблемы с
конкурентным доступом практически нет. Когда их 20-30 - за каждую
милисекунду приходится сражатся, и спасатся мыслью, что размер записи для
этого счета в БД составляет лишь одну 100 миллионную долю от ее общего
размера БД как-то мало утешает.
--
С уважением,
Сергей Прач
=================
Please, send you private mail to: s_pratch@mail.ru
--- ifmail v.2.15dev5
* Origin: LtawaSoft (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
