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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 01.07.2024, 18:37   #1  
Lankey is offline
Lankey
Участник
 
98 / 23 (1) +++
Регистрация: 19.05.2020
Multithreading?
AX2009
Нужно сделать batch job, который идет по записям таблицы и их обрабатывает. Порядок их обработки не важен.
Имеет ли смысл срау делать multithreading , чтобы быстро обработать все записи ?
Боюсь, что multithreading - прямой путь к проблемам с локами на таблицах и сложностям в отладке. Особых проблем в производительностью у клиента пока нет.

Какие еще есть за и против, подводные камни, и на что надо обратить внимание?
Старый 01.07.2024, 22:05   #2  
Товарищ ♂uatr is offline
Товарищ ♂uatr
Участник
Аватар для Товарищ ♂uatr
MCBMSS
 
285 / 841 (29) +++++++
Регистрация: 23.10.2012
Нет тут серебряной пули.
"Боюсь, что multithreading - прямой путь к проблемам с локами на таблицах и сложностям в отладке. " - это заблуждение.
В первую очередь можно определить:
1. Будут ли объёмы обрабатываемых данных расти с ходом времени + будет ли функционал становиться "тяжелее". Если да, здесь вилка:
1.1. Постараться сократить их объем на уровне архитектуры решения. Например, использовать какую-либо группировку позволяющую за раз обработать схожие записи.
1.2. Противоположность 1.1 - не создавать избыточные записи, валидировать наличие "похожих" и пропускать этап создания, как следствие обработки.
1.3. Изначально целиться в многопоток.
2. Какие записи определяют атомарность? Если способ получения записей прост, либо они не пересекается среди множества записей или не обновляются и ложатся на индексы (ну индесы можно исправить всегда, а простоту получения можно обеспечить дополнительными уровнями абстракции на уровне данных) - это критерии ЗА многопоточность.

PS Рекомендую использовать, в данном случае, принцип разработки KISS: https://ru.wikipedia.org/wiki/KISS_(...86%D0%B8%D0%BF)
PS2 "Какие еще есть за и против, подводные камни, и на что надо обратить внимание?" На соответствие принципам разработки SOLID или GRASP + наличию модульных тестов. Это гарантии простого видоизменения функционала в случае возникновения такой необходимости.

Последний раз редактировалось Товарищ ♂uatr; 01.07.2024 в 22:16.
За это сообщение автора поблагодарили: Lankey (1).
Старый 01.07.2024, 22:05   #3  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,292 / 3514 (124) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Правильно заданный вопрос содержит половину ответа
Если нет проблем с производительностью - то зачем тогда ставить задачу "быстро обработать все записи"?
Многопоточка да, очевидно, имеет сложности в отладке, но отлаживать ее можно и в одном потоке.
А вот с фразой, что многопоточка - "прямой путь к проблемам с локами на таблицах" категорически не согласен. Просто методики программирования под многопоточку должны быть несколько иными, нежели обычное программирование.
Во-первых, для многопоточки нужно четкое секционирование объема данных для каждого потока. С учетом понимания, что накладные расходы на запуск и завершение потока должны быть ничтожно малы по отношению к времени работы потока. Т.е. условно - на каждый поток есть смысл планировать не меньше 1000-5000 записей (цифры условные - точные цифры покажет время; реализовав многопоточку - нужно добавлять параметры, регулирующие количество потоков и объем данных потока чтобы получить оптимальную скорость)

Во-вторых, это четкое секционирование необходимо обеспечить кластерным индексом (а лучше, чтобы этот кластерный индекс еще был бы и уникальным)

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

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

В общем, пожалуй - самое важное - это деление данных + оценка "стоит ли игра свеч".
Для понимания: Если надо по-быстрому перелопатить 24 млн записей - это один расклад. Если речь идет об объеме 1-2 млн записей - то смысле нет.
__________________
Возможно сделать все. Вопрос времени
За это сообщение автора поблагодарили: Lankey (1).
Теги
ax2009

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
daxdilip: Scheduling a Batch Job through code, Batch Multithreading and creating batch tasks at run time Blog bot DAX Blogs 0 17.02.2011 15:11
Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

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