Цитата:
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.
Ох, прости господи...
Проблемы, как правило, в головах у людей