|
![]() |
#1 |
Administrator
|
Правильно заданный вопрос содержит половину ответа
![]() Если нет проблем с производительностью - то зачем тогда ставить задачу "быстро обработать все записи"? Многопоточка да, очевидно, имеет сложности в отладке, но отлаживать ее можно и в одном потоке. А вот с фразой, что многопоточка - "прямой путь к проблемам с локами на таблицах" категорически не согласен. Просто методики программирования под многопоточку должны быть несколько иными, нежели обычное программирование. Во-первых, для многопоточки нужно четкое секционирование объема данных для каждого потока. С учетом понимания, что накладные расходы на запуск и завершение потока должны быть ничтожно малы по отношению к времени работы потока. Т.е. условно - на каждый поток есть смысл планировать не меньше 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 | 0 |
Опции темы | Поиск в этой теме |
Опции просмотра | |
|