InventLocationId в InventTrans

[Pustik]

Кто-нибудь задумывался о том, что перенос аналитики Склад в Таблицу Складских проводок(InventTrans) заметно увеличит производительность всего, что с этим связано?

[Logger]

Задумывались. Но так и не сделали.
Сделали для InventSum. Результатом довольны.

[Pustik]

не плохое решение, как сильно повлияло на производительность?

[Logger]

Сильно.
Чем больше записей в InventSum - тем сильнее. Используется партионный учет.

По сути везде где надо быстро получить остатки в разрезе номенклатур и складов, используется только InventSum без джоинов. Поэтому цифр сходу не скажу. (Надо специально попробовать с джоином)

[Pustik]

Цитата:

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

Сильно.
По сути везде где надо быстро получить остатки в разрезе номенклатур и складов, используется только InventSum без джоинов.

Нам часто интересны не остатки, а обороты.
Почему решили именно в InventSum?(если для остатков - идеальное решение).Но ведь добавление склада в InventTrans решает все проблемы. И остатков и оборотов.У Вас были сомнения? Если можно расскажите?

[lev]

Цитата:

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

Кто-нибудь задумывался о том, что перенос аналитики Склад в Таблицу Складских проводок(InventTrans) заметно увеличит производительность всего, что с этим связано?

Да, склад в InventTrans добавляли (на первом моем прооекте по аксапте ).
И сделано это было, когда поняли, что надо что то делать с производительностью!
Отчеты по остаткам в разрезе складов, а так же отчеты анализа приходов \ расходов по складам (это не все, первое что вспомнилось) начали работать гараздо быстрее! А именно, например, остаток по складам вместо ~30 мин, стал выводится за 1-2 минуты.

P.S. это делали ещё в трешке.

[Мартынов Дмитрий]

Цитата:

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

Кто-нибудь задумывался о том, что перенос аналитики Склад в Таблицу Складских проводок(InventTrans) заметно увеличит производительность всего, что с этим связано?

Неплохо бы туда перенести и все остальные аналитики.
Надеюсь что это будет сделано в следующей версии системы.
Кстати и Dimension туда бы тоже неплохо...

Кто еще что туда предложит? Получится одна универсальная таблица.
Но микрософт не чем не сможет похвастать перед конкурентами. Все будут говорить - в нашей erp 1000 таблиц или 2000 таблиц. А у нас, скажет микрософт, всего одна таблица и дальше добавит, зато производительность, удобство работы и прочее... Но вторую часть фразы уже ни кто слушать не будет.

[gl00mie]

Цитата:

Сообщение от Мартынов Дмитрий

Неплохо бы туда перенести и все остальные аналитики. Надеюсь что это будет сделано в следующей версии системы. Кстати и Dimension туда бы тоже неплохо... Кто еще что туда предложит? Получится одна универсальная таблица.

Непонятен этот сарказм: если у людей есть реальные проблемы с производительностью, то некоторая денормализация данных может дать очень ощутимый эффект. Правда, в исходной постановке задачи ("Нам часто интересны не остатки, а обороты") логичнее было бы использовать кубы, а не агрегировать постоянно тучу транзакционных данных, но мало ли, может, обороты надо считать оперативно и с учетом всех последних данных... Вообще же, на счет и по поводу я солидарен с Zabr:

Цитата:

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

Я бы еще предложил признать склад "особой аналитикой" и вынести его из inventdim непосредственно в таблицы проводок, сумм и т.д.(то есть везде, где есть InventDimid).

Держать аналитики в отдельной таблице - хорошая идея, однако "у нас все аналитики равны, но некоторые равнее других".

[Pustik]

Извините,не уточнил , обороты, нам необходимо видеть в режиме Online. Такая вот специфика предприятия.

[Мартынов Дмитрий]

Цитата:

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

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

Вопрос очень старый. Например я писал об этом здесь (см. главу "Структуры данных"). Но микрософт упорно делает все наоборот. Раньше "Конфигурация" была в InventTrans. И чем дальше тем хуже. Например в Акс 5 в мероприятиях CRM аналитики вынесены аналогичным образом.

[Pustik]

Не поленился. На тестовой базе сделал аля InventTrans2. Сделал поле Склад. Джобом перекопировал данные из стандартного InventTrans(c учетом склада) в новый InventTrans2. Отрихтовал оборотку (убрал из джоина InventDim). Отчет выдал информацию в 10 раз быстрее, причем за год, по всем складам. По конкретному складу, вообще нечего говорить, если настроить в InventTrans2 индекс.

[sukhanchik]

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

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

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

Сейчас во главе угла стоит возможность включать / отключать аналитики пользователем (напоминаю, что для этого требуется не только менять СУБД, а еще и писать выборки с использованием макросов #InventDim*). Это очень сильная возможность, в т.ч. маркетинговая. Поэтому, МСу нужно решить вопрос быстродействия не ломая эту возможность. Если МС пожертвует отключабельностью аналитики Склад, то тогда можно будет сконцентрироваться на быстродействии. По идее - вряд ли кто использует логистический контур системы с отключенной аналитикой Склад, поэтому тут можно было бы МСу и рискнуть. Но вопрос с остальными аналитиками остается открытым.

[Logger]

Если MS сможет продавать Аксапту на большие проекты (с большим числом транзакций), то скорее всего вопрос решится сам собой. Жизнь заставит.

[fed]

Очень странно, что перенос склада в inventTrans дал такой прирост производительности. Могу поверить в типичный показатель накладных расходов на джойн двух таблиц в 40-50%. Могу поверить на нетипичные случаи с 200% накладных расходов. Не могу поверить в накладные расходы в 900%
Мне кажется, у вас там просто какая-то беда с планом запроса в стандартной оборотке. Может статистика кривая, может сам сиквел глючит почему-то, может индексы не перестраивались несколько лет. В общем - попробуйте план запроса выщемить и выложить.

[Logger]

Мне кажется, результат еще сильно должен зависеть от объема памяти который в среднем выделяется на сессию.

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

Так что неплохо бы знать еще объемы таблицы, индексов, числа юзеров и оперативки БД.

[Мартынов Дмитрий]

Цитата:

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

Мне кажется, результат еще сильно должен зависеть от объема памяти...

От объема памяти зависит много, но в данном случае по сути не зависит ни чего!

Цитата:

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

Не могу поверить в накладные расходы в 900%
Мне кажется, у вас там просто какая-то беда с планом запроса в стандартной оборотке.

А верить не надо - возьми например, тот же x++ (хотя лучше c++) и напиши на нем выборку без использования оператора select со связкой двух таблиц с использованием индекса. (Если кто не знает, то индекс - это тоже такая таблица только сортированная). И все недоумение сразу пропадет...

[Logger]

Цитата:

Сообщение от Мартынов Дмитрий

От объема памяти зависит много, но в данном случае по сути не зависит ни чего!

А почему в данном случае не зависит ? Чем он отличается от общего случая ? Как-то вы загадками говорите.

[fed]

Цитата:

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

А почему в данном случае не зависит ? Чем он отличается от общего случая ? Как-то вы загадками говорите.

А это такое проявление "научного подхода" к внедрениям. Автор считает что индекс, это не B-дерево, а таблица отсортированная. Также автор считает что джойн на SQL Server (все равно какой - sort/merge, hash join, nested loop join) легко может быть смоделирован с помощью вложенного селекта на клиентской стороне. Причем - и в этом, вероятно, суть "научного подхода", писать джойн надо не не ламерском X++, а на пацанском научном C++, потому что все нормальные пацаны ученые пишут только на C++, который компилируется не в ламерский байткод, а в настоящие процессорные команды. Что, конечно же, очень увеличивает степень подобия такого теста исполнению join внутри SQL Server...

[fed]

Цитата:

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

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

Ты в общем прав, но мне кажется что это какой-то уж очень вырожденый случай должен быть, который тяжело в реальности встретить. Все-таки трудно представить что inventTrans по отдельности в память влез, для inentTrans+inventDim настолько не хватило памяти, что скорость упала в 10 раз (а не в 1.5-2). Хотя да - интересно сколько у них там памяти, какой размер inventDim и inventTrans за год в записях; какой размер этих таблиц в целом, ну и наконец интересно было бы посмотреть на планы исполнения самых ресурсоемких запросов из оборотки...

[Мартынов Дмитрий]

Цитата:

Сообщение от 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 уж не обижайтесь - я не про Вас, ваши обиды мне дорого обходятся...