fed: Ledger Balance Data in DAX

[fed]

Цитата:

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

Ах так?

Предлагаю тогда реализовать вашу идею с выборкой данных по проводкам в ГК с на промышленной БД с внушительным количеством проводок ГК, и дать бухгалтерам похлопать формой плана счетов с корректно настроенным отображением сальдо по счету. Желательно сразу несколько посадить их чтобы одновременно хлопали.

Посмотрим, чем они вас отблагодарят. И что вам скажет дисковый массив сервера БД.

Еще можно попробовать поставить на счетах проверку сальдо. Типа обязательное неотрицательное сальдо. И посмотреть как скоро начнут разноситься журналы ГК с большим количеством операций. Да и любые журналы, которые порождают проводки в ГК (те же складские).

Сальдо в форме плана счетов просто не место. Контроль неотрицательности сальдо - забавная штука. Никогда в своей практике не пользовался. Похоже что нормального контроллинга с его помощью просто не организуешь, а накладняк на проверку - приличный.
К слову сказать - не понятно за что ты так бьешься. Ведь мы уже выяснили что обычно размеры сопоставимы. Даже если размер ledgerBalancesDimTrans составляет скажем 15-20% от размера ledgerTrans, время выполнения запроса по ней не падает в 5 раз. Время запроса с ростом таблицы растет (и падает) не совсем линейно (вспомни хотя бы про распараллеливание запросов в SQL).
То есть - ты мне с горячностью рассказываешь про преимущества, которых мы все равно лишились еще во времена выхода 3.0. Не очень понятно чего теперь меня за советскую власть аггитировать...

[glibs]

Цитата:

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

...
Сальдо в форме плана счетов просто не место.
...

Неправильные пчелы делают неправильный мед значит.

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

Нет уж. Сдавайтесь. Зря итоговые таблицы обидели.

petr прав, все сделали по уму.

[Vadik]

Цитата:

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

К слову сказать - не понятно за что ты так бьешься. Ведь мы уже выяснили что обычно размеры сопоставимы

Да вот не всегда. Для небольшой инсталляции (полторы проводки в день по счету) таки да - что проводки просканировать, что балансы - разница несущественная, но там при любом подходе проблем с производительностью нет. Для большой (сотни а еще лучше тысячи проводок в день по счету - касса к примеру или производство) после пересчета балансов разница будет. Плюс LedgerBalancesXXX таблицы лучше сжимаются средствами БД за счет того, что в них нет такого безусловно важного хлама как текст проводки, номера журналов и пр. Я не сталкивался с инсталляциями на которых есть серьезные проблемы с получением остатков\оборотов по ГК, но технологически вроде все сделано логично и с запасом "на вырост". Вот только пересчет балансов "очеловечили" бы, снабдив параметрами для задания периода - весь LedgerTrans перелопачивать каждый раз некрасиво как-то

[Ivanhoe]

Цитата:

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

... Вот только пересчет балансов "очеловечили" бы, снабдив параметрами для задания периода - весь LedgerTrans перелопачивать каждый раз некрасиво как-то

Пересчет можно запустить из формы периодов по конкретному периоду

[glibs]

Цитата:

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

...
Ведь мы уже выяснили что обычно размеры сопоставимы. Даже если размер ledgerBalancesDimTrans составляет скажем 15-20% от размера ledgerTrans, время выполнения запроса по ней не падает в 5 раз.
...

Давайте найдем большую БД и проверим.

Одно индексирование LedgerBalancesDimTrans способствует более быстрому получению оборотов (сальдо = оборот с начала периода) за период по счету с фильтрацией по аналитикам или без такового. Одно дело сканировать фрагменты кластерного индекса, и совсем другое лукапить хренову тучу проводок по индексу, а то и свалиться в сканирование таблицы (как уж решит оптимизатор в той или иной ситуации). Выборки то огроменные получаются.

[fed]

Цитата:

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

Давайте найдем большую БД и проверим.

Одно индексирование LedgerBalancesDimTrans способствует более быстрому получению оборотов (сальдо = оборот с начала периода) за период по счету с фильтрацией по аналитикам или без такового. Одно дело сканировать фрагменты кластерного индекса, и совсем другое лукапить хренову тучу проводок по индексу, а то и свалиться в сканирование таблицы (как уж решит оптимизатор в той или иной ситуации). Выборки то огроменные получаются.

Ну насчет кластерных индексов - как раз сомнительно. Если у тебя стандартный индекс accountNum+dimension, а я ищу выборку по AccountNum+dimension[2], то индекс будет использоваться только для отбора всех проводок по счету. Фильтрация по аналитике будет делаться уже за счет данных, а не за счет индекса. И если условие по dimension[2] высокоселективно, то надо по нему индекс строить (типа transDate+accountNum+dimension[2]) (независимо от того - ищем мы по ledgerTrans или ledgerBalancesDimTrans). Может заметно быстрее получиться - несмотря на лукап... Кстати - длинный ключ кластерного индекса по ledgerBalances тут может негативную роль сыграть...

[glibs]

Цитата:

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

...
Ну насчет кластерных индексов - как раз сомнительно.
...

Не конкретно.

Цитата:

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

...
Если у тебя стандартный индекс accountNum+dimension, а я ищу выборку по AccountNum+dimension[2], то индекс будет использоваться только для отбора всех проводок по счету. Фильтрация по аналитике будет делаться уже за счет данных, а не за счет индекса.
...

Верно. Но если индекса по AccountNum+dimension[2] нет и на LedgerTrans, а его там нет, то выборка по кластерному индексу приведет к эффекту сканирования фрагментов кластерного индекса на LedgerBalancesdimTrans. Т.е. произойдет а-ля сканирования таблицы на самом деле, но по отдельным кускам таблицы. Это оптимальный подход к выборке данных в данном случае. Да, фильтрация по данным будет.

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

Индекс некластерный эффективен при выборке одной или нескольких записей из большой таблицы.

Цитата:

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

...
И если условие по dimension[2] высокоселективно, то надо по нему индекс строить (типа transDate+accountNum+dimension[2]) (независимо от того - ищем мы по ledgerTrans или ledgerBalancesDimTrans). Может заметно быстрее получиться - несмотря на лукап
...

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

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

Цитата:

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

...
Кстати - длинный ключ кластерного индекса по ledgerBalances тут может негативную роль сыграть
...

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

Блокировки? Скорость разноски на OLTP операциях?

Разумеется. OLTP оно такое. Должно учитывать интересы аналитических задач. Но при грамотной архитектуре БД тормоза OLTP пользователь не ощутит. При этом будет учтен интерес аналитических пользователей.

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