Multithreading?

[Lankey]

AX2009
Нужно сделать batch job, который идет по записям таблицы и их обрабатывает. Порядок их обработки не важен.
Имеет ли смысл срау делать multithreading , чтобы быстро обработать все записи ?
Боюсь, что multithreading - прямой путь к проблемам с локами на таблицах и сложностям в отладке. Особых проблем в производительностью у клиента пока нет.

Какие еще есть за и против, подводные камни, и на что надо обратить внимание?

[Товарищ ♂uatr]

Нет тут серебряной пули.
"Боюсь, что 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 + наличию модульных тестов. Это гарантии простого видоизменения функционала в случае возникновения такой необходимости.

[sukhanchik]

Правильно заданный вопрос содержит половину ответа
Если нет проблем с производительностью - то зачем тогда ставить задачу "быстро обработать все записи"?
Многопоточка да, очевидно, имеет сложности в отладке, но отлаживать ее можно и в одном потоке.
А вот с фразой, что многопоточка - "прямой путь к проблемам с локами на таблицах" категорически не согласен. Просто методики программирования под многопоточку должны быть несколько иными, нежели обычное программирование.
Во-первых, для многопоточки нужно четкое секционирование объема данных для каждого потока. С учетом понимания, что накладные расходы на запуск и завершение потока должны быть ничтожно малы по отношению к времени работы потока. Т.е. условно - на каждый поток есть смысл планировать не меньше 1000-5000 записей (цифры условные - точные цифры покажет время; реализовав многопоточку - нужно добавлять параметры, регулирующие количество потоков и объем данных потока чтобы получить оптимальную скорость)

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

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

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

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