|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Dmitry Kuzmenko 2:5020/400 08 Jan 2003 16:18:44
To : Tolik Tentser
Subject : Re: Синхронизация дос тупа к БД
--------------------------------------------------------------------------------
4ax.com>
From: Dmitry Kuzmenko <kdv@ibase.ru>
Hello, Tolik!
Tolik Tentser wrote:
> При наличии нескольктх версий таблицы (для простоты одной) - наверно в
> природе должно существовать несколько версий индексов (и селективность
> одного и того же поля в каждом из них может оказаться разной), а также
это версии ключа, но они как версии не рассматриваются. Дешевле
выбрать все ключи заданного диапазона и потом уже по записям
определять, что должно быть "видно" транзакции, а что нет.
Поэтому статистика по индексу общая - для всех версий, в том числе
и даже non-committed.
> несколько статистик распределения записей. Рискну предположить, что
> при этом в каждой сессии, в зависимости от имеющегося в ней снапшота
> оптимизатору придется по разному оптимизировать одни и те же запросы.
как правило нет, т.к. оптимизатор не может сказать чего и кому надо,
т.к. все навалено в одну кучу. М.б. у Оракла это действует, т.к. там
это можно делать по сегментам transaction log для конкретных транзакций
(я не знаю как там это сделано, возможно что и не так).
> Позволю себе также высказать гипотезу, что это оптимизатора не
> упростит и времени разработчикам БД на его улучшение не добавит. Скажу
> даже, что поиск записи по индексу, в котором разные элементы имеют
> разные версии - сам по себе медленнее, поскольку, кроме просто прохода
> по тому-же B-дереву требует дополнительных оценок - а та ли это версия
> листа.
здесь нет, т.к. ключи при хранении упаковываются, и номера транзакций
для ключей не хранятся. Поэтому выборка подмножества ключей даже
для всех версий происходит максимально быстро.
"Плохо" здесь начинается когда удаляются записи, и в индексе
много дубликатов ключей, т.е. низкая селективность - идет обратный процесс,
от записи к ключу и обратно, из-за чего торможение может быть экспоненциальным
в зависимости от кол-ва дубликатов в ключе.
Правда, не все так страшно, на эту тему есть предупреждения и рекомендации.
> Я уже как-то писал сюда, что в будующем, видимо, все серверы придут к
> версионности, но на настоящем этапе развития науки и технике - эта
> технология имеет немало нерешенных проблем и пока вряд ли может
[skip]
> облегчение жизни программистов. Пока же - какртина, увы, иная -
> производительность сервера БД - есть критичный ресурс и всё, что
> требует его дополнительно загрузки при том же потоке транзакций - не
> есть хорошо.
да, увы.
--
Dmitri Kouzmenko, www.ibase.ru, 953-13-34
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
--- ifmail v.2.15dev5
* Origin: iBase (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
