fed: Ledger Balance Data in DAX

[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...