Повысит ли производительность запросов на вставку несколько подключений к базе данных из нескольких потоков приложения?

Question

Здесь я имею дело с базой данных, содержащей десятки миллионов записей.У меня есть приложение, которое подключается к базе данных, получает все данные из одного столбца таблицы, выполняет над ними некоторые операции и обновляет их (для SQL Server - с использованием курсоров).

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

1. использование нескольких потоков с независимым соединением для каждого потока.

или

2. используя одно соединение во всех потоках для запуска запросов на обновление.

Какой из них быстрее, или если у вас есть другие идеи, объясните, пожалуйста.

Мне нужно решение, независимое от типа базы данных, или даже если вы знаете конкретные решения для каждого типа базы данных, ответьте.

Answer 1

Ускорение, которого вы пытаетесь достичь, не сработает.Напротив, это замедлит общую обработку, поскольку базе данных теперь также приходится синхронизировать несколько соединений/сеансов/транзакций.

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

Answer 2

Все зависит от базы данных и оборудования, на котором она работает.

Если база данных может использовать параллельную обработку и позволяет избежать конфликтов за общие ресурсы (например,блокировки на основе страниц будут охватывать несколько записей, а блокировки на основе записей — нет).Общие ресурсы в этом случае включают аппаратное обеспечение, одноядерный блок не сможет выполнять несколько операций с интенсивным использованием ЦП (например,синтаксический анализ SQL) действительно параллельно.

Задержку в сети можно уменьшить с помощью параллельных вставок, даже если сама база данных не способна использовать параллелизм.

Как и в случае с любым вопросом производительности, существует альтернатива тестированию в вашем конкретном сценарии.

Answer 3

Если возможно, попробуйте использовать хранимую процедуру, чтобы выполнить всю обработку и обновить записи.