Я в замешательстве от предпоследнего слайда.

Допустим, у меня таблица Docs с 5.000.000 записями, и мне надо загрузить 500 докуметов с известными ключами.

Я просто делаю select * from Docs where DocId in (123,124,145,148, ... )
И всё моментально грузится.

Если последовать совету и переписать на where DocId+0 in (...)
станет всё очень медленно и печально.

kdvВ основном field in (...) используют с неуникальными индексами, о чём я и говорил
Спасибо, теперь стало понятнее.
Также это, возможно, объясняет явление, что join по primary key намного быстрее, чем по другому индексированному полю таблицы.

Я никак не мог этого понять, думал, что в обоих случаях используется одинаковый поиск по ключу в индексе.

Ivan_PisarevskyОпять таки, если у тебя так много известных ИДов, то можно очень легко натолкнуться на ограничение по длине запроса. а если не 500, скажем 5000?
разбиваю на блоки по 500

Ivan_PisarevskyСдается мне дешевле будет ИДы влить в ГТТ табличку и сджойниться с ней, чем писать ин.
тут проблема будет передать 500 инсертов, это очень медленно.
всё никак не дождусь, когда сделают bulk insert

Гаджимурадов Рустамunah> явление, что join по primary key намного быстрее, чем по другому индексированному полю таблицы.

Ась? Это откуда ?

Из жизни.
Вот пример:


заливаем 700 записей в Shops, и 5.000.000 в Orders.
Теперь сравниваем скорость


и

Симонов ДенисВо-вторых сравнивать надо


это понятно, что всё надо фетчить.

сейчас сравнил все варианты на тестовом сервере.

join по primary key - быстрее

PLAN JOIN (O NATURAL, S INDEX (PK_SHOPS))

------ Performance info ------
Prepare time = 15ms
Execute time = 16s 224ms
Avg fetch time = 16 224,00 ms
Current memory = 147 808 712
Max memory = 800 120 680
Memory buffers = 2 048
Reads from disk to cache = 75 685
Writes from cache to disk = 17
Fetches from cache = 0

чем так

PLAN JOIN (S NATURAL, O INDEX (FK_ORDER_REF_SHOP))

------ Performance info ------
Prepare time = 16ms
Execute time = 19s 640ms
Avg fetch time = 19 640,00 ms
Current memory = 147 734 296
Max memory = 800 120 680
Memory buffers = 2 048
Reads from disk to cache = 1 672 411
Writes from cache to disk = 28
Fetches from cache = 0

И внимание на кол-во страниц, это очень важно. Под нагрузкой время будет отличаться намного сильнее.

Хеш-join вне конкуренции (новость тройки? я его как-то упустил из виду)

PLAN HASH (O NATURAL, S NATURAL)

------ Performance info ------
Prepare time = 0ms
Execute time = 6s 615ms
Avg fetch time = 6 615,00 ms
Current memory = 147 732 704
Max memory = 800 120 680
Memory buffers = 2 048
Reads from disk to cache = 75 433
Writes from cache to disk = 8
Fetches from cache = 0

Ivan_PisarevskyКлиент же каким-то образом раздобыл себе списки ключей, сдается мне, что он вычитал оные с сервера, а не придумал сам.

Откуда берутся эти списки ИДов?
Разные случаи.

Самое простое - загрузка (или любая другая операция) с большим списком сущностей, по которой юзер хочет видеть прогресс.
Тогда первый запрос select Id from ... join ....
узнаём, сколько всего будет строк в результате, а потом выполняем операцию (грузим на клиент) пачками по 100-1000.

Особенно актуально, если клиент подключен не БД, а к серверу приложений по HTTP и на каждый запрос у клиента лимит по времени и размеру пакета.


Был ещё вариант использования FB как тупое key-value хранилище.

Применялось ручное управление кешированием в сервере приложений.
Все join-ы делаются в памяти, а строки грузятся по списку Id, только те, которых ещё нет в памяти инстанса. Сильно экономит кол-во чтений из БД.

И напоследок. Отношения многие-ко-многим.
Мастер-сущность в таблице с 30 млн. записей, Detail - 3 млн. записей и линков между ними - более 300 млн (отдельная таблица со ссылками на master и detail для каждой связи, всё по лучшим практикам).
И вот как раз join к таблице links стал захлёбываться (потому что не по unique index?).

Последователи чистой реляционной теории могут плеваться, но факт есть факт.
После переноса links в таблицу master тупо в строковое поле varchar(3000) id-шники через запятую, и чтением details по списку Id (where DetailId in (121,122,123,...)) нагрузка настолько уменьшилась, что система была спасена.

Старый плюшевый мишкаЯ тебе один умный вещь скажу, только ты не обижайся пожалуйста (С)У вас опыт слишком ограничен, а мне обижаться? ;)

Симонов ДенисНу и буфер Memory buffers = 2 048 для троечного SS это просто смех.
Проверил на другом сервере

PLAN JOIN (O NATURAL, S INDEX (PK_SHOPS))
Memory buffers = 4 194 304
Reads from disk to cache = 120


PLAN JOIN (S NATURAL, O INDEX (FK_ORDER_REF_SHOP))
Memory buffers = 4 194 304
Reads from disk to cache = 914


Похоже это не бага с огромным кол-вом чтений при таких join-ах.
Просто надо buffers поднимать ))) Кто-ж знал )))

hvlad,

у меня было хорошо воспроизводимое наблюдение:

- если добавлять в запрос join-ы по primary key, никаких проблем можно не ждать

- есть добавлять в запрос join-ы по другим индексам, может резко вырасти кол-во чтений страниц, и такими join-ами надо всё 100 раз проверить.

Хорошо, что в этой теме более-менее разобрали причину.

Старый плюшевый мишкаХоспиди, да при чём тут ПК-не ПК... Азбука, порядок объединения таблиц. Ясен пень перебор большей с подтягиванием элементов меньшей будет тормозней, какой индекс ни используй.
Результат видели? Перебор большей с подтягиванием элементов меньшей получился быстрее ;)

unahСтарый плюшевый мишкаХоспиди, да при чём тут ПК-не ПК... Азбука, порядок объединения таблиц. Ясен пень перебор большей с подтягиванием элементов меньшей будет тормозней, какой индекс ни используй.
Результат видели? Перебор большей с подтягиванием элементов меньшей получился быстрее ;)
Я так понимаю, причина в том, что страницы большой таблицы сервер читает последовательно, а маленькая умещается в кешах.

Если ходить по маленькой и присоединять большую, записи большой таблицы будут подтягиваться рандомно из разных страниц, страницы придётся перечитывать.

Ivan_PisarevskyКакая глубина индекса по большой таблице?

в мастер-таблице не бывает удалений, вообще заменить FK на Check.
что именно проверять надо?

Ivan_PisarevskyМои в этом плане отучены уже требовать прогресс бар. дрессировка, однако. Прогресс бары зло, на них ресурсов надо почти как на само действо
Ну вот ещё причина. Допустим, сервер приложений не умеет делать read-only транзакции, а выборка 8000 объектов (с кучей подгрузок из других таблиц) занимает 10 минут.

В этом случае, быстро получаем список Id документов в одной короткой транзакции (без деталей).
И потом делаем небольшие транзакции, на пару секунд, по 20 документов в пачке.

300 транзакций по 2 секунды лучше, чем одна 10-минутная?

Ivan_Pisarevskyнавскидку криминала не заметно, если интересно лучше создать отдельный топик и перетереть, с примерами, планами, статистикой.
Сейчас не важно. Понятно, что buffers сильно не хватало.
Было это на FB 2.5 CS, текущий FB 3.0 SS может и справился бы, если увеличить buffers.
Но всё равно, новая денормализованная схема будет быстрее любых join-ов.

hvladunahFetches from cache = 0Серьёзно ? Откуда это ???
Похоже, IBExpert перестал показывать.
В mon-таблицах всё честно:


2511127

Старый плюшевый мишкаНаличие записи в Sklad при вставке в Order и при изменении в ордере склада.
Я думал, какой check constraint предлагаете...
Видимо, подразумевалось заменить foreign key на index.

hvladunahПохоже, IBExpert перестал показывать.Если так, то нужно сообщить Александру

Я потестил немного... Проблема не в IBExpert.

Берём gds32.dll от FB 2.6, кладём в IBExpert - fetches показывает (естественно, на FB 2.5, к 3.0 не коннектится).

Но любая 32-битная fbclient.dll от тройки (начиная с беты до последнего снепшота 3.0.4) или четвёрки (4.0.0.918) приводит к тому, что fetches=0, что при подключении к FB3, что к FB2.5

Версия IBExpert любая - 2015, 2017, 2018

Как бы эти fetches и не нужны вовсе. Убрать их, чтобы не смущали.

unahот FB 2.6
от 2.5.6

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

я те уберу Ну, то есть ты ими так активно пользовался, что не заметил, как они пару лет назад отвалились :)

Симонов Денися те уберу
Да, удалять только Fetches недостаточно.

Там, оказывается, врёт не только Fetches, но как минимум и "Writes from cache to disk".
Иногда показывает много writes в select, но мусора точно нет - база после sweep и никто в ней не работает.