|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Dmitry Kuzmenko 2:5020/400 08 Jan 2003 17:14:28
To : Sergey Prach
Subject : Re: Синхронизация доступа к БД
--------------------------------------------------------------------------------
Hello, Sergey!
Sergey Prach wrote:
> > все не так страшно, хотя при работе с IB эту его особенность надо
> учитывать...
>
> Я тебе про жаренное, а ты мне про стриженное. Я про то, что раз индексы
> хранят все версии, то падает эффективность использования индексов, особенно
> уникаьных. Так как приходится индекс строить всегда по большему набору
> атрибутов (базовый набор атрибут + N-версии). Т.е. даже для такого часто
> используемого
> индекса, как по целочисленному 32-х битовому целому, реальный размер записи
> в индексе значительно больше, а значит необходимо больше пространства под
> индекс, увелечение процессорных операций, и другие "приятности".
гм, ну без конкретного примера не удастся обойтись :-)
К сожалению, БД из restore, т.е. "чистая".
размер страницы - 16К (сама БД 2 гига).
таблица X - 1 миллион 75 тысяч записей
макс размер записи - 78 байт (в записи 2 varchar(15) и один varchar(20)).
ПК построен по трем полям, timestamp+vchar(15)+vchar(15)
(т.е. макс длина ключа 8+15+15 =38 байт).
статистика по ПК
Index RDB$PRIMARY161 (0)
Depth: 3, leaf buckets: 1527, nodes: 1075134
Average data length: 17.00, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 1527
умножаем 1527 на размер страницы (16К) =~ 25 мегабайт.
Делим на чистый размер ключа, получаем ... 658 тысяч.
Т.е. если бы ключи хранились в лоб, то в таком объеме их было бы
почти в 2 раза меньше, чем хранится сейчас, и это без учета
оверхеда страницы, без ссылки на запись и т.п.
Есть и еще более сильный вариант, когда индекс по ПК,
поле 32 символа, но "автоинкрементируется" только последний
(строковый GUID, реверсированный).
Index RDB$PRIMARY2 (0)
Depth: 2, leaf buckets: 92, nodes: 100000
Average data length: 1.00, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 8
60 - 79% = 0
80 - 99% = 83
это прямо после вставки, размер страницы 8К. Итого получаем:
(8192 * 92) / 32 байта = 23552 теоретических ключа.
А ключей на самом деле - 100 тысяч!
Т.е. налицо почти 5-ти кратная упаковка (у числовых "автоинкрементов" получается
то же самое, если не еще сильнее).
С неуникальными индексами тоже упаковка неслабая, так что чтений на самом деле
происходит еще меньше.
--
Dmitri Kouzmenko, www.ibase.ru, 953-13-34
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
--- ifmail v.2.15dev5
* Origin: iBase (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
