|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Vova Aksionov 2:5020/400 03 Jan 2003 10:19:27
To : Sergey Prach
Subject : Re: Синхронизация доступа к БД
--------------------------------------------------------------------------------
On Mon, 30 Dec 2002 19:57:23 +0000 (UTC), "Sergey Prach"
<slprach@kot.poltava.ua> wrote:
>> Почему-то забываем при этом вопросы нескольких версий записей в
>> индексах, нескольких версий статистики и секса, которого приходится
>> иметь оптимизатору запросов.
>>
>> Hе памятью единой ...
>
> Я хотел было упомянуть, про индексы и прочую служебную информацию, но
>потом подумал - если мы пока не пришли к конценсусу, гже же размещаются эти
>версии данных, то о версиях и ресурсах под них для служебной информации
>лучше пока промолчи. ;-)
Как представитель news:\\forums.demo.ru\epsilon.public.interbase
я бы мог наверное внести некоторую ясность в вышезаданные вопросы.
1. Дельты записей (версии) ничем не отличаются от самих записей по
технологии хранения - и лежать могут на любой странице - нет
необходимости предварительного резервирования места именно под версии.
2. Индексы не являются версионными - они видят все версии записей.
Перед выдачей данных клиенту проверяется какие же из версий этих
записей должны быть видны запрашивающей транзакции - и выдаются только
те которые соответствуют уровню транзакции. Собственно это самое
больное место - если версий очень много - то серверу приходится
перебирать их все что бы выяснить что же можно выдавать. Для того что
бы избегать таких ситуаций в IB предусмотрено несколько механизмов
ликвидации неактуальных версий. В общем случае неактуальные версии
удаляет обращение в этим версиям следующей транзакции после той
которая эти версии создала. Hапример (псевдокод):
StartTransaction.
update table set kol = kol + 10 where idgroup = 100
Commit;
StartTransaction;
select * from table where idgroup = 100
/* здесь неактуальные версии будут удалены */
Commit;
3. Статистика в IB сама не пересчитывается. Ее пересчет запускается с
клиента - когда надо тогда и запускаешь. Поскольку статистика
показывает селективность индекса а он неверсионный - то и статистика
соответсвенно неверсионная, т.е. учитывает все версии записей.
Hе исключено что сбор статистики сам порождает сбор мусорных версий -
тут я не в курсе.
4. IMHO Оптимизатору версии пофиг - он рассматривает все что видят
индексы, выкидывание мусорных версий происходит при выдаче данных.
Итого - версионность дается не даром и требует иного подхода к
проектированию и програмированию.
Самый яркий пример - select count(*) from table -
у IB происходит полный перебор всех записей и всех их версий - и на
миллионных таблицах может длиться минутами, в то время как на
блокировочниках это выдается мнгновенно.
Пока.
-------------
Vova Aksionov
Novosibirsk
--- ifmail v.2.15dev5
* Origin: Sinor-NMTS (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
