"И снова здравствуйте!".

При очередном перечитывании Писания : 1.2.3. Навигация по индексу

Индексная навигация есть ни что иное, как последовательное сканирование ключей индекса. А так как для каждой записи серверу надо выполнить фетч записи и проверить ее видимость для нашей транзакции, то данная операция выходит достаточно дорогой.
. . .
Основное отличие индексной навигации от сканирования (описанного в пункте 1.2.2) заключается в отсутствии битовой карты между сканированием индекса и доступом к записи через ее идентификатор. Причина понятна - сортировка записей по физическим номерам в данном случае противопоказана. Из этого можно сделать вывод, что при индекс сканируется по мере фетча с клиента, а не "за раз" (как в случае использования битовой карты).- внезапно вспых вопрос.

Почему нельзя сначала пройтись по всем ключикам (с учётом where / rows ограничений, если они есть) и затолкать ID'шники записей в структуру типа TreeSet, которую по окончании сканирования индеска можно спокойно юзать для обхода записей в порядке возрастания их ID - ?
Да, понятно, что такой селект не выдаст клиенту ни одной строки до тех пор, пока не доберётся до последнего ключа и не начнёт выдавать содержимое TreeSet'a. Но селект ведь не только для выдачи результата клиенту юзается, а еще и просто для обработки строк в нужном порядке (т.е. курсором: for select ... from <T> where ... ORDER BY <F1, F2> as cursor C do ...)

Что "зачем" ? Уменьшение числа random IO ?

Симонов Денискхе... порядок IDшников записей далеко не всегда (читай почти никогда, если это не ПК) совпадает с порядком ключей сортировкиНу так я про то и говорю! Раз он не совпадает, значит, надо сначала пройтись по индексу и каждый ID записи, который там будет встречен, помещать предварительно в TreeSet. И только после окончания навигации начинать выталкивать из TreeSet'a его содержимое.

Допустим, в индексе на страницах 123 и 124 сидят следующие ключи с ID'шниками:
index page =>123123123123124124124124index keys =>abcabcdbcdebcdefbcdfabcdfbbczbcz2rec IDs =>65432112345678901265002112159014999991112

Навигация начинается с левого ключа, т.е. с 'abc'. Там ID'шник = 654321 - помещаем его в TreeSet, но НЕ выдаём ничего пока что клиенту.
Далее переходим к ключу 'abcd', там ID'шник = 123456. Добавляем его в TreeSet, содержимое этого дерева будет теперь таким, что его итерация по его элементам выдаст (автоматом) их так: 123456, 654321.
Затем переходим дальше, к ключу 'bcde', там ID = 789012, и т.д.

В результате, по окончании этого процесса TreeSet будет таким, что итератор по нему выдаст элементы (ID'шники записей) в порядке их возрастания:
TreeSet iter.next()21212345615901465002165432178901299999111
И вот только тут, на этапе итерации по этому дереву, начинаем проверять видимость записей нашей транзакции и выдаём их на гор а , если сиё допускается. И обходим эти записи уже в порядке возрастания ID'шников.

Симонов Денисну так порядок то будет не тот. а, тьфу... точно :-)
ну ладно, значит не судьба...

я в печальке большой: не могу в одном месте избавиться от этого PLAN ORDER'a, бызнес-логика его требует.
И именно из-за него получаю совершенно дикие значения по произв-сти в трейсе.

Dimitry SibiryakovТаблоидИ именно из-за него получаю совершенно дикие значения по произв-сти в трейсе.Кэш увеличь, чтобы нужный индекс в него помещался.
Кеш в SS поставил давно уже 512К, в трейсе при таком значении практически никогда не лезут read(s)>0.
А в SC пробовал и с кешем 16384 (больше не задавал, вряд ли такое увидишь в реале :)), но read(s)>0 периодически прут.
И сильно подозреваю, что даже если выставить в SC еще бОльший кеш ради истребления reads'ов - не поможет. Ибо SS тому пример.

Симонов Денис,

там есть две процедурки, отвечающие за сторнирование количеств и стоимостей: sp_make_qty_storno & sp_make_cost_storno.
У них (в твоей версии теста) курсоры, обрабатывающие строки, делают это с PLAN ORDER. Сколько я не крутил-мутил с индексами, ничего там не улучшилось.
Курсорный запрос вида:

- вгонял всё в гроб.
После добавления волшебного "плюс-нолика" в его order by всё залетало, ускорение в десятки раз.
Но это и другие исправления я еще тебе не высылал.

Однако, остались еще режимы, где PLAN ORDER таки требуется. Это выбор случайных документов для обработки - то, что делает fn_get_random_id через вот то: select id from <view_for_random_search> where id >= :x ORDER BY ID rows 1.
Почесав репу, я догадался, что вряде случаев можно и здесь убрать ORDER BY, потому что как только документ успешно залочен и взят в обработку, то при успешном её завершении он - возможно - исчезнет из видимости вьюхи <view_for_random_search>, т.к. перейдёт в такое состояние, когда по нему "всё сторнировано".
Но это будет НЕ СРАЗУ, а при многократных обработках выбранного док-та, т.к. за один присест с него сдёргивается для сторнирования не всё кол-во. Поэтому мне совсем не нравится этот подход, ибо костыль же, явный и убогий.

kdvТаблоидне могу в одном месте избавиться от этого PLAN ORDER'aнасколько я в курсе, всегда можно избавиться от PLAN ORDER, только он поменяется на PLAN SORT. если при ORDER дофига random io, то SORT будет хорошо.Можно, ес-сно. Но только если объем записей для SORT'a не очень большой. Именно так у мну, к щясью, и происходит.

Таблоидну ладно, значит не судьба...А нет, стоп. Всё таки - судьба! :-)
Формируем битмап для хранения ID'шников, а также Tree Map , в котором:
<Key> - это результат вычисления для каждой записи выражения ORDER BY (т.е. значений одного или нескольких полей);
<Val> - это все прочие поля, не указанные в ORDER BY (кроме блобов, ес-сно; для них туда пишем только указатели).

Стартуем так, как делается при PLAN INDEX, в итоге будет сформирован битмап.
Далее, по нему делаем обход записей в порядке возрастания ID'шников, вытаскивая из записей все поля, которые были перечислены в ORDER BY и в SELECT-секции.

Для каждой такой записи проверяем её видимость текущей транзакции и если Ок, то заполняем <key> & <val> нашего TreeMap'a.

А затем - вываливаем вызывателю содержимое TreeMap'a, вызывая его итератор.

В итоге получаем:
1) однократное посещение записей и только в порядке возрастания их ID;
2) вывод из TreeMap'a идёт в том порядке, что задан был в ORDER BY.

Минус вижу только один: доп. расход памяти. Но в наш суровый век дешёвых терабайтов это не должно быть существенным.

Симонов Денискак раз когда есть ограничитель rows, да ещё и стоит там всего одна запись, PLAN ORDER будет эффективней чем SORT. Я не увидел этой эффективности, когда база под нагрузкой.
Именно на запросах вида select ID from <view> where ID >= :x ORDER BY ID rows 1 неоднократно получал в трейсе то 5, а то 10 сек. И это при том, что ORDER BY - по первичному ключу, т.е. у нас достаточно большая вероятность того, что физ. порядок следования записей соотв-вует индексному.

Симонов Дениси чем это лучше чем сортировка в памяти (не навигация по индексу)Хм... не знаю, сравнивать надо. Но один плюсик всё же есть: не нужно будет костыли всовывать везде (я про "+0").

Симонов Денисзначит у тебя вьюха хитрая. Не, примитивизм сплошной:
Где fn_oper_retail_reserve() - детерминистик-функция, лезет в базу только при первом своём вызове. При последующих возвращает ID операции, сохранённый у себя в кошельке. И даже если заменить её на тупой литерал (у мну - 3000), не поможет, не в ней дело.

Симонов ДенисНа простой таблице выигрыш просто огромныйКак-то не очень сильно бросилось в глаза... 16 мс против 63 ? это ты ведь в моно-коннекте сделал, так ?

Симонов Денистут скорее всего для optype_id есть дополнительный индекс есть, конечно же (см DDL, их есть у тебя).
Только вот какое дело: не вижу я чё-то при работе в моноконнекте никаких осязаемых преимуществ order by id+0 над order by id.

Вот пример.
DDL: (будет создана таблица t(id, x) с 500 тыс записями, но физ. расположение строк в ней будет отвратительным с т.зр. навигации по ID-индексу.

Test:



Запусти у себя сначала с "declare c smallint = 1;", а затем поменяй на "declare c smallint = 2;", чтобы вызовы были с order by id+0.
Я разницу как-то не ощутил.

Может, в сильно-конкурентной среде, когда в таблицу `t` будут падать новые строки, будет всё по-другому, не знаю.

dimitrТаблоидМожет, в сильно-конкурентной средеили просто когда база не влазит в кеш :-)Дык у мну в ФБ-3 кеш 512к, я не вижу в трейсе reads>0.

kdvТаблоидМожно, ес-сно. Но только если объем записей для SORT'a не очень большой.
как показывают мои тесты, даже при миллионах записей PLAN ORDER получается хреновее из-за disk io вместо plan SORT. Который выдает результат за N секунд, а не сразу, но зато навсегда.
- - -
если что, рекомендую перечитать
http://ibaseforum.ru/viewtopic.php?f=4&t=4175 Да, я читал её. И перечитал только что снова :-)
Там речь идёт о сравнении ORDER vs SORT для источника данных кардинальностью 14 млн строк. Такие объемы вряд ли перелопачиваются в OLTP-среде. У мну в текущих настройках для одного документа будут перелопачены 50 * 15 * 2 = 4500 строк - и это только в самом худшем случае. Длина записи таблицы (её имя: QDistr), в которой идёт это - 42 байта.

Хотя, один из индексов в ней действительно с не самой лучшей селективностью, но PLAN ORDER был как раз НЕ по нему, а по другому:
TAB_NAMEIDX_NAMELAST_STATCURR_STATDIFF_STATLAST_DONEQDISTRPK_QDISTR5,87758165693231E-75,87233557780564E-75,24607912666397E-1026.07.2014 22:42:14QDISTRQDISTR_DOC_SND 5,85617226533941E-6 5,85370435146615E-62,46791387326084E-926.07.2014 22:42:14QDISTRQDISTR_SNDOP_RCVOP_SND_ID_DESC5,38363792657037E-65,38022004548111E-63,41788108926266E-926.07.2014 22:42:14QDISTRQDISTR_SND_ID5,85610359848943E-65,85366979066748E-62,43380782194436E-926.07.2014 22:42:14QDISTR QDISTR_WARE_SND_OPTYPE 0,000500000023748726 0,000500000023748726026.07.2014 22:42:14
И вот этот индекс, по которому идёт навигация, он-то как раз с хорошей селективностью.

Хотя она у него такая "хорошая" за счет второго поля (там составной ключ: doc_id, snd_id). По первому полю
- возвращает гадость: 0,016215913.

Это похоже на пример из статьи:kdv

Если навигация по индексу с плохой селективностью (а для составного индекса - с плохой селективностью "префикс"-полей) всегда тормозит, то сиё очень плохо. Потому что как только мы добавим в таблицу какой-нить составной индекс, оптимизатор может запросто выбрать его, в т.ч. для PLAN ORDER'a. И - "куку" :(

Согласен вот с этим:автор4. для небольшого количества записей "стоимость" сортировки на диске или выборки в порядке индекса может быть одинаковой.- но увидел это в своём тесте только для 2.5. А вот для 3.0 разница оказалась очень серьёзной, в пользу PLAN SORT'a. База та у мну сохранилась, её саму и примеры я высылал dimitr'у.

PS. К сож-ю, в этой статье не сказано про влияние на время сортировки значений TempCacheLimit'a и TempBlockSize (впрочем, были ли они тогда, в 1.5 ?).

PPS. И еще. Полуофф (?).
Зачем тут говорится про то, что "недофетчили, оттого и быстро":kdvВторой запрос, с выборкой в порядке индекса B, несмотря на мгновенность выполнения выдает только часть записей в grid, поэтому то же самое считывание страниц и их вытеснение из кэша может начаться по мере того, как пользователь будет нажимать в grid кнопку PageDn (или стрелку вниз).- ?
Ведь ясно же, что такое сравнение некорректно и надо было сразу Shift-F9 жмякать :-)

Симонов Денис1. Я запускал твой тест и там с точностью наоборот. Навигация оказалась быстрееЧисло коннектов-молотилок + сколько ты дал времени им поработать перед тем, как сравнивать ?
(и как сравнивал: просто добавил/убавил "+0" из той ХП и перекомпилил её ?)

Симонов Денис2. Про недофетчили. В гридах дельфей это очень частый режим.Я знаю. Но у мну нет тут гридов :-)
Есть ХП, которая, вместо возврата строк в грид, должна обработать эти строки в опр. порядке, причём обязательно все .

Симонов ДенисГде то в fbdevel ДЕ рассуждал о подсказках оптимизатору.Один и тот же запрос с where f = :x будет молотить разное кол-во строк при разных :x, т.к. данные всегда могут быть перекошенными.
Без гистограмм распределения значений сколько не подсказывай оптимизатору, толку большого не будет.

Симонов Денис
эквивалентен
При наличии индекса по ID. Но второй мне как-то более понятным кажется.

Гаджимурадов РустамТаблоид> Без гистограмм распределения значений сколько
Таблоид> не подсказывай оптимизатору, толку большого не будет.

С чего это вдруг? Это смотря какие хинты и как реализовать.Ну так если оптимизатор будет знать распределение данных и НЕ будет составлять план параметризованного запроса заранее, до получения конкретного значения параметра, то... зачем тогда вообще хинты ? :)

dimitrесть куча запросов с непараметризованными предикатами. Классический пример: WHERE IS_DELETED = 0 AND blah-blah-blah - тут тебе и константа и охрененный перекос в распределении.я видел эти дебаты по поводу подсказок (летом в прошлом году они были ?), но что там решили в итоге - не дочитал. Искать в fb-devel'e невозможно, в почте яндекса (куда мне идёт пересыл) - тоже.
Хинты - зло. Рано или поздно они устаревают ввиду изменений в данных. План должен быть другим, но не становится таковым.
Даже с изменением PLAN ORDER на PLAN SORT (добавлением "+0") - возможна ситуация, когда надо будет вернуть всё взад. Я уж не говорю про всякие искуственные замены inner join'ов на left join'ы, воткнутые в авральном порядке, "чтобы сейчас хоть как-то работало, а попозже обязательно разберёмся" (ога, ну-ну...).

Если будет какая-то возможность отследить (трейсом ?) запросы, идущие с хинтами, то это еще ладно, фиг с ними. Но если хинты будут проскакивать мимо всяких средств отслежки, то это бомба себе под табуретку.

Симонов Денисне в случае двух обсуждаемых типов хинтовчто именно "не в случае" ? Думаешь, не понадобится отлов таких вариантов запросов (с ALL_ROWS | FIRST_ROWS) ?