В настоящее время я изучаю способы ускорения и увеличения продолжительного совпадающего задания, которое в настоящее время выполняется как хранимая процедура в MSSQL 2005. Соответствие включает в себя несколько полей со многими неточными случаями. Хотя я хотел бы, в конечном счете, масштабировать его до крупномасштабных наборов данных за пределами базы данных, мне также нужно рассмотреть некоторые более короткие решения.Выполняет ли параллелизация хранимой процедуры более высокую производительность кластеров?
Учитывая, что я не знаю много о внутренней реализации того, как они выполняются, мне интересно, можно ли разделить процесс на параллельные процедуры, разделив набор данных с помощью мастер-процедуры, который затем пинает которые работают с меньшими наборами данных.
Может ли это обеспечить прирост производительности с помощью кластерной базы данных? Будет ли MSSQL распределять подпрограммы через узлы кластера автоматически и разумно?
Возможно, лучше иметь мастер-процесс в Java и вызвать рабочие процедуры через jdbc, которые предположительно эффективно используют балансировку нагрузки кластера? Помимо каких-либо аргументов в отношении ремонтопригодности, это может быть быстрее?
Что? О, вау, я подумал, что сервер SQL Server загрузил балансировку! Это научит меня делать предположения! – barrymac
Хорошо сгруппированы в сторону, будет ли параллелизировать процесс, чтобы повысить производительность на 16-ядерном ящике? – barrymac
№. Ваши индивидуальные вызовы подпрограмм из вашей главной процедуры будут синхронными. Вы ожидали завершения одного подпрограммы до следующего запуска. Вы не достигнете распараллеливания, которое вы ожидаете. Напишите свой запрос, сравните его и настройте его соответствующим образом, но не пытайтесь переубедить это или перехитрить оптимизатор SQL. –