AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 23.12.2011, 20:01   #1  
Pustik is offline
Pustik
Участник
 
807 / 372 (14) ++++++
Регистрация: 04.06.2004
InventLocationId в InventTrans
Кто-нибудь задумывался о том, что перенос аналитики Склад в Таблицу Складских проводок(InventTrans) заметно увеличит производительность всего, что с этим связано?
__________________
-Ты в гномиков веришь?
-Нет.
-А они в тебя верят, смотри, не подведи их.
Старый 23.12.2011, 20:28   #2  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,936 / 3229 (115) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Задумывались. Но так и не сделали.
Сделали для InventSum. Результатом довольны.
Старый 23.12.2011, 21:37   #3  
Pustik is offline
Pustik
Участник
 
807 / 372 (14) ++++++
Регистрация: 04.06.2004
не плохое решение, как сильно повлияло на производительность?
__________________
-Ты в гномиков веришь?
-Нет.
-А они в тебя верят, смотри, не подведи их.
Старый 23.12.2011, 22:10   #4  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,936 / 3229 (115) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Сильно.
Чем больше записей в InventSum - тем сильнее. Используется партионный учет.

По сути везде где надо быстро получить остатки в разрезе номенклатур и складов, используется только InventSum без джоинов. Поэтому цифр сходу не скажу. (Надо специально попробовать с джоином)
Старый 24.12.2011, 05:48   #5  
Pustik is offline
Pustik
Участник
 
807 / 372 (14) ++++++
Регистрация: 04.06.2004
Цитата:
Сообщение от Logger Посмотреть сообщение
Сильно.
По сути везде где надо быстро получить остатки в разрезе номенклатур и складов, используется только InventSum без джоинов.
Нам часто интересны не остатки, а обороты.
Почему решили именно в InventSum?(если для остатков - идеальное решение).Но ведь добавление склада в InventTrans решает все проблемы. И остатков и оборотов.У Вас были сомнения? Если можно расскажите?
__________________
-Ты в гномиков веришь?
-Нет.
-А они в тебя верят, смотри, не подведи их.
Старый 24.12.2011, 10:09   #6  
lev is offline
lev
Ищущий знания...
Аватар для lev
Oracle
MCBMSS
Axapta Retail User
 
1,723 / 491 (20) +++++++
Регистрация: 18.01.2005
Адрес: Москва
Цитата:
Сообщение от Pustik Посмотреть сообщение
Кто-нибудь задумывался о том, что перенос аналитики Склад в Таблицу Складских проводок(InventTrans) заметно увеличит производительность всего, что с этим связано?
Да, склад в InventTrans добавляли (на первом моем прооекте по аксапте ).
И сделано это было, когда поняли, что надо что то делать с производительностью!
Отчеты по остаткам в разрезе складов, а так же отчеты анализа приходов \ расходов по складам (это не все, первое что вспомнилось) начали работать гараздо быстрее! А именно, например, остаток по складам вместо ~30 мин, стал выводится за 1-2 минуты.

P.S. это делали ещё в трешке.
__________________
"Страх перед возможностью ошибки не должен отвращать нас от поисков истины." (с)
С Уважением,
Елизаров Артем
За это сообщение автора поблагодарили: Pustik (3).
Старый 24.12.2011, 12:12   #7  
Мартынов Дмитрий is offline
Мартынов Дмитрий
Участник
 
236 / 66 (3) ++++
Регистрация: 02.02.2004
Адрес: г. Москва
:)
Цитата:
Сообщение от Pustik Посмотреть сообщение
Кто-нибудь задумывался о том, что перенос аналитики Склад в Таблицу Складских проводок(InventTrans) заметно увеличит производительность всего, что с этим связано?
Неплохо бы туда перенести и все остальные аналитики.
Надеюсь что это будет сделано в следующей версии системы.
Кстати и Dimension туда бы тоже неплохо...

Кто еще что туда предложит? Получится одна универсальная таблица.
Но микрософт не чем не сможет похвастать перед конкурентами. Все будут говорить - в нашей erp 1000 таблиц или 2000 таблиц. А у нас, скажет микрософт, всего одна таблица и дальше добавит, зато производительность, удобство работы и прочее... Но вторую часть фразы уже ни кто слушать не будет.
Старый 24.12.2011, 22:45   #8  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5798 (201) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от Мартынов Дмитрий Посмотреть сообщение
Неплохо бы туда перенести и все остальные аналитики. Надеюсь что это будет сделано в следующей версии системы. Кстати и Dimension туда бы тоже неплохо... Кто еще что туда предложит? Получится одна универсальная таблица.
Непонятен этот сарказм: если у людей есть реальные проблемы с производительностью, то некоторая денормализация данных может дать очень ощутимый эффект. Правда, в исходной постановке задачи ("Нам часто интересны не остатки, а обороты") логичнее было бы использовать кубы, а не агрегировать постоянно тучу транзакционных данных, но мало ли, может, обороты надо считать оперативно и с учетом всех последних данных... Вообще же, на счет и по поводу я солидарен с Zabr:
Цитата:
Сообщение от Zabr Посмотреть сообщение
Я бы еще предложил признать склад "особой аналитикой" и вынести его из inventdim непосредственно в таблицы проводок, сумм и т.д.(то есть везде, где есть InventDimid).
Держать аналитики в отдельной таблице - хорошая идея, однако "у нас все аналитики равны, но некоторые равнее других".
За это сообщение автора поблагодарили: Logger (3), lev (3).
Старый 24.12.2011, 23:46   #9  
Pustik is offline
Pustik
Участник
 
807 / 372 (14) ++++++
Регистрация: 04.06.2004
Извините,не уточнил , обороты, нам необходимо видеть в режиме Online. Такая вот специфика предприятия.
__________________
-Ты в гномиков веришь?
-Нет.
-А они в тебя верят, смотри, не подведи их.
Старый 25.12.2011, 12:49   #10  
Мартынов Дмитрий is offline
Мартынов Дмитрий
Участник
 
236 / 66 (3) ++++
Регистрация: 02.02.2004
Адрес: г. Москва
Lightbulb
Цитата:
Сообщение от gl00mie Посмотреть сообщение
Непонятен этот сарказм: если у людей есть реальные проблемы с производительностью, то некоторая денормализация данных может дать очень ощутимый эффект.
Вопрос очень старый. Например я писал об этом здесь (см. главу "Структуры данных"). Но микрософт упорно делает все наоборот. Раньше "Конфигурация" была в InventTrans. И чем дальше тем хуже. Например в Акс 5 в мероприятиях CRM аналитики вынесены аналогичным образом.
Старый 25.12.2011, 13:11   #11  
Pustik is offline
Pustik
Участник
 
807 / 372 (14) ++++++
Регистрация: 04.06.2004
Не поленился. На тестовой базе сделал аля InventTrans2. Сделал поле Склад. Джобом перекопировал данные из стандартного InventTrans(c учетом склада) в новый InventTrans2. Отрихтовал оборотку (убрал из джоина InventDim). Отчет выдал информацию в 10 раз быстрее, причем за год, по всем складам. По конкретному складу, вообще нечего говорить, если настроить в InventTrans2 индекс.
__________________
-Ты в гномиков веришь?
-Нет.
-А они в тебя верят, смотри, не подведи их.
За это сообщение автора поблагодарили: lev (2).
Старый 25.12.2011, 14:40   #12  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,305 / 3538 (124) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Напрашивается следующий вывод (для Микрософта).
Нужно аналитику склад сделать первичной и неотключабельной в форме группы складских аналитик. Наверное, даже идеологически вынести склад из складских аналитик, и добавить отдельным полем во все таблицы, где есть inventDimId (аналог - заказы на перемещения). Только надо подумать, что делать с галкой "финансовый" (а хотя ее тоже наверное можно по умолчанию считать включенной).

С добавлением всех аналитик в InventTrans могут возникнуть сложности - т.к. все же у всех есть аналитика Склад (пусть даже у мелких контор он один), а вот все остальные аналитики далеко не всегда задействованы, а отключить выборку по ним сейчас все же проще (через InventDimParn), нежели когда они будут разбросаны по всем таблицам. Опять-таки необходимо иметь возможность добавления складских аналитик силами внедренца в боле-менее разумные сроки.

В общем, перед Микрософтом со складскими аналитиками стоят 3 задачи:
- Быстродействие
- Возможность включения / отключения пользователем (не разработчиком)
- Обеспечение возможности добавления аналитики внедренцем с минимальным изменением штатного кода.
- Навешивание на аналитики разного функционала (у складов есть своя логика, у серийных номеров - тоже есть своя и т.д.).

Сейчас во главе угла стоит возможность включать / отключать аналитики пользователем (напоминаю, что для этого требуется не только менять СУБД, а еще и писать выборки с использованием макросов #InventDim*). Это очень сильная возможность, в т.ч. маркетинговая. Поэтому, МСу нужно решить вопрос быстродействия не ломая эту возможность. Если МС пожертвует отключабельностью аналитики Склад, то тогда можно будет сконцентрироваться на быстродействии. По идее - вряд ли кто использует логистический контур системы с отключенной аналитикой Склад, поэтому тут можно было бы МСу и рискнуть. Но вопрос с остальными аналитиками остается открытым.
__________________
Возможно сделать все. Вопрос времени
Старый 25.12.2011, 14:52   #13  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,936 / 3229 (115) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Если MS сможет продавать Аксапту на большие проекты (с большим числом транзакций), то скорее всего вопрос решится сам собой. Жизнь заставит.
Старый 25.12.2011, 15:36   #14  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,907 / 5717 (196) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Очень странно, что перенос склада в inventTrans дал такой прирост производительности. Могу поверить в типичный показатель накладных расходов на джойн двух таблиц в 40-50%. Могу поверить на нетипичные случаи с 200% накладных расходов. Не могу поверить в накладные расходы в 900%
Мне кажется, у вас там просто какая-то беда с планом запроса в стандартной оборотке. Может статистика кривая, может сам сиквел глючит почему-то, может индексы не перестраивались несколько лет. В общем - попробуйте план запроса выщемить и выложить.
За это сообщение автора поблагодарили: Logger (3).
Старый 25.12.2011, 15:57   #15  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,936 / 3229 (115) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Мне кажется, результат еще сильно должен зависеть от объема памяти который в среднем выделяется на сессию.

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

Так что неплохо бы знать еще объемы таблицы, индексов, числа юзеров и оперативки БД.
Старый 25.12.2011, 17:01   #16  
Мартынов Дмитрий is offline
Мартынов Дмитрий
Участник
 
236 / 66 (3) ++++
Регистрация: 02.02.2004
Адрес: г. Москва
->
Цитата:
Сообщение от Logger Посмотреть сообщение
Мне кажется, результат еще сильно должен зависеть от объема памяти...
От объема памяти зависит много, но в данном случае по сути не зависит ни чего!

Цитата:
Сообщение от fed Посмотреть сообщение
Не могу поверить в накладные расходы в 900%
Мне кажется, у вас там просто какая-то беда с планом запроса в стандартной оборотке.
А верить не надо - возьми например, тот же x++ (хотя лучше c++) и напиши на нем выборку без использования оператора select со связкой двух таблиц с использованием индекса. (Если кто не знает, то индекс - это тоже такая таблица только сортированная). И все недоумение сразу пропадет...
За это сообщение автора поблагодарили: fed (-3).
Старый 25.12.2011, 17:42   #17  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,936 / 3229 (115) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от Мартынов Дмитрий Посмотреть сообщение
От объема памяти зависит много, но в данном случае по сути не зависит ни чего!
А почему в данном случае не зависит ? Чем он отличается от общего случая ? Как-то вы загадками говорите.
Старый 25.12.2011, 17:51   #18  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,907 / 5717 (196) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от Logger Посмотреть сообщение
А почему в данном случае не зависит ? Чем он отличается от общего случая ? Как-то вы загадками говорите.
А это такое проявление "научного подхода" к внедрениям. Автор считает что индекс, это не B-дерево, а таблица отсортированная. Также автор считает что джойн на SQL Server (все равно какой - sort/merge, hash join, nested loop join) легко может быть смоделирован с помощью вложенного селекта на клиентской стороне. Причем - и в этом, вероятно, суть "научного подхода", писать джойн надо не не ламерском X++, а на пацанском научном C++, потому что все нормальные пацаны ученые пишут только на C++, который компилируется не в ламерский байткод, а в настоящие процессорные команды. Что, конечно же, очень увеличивает степень подобия такого теста исполнению join внутри SQL Server...

Последний раз редактировалось fed; 25.12.2011 в 18:06.
Старый 25.12.2011, 18:05   #19  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,907 / 5717 (196) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от Logger Посмотреть сообщение
Если InventDim с используемым индексом влезает в оперативку, то не должно быть существенной разницы. Если же сильно не влезает, т.е. время сканирования определяется не скоростью доступа к памяти, а скоростью начитки из дискового хранилища, то почему бы и не быть таким цифрам ?
Ты в общем прав, но мне кажется что это какой-то уж очень вырожденый случай должен быть, который тяжело в реальности встретить. Все-таки трудно представить что inventTrans по отдельности в память влез, для inentTrans+inventDim настолько не хватило памяти, что скорость упала в 10 раз (а не в 1.5-2). Хотя да - интересно сколько у них там памяти, какой размер inventDim и inventTrans за год в записях; какой размер этих таблиц в целом, ну и наконец интересно было бы посмотреть на планы исполнения самых ресурсоемких запросов из оборотки...
Старый 25.12.2011, 18:33   #20  
Мартынов Дмитрий is offline
Мартынов Дмитрий
Участник
 
236 / 66 (3) ++++
Регистрация: 02.02.2004
Адрес: г. Москва
Цитата:
Сообщение от fed Посмотреть сообщение
А это такое проявление "научного подхода" к внедрениям. Автор считает что индекс, это не B-дерево, а таблица отсортированная. Также автор считает что джойн на SQL Server (все равно какой - sort/merge, hash join, nested loop join) легко может быть смоделирован с помощью вложенного селекта на клиентской стороне. Причем - и в этом, вероятно, суть "научного подхода", писать джойн надо не не ламерском X++, а на пацанском научном C++, потому что все нормальные пацаны ученые пишут только на C++, который компилируется не в ламерский байткод, а в настоящие процессорные команды. Что, конечно же, очень увеличивает степень подобия такого теста исполнению join внутри SQL Server...
Интересно, что когда я не вдаюсь в технические детали - то меня начинаю обвинять в невежестве... Разница между B-деревом и сортированной таблицей с точки зрения нашей задачи небольшая. Более того если мы создаем правильные структуры данных и делаем правильные запросы, то разница между ними вообще не в пользу B-дерева.

Хотите - можно написать на Х++, вместо таблиц здесь можно использовать контейнер без операции поиска, только с запоминанием индекса элемента. Суть задачи сводится к выборке по двум таблицам и четырем индексам: фильруем по полю 1 в первой таблице, связываем по полю 2 таблицы, фильтруем по полю 3 вторую таблицу. В первой таблице есть 2 индекса по полю 1 и полю 2 соответственно, аналогично во второй есть индексы по полям 2 и 3.

А ваше предположение что авторы которые пишут SQL сервер обладают тайным знанием - в корне неверно, скорее те кто использую SQL по большей части бездари и по этому разница бросается в глаза... Но вы fed уж не обижайтесь - я не про Вас, ваши обиды мне дорого обходятся...
За это сообщение автора поблагодарили: Vadik (-6).
Теги
оптимизация, склад, складская аналитика, складские отчеты

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Развалились InventSum - InventTrans Logger DAX: Программирование 21 25.08.2017 11:41
DynamicsAxSCM: The InventTrans table. Explore various field usages. Blog bot DAX Blogs 0 09.11.2010 19:10
Разница NotInTTS и Found Logger DAX: База знаний и проекты 6 18.09.2008 12:35
Временная таблица + RLS leshy DAX: Программирование 6 27.04.2006 12:39
Связь таблиц InventTrans и PurchLine Pustik DAX: Программирование 2 25.11.2004 12:23
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 03:11.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.