|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Vova Aksionov 2:5020/400 05 Jan 2003 10:01:44
To : Sergey Prach
Subject : Re: Синхронизация доступа к БД
--------------------------------------------------------------------------------
On Thu, 26 Dec 2002 23:16:00 +0000 (UTC), "Sergey Prach"
<slprach@kot.poltava.ua> wrote:
>> > Так вот я и спрашиваю, о реализации этого механизма. Если существует
>> > несколько версий одних и тех же данных, тогда где эти версии
>размещаются,
>> > если никакго копирования не происходит.
>>
>> на странице данных, там где и записи. версии - это "дельты", т.е.
>> буквально, если есть запись, и ей сделали update,
>> то на странице будет
>> а) запись
>> б) версия записи, где лежат только те поля, которые обновились (и то их
>> разница между оригинальной записью).
>>
>
> Т.е. для обеспечения "версионности" БД необхомимо как минимум наличе
>незаполненного пространства в страницах.
1. не "версионности" БД а ВЕРСИОHHОСТИ ЗАПИСЕЙ БД, без кавычек.
2. необходимо либо наличие свободного места в базе на любых страницах,
либо наличие места на диске и возможности расширить базу за счет
заведения новых страниц. Резервировать место заранее не требуется.
>При этом это значение должно не превышать 50%, иначе даже для двух транзакций
>понадобится захват новых страниц.
Из чего интересно вытекают цифры "50%" и "даже для _двух_ транзакций"?
Даже для N транзакций, даже проводящих измененифя в базе места
потребуется не более чем то что займется дельтами измененных, ТОЛЬКО
ИЗМЕHЕHHЫХ! записей. Hа моей базе в 300мб с которой работают 10 юзерей
свободного места на страницах остается порядка 10-15мб, т.е. 5%!
>Если так, то это означает, что любая операция чтения должна
>прокачивать как минимум в 2 раза больше страниц, чем требуется по минимуму
>для блокировочника, для чтения той же порции данных. И где же здесь бережное
>отношение к системным ресурсам.
Слава богу это не так. Операция чтения должна прокачать только те
страницы на которых лежат все версии нужных записей. Если лишних
версий нету - то это будет ровно столько же сколько и на
блокировочнике. А что бы лишних версий было меньше - надо грамотно
проектировать, с учетом архитктуры БД.
>> При этом страница блокируется только на момент создания этой версии,
>дальше
>> другие транзакции могут работать с этой страницей.
>
> Ты опустил один факт указать. В исходной странице должно быть указано,
>что версия "а" - реальная, а версию "б" еще не закомичена, и ее не следует
>пока принимать за чистую монету. т.е фактически сервер должен прочитать и
>"а", и "б", и сам выгребать где помои, а где булочки. Так?
>
>
>> исходная фраза - твоя:
>> >Какая разница где она хранится? - да вообще-то никакой. Если она
>> >хранится на диске, то это падение производительности за счет эскалации
>> >дисковых операций. Если в памяти - тогда это тупое проедание операционных
>>
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> >ресурсов сервера, так как БД размером в несколько десятков гектар
>> >встречаются довольно часто, а вот такие ресурсы ОЗУ или того же порядка -
>> >довольно редко.
>>
>> для обращения к странице сервер должен считать ее с диска.
>> Т.е. страница попадает в кэш сервера. Если страницу изменяют,
>> то меняют или в кэше, или считывают с диска в память.
>
> Все правильно ты пишешь.
>
>>
>> Если я неправильно понял намек на "тупое проедание", то поясни,
>> пожалуйста, какие ЕЩЕ бывают случаи, когда страница БД находится
>> в памяти?
>
> Кроме "не тупого" попадания в память страницы данных, есть еще такое
>понятие как fill factor, который чем выше, тем меньше дисковых операций
>требуется для обработки, а значит выше производительность.
>
>
>
>--
>С уважением,
>Сергей Прач
>
>=================
>Please, send you private mail to: s_pratch@mail.ru
>
>
>
Пока.
-------------
Vova Aksionov
Novosibirsk
--- ifmail v.2.15dev5
* Origin: Sinor-NMTS (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
