dynamicsmatters: Performance and InventDim

[Blog bot]

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



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

[mazzy]

ужас какой-то...

[kashperuk]

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

[mazzy]

можно тогда попросить тебя изложить своими словами то, что он предложил?
может быть мой английский настолько плох, что я ни черта не понял?

[kashperuk]

Если кратко, то он предложил:

1. Удалить таблицу InventDim
2. Во всех таблицах, где есть поле InventDimId, это поле удалить, и добавить по 3 новых (с ArraySize > 1 у всех)

То есть в каждой таблице (на стороне SQL) будет вместо 1 поля 9 (или сколько там, я не посчитал)

Чем мне не нравится такой подход:
- Размер базы намного больше
- В каждой таблице больше полей, поэтому больше постоянно тянется при запросах
- Размер индексов больше, соответственно, размер базы больше и скорость меньше.
т.д.

P.S. Поздравляю с репутацией == 600!
Я бы создал в соответствущей теме это, но пора бежать на развозку.

[mazzy]

Цитата:

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

Если кратко, то он предложил:

1. Удалить таблицу InventDim
2. Во всех таблицах, где есть поле InventDimId, это поле удалить, и добавить по 3 новых (с ArraySize > 1 у всех)

То есть в каждой таблице (на стороне SQL) будет вместо 1 поля 9 (или сколько там, я не посчитал)

Угу. И все с индексами. Если я правильно понимаю, то одна из главных задач, которая решалась при созданиии InventDim - это избавиться от монстроидальных составных индексов на таблицах проводок/строк журналов/строк заказов/итогов.

Я и говорю - ужас какой-то (несмотря на мой плохой английский, понял таки правильно )

[gl00mie]

Цитата:

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

Угу. И все с индексами. Если я правильно понимаю, то одна из главных задач, которая решалась при созданиии InventDim - это избавиться от монстроидальных составных индексов на таблицах проводок/строк журналов/строк заказов/итогов.

Вместо монстроидальных индексов получили монстроидальные планы запросов, когда join'ятся несколько таблиц, в каждой из которых - миллионы записей, из-за чего в конечном итоге возникает то тут, то там денормализация данных: рядом с inventDimId в транзакционных таблицах селится inventLocationId или другие поля из InventDim. Кроме того, если на каждой таблице проводок/строк журналов/строк заказов будут свои индексы, ими будет проще управлять, даже если они будут на sys-слое. Нужно ускорить выборку по какой-то таблице в каком-то разрезе - привинтил индекс, не нужно - отключил его, и пусть болтается в AOT'е. А так выходит, что одна таблица InventDim, пухнущая не по дням, а по часам, обрастает кучей индексов на все случаи жизни...

[mazzy]

Цитата:

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

Вместо монстроидальных индексов получили монстроидальные планы запросов, когда join'ятся несколько таблиц, в каждой из которых - миллионы записей, из-за чего в конечном итоге возникает то тут, то там денормализация данных:

Хе... А это вы просто ГТД бездумно используете.
Обратите внимание, что серийные номера и партии в стандартном функционале относятся к "селективным" (там метод такой есть). А вот ГТД забыли в этот метод включить

Кроме того, обратите внимание, на отдельные запросы по селективным полям... А у ГТД опять же "забыли" сделать отдельные запросы.

Сколько раз видел, что народ добавляет свои поля, похожие на ГТД и также не указывает "селективность"... Кроме того и ГТД нельзя в InventDim запихивать. В inventDim должны присутствовать только признаки, которые можно проинвентаризировать.

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

[Vadik]

Цитата:

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

Я и говорю - ужас какой-то (несмотря на мой плохой английский, понял таки правильно )

Зачем сразу "ужас". Это не ужас. Это идея, причем здравая - INVENTDIM при использовании палет или серийных номеров и есть настоящий монстр, постоянно join-ящийся к проводочным таблицам. И на нем как раз монстроидальный составной индекс DimIdx.

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

P.S. Ты посмотри на \Data Dictionary\Tables\InventSum\Methods\queryAddHint, \Data Dictionary\Tables\InventSum\Methods\queryAddHintFromCaller
Вот где ужас-то
P.P.S. Хотя одними макросами тут конечно не обойдется..

[Vadik]

Цитата:

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

Хе... А это вы просто ГТД бездумно используете.
Обратите внимание, что серийные номера и партии в стандартном функционале относятся к "селективным" (там метод такой есть). А вот ГТД забыли в этот метод включить

а включим ГТД в волшебный метод - и размер таблицы волшебным же образом уменьшится?


опять же - "бездумно"..
какой функционал есть, такой и используем..
или предлагаешь свой написать?

[mazzy]

Цитата:

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

Зачем сразу "ужас". Это не ужас. Это идея, причем здравая - INVENTDIM при использовании палет или серийных номеров и есть настоящий монстр, постоянно join-ящийся к проводочным таблицам. И на нем как раз монстроидальный составной индекс DimIdx.

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

Дык, они и так разными запросами join'ятся.
См. например, \Classes\InventSumFinancial\setValueQty

Цитата:

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

P.S. Ты посмотри на \Data Dictionary\Tables\InventSum\Methods\queryAddHint, \Data Dictionary\Tables\InventSum\Methods\queryAddHintFromCaller
Вот где ужас-то
P.P.S. Хотя одними макросами тут конечно не обойдется..

И сюда тоже ГТД вписать надо
Вообще говоря, ты привел методы, которые используют метод
\Data Dictionary\Tables\InventDimParm\Methods\isFlagSelective

посмотри чем он используется при помощи перекрестных ссылок. Этот метод определяет поля, поиск по которым дает очень селективную выборку. В зависимости от этого метода в Аксапте работает очень много кода для "оптимизации".

Попробуй сделать минимальную правку - добавь ГТД в метод isFlagSelective. Обрати внимание насколько изменилось поведение системы


А вообще говоря, согласен с тем, что сам InventDim - это результат программистского подхода: щас мы наваяем универсальный механизм, а пользователи его будут настраивать. Но перенести этот универсальный механизм в array - это не выход. Это тот же самый программистский подход - вид сбоку

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

[mazzy]

Цитата:

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

а включим ГТД в волшебный метод - и размер таблицы волшебным же образом уменьшится?

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

Цитата:

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

опять же - "бездумно"..
какой функционал есть, такой и используем..
или предлагаешь свой написать?

Не знаю. Все еще не знаю. Но идея Axapta Light по прежнему бурлит... Пока себя сдерживаю изо всех сил.

[glibs]

Цитата:

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

...
"Миллионы записей в InventDim" - это ненормально.
...

Если использовать WMS (даже без ГТД) — вполне реально. Партии и серийные номера раздувают InventDim сильно. В производстве это особенно актуально (там партии используются частенько, серийные номера иногда).

А селективность спасает только на определенных запросах. При раздутом другими аналитиками InventDim отбор проводок, которые относятся к определенному складу, например, превращается в трудоемкую задачу для сервера СУБД.

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

[kashperuk]

Цитата:

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

Надо перерабатывать саму идеологию.

Слава богу,

Цитата:

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

разработчик

вроде как раз так и думает сделать. Что не может не радовать

[Vadik]

Цитата:

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

Дык, они и так разными запросами join'ятся.
..
посмотри чем он используется при помощи перекрестных ссылок. Этот метод определяет поля, поиск по которым дает очень селективную выборку. В зависимости от этого метода в Аксапте работает очень много кода для "оптимизации".
См. например, \Classes\InventSumFinancial\setValueQty
..
если идет фильтрация по селективному полю, то будут работать совсем другие запросы и совсем другие хинты

Знаю, поэтому и говорю - "ужас"
Мне кажется, это тупиковое направление. Особенно если учитывать возможность добавления новых "селективных" аналитик. Как например должна выглядеть логика в случае указания двух "селективных" аналитик - выбирать "наиболее селективную"?
А оптимизатор СУБД на что придуман? За него ведь "уже уплочено"..

Цитата:

Попробуй сделать минимальную правку - добавь ГТД в метод isFlagSelective. Обрати внимание насколько изменилось поведение системы

Да если бы оно от этого сильно менялось.. Индекс по номеру ГТД ведь в коде не протянули.

Цитата:

А вообще говоря, согласен с тем, что сам InventDim - это результат программистского подхода: щас мы наваяем универсальный механизм, а пользователи его будут настраивать.

Так.. опять наезды на программистов
Идея универсального механизма хорошая, но механизм пора чуток обновить с учетом того, что самих аналитик и их комбинаций чуть больше, чем задумывалось на этапе проектирования

Цитата:

Но перенести этот универсальный механизм в array - это не выход. Это тот же самый программистский подход - вид сбоку

Да, тут человек недодумал скорее всего. Потому что получение остатков в разрезе аналитик теперь невозможно - либо запрос по транзакционным таблицам, либо перенос аналитик в InventSum
Но не беда. Зато - идет мыслительный процесс

Цитата:

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

Собственно, я о том же.


Разве что с тем, что комбинаций номенклатурных аналитик больше, не совсем согласен. It depends

[mazzy]

Так. Я кажется выразился невнятно.

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

Совсем как некоторые Майкрософты, партнеры или некоторые клиенты, которые переписывают Аксапту под девизом "мы сейчас за две недели не коленке сбацаем". Причем они уверены, что сбацают гораздо лучше, чем предшественники.

Теперь к обсуждению:

Цитата:

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

Если использовать WMS (даже без ГТД) — вполне реально. Партии и серийные номера раздувают InventDim сильно. В производстве это особенно актуально (там партии используются частенько, серийные номера иногда).

А селективность спасает только на определенных запросах. При раздутом другими аналитиками InventDim отбор проводок, которые относятся к определенному складу, например, превращается в трудоемкую задачу для сервера СУБД.

Именно. На "определенных запросах".

Автор должен был либо проанализировать что уже сделано и как можно улучшить с сохранением совместимости. Либо проанализировать свое предложение - не станет ли "спасительных опеределенных запросов" меньше.

Я не спорю.
В свое время писал Добавление аналитики (и другие темы)
и сейчас повторю: Аксапта работает с нормальной производительностью при условии что InventDim существенно меньше, чем InventTrans.

Большой InventDim - зло. Аксиома.

НО: во многих российских внедрениях проблемы возникают не из-за WMS, партий и серийных номеров. А из-за неправильно реализованного ГТД. Кроме того, народ добавляет складские аналитики, беря за образец ГТД, и делает это неправильно.

Одним только включением ГТД (и добавленных по его подобию аналитик) в список селективных полей можно решить проблемы производительности в 60-80% внедрений.
(Vadik правильно напомнил об индексе по ГТД. Это само собой разумеется)

Еще раз повторю: согласен, большой InventDim - зло.
Но разработчики стандартной аксапты об этом зле хоть как-то подумали, а автор "универсального" предложения - нет. Именно в этом заключается "ужас", на мой взгляд.

Цитата:

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

Смотри, Глеб. Давным давно мы говорили об ответственности за свои советы.
Я более, чем уверен, что и ты, и Vadik, и несколько других человек реализуют этот способ корректно.
И я более, чем уверен, что у большинства последователей этого совета будут проблемы с целостностью.

Будь внимателен и осторожен.
Предложенный тобой способ может быть и принесет выигрыш, но чреват массой засад и потерей целостности.
Поэтому я бы не рекомендовал так делать пока разработчик не будет уверен в своих действиях на 200%.

Цитата:

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

Знаю, поэтому и говорю - "ужас"

Мы говорим о разных "ужасах"

Цитата:

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

Мне кажется, это тупиковое направление.

Я с тобой согласен вот в чем: согласен, что тупиковым является направление "универсальных", "платформенных", "программистских" механизмов, которые, по мнению разработчика, будут работать "при любых настройках".

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

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

Цитата:

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

Да если бы оно от этого сильно менялось.. Индекс по номеру ГТД ведь в коде не протянули.

О-о-о... Это отдельная пестня.

Цитата:

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

Так.. опять наезды на программистов

Да.
К сожалению

Цитата:

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

Идея универсального механизма хорошая, но механизм пора чуток обновить с учетом того, что самих аналитик и их комбинаций чуть больше, чем задумывалось на этапе проектирования

Нет, Вадим.
Пора не "чуток обновить" механизм, а разделить его на несколько механизмов согласно логике и смыслу (возможно не универсальных)

Цитата:

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

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

Насколько я понимаю, везде вместо InventDimID он предлагает вставить массив.
И в InventSum, и в заказах, и в журналах, и в накладных, и в транзакциях... Везде. А таблицу InventDim он предлагает удалить.

Цитата:

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

Но не беда. Зато - идет мыслительный процесс

А вот тут ты скорее всего прав. Как всегда
Чел предложил и предоставил замечательный повод пообсуждать задачу.
Зря бурчу. Спасибо.

Цитата:

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

Слава богу, вроде как раз так и думает сделать. Что не может не радовать

Как именно? Разработчик сделает несовместимое решение?
Можно подробнее?

[kashperuk]

Цитата:

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

Как именно? Разработчик сделает несовместимое решение?
Можно подробнее?

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

[TasmanianDevil]

Джентльмены, простите, что вмешиваюсь в высоконаучный спор мэтров ...

9(или сколько там ) полей в складской аналитике Вас пугают , а сам принцип линейной аналитики , который при добавлении нового аналитического разреза вынуждает создавать новое поле в аналитике - нет. А реально из этих 9 (или сколько там у Вас) сколько используются одновременно в одной проводке ? Два, три, четыре ? Тогда зачем плодить столь много ссылочных полей , большая часть которых для одной операции не заполняется ?

Массив ссылок, массив Enum(определяет на кого ссылается данный уровень аналитики и настраивается при настройке соответствующей модели складской аналитики, выбирая только нужные) одинаковой размерности и для каждого поля массива ссылок набор relations на соотвествующие таблицы согласно значений Enum - вот вполне разумный выход вместо линейного набора N-дцати полей, из которых в лучшем случае используются 3-4 одновременно.

У меня сейчас на одном проекте наколбасили аж 13 уровней аналитики складской, из которых в лучшем случае 3 одновременно используется - смотреть на эту порнографию тошно

[miklenew]

Не плохо бы если сделали бы и так и так, а клиент пусть сам решает как ему удобнее.

[mazzy]

Цитата:

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

9(или сколько там ) полей в складской аналитике Вас пугают , а сам принцип линейной аналитики , который при добавлении нового аналитического разреза вынуждает создавать новое поле в аналитике - нет.

Нет, не пугает.
Это реляционные таблицы и реляционные СУБД. Очень хочется послать читать теорию

Цитата:

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

А реально из этих 9 (или сколько там у Вас) сколько используются одновременно в одной проводке ? Два, три, четыре ? Тогда зачем плодить столь много ссылочных полей , большая часть которых для одной операции не заполняется ?

Для разных номенклатур заполняются разные поля.
И что в этом плохого?

"Лишние" выключаются конфигурационными ключами, секьюрити ключами, настройкой "отображение складских аналитик"

Цитата:

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

Массив ссылок, массив Enum(определяет на кого ссылается данный уровень аналитики и настраивается при настройке соответствующей модели складской аналитики, выбирая только нужные) одинаковой размерности и для каждого поля массива ссылок набор relations на соотвествующие таблицы согласно значений Enum - вот вполне разумный выход вместо линейного набора N-дцати полей, из которых в лучшем случае используются 3-4 одновременно.

Еще один деятель... Только теперь предлагает использовать жестко заданный в коде enum вместо таблицы настроек. Полей ему жалко, а 8тыс евро на инструменты разработки не жалко...

Какой блин, enum? Вы посмотрите на настройку групп складской аналитики и на то сколько там параметров. Куда эти параметры девать будете?
Какой блин, enum? Вы как выключать лишние при помощи конфигурационных ключей будете?
Какой блин, enum? Как секьюрити будете раздавать? Как RLS включать?...
Какой блин, enum? Как индексы ставить будете?

Вы предлагаете механизм, похожий на механизм субконто в 1С:Бухгалтерии.
Вы пробовали администрировать этот механизм? Вы видели эти запросы?

Оптимизаторы, блин, хреновы...
Ужас-ужас-ужас!!! Ну, продумайте до конца свою идею... Программисты, блин...

Цитата:

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

У меня сейчас на одном проекте наколбасили аж 13 уровней аналитики складской, из которых в лучшем случае 3 одновременно используется - смотреть на эту порнографию тошно

1. Не смотрите: Выключите лишние при помощи настройки "Отображение складских аналитик"
2. Не смотрите: Выключите лишние при помощи конфигурационных ключей
3. Не смотрите: Настройте ключи безопасности

Полей блин, ему жалко...
Экономика, блин, должна быть экономной, блин...
Зла не хватает...