fed: Ledger Balance Data in DAX

[fed]

Цитата:

Сообщение от glibs

А вот если бы индекс был некластерный, то записи будут лукапиться последовательно (сначала будет сканироваться кусками индекс, а потом будут лукапиться уже данные). В случае с кластерным индексом каждая страница с данными гарантировано считается только один раз (оптимально). А в случае с лукапом по индексу одна и та же страница может считаться много раз (зависит от ресурсов памяти, которыми располагает сервер БД и насколько много сессий он обслуживает и какую нагрузку они ему обеспечивают). Если весь LedgerTrans поместится в кеше, то запрос может и быстро отработать, но если пользователи-конкуренты его в момент запроса сильно нагрузят, то памяти на кеш на всех может не хватить, и будет прилично ввода-вывода.

Не совсем так. MS SQL прочитает из страниц некластерного индекса rowId страниц с данными (то есть - сочетание номер файла:номер страницы:смешение в странице), отсортирует по файлам и страницам и начнет читать. Каждая страница будет прочитана один раз. (Насчет нехватки памяти - один rowId то ли 10 то ли 12 байт памяти занимает, вряд ли памяти в систем не хватит, даже если идет чтение 10 миллионов записей). Тут правда, действительно, есть одно "но": Если по кластерному индексу у нас надо выбрать 60% записей, то система 60% страниц и прочитает. А вот по таблице с heap-org, с большой вероятностью данные из этих 60% записи разбросаны по всем станицам и запрос выльется в fullscan.
[/QUOTE]

Цитата:

Сообщение от glibs

Я говорил про стандартные индексы. На все случаи жизни индексов не настроишь. Индексирование — дело разумного компромисса.

Ну да - согласен.

.

Цитата:

Сообщение от glibs

О чем идет речь?

Ну если у тебя по таблице есть кластерный индекс, то все остальные индексы содержат не rowId, а значение ключа кластерного индекса. Поскольку ключ в стандартном ledgerBalancesDimTrans длинный, то размер индексной запси (ключ некластерного индекса+ключ для поиска по кластерному индексу) будет заметно больше. Длинее индексная запись - меньше индексных записей в странице. Меньше индексных записей в странице - выше дерево. Выше дерево - больше операций чтения.
Кроме того - если я отбираю в некластерном индексе те же 60% записей, то опять таки может сложится ситуация при котором эти 60% записей раскиданы по всем страницам кластерного индекса. И все это выльется в итоге в фулл-скан.

Так что для того чтобы кластерный индекс был действительно эффективным, надо чтобы большая часть поисков (ну то есть - эдак процентов 70 хотя бы) выполнялось всегда по одному и тому же ключу. Это хорошо выполняется для custTable, например а вот для LedgerBalanceDimTrans - не выполняется, поскольку фильтрация всегда идет по сочетанию Счет+некий набор аналитик. Просто я тут наблюдал как работает некоторое специализированное распределение счетов, в которой автор как раз использует ledgerBalancesDimTrans, и для разных видов затрат задает разные фильтры по аналитикам. Так вот - индекс использовался только для фильтрации по номеру счета+дата.

[glibs]

Цитата:

Сообщение от fed

...
Не совсем так.

Спасибо. Я действительно с процессами доступа к данным в MS SQL не знаком. Представление складываю на основании удачных попыток оптимизации производительности.

Цитата:

Сообщение от fed

...
MS SQL прочитает из страниц некластерного индекса rowId страниц с данными (то есть - сочетание номер файла:номер страницы:смешение в странице), отсортирует по файлам и страницам и начнет читать. Каждая страница будет прочитана один раз.

Я с трудом себе это представляю если в запросе будет сортировка или группировка или join. Это общий случай описан или применительно к суммированию LedgerBalancesdimTrans?

Цитата:

Сообщение от fed

...
Ну если у тебя по таблице есть кластерный индекс, то все остальные индексы содержат не rowId, а значение ключа кластерного индекса. Поскольку ключ в стандартном ledgerBalancesDimTrans длинный, то размер индексной запси (ключ некластерного индекса+ключ для поиска по кластерному индексу) будет заметно больше. Длинее индексная запись - меньше индексных записей в странице. Меньше индексных записей в странице - выше дерево. Выше дерево - больше операций чтения.

Спасибо.

Цитата:

Сообщение от fed

...
Кроме того - если я отбираю в некластерном индексе те же 60% записей, то опять таки может сложится ситуация при котором эти 60% записей раскиданы по всем страницам кластерного индекса. И все это выльется в итоге в фулл-скан.
...

60% записей — это full scan как ни крути. Исключение — если условие совпадает с кластерным индексом. Тогда это 60 процентов full scan.

Разумеется, если в условии запроса не будет критериев по первым полям кластерного индекса, то будет full scan. О том что кластерный индекс исключает full scan речи не было и быть не могло.

Цитата:

Сообщение от fed

...
Так что для того чтобы кластерный индекс был действительно эффективным, надо чтобы большая часть поисков (ну то есть - эдак процентов 70 хотя бы) выполнялось всегда по одному и тому же ключу.
...

Я бы не стал говорить про эффективность индекса вообще. Это больше похоже на теорию. Меня больше интересуют конкретные запросы и скорость их работы. Если какие-то запросы из-за индекса работают быстро — хорошо. Если он чему-то реально мешает — плохо. Дальше думать.

Цитата:

Сообщение от fed

...
а вот для LedgerBalanceDimTrans - не выполняется, поскольку фильтрация всегда идет по сочетанию Счет+некий набор аналитик.
...

Сначала код компании, потом дата, потом счет, потом сканирование по данным уже по аналитикам. Для запросов по суммированию проводок с начала времен это почти оптимально.

Цитата:

Сообщение от fed

...
Так вот - индекс использовался только для фильтрации по номеру счета+дата.
...

Если там тоже суммируются проводки с начала времен — это уже отличный результат. Иначе был бы full scan. И даже выборка по некластерному индексу большого количества данных может оказаться хуже full scan.

А проектировать систему под full scan...