23.12.2011, 20:01 | #1 |
Участник
|
InventLocationId в InventTrans
Кто-нибудь задумывался о том, что перенос аналитики Склад в Таблицу Складских проводок(InventTrans) заметно увеличит производительность всего, что с этим связано?
__________________
-Ты в гномиков веришь? -Нет. -А они в тебя верят, смотри, не подведи их. |
|
23.12.2011, 20:28 | #2 |
Участник
|
Задумывались. Но так и не сделали.
Сделали для InventSum. Результатом довольны. |
|
23.12.2011, 21:37 | #3 |
Участник
|
не плохое решение, как сильно повлияло на производительность?
__________________
-Ты в гномиков веришь? -Нет. -А они в тебя верят, смотри, не подведи их. |
|
23.12.2011, 22:10 | #4 |
Участник
|
Сильно.
Чем больше записей в InventSum - тем сильнее. Используется партионный учет. По сути везде где надо быстро получить остатки в разрезе номенклатур и складов, используется только InventSum без джоинов. Поэтому цифр сходу не скажу. (Надо специально попробовать с джоином) |
|
24.12.2011, 05:48 | #5 |
Участник
|
Цитата:
Почему решили именно в InventSum?(если для остатков - идеальное решение).Но ведь добавление склада в InventTrans решает все проблемы. И остатков и оборотов.У Вас были сомнения? Если можно расскажите?
__________________
-Ты в гномиков веришь? -Нет. -А они в тебя верят, смотри, не подведи их. |
|
24.12.2011, 10:09 | #6 |
Ищущий знания...
|
Цитата:
И сделано это было, когда поняли, что надо что то делать с производительностью! Отчеты по остаткам в разрезе складов, а так же отчеты анализа приходов \ расходов по складам (это не все, первое что вспомнилось) начали работать гараздо быстрее! А именно, например, остаток по складам вместо ~30 мин, стал выводится за 1-2 минуты. P.S. это делали ещё в трешке.
__________________
"Страх перед возможностью ошибки не должен отвращать нас от поисков истины." (с) С Уважением, Елизаров Артем |
|
|
За это сообщение автора поблагодарили: Pustik (3). |
24.12.2011, 12:12 | #7 |
Участник
|
Цитата:
Надеюсь что это будет сделано в следующей версии системы. Кстати и Dimension туда бы тоже неплохо... Кто еще что туда предложит? Получится одна универсальная таблица. Но микрософт не чем не сможет похвастать перед конкурентами. Все будут говорить - в нашей erp 1000 таблиц или 2000 таблиц. А у нас, скажет микрософт, всего одна таблица и дальше добавит, зато производительность, удобство работы и прочее... Но вторую часть фразы уже ни кто слушать не будет. |
|
24.12.2011, 22:45 | #8 |
Участник
|
Цитата:
Держать аналитики в отдельной таблице - хорошая идея, однако "у нас все аналитики равны, но некоторые равнее других". |
|
|
За это сообщение автора поблагодарили: Logger (3), lev (3). |
24.12.2011, 23:46 | #9 |
Участник
|
Извините,не уточнил , обороты, нам необходимо видеть в режиме Online. Такая вот специфика предприятия.
__________________
-Ты в гномиков веришь? -Нет. -А они в тебя верят, смотри, не подведи их. |
|
25.12.2011, 12:49 | #10 |
Участник
|
Цитата:
|
|
25.12.2011, 13:11 | #11 |
Участник
|
Не поленился. На тестовой базе сделал аля InventTrans2. Сделал поле Склад. Джобом перекопировал данные из стандартного InventTrans(c учетом склада) в новый InventTrans2. Отрихтовал оборотку (убрал из джоина InventDim). Отчет выдал информацию в 10 раз быстрее, причем за год, по всем складам. По конкретному складу, вообще нечего говорить, если настроить в InventTrans2 индекс.
__________________
-Ты в гномиков веришь? -Нет. -А они в тебя верят, смотри, не подведи их. |
|
|
За это сообщение автора поблагодарили: lev (2). |
25.12.2011, 14:40 | #12 |
Administrator
|
Напрашивается следующий вывод (для Микрософта).
Нужно аналитику склад сделать первичной и неотключабельной в форме группы складских аналитик. Наверное, даже идеологически вынести склад из складских аналитик, и добавить отдельным полем во все таблицы, где есть inventDimId (аналог - заказы на перемещения). Только надо подумать, что делать с галкой "финансовый" (а хотя ее тоже наверное можно по умолчанию считать включенной). С добавлением всех аналитик в InventTrans могут возникнуть сложности - т.к. все же у всех есть аналитика Склад (пусть даже у мелких контор он один), а вот все остальные аналитики далеко не всегда задействованы, а отключить выборку по ним сейчас все же проще (через InventDimParn), нежели когда они будут разбросаны по всем таблицам. Опять-таки необходимо иметь возможность добавления складских аналитик силами внедренца в боле-менее разумные сроки. В общем, перед Микрософтом со складскими аналитиками стоят 3 задачи: - Быстродействие - Возможность включения / отключения пользователем (не разработчиком) - Обеспечение возможности добавления аналитики внедренцем с минимальным изменением штатного кода. - Навешивание на аналитики разного функционала (у складов есть своя логика, у серийных номеров - тоже есть своя и т.д.). Сейчас во главе угла стоит возможность включать / отключать аналитики пользователем (напоминаю, что для этого требуется не только менять СУБД, а еще и писать выборки с использованием макросов #InventDim*). Это очень сильная возможность, в т.ч. маркетинговая. Поэтому, МСу нужно решить вопрос быстродействия не ломая эту возможность. Если МС пожертвует отключабельностью аналитики Склад, то тогда можно будет сконцентрироваться на быстродействии. По идее - вряд ли кто использует логистический контур системы с отключенной аналитикой Склад, поэтому тут можно было бы МСу и рискнуть. Но вопрос с остальными аналитиками остается открытым.
__________________
Возможно сделать все. Вопрос времени |
|
25.12.2011, 14:52 | #13 |
Участник
|
Если MS сможет продавать Аксапту на большие проекты (с большим числом транзакций), то скорее всего вопрос решится сам собой. Жизнь заставит.
|
|
25.12.2011, 15:36 | #14 |
Moderator
|
Очень странно, что перенос склада в inventTrans дал такой прирост производительности. Могу поверить в типичный показатель накладных расходов на джойн двух таблиц в 40-50%. Могу поверить на нетипичные случаи с 200% накладных расходов. Не могу поверить в накладные расходы в 900%
Мне кажется, у вас там просто какая-то беда с планом запроса в стандартной оборотке. Может статистика кривая, может сам сиквел глючит почему-то, может индексы не перестраивались несколько лет. В общем - попробуйте план запроса выщемить и выложить. |
|
|
За это сообщение автора поблагодарили: Logger (3). |
25.12.2011, 15:57 | #15 |
Участник
|
Мне кажется, результат еще сильно должен зависеть от объема памяти который в среднем выделяется на сессию.
Если InventDim с используемым индексом влезает в оперативку, то не должно быть существенной разницы. Если же сильно не влезает, т.е. время сканирования определяется не скоростью доступа к памяти, а скоростью начитки из дискового хранилища, то почему бы и не быть таким цифрам ? Так что неплохо бы знать еще объемы таблицы, индексов, числа юзеров и оперативки БД. |
|
25.12.2011, 17:01 | #16 |
Участник
|
От объема памяти зависит много, но в данном случае по сути не зависит ни чего!
А верить не надо - возьми например, тот же x++ (хотя лучше c++) и напиши на нем выборку без использования оператора select со связкой двух таблиц с использованием индекса. (Если кто не знает, то индекс - это тоже такая таблица только сортированная). И все недоумение сразу пропадет... |
|
|
За это сообщение автора поблагодарили: fed (-3). |
25.12.2011, 17:42 | #17 |
Участник
|
|
|
25.12.2011, 17:51 | #18 |
Moderator
|
Цитата:
Последний раз редактировалось fed; 25.12.2011 в 18:06. |
|
25.12.2011, 18:05 | #19 |
Moderator
|
Цитата:
|
|
25.12.2011, 18:33 | #20 |
Участник
|
Цитата:
Сообщение от fed
А это такое проявление "научного подхода" к внедрениям. Автор считает что индекс, это не B-дерево, а таблица отсортированная. Также автор считает что джойн на SQL Server (все равно какой - sort/merge, hash join, nested loop join) легко может быть смоделирован с помощью вложенного селекта на клиентской стороне. Причем - и в этом, вероятно, суть "научного подхода", писать джойн надо не не ламерском X++, а на
Хотите - можно написать на Х++, вместо таблиц здесь можно использовать контейнер без операции поиска, только с запоминанием индекса элемента. Суть задачи сводится к выборке по двум таблицам и четырем индексам: фильруем по полю 1 в первой таблице, связываем по полю 2 таблицы, фильтруем по полю 3 вторую таблицу. В первой таблице есть 2 индекса по полю 1 и полю 2 соответственно, аналогично во второй есть индексы по полям 2 и 3. А ваше предположение что авторы которые пишут SQL сервер обладают тайным знанием - в корне неверно, скорее те кто использую SQL по большей части бездари и по этому разница бросается в глаза... Но вы fed уж не обижайтесь - я не про Вас, ваши обиды мне дорого обходятся... |
|
|
За это сообщение автора поблагодарили: Vadik (-6). |
Теги |
оптимизация, склад, складская аналитика, складские отчеты |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|