|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Sergey Prach 2:5020/400 27 Dec 2002 03:16:00
To : Dmitry Kuzmenko
Subject : Re: Синхронизация доступа к БД
--------------------------------------------------------------------------------
Hi!
"Dmitry Kuzmenko" <kdv@ibase.ru> сообщил/сообщила в новостях следующее:
news:3E0B045F.8A73145C@ibase.ru...
> > Так вот я и спрашиваю, о реализации этого механизма. Если существует
> > несколько версий одних и тех же данных, тогда где эти версии
размещаются,
> > если никакго копирования не происходит.
>
> на странице данных, там где и записи. версии - это "дельты", т.е.
> буквально, если есть запись, и ей сделали update,
> то на странице будет
> а) запись
> б) версия записи, где лежат только те поля, которые обновились (и то их
> разница между оригинальной записью).
>
Т.е. для обеспечения "версионности" БД необхомимо как минимум наличе
незаполненного пространства в страницах. При этом это значение должно не
превышать 50%, иначе даже для двух транзакций понадобится захват новых
страниц. Если так, то это означает, что любая операция чтения должна
прокачивать как минимум в 2 раза больше страниц, чем требуется по минимуму
для блокировочника, для чтения той же порции данных. И где же здесь бережное
отношение к системным ресурсам.
> При этом страница блокируется только на момент создания этой версии,
дальше
> другие транзакции могут работать с этой страницей.
Ты опустил один факт указать. В исходной странице должно быть указано,
что версия "а" - реальная, а версию "б" еще не закомичена, и ее не следует
пока принимать за чистую монету. т.е фактически сервер должен прочитать и
"а", и "б", и сам выгребать где помои, а где булочки. Так?
> исходная фраза - твоя:
> >Какая разница где она хранится? - да вообще-то никакой. Если она
> >хранится на диске, то это падение производительности за счет эскалации
> >дисковых операций. Если в памяти - тогда это тупое проедание операционных
>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >ресурсов сервера, так как БД размером в несколько десятков гектар
> >встречаются довольно часто, а вот такие ресурсы ОЗУ или того же порядка -
> >довольно редко.
>
> для обращения к странице сервер должен считать ее с диска.
> Т.е. страница попадает в кэш сервера. Если страницу изменяют,
> то меняют или в кэше, или считывают с диска в память.
Все правильно ты пишешь.
>
> Если я неправильно понял намек на "тупое проедание", то поясни,
> пожалуйста, какие ЕЩЕ бывают случаи, когда страница БД находится
> в памяти?
Кроме "не тупого" попадания в память страницы данных, есть еще такое
понятие как fill factor, который чем выше, тем меньше дисковых операций
требуется для обработки, а значит выше производительность.
--
С уважением,
Сергей Прач
=================
Please, send you private mail to: s_pratch@mail.ru
--- ifmail v.2.15dev5
* Origin: LtawaSoft (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
