|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Dmitry Kuzmenko 2:5020/400 08 Jan 2003 15:31:34
To : Sergey Prach
Subject : Re: Синхронизация доступа к БД
--------------------------------------------------------------------------------
Hello, Sergey!
Sergey Prach wrote:
> Т.е. для обеспечения "версионности" БД необхомимо как минимум наличе
> незаполненного пространства в страницах. При этом это значение должно не
> превышать 50%, иначе даже для двух транзакций понадобится захват новых
> страниц. Если так, то это означает, что любая операция чтения должна
> прокачивать как минимум в 2 раза больше страниц, чем требуется по минимуму
> для блокировочника, для чтения той же порции данных. И где же здесь бережное
> отношение к системным ресурсам.
насколько мне известно, блокировочники тоже не стремятся
на 100% заполнять страницы. Если же это не так, то у них возникают
проблемы другого рода - блокирование "последней" страницы, куда
идет insert/append, или появление новых страниц при update,
если только не используется фиксированный размер записи.
Кажется, у MS SQL раньше update записей с Varchar вырождался
в пару delete/insert с соответствующими последствиями
а) образование "дырки" на странице при Delete
б) блокирование "последней" страницы при insert
в) увеличение transaction log из-за 2 операторов вместо одного.
Так что заполнять страницы на 100% нигде не выгодно. В IB
есть параметр no_reserve, при котором все заполняется
по максимуму, но в результате это ухудшает производительность
на обновлениях. А произвольная длина записи и дельты
при обновлениях уменьшают конечное количество страниц
на тот же объем данных.
Так что в итоге, резерв пустого места в IB может в сумме
дать _меньший_ объем хранимых данных по сравнению с
хранением того же объема сырых данных на другом сервере.
> > При этом страница блокируется только на момент создания этой версии,
> дальше
> > другие транзакции могут работать с этой страницей.
>
> Ты опустил один факт указать. В исходной странице должно быть указано,
> что версия "а" - реальная, а версию "б" еще не закомичена, и ее не следует
> пока принимать за чистую монету. т.е фактически сервер должен прочитать и
> "а", и "б", и сам выгребать где помои, а где булочки. Так?
да. у каждой записи в заголовке есть номер транзакции. А состояние
транзакций определяется по transaction inventory page.
Hамек на ухудшение производительности в этом случае я понял, хотя
все относительно - блокировщик "блокирует" конкурентов, а версионник
дает им работать без конфликтов. Т.е. можно сказать что одна
и та же задача решается примерно за одинаковое время в обоих случаях,
только версионник является более "параллельным" и менее дискретным,
чем блокировочник. Hу как Windows NT и Windows 3.1, соответственно :-)
> > Если я неправильно понял намек на "тупое проедание", то поясни,
> > пожалуйста, какие ЕЩЕ бывают случаи, когда страница БД находится
> > в памяти?
>
> Кроме "не тупого" попадания в память страницы данных, есть еще такое
> понятие как fill factor, который чем выше, тем меньше дисковых операций
> требуется для обработки, а значит выше производительность.
см. выше, про этот самый fill factor.
--
Dmitri Kouzmenko, www.ibase.ru, 953-13-34
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
--- ifmail v.2.15dev5
* Origin: iBase (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
