AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Администрирование
DAX
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 14.02.2007, 11:01   #1  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
? Кластерный индекс на InventTrans в AX 4.0
Добрый день!

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

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

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

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

Поделитесь своим мнением! Особенно интересно что будет физически происходить с БД?
__________________
Ivanhoe as is..
Старый 14.02.2007, 11:35   #2  
Jony is offline
Jony
Участник
 
99 / 22 (1) +++
Регистрация: 25.06.2003
Адрес: г. Барнаул
При вставке будет происходить расщепление страниц - замедление
При чтении - само собой увеличение скорости выполнеиня запроса.

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

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


ПС: надеюся ничего не напутал
Старый 14.02.2007, 11:59   #3  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
В AX 4.0 на таблице InventTrans появился кластерный индекс TransIdIdx, в который входят компания, лот, код складской аналитики, recid.
Сейчас скажу спорное утверждение, пусть меня поправят более знающие товарищи: Кластерный индекс хорошо работает на вставке, если поля, входящие в кластерный индекс, как правило, монотонно возрастают. В этом случае новые записи просто добавляются в конец, а тяжелая процедура расщепления SQL-страниц не выполняется.

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

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

Я бы не стал делать этот индекс кластерным, поскольку длина записи в InventTrans достаточно большая, обычных индексов много, а цена вставки в середину и цена расщепления страниц достаточно велика.
__________________
полезное на axForum, github, vk, coub.
Старый 14.02.2007, 12:11   #4  
Jony is offline
Jony
Участник
 
99 / 22 (1) +++
Регистрация: 25.06.2003
Адрес: г. Барнаул
Если оставлять кластерный индекс (в его наличии кроме минусов есть и плюсы) , то нужно держать страници на половину пустыми (играться с fillfactor) - сократив минусы кластеризации. Но ещ раз - поэксперементируйте. Однозначно сказать, что такой кластерный индекс это плохо, нельзя. (ну конечно так же нельзя сказать что это хорошо ).
Старый 14.02.2007, 12:13   #5  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Jony Посмотреть сообщение
то нужно держать страници на половину пустыми (играться с fillfactor)
Не поможет, если в середину вставляется достаточно много записей.
InventDimId - как правило имеет очень широкий диапазон.
__________________
полезное на axForum, github, vk, coub.
Старый 14.02.2007, 14:17   #6  
Torin is offline
Torin
Участник
 
127 / 31 (2) +++
Регистрация: 10.03.2003
Адрес: Odessa, Ukraine
Согласен со всеми, но вставлю еще свои 5 копеек. Кластерный индекс, действительно, должне быть по возрастающему полю, но делать из него покрывающий индекс - занабто.
Кластерный индекс быстрее RID, поэтому желательно его иметь. Он должен быть быстрым, поэтому лучьше убирать строковые значения. Надо смотреть на плотность - база и так читает постанично, пожтому инфантильно выводить на одну необходимую запись неправильно.
Из личного опыта - наилучьшие значения произовдительности получил на recid + dataareaid кластерных индексах. И по INVENTTRANS и по INVENTSUM и по другим тоже. Но это только потому, что есть многоитерационное приближение к хорошим покрывающим индексам на том же INVENTTRANS;-)
За это сообщение автора поблагодарили: EVGL (5).
Старый 14.02.2007, 14:19   #7  
Torin is offline
Torin
Участник
 
127 / 31 (2) +++
Регистрация: 10.03.2003
Адрес: Odessa, Ukraine
И, кстати, никаких "ночных" переуплотнений - по статистике, раз в неделю только дефрагментация и все пучком.
Старый 14.02.2007, 14:31   #8  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от Torin Посмотреть сообщение
Из личного опыта - наилучьшие значения произовдительности получил на recid + dataareaid кластерных индексах. И по INVENTTRANS и по INVENTSUM и по другим тоже. Но это только потому, что есть многоитерационное приближение к хорошим покрывающим индексам на том же INVENTTRANS;-)
А при массированном добавлении записей с разных рабочих мест проблем не было ?
Просто в случае кластерного индекса по RecID все сессии будут при вставке долбить в одну страницу...
По идее можно ожидать снижения производительности, так как производится попытка вставки практически в одно и то же место в дисковом хранилище.
Старый 14.02.2007, 15:25   #9  
Torin is offline
Torin
Участник
 
127 / 31 (2) +++
Регистрация: 10.03.2003
Адрес: Odessa, Ukraine
Не уверен, что могу верно предположить Ваши и мои масштабы "массированности" ;-)
У меня нет цифр, которые можно было сравнить с Вами - я с приблудой, которая замеряет ASU и т.д. - так и не подружился. Если есть короткая и понятная инструкция - запущу, сравним.
То, что знаю - на, практически, оригинальных торговых и кастомизированных складских модулях SP3, каждую ночь разноситься от 2 до 5 тыс заказов (вместе с разноской накладных и сторнированием). Это процесс идет на скорости 600-1200 batch/sec сиквела.
А, еще раз, напоминаю - у нас еще партишионинг по dataareaid - вопрос на нескольких компаниях задавать не надо :-)
ТО, что можно визуально увидеть (когда время выполнения запроса больше 20 мс) - вставки в INVENTTRANS подтормаживают, но, как уже убедились, за счет более 2-х кратного увеличения покрывающих индексов.
Старый 14.02.2007, 15:28   #10  
Torin is offline
Torin
Участник
 
127 / 31 (2) +++
Регистрация: 10.03.2003
Адрес: Odessa, Ukraine
думаю, что ветку стоит в администрирование перенести.
Старый 14.02.2007, 15:35   #11  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от Torin Посмотреть сообщение
каждую ночь разноситься от 2 до 5 тыс заказов (вместе с разноской накладных и сторнированием). Это процесс идет на скорости 600-1200 batch/sec сиквела.
Если иметь мощное железо, то тогда можно наверно и на одном компе в пакете такое количество за ночь разнести.

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

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

Это в качестве тестового примера, если интересно конечно.
Старый 14.02.2007, 16:59   #12  
Torin is offline
Torin
Участник
 
127 / 31 (2) +++
Регистрация: 10.03.2003
Адрес: Odessa, Ukraine
под одной транзакцией ? ;-) Ничего не даст - все будут ждать первого. Вставлять пачками по 20 записей ? А в чем мерять производительность системы, чтобы можно было сравнивать ? ;-)
Старый 14.02.2007, 17:34   #13  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от Torin Посмотреть сообщение
под одной транзакцией ? ;-) Ничего не даст - все будут ждать первого. Вставлять пачками по 20 записей ? А в чем мерять производительность системы, чтобы можно было сравнивать ? ;-)

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

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

Производительность как мерять, хм...
Для начала на глазок запустить генерацию большого числа записей от 50 клиентов на таблице с кластерным индексом по RecID . А потом то же самое на таблице без кластерного индекса. И сравнить время.
Старый 17.03.2015, 11:17   #14  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Подыму тему с учетом AX 2012. В кластерном индексе следующие поля (в АОТ): InventTransOrigin, inventDimId, RecId.
Приходилось ли на проектах явно убирать такой индекс из-за производительности?
__________________
Ivanhoe as is..
Старый 17.03.2015, 13:11   #15  
Kabardian is offline
Kabardian
Талантливый разгвоздяй
Аватар для Kabardian
 
424 / 338 (12) ++++++
Регистрация: 14.12.2008
Адрес: Москва
Записей в блоге: 14
Не приходилось как-то... с другой стороны в AX 2012 проводился же тест Day In Life, там было очень много транзакций, например, в тесте Retail 16,575,000 строк стэйтментов обработано за 8 ч 45 м (включая и резервирование запасов). Может индекс не так сильно влияет на производительность?

Последний раз редактировалось Kabardian; 17.03.2015 в 13:13.
Старый 17.03.2015, 13:23   #16  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
В целом я согласен, что не влияет. Есть другие мнения В примере MS это не совсем корректно - стандартный ритейл не поддерживает партии по номенклатуре, т.е. резервирование не плодит проводки.
__________________
Ivanhoe as is..
Старый 17.03.2015, 13:45   #17  
AndyD is offline
AndyD
Участник
КОРУС Консалтинг
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
2,560 / 2476 (88) +++++++++
Регистрация: 20.08.2005
И сколько тех резервирований на один лот делается?
Ну десяток-другой.

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

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

А вообще - интересно посмотреть цифры, если кто-нибудь заморачивался с подобным
__________________
Axapta v.3.0 sp5 kr2
За это сообщение автора поблагодарили: Ivanhoe (1).
Старый 17.03.2015, 20:18   #18  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
В целом я согласен, что не влияет. Есть другие мнения .
Кластерный индекс конечно выбран не сильно удачно, так как помимо расщепления проводок по лоту есть еще и обновление InventDimId, выливающаяся в необходимость
а) физически переместить запись (возможно, даже на другую страницу)
б) обновить все ссылающиеся записи некластерных индексов
Я как пурист со стажем меняю обычно на кластерный индекс по RecId, но в целом готов согласиться с AndyD - отложенная запись в паре с кэшем контроллера разницу сглаживают достаточно сильно
__________________
-ТСЯ или -ТЬСЯ ?
За это сообщение автора поблагодарили: Ivanhoe (1).
Старый 17.03.2015, 21:57   #19  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от Vadik Посмотреть сообщение
Я как пурист со стажем меняю обычно на кластерный индекс по RecId, но в целом готов согласиться с AndyD - отложенная запись в паре с кэшем контроллера разницу сглаживают достаточно сильно
Vadik, а тот факт что recid в общем случае не возрастающий счетчик - не мешает ? Опять же, до 2012-й еще и dataareaid болтался в индексе. Ну и при расщеплении проводки также новый recid будет. В чем же выигрыш ? За счет меньшего размера ключа ?

Последний раз редактировалось Logger; 17.03.2015 в 22:05.
Старый 17.03.2015, 22:08   #20  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Я бы даже спросил, правильно ли вообще держать на InventTrans кластерный индекс ? Может эффективнее от него отказаться ?
Теги
ax4.0, inventtrans, индекс, производительность

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Dynamics AX: Managing Your Supply Chain Using Microsoft Dynamics AX 2009 - Book Review Blog bot DAX Blogs 0 31.03.2009 23:06
axStart: Microsoft Dynamics AX 2009 Hot Topics Web Seminar Series Blog bot DAX Blogs 0 06.08.2008 12:05
Arijit Basu: AX 2009 - Quick Overview Blog bot DAX Blogs 4 19.05.2008 14:47
CustInvoiceTrans кластерный индекс Tarrash DAX: Программирование 25 25.03.2008 10:25
Arijit Basu: Reporting & BI in AX: An Overview [Level 100] Blog bot DAX Blogs 0 07.01.2008 16:01
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 16:33.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.