Кластерный индекс на InventTrans в AX 4.0

[Ivanhoe]

Добрый день!

В ходе общения с программистами (я консультант ) возник следующий спор:

В AX 4.0 на таблице InventTrans появился кластерный индекс TransIdIdx, в который входят компания, лот, код складской аналитики, recid.

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

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

Поделитесь своим мнением! Особенно интересно что будет физически происходить с БД?

[Jony]

При вставке будет происходить расщепление страниц - замедление
При чтении - само собой увеличение скорости выполнеиня запроса.

Про расщепление - если работа идет не 24х7 , то можно например по ночам реиндексировать inventTrans, выставляя для индекса fillfactor поменше (находится опытным путем - стандартные рекомендации 30% вроде бы) - но при этом размер таблички бодет побольше. - такая реиндексация позволит значительно сократить количество расщиплений. И в целом вставка будет происходить почти так же как и без кластерного индекса.

А вообще такие вещи можно проверить на месте , производя операции над складом с и без кластерного индекса, замеряя время их выполнения. Однозначно сказать "будет плохо" или "будет хорошо" нельзя - надо искать компромис.


ПС: надеюся ничего не напутал

[mazzy]

Цитата:

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

В AX 4.0 на таблице InventTrans появился кластерный индекс TransIdIdx, в который входят компания, лот, код складской аналитики, recid.

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

Среди указанных вами полей монотонно возрастают только лот и recid (с некоторыми допущениями)
Из-за складской аналитики записи постоянно будут вставляться между уже существующими.

Поскольку складская аналитика идет вторым полем, то отрицательные последствия не так страшны... Но все равно вероятность расщепления страниц достаточно велика.

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

[Jony]

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

[mazzy]

Цитата:

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

то нужно держать страници на половину пустыми (играться с fillfactor)

Не поможет, если в середину вставляется достаточно много записей.
InventDimId - как правило имеет очень широкий диапазон.

[Torin]

Согласен со всеми, но вставлю еще свои 5 копеек. Кластерный индекс, действительно, должне быть по возрастающему полю, но делать из него покрывающий индекс - занабто.
Кластерный индекс быстрее RID, поэтому желательно его иметь. Он должен быть быстрым, поэтому лучьше убирать строковые значения. Надо смотреть на плотность - база и так читает постанично, пожтому инфантильно выводить на одну необходимую запись неправильно.
Из личного опыта - наилучьшие значения произовдительности получил на recid + dataareaid кластерных индексах. И по INVENTTRANS и по INVENTSUM и по другим тоже. Но это только потому, что есть многоитерационное приближение к хорошим покрывающим индексам на том же INVENTTRANS;-)

[Logger]

Цитата:

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

Из личного опыта - наилучьшие значения произовдительности получил на recid + dataareaid кластерных индексах. И по INVENTTRANS и по INVENTSUM и по другим тоже. Но это только потому, что есть многоитерационное приближение к хорошим покрывающим индексам на том же INVENTTRANS;-)

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

[Torin]

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

[Torin]

Не уверен, что могу верно предположить Ваши и мои масштабы "массированности" ;-)
У меня нет цифр, которые можно было сравнить с Вами - я с приблудой, которая замеряет ASU и т.д. - так и не подружился. Если есть короткая и понятная инструкция - запущу, сравним.
То, что знаю - на, практически, оригинальных торговых и кастомизированных складских модулях SP3, каждую ночь разноситься от 2 до 5 тыс заказов (вместе с разноской накладных и сторнированием). Это процесс идет на скорости 600-1200 batch/sec сиквела.
А, еще раз, напоминаю - у нас еще партишионинг по dataareaid - вопрос на нескольких компаниях задавать не надо :-)
ТО, что можно визуально увидеть (когда время выполнения запроса больше 20 мс) - вставки в INVENTTRANS подтормаживают, но, как уже убедились, за счет более 2-х кратного увеличения покрывающих индексов.

[Logger]

Цитата:

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

каждую ночь разноситься от 2 до 5 тыс заказов (вместе с разноской накладных и сторнированием). Это процесс идет на скорости 600-1200 batch/sec сиквела.

Если иметь мощное железо, то тогда можно наверно и на одном компе в пакете такое количество за ночь разнести.

Интересно как поведет себя система если одновременно с 10- 50 рабочих мест вставлять данные будут.

Для примера можно создать простенький джоб который будет генерить строчки в InventTrans или в InventJournalTrans и запустить его одновременно с 10 - 50 компов и посмотреть как поменяется производительность системы.

Это в качестве тестового примера, если интересно конечно.

[Torin]

думаю, что ветку стоит в администрирование перенести.

[Torin]

под одной транзакцией ? ;-) Ничего не даст - все будут ждать первого. Вставлять пачками по 20 записей ? А в чем мерять производительность системы, чтобы можно было сравнивать ? ;-)

[Logger]

Цитата:

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

под одной транзакцией ? ;-) Ничего не даст - все будут ждать первого. Вставлять пачками по 20 записей ? А в чем мерять производительность системы, чтобы можно было сравнивать ? ;-)

Нет, под разными транзакциями. Можно пачками по 20 записей. чтоб каждая пачка в одной транзакции была.

Кстати, если все делать в одной транзакции то никто никого ждать не будет. Это точно. Так как записи не апдейтятся, а вставляются. На чем блокировка (и как следствие ожидание) возникнет ? На номерной серии не будет (это не 1С 7.7) - в Аксапте номера в отдельных сессиях выделяются.

Производительность как мерять, хм...
Для начала на глазок запустить генерацию большого числа записей от 50 клиентов на таблице с кластерным индексом по RecID . А потом то же самое на таблице без кластерного индекса. И сравнить время.

[Ivanhoe]

Подыму тему с учетом AX 2012. В кластерном индексе следующие поля (в АОТ): InventTransOrigin, inventDimId, RecId.
Приходилось ли на проектах явно убирать такой индекс из-за производительности?

[Kabardian]

Не приходилось как-то... с другой стороны в AX 2012 проводился же тест Day In Life, там было очень много транзакций, например, в тесте Retail 16,575,000 строк стэйтментов обработано за 8 ч 45 м (включая и резервирование запасов). Может индекс не так сильно влияет на производительность?

[Ivanhoe]

В целом я согласен, что не влияет. Есть другие мнения В примере MS это не совсем корректно - стандартный ритейл не поддерживает партии по номенклатуре, т.е. резервирование не плодит проводки.

[Vadik]

Цитата:

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

В целом я согласен, что не влияет. Есть другие мнения .

Кластерный индекс конечно выбран не сильно удачно, так как помимо расщепления проводок по лоту есть еще и обновление InventDimId, выливающаяся в необходимость
а) физически переместить запись (возможно, даже на другую страницу)
б) обновить все ссылающиеся записи некластерных индексов
Я как пурист со стажем меняю обычно на кластерный индекс по RecId, но в целом готов согласиться с AndyD - отложенная запись в паре с кэшем контроллера разницу сглаживают достаточно сильно

[Logger]

Цитата:

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

Я как пурист со стажем меняю обычно на кластерный индекс по RecId, но в целом готов согласиться с AndyD - отложенная запись в паре с кэшем контроллера разницу сглаживают достаточно сильно

Vadik, а тот факт что recid в общем случае не возрастающий счетчик - не мешает ? Опять же, до 2012-й еще и dataareaid болтался в индексе. Ну и при расщеплении проводки также новый recid будет. В чем же выигрыш ? За счет меньшего размера ключа ?

[Vadik]

Цитата:

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

тот факт что recid в общем случае не возрастающий счетчик - не мешает ?

Речь про несколько инстансов AOS ? Не мешает. При интенсивной вставке образуется непрерывная "горячая область", ее размер можете посчитать самостоятельно из своего количества AOS-ов, размера пула RecId (250), размера записи в InventTrans (около 900 байт) и условного fillfactor-а (50 - 100%). Получается несколько мегабайт на компанию, гарантированно "горячих" (уже находящихся в памяти) которые будут скинуты на диск одной или несколькими последовательными операциями записи (continuous writes), в отличие от множества мелких random writes по всему массиву при обновлении InventDimId. Ну то есть - никак не дороже. Скорее наоборот - у меня сейчас на рабочем инстансе согласно sys.dm_db_index_operational_stats расщеплений страниц на индексе по RecId на порядок (десятичный ) меньше чем расщеплений на TransOriginIdx. Плюс, расщепления по RecId при вставке - "виртуальные", так как по факту страницы как правило только в памяти живут и на диск еще не сброшены

Цитата:

В чем же выигрыш ? За счет меньшего размера ключа ?

• Меньший размер ключа некластерного индекса (а у нас их 9 в стандарте)
• Нет необходимости физически перемещать запись в InventTrans при обновлении InventDimId
• Нет необходимости обновлять записи всех некластерных индексов при обновлении InventDimId

[AndyD]

И сколько тех резервирований на один лот делается?
Ну десяток-другой.

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

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

А вообще - интересно посмотреть цифры, если кто-нибудь заморачивался с подобным