dynamicsmatters: Performance and Inventdim PII

[Blog bot]

Источник: http://dynamicsmatters.blogspot.com/...ntdim-pii.html
==============



Источник: http://dynamicsmatters.blogspot.com/...ntdim-pii.html

[mazzy]

первая часть
dynamicsmatters: Performance and InventDim

[mazzy]

Цитата:

the customer had built up a database of 24 million inventory transactions,
there were 2,5 million lines in inventdim,
inventsum had 6 million lines,
the only active dimensions were the configuration on the inventory side and the warehouse, location and palett on the storage side. No serial numbers or Batch numbers so reasonably limited usage of inventdimid's. They used FIFO costing so inventsettlements were not too bad around 16 Million.

We ran a valuation report as at 3 months in the past. The report was unable to complete after 100 hours of processing time. The server was a quad processor with 32 Gb of RAM and a dedicated 15 K RPM raid 0+1 array with 24 disks in it, no penny pinching there.

Бараны какие то, прости господи...
я бы не сказал, что это запредельно большие объемы - так средние.
Сервер какой-то запредельный, но почему то считает более 100 часов...
Использование FIFO можно считать оптимизацией, поскольку если бы закрывали "по среднему", то inventsettlement был бы на порядок больше

Не очень понятна фраза - мы считали отчет на 3 месяца в прошлое.
Значит ли это, что у них данных было всего за три месяца или данных было больше, а дату отчета унесли в прошлое на три месяца?

Здесь рассказано о концепции, которая лежит в расчете складских остатков в Аксапте
http://axapta.mazzy.ru/lib/inventsumdate/
Если у них данных было всего за три месяца, то они "считали от начала времен".




не очень понятно как они строили отчет - по всем существующим аналитикам?
но так отчет не строят в реальной жизни.
Суть в следующем. есть две основные модели использования inventDim
1. используются только условно постоянные признаки - склады, цвета, размеры, ячейки
(inventDim резко растет при запуске, затем растет очень медленно)
2. используются переменные признаки - серийные номера, партии
(InventDim резко растет при запуске, затем растет достаточно быстро. Но в каждый конкретный момент активно относительно небольшое число аналитик)

Паллеты могут относится как к первой, так и ко второй модели: можно использовать одни и те же паллеты (постоянные коды паллет) или же каждый раз создавать новый номер паллеты при приходе.

Основная идея заключается в том, что переменные коды создаются во время прихода на склад, а во время списания "уходят", закрываются и повторно не используются. В результате для второй модели InventDim пухнет (и это плохо, конечно), но активными являются относительно немного значений.

Так вот возникает вопрос - как они используют паллеты, чтобы получить 2.5 миллиона записей в InventDim. Предположим у них 100 складов. На каждом складе по 25тыс паллет(!!?) (напомню, что складов 100). Обычно паллета имеет размер около метра-двух по каждой стороне. Предположим, мы работаем с маленькими паллетами 0,5х0,5. Предположим у нас стеллажи по 10 этажей. Получается, что бы разместить только 25 тыс. паллет нужен склад площадью 625 квадратных метров. С учетом проходов и служебных помещений - около 1000 квадратных метров (на самом деле больше). И это для мини-паллет размером с коробку от ноутбука.

Сколько стоит такой склад? По разному, но аренда меньше $100 за кв.м в год бывает редко. Возьмем для определенности $100. Стоимость аренды одного такого склада в месяц около $8333.
Вы не забыли, что таких складов нужно 100, чтобы выйти на тестируемый объем?
(Для простоты предположим, что между этими складами налажена постоянная и быстрая связь. Такое предположение нужно, чтобы не обсуждать целесообразность решения с единой базой данных вместо multiSite)

Т.е. данный тестовый пример рассчитан на затраты порядка $83тыс долларов в месяц (!) только на аренду складов по московским оценкам для паллет размером с коробку ноутбука(!) (Кстати, склады >1000 кв.м выделяются в отдельную группу у операторов недвижимости)

Либо, скорее всего, тестируется модель 2, когда каждая паллета нумеруется заново, когда попадает на склад. Но при такой модели большинство номеров паллет должно быть закрыто и не должно попадать в отчет. Что значит закрыто? Это значит, что inventSum c данной аналитикой имеет признак Closed. Такие inventSum должны отбрасываться на ранних этапах построения отчета, если пользователь не указал галочкой, что хочет видеть и закрытые тоже.

Непонятно, почему они не смоги получить отчет и что значит "he report was unable to complete". Стандартные отчеты генерят первые страницы сразу. Если бы было написано "мы получили ...надцать тысяч страниц отчета, но так и не дошли до конца", то я бы поверил... А так фигня какая-то...

В общем, какой-то очередной сферический конь в вакууме.
Причем есть сомнения в квалификации тестирующих. Чем дальше, тем больше.

Цитата:

The problem lies in the volume of data.

Ох, прости господи...
Проблемы, как правило, в головах у людей

[mazzy]

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

[mazzy]

Цитата:

the customer had built up a database of 24 million inventory transactions,
there were 2,5 million lines in inventdim,
inventsum had 6 million lines,
the only active dimensions were the configuration on the inventory side and the warehouse, location and palett on the storage side. No serial numbers or Batch numbers so reasonably limited usage of inventdimid's. They used FIFO costing so inventsettlements were not too bad around 16 Million.

We ran a valuation report as at 3 months in the past. The report was unable to complete after 100 hours of processing time. The server was a quad processor with 32 Gb of RAM and a dedicated 15 K RPM raid 0+1 array with 24 disks in it, no penny pinching there.

чем больше думаю, тем чудесатее и чудесатее.

посмотрел в средний размер записи на SQL-сервере на демобазе (в демобазе используется больше аналитик, чем в обсуждаемом примере)
inventdim: avg size = 100, records = 2,500,000
inventsum: avg size = 327, records = 6,000,000
inventtrans: avg size = 413, records = 24,000,000
invetnsettlement: avg size = 302, records = 16,000,000

Общий размер данных ~= 17Гб (16,956,000,000)
А у них сервер имеет память 32Гб.

Понимаю, что индексы добавляют объем.
Понимаю, что у них средний размер записей может быть другой (скорее всего, меньше).
Но даже 30Гб данных с индексами такой сервер должен засосать почти полностью и держать в кэше. Даже на 40-50Гб должен справляться почти не затрагивая диск.
Как они смогли получить на ТАКОМ сервере больше 100часов на отчет? Это ж постараться надо...

Интересно, на какой версии тестировалось и на каком MS SQL?
Если на ax3.0, то выполнялось ли выравнивание влево? http://axapta.mazzy.ru/lib/adjustment/

Цитата:

The problem lies in the volume of data.

Господи, прости...

[mazzy]

Цитата:

A consultant that helped design the above data model came and installed his solution which basically takes the data from inventtrans + Inventdim + inventsettlement and creates a flat table from the result.

Спасибо, что InventSum не запихали во flat-таблицу

Интересно, как они inventSettlement запихали во flat таблицу.
Они же потеряли возможность сопоставления многие-ко-многим.
Если они просто просуммировали сумму из всех неотмененных InventSettlement в InventTrans, то никакого "his solution" не нужно. Нужно просто юзать уже существующее поле CostAmountAdjustment.

Но все дело в том, что так нельзя делать в отчете на произвольную дату.
Суть в том, что есть первично рассчитанная себестоимость - CostAmountPosted и есть коррекции. Прикол в том, что коррекций может быть много и они могут выполняться разными датами!

Например,
01.01.2008 - 100 рублей (Первично рассчитанная себестоимость)
10.01.2008 - 10 рублей (коррекция, пересчет или закрытие)
20.01.2008 - 5 рублей (коррекция, пересчет или закрытие)

После 20.01 поле CostAmountAdjustment = 15 рублей.
Но это поле нельзя использовать для получения себестоимости на произвольную дату!!! (есть еще и закрытое количество, и закрытая себестоимость. их тоже нельзя)

Отчет на этих неизменных данных должен показывать себестоимость:
- после 05.01 = 100 рублей.
- после 15.01 = 110 рублей.
- после 20.01 = 115 рублей.

Внеся InventSettlement во flat-таблицу консультанты легким дивжением руки запороли работу "задним числом". Теперь в качестве побочного эффекта, они получили "непредсказуемо меняющиеся отчеты за старые периоды". Теперь они вынуждены будут вводить данные только текущим числом. (И если бы это был единственный случай! Как много обращающихся к нам страдают от подобных "him solution").

Цитата:

12 hours of processing time. Afterwards the valuation report was printed in less than 10 minutes.

Маладца!
Только себестоимость в отчетах за старые периоды будут изменяться непредсказуемым образом...

Анекдот:
принимает (К)адровик на работу (С)екретаршу, спрашивает:
(К) - с какой скоростью печатаете?
(С) - 600 знаков в минуту.
(К) - О! мы вас берем.
(С) - (про себя) такая фигня получается...

Цитата:

The problem lies in the volume of data.

Господи, прости...

[mazzy]

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

Но почему? Почему в массе своей программисты и консультанты в этих пресловутых "him solution" ведут себя как медведи в мультике про вершки и корешки несчадно запарывая чужую работу, чтобы сделать свою?!

[fed]

Рискну предположить, что автор просто пишет о том, как в каком-то отчете заменили тупой вызов классов InventSumDate* в цикле, на механизм InventSumDateTrans/InventSumDateEngine.
Тем более что автор уже писал про этот механизм раньше - Dynamics AX Base Data Model Part II
А под фразой "A consultant that helped design the above data model came and installed his solution which basically takes the data from inventtrans + Inventdim + inventsettlement and creates a flat table from the result. ", подразумевается Benny Olesen. Это человек, который когда-то спроектировал логистику в Аксапте и XALе, а потом ушел из Микрософта и открыл собственную консалтинговую фирму Olesen Data. Как раз один из основных продуктов, который продает эта консалтинговая фирма - это Fast Inventory Reports. Судя по тому, что автор блога писал в своей заметке про модель данных в Аксапте, эти быстрые отчеты основаны на той же идее, что и механизм InventSumDateTrans/InventSumDateEngine в 4ой Аксапте.

[mazzy]

Цитата:

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

Рискну предположить, что автор просто пишет о том, как в каком-то отчете заменили тупой вызов классов InventSumDate* в цикле, на механизм InventSumDateTrans/InventSumDateEngine.

Думаешь?
Что-то не похожи вот эти слова на замену механизма InventSumDate*

Цитата:

...and creates a flat table from the result.

[mazzy]

Цитата:

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

Как раз один из основных продуктов, который продает эта консалтинговая фирма - это Fast Inventory Reports. Судя по тому, что автор блога писал в своей заметке про модель данных в Аксапте, эти быстрые отчеты основаны на той же идее, что и механизм InventSumDateTrans/InventSumDateEngine в 4ой Аксапте.

1. Спасибо за ссылку. Интересно. Но это типичный сайт в стиле "у нас есть такие приборы, но мы вам о них не расскажем..."

2. Давай попробуем сформулировать публично самое главное отличие между InventSumDateTrans/InventSumDateEngine и старыми InventSumDate*

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

Правильно? Я ничего существенного не забыл?

И это продается как основной продукт? Или в Fast Inventory Reports еще что-то есть? Может там кардинально меняется механизм InventDim? Если нет, то благословенна страна Дания...

[fed]

Когда мы пользуемся стандартными классами inventSumDate*, то алгоритм выглядит примерно так:
1. Строим запрос по inventSum+inventDim, группируя по нужному сочетанию аналитик
2. В цикле бежим по результату запроса, вызывая класс inventSumDate* для каждого найденного сочетания аналитик. При этом внутри этого класса, система порождает несколько отдельных запросов к inventSum, inventtrans+inventTransPosting, inventSettlement. При этом каждый запрос, естественно, вызывает достаточно приличные накладные расходы на разбор сервером, построение плана запроса, чтение нескольких страниц из БД и так далее.

InventSumDateEngine работает по другому:
1. Создает запрос по всем номенклатурам и аналитикам в inventSum+inventDim, пишет аналитики и суммы с количествами в inventSumDateTrans
2.Создает аналогичный запрос по inventTrans+inventTransPosting для физических разносок за период, пишет результаты в inventSumDateTrans
3. Аналогично - для финансовых разносок в inventTransPosting за период.
4. Создает запрос для всех коррекций в inventSettlement за период.
5. Группирует и суммирует уже созданные записи в inventSumDateTrans
Потом ты в своем собственном коде должен пробежаться по inventSumDateTrans, напечатать и удалить Да - там еще есть некое поле с номером сессии или чем-то подобным, чтобы несколько пользователей друг другу не мешали. Вообще - с этим механизмом мне не все понятно. Я, например, так и не понял почему они физические разноски мешают с финансовыми коррекциями. Ну да ладно. А повышение производительности происходит из за того что ты много мелких запросов по каждой номенклатуре и складской аналитике заменяешь на несколько крупных, на которых лучше отыгрывает мощный сервер БД.

Чего сделано в Fast Inventory Reports - не знаю, сам не щупал.

[Logger]

Mazzy, почему бы тебе не обсудить эту тему с самим автором ?

Создается ощущение некоей предвзятости с твоей стороны. Описание которое оставил Sven - очень краткое и непонятно что он имел в виду, но это не помешало тебе его раскритиковать.

[mazzy]

Цитата:

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

Mazzy, почему бы тебе не обсудить эту тему с самим автором ?

А почему я должен обсуждать с автором его публичные выступления?

Мне по русски-то время нужно, чтобы написать
А по-аглийски... Ломает.

Думаю, что русский текст даст пищу для размышлений и будет полезен тем, кто раздумывает "переписать себестоимость", а также тем, кому предлагают "переписать себестоимость" консультанты...

Цитата:

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

Создается ощущение некоей предвзятости с твоей стороны. Описание которое оставил Sven - очень краткое и непонятно что он имел в виду, но это не помешало тебе его раскритиковать.

Совершенно верно. Жуткая предвзятость. Дело в том, что это не единственный случай, когда консультанты с "him solution" ломают стандартную функциональность... ладно бы что-нибудь отсутствующее добавляли... просто ломают предоставляя меньший функционал... Наболело.

[Logger]

Цитата:

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

А почему я должен обсуждать с автором его публичные выступления?

Да нет, не должен конечно...

Ну так просто конструктива больше получится.
Они ведь там в своем соку варятся - не учтут что-нить - а потом мы расхлебывай в очередной версии.

Я Sten-у пробовал писать - интересные обсуждения получились.

[fed]

Решил поднять старую тему поскольку выяснилось что этот самый Бенни Оллесен открыл собственную фирму, которая разрабатывает улучшенный модуль логистики для Аксапты.
http://www.inventoryii.com
На вский случай - я это не продаю, да и вообще не вижу смысла в покупке каких-то дополнительных модулей третьих фирм для аксапты. Просто в описании продукта все-таки проглядывают некоторые идеи и know-how, которые могут кому-то пригодиться для собственных разработок...

[kashperuk]

Я, кстати, буду работать вплотную с решением этим через некоторое время - интересно посмотреть, что они там наделали.

[Zabr]

Цитата:

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

Решил поднять старую тему поскольку выяснилось что этот самый Бенни Оллесен открыл собственную фирму, которая разрабатывает улучшенный модуль логистики для Аксапты.
http://www.inventoryii.com

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

[fed]

Цитата:

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

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

Ну у них основной сайт здесь вот: http://www.fsbdev.com/
FSB Development как ни странно Но что-то я этой информации на форуме не помню...