Как распараллелить нагрузку на sql

Как распараллелить нагрузку на sql

Информация, которую я нашел в Интернете, показывает, что SQL Server 2008 не поддерживает истинную балансировку нагрузки.

Это правда? Я не могу найти приличную документацию на сайте MS, поэтому любые ссылки будут оценены.

Кроме того, различия между активными / активными и активными / пассивными.

Я предполагаю, что вы не можете подключить более одного экземпляра SQL Server к одной базе данных, не так ли? Cos, что указывает на истинную балансировку нагрузки.

Итак, активна / активна, когда у вас есть два отдельных экземпляра SQL Server для доступа к двум базам данных ПОЛНОСТЬЮ ОТДЕЛЬНО? Если кто-то терпит неудачу, то он просто разделяет нагрузку на один оставшийся экземпляр? Эта конфигурация на самом деле используется только в том случае, если у нас действительно есть две ПОЛНОСТЬЮ ОТДЕЛЬНЫЕ базы данных?

Итак, в моем случае, когда у меня есть только один db, мне нужно перейти на Active / Passive как параметр высокой доступности?

Это довольно простые вопросы, но я не смог найти довольно простые ответы!

5 ответов

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

Кластеры SQL Server могут быть настроены как Active / Active или Active / Passive в двух сценариях сервера. Либо оба узла кластера Microsoft SQL Server предназначены для запуска хотя бы одного экземпляра SQL (Active-Active) или хотя бы один из этих узлов зарезервирован как резервный для принятия отказоустойчивости отказавшего SQL Экземпляр сервера (Active-Passive).

Вот несколько статей, которые вы могли бы прочитать:

В одной статье описываются другие параметры (на уровне приложений):

Кластеризация — это решение высокой доступности, а не решение масштабируемости. Так называемый «активный / активный» действительно представляет собой повторное использование резервных узлов для развертывания другого, полностью отдельного экземпляра.

Для чтения и записи запросов Transact-SQL нет балансировки нагрузки в любой форме. Для rad-only Transact-SQL (отчетность) существует опция Масштабируемой общей базы данных .

Единственная технология, поддерживающая балансировку нагрузки «из коробки» в SQL 2005 и SQL 2008, — это Service Broker, путем развертывания маршрутов балансировки нагрузки. Но я сомневаюсь, что это вас интересует.

Простое добавление дополнительных узлов в кластер SQL не добавляет пропускной способности, оно просто увеличивает доступность, так как у вас больше узлов, чтобы оставаться в сети. Обработка запросов чтения / записи ограничена одним узлом, нет концепции балансировки нагрузки по кругу.

Вот технический документ от Microsoft под названием «Производительность и масштаб SQL Server 2008» Ссылка

В этом документе обсуждаются различия между масштабированием и масштабированием SQL Server. Как отметил Ремус, существует концепция масштабируемой общей базы данных для баз данных только для чтения (подумайте о больших хранилищах данных).

Вы можете использовать одноранговую репликацию для распределенной обработки, если это соответствует вашим потребностям. Конечно, он вводит другие осложнения.

Вы можете прочитать о MySpace и о том, как они обрабатывали большие нагрузки с помощью SQL Server. Это серия трюков, но балансировка нагрузки отсутствует.

Во-первых: SQL Server не поддерживает балансировку нагрузки, если это поле, поэтому пусть Windows os выполняет эту работу. Вы можете установить 2 экземпляра SQL Server и настроить «peer to peer replication», чтобы у вас были согласованные данные на обоих серверах. Вы действительно работаете с 2 (!) Различными базами данных. Но тогда могут возникнуть конфликты во время DML-заявлений в одной записи от 2-х пользователей (один случайно на сервере 1, а другой на сервере 2 ..). Ваша задача избежать таких конфликтов с помощью вашего планирования и программирования на передней панели. К сожалению, сервер SQL не может взять на себя эту задачу. С другой стороны «Сбой кластера» возможен, когда SHARED STORE используется для всех участвующих узлов. Таким образом, система затем работает с ОДНОЙ отдельной базой данных, и нет балансировки нагрузки (!), Но только сбой. Отразите, что это не то же самое! Если один узел выходит из строя, другой принимает сразу свои задачи. Пока я надеюсь, что это поможет вам. Томас

SQL Server умеет выполнять запросы одновременно на нескольких процессорах. Такую возможность принято называть параллельным исполнением запроса. Параллельное исполнение запроса может использоваться для сокращения времени отклика (то есть, повышение быстродействия) больших запросов. Оно также может использоваться и при исполнении больших запросов (которые обрабатывают большой объём данных) в одно и то же время с маленькими запросами (масштабирование), увеличивая число процессоров, используемых в обслуживании запроса. Для большинства больших запросов SQL Server масштабируется практически линейно или почти линейно. Повышение быстродействия тут означает, что если мы удваиваем число процессоров, мы можем наблюдать сокращение времени отклика тоже в два раза. Масштабирование тут означает, что если мы удваиваем число процессоров и размер запроса, мы получает то же самое время отклика.

Читайте также:  Как объединить клетки в excel

Когда параллелизм полезен?

Как я уже отметил выше, параллелизм может использоваться для сокращения времени отклика одного запроса. Однако, параллелизм влияет на стоимость: она увеличивается за счёт увеличения накладных расходов на исполнение запроса. Несмотря на то, что эти накладные расходы невелики, параллелизм не желателен для маленьких запросов (особенно для OLTP -запросов), для которых такой "довесок" будет соразмерим с полным временем исполнения. Кроме того, если мы сравним время исполнения одного и того же маленького запроса в режиме параллельного исполнения на двух процессорах или последовательного исполнения (без параллелизма, на одном процессоре), для таких запросов будет типично более длительное исполнение распараллеленного запроса, причём, почти в два раза дольше. Опять же, это объясняется сравнительно большой долей накладных расходов на параллелизм для маленьких запросов.
В первую очередь параллелизм полезен для тех серверов, которые выполняют относительно небольшое число параллельных запросов. Для таких серверов, параллелизм может предоставить возможность маленькому числу запросов утилизировать большое число процессоров. Для серверов с большим числом параллельных запросов (например, OLTP), необходимость в параллелизме меньше, поскольку все процессоры и так будут утилизированы; просто потому, что у системы достаточно много для этого запросов. Распараллеливание этих запросов только добавило бы дополнительную нагрузку, что снизило бы общую производительность системы.

Как SQL Server распараллеливает запросы?

SQL Server распараллеливает запросы, выполняя горизонтальное секционирование входных даны, и число приблизительно равных секций устанавливается равным числу доступных процессоров, после чего для каждой секции выполняется одна и та же операция (например, агрегация, соединение и т.п.). Предположим, что мы хотим использовать два процессора для запроса с агрегатом хэша, который нужен для группировки по целочисленному столбцу. Мы создаем два потока (один для каждого процессора). Каждый поток выполняет один и тот же оператор агрегата хэша. Разделение входных данных можно организовать, например, на основе чётности или нечётности значений столбца группировки. Все принадлежащие одной группе и выделенные в один поток строки обрабатываются одним оператором агрегации хэша, и в итоге мы получаем правильный результат.

Этот метод параллельного выполнения запроса является и простым и хорошо масштабируемым. В показанном выше примере, оба потока агрегата хэша выполняются независимо. Этим двум потокам не нужно обмениваться сообщениями или координировать свою работу. Если нужно увеличить степень параллелизма (DOP), мы можем простой добавлять ещё потоков и откорректировать соответственно функцию секционирования (на практике для секционирования строк для агрегата хэша используется хеш-функция, которая пригодна для любого типа данных, любого числа групп столбцов, и любого числа потоков).
Реальное секционирование и перемещение данных между потоками выполняется итератором параллелизма (или ещё говорят — итератором обмена). Хотя этот итератор очень специфичен, он поддерживает те же интерфейсы, что любой другой итератор. Большинство итераторов не должны ничего знать о том, что они выполняются параллельно. Просто соответствующие итераторы параллелизма добавляются в план, и выполнение идёт параллельно.
Обратите внимание на то, что описанный выше метод параллелизма не одно и тот же, что и "конвейерный" параллелизм, когда несколько не связанных между собой операторов выполняются одновременно в разных потоках. Хотя SQL Server часто размещает разные операторы в разные потоки, первопричина в том, чтобы можно было снова выделять секции данных, когда они будут передаваться от одного оператора к следующему. С конвейером степень параллелизма и общее число потоков были бы ограничены числом операторов.

Кто решает, распараллеливать ли запрос?

Оптимизатор запросов принимает решение о необходимости распараллеливания исполнения запроса. Это решение, как и большинство других, основывается на стоимости. Сложный и дорогой запрос, который обрабатывает много строк, с большей вероятностью будет распараллелен, чем простой запрос, который обрабатывает очень мало строк.

Кто определяет степень параллелизма (DOP)?

Читайте также:  Звонок на удержании как снять

DOP — не является частью кэшируемого откомпилированного плана исполнения запроса и может измениться при следующем исполнении. DOP определяется в начале исполнения, с учётом числа процессоров на сервере и установленных посредством sp_configure параметров глобальной конфигурации "max degree of parallelism" и "max worker threads" (они видны только если установлено значение "show advanced options"), и с учётом подсказки оптимизатору MAXDOP, если она используется. Короче говоря, DOP выбирается таким, чтобы получить параллелизм и не исчерпать число рабочих потоков. Если указан MAXDOP 1, все итераторы параллелизма будут из плана удалены и запрос выполняется по последовательному плану в одном потоке.
Обратите внимание, что число используемых параллельным запросом потоков может превысить DOP. Если при исполнении параллельного запроса отслеживать состояние sys.sysprocesses, можете увидеть большее чем DOP число потоков. Как я говорил выше, если снова выделять секции данных между двумя операторами, они будут помещаться в разные потоки. DOP определяет число потоков на оператор, а не общее число потоков на план исполнения запроса. В SQL Server 2000, если DOP был меньше числа процессоров, дополнительные потоки могли использовать оставшиеся процессоры, что фактически могло привести к отступлениям от заданных настроек MAXDOP. В SQL Server 2005, когда исполняется запрос с заданным DOP, также ограничивается и число планировщиков. То есть все потоки, используемые запросом, будут назначены тому же самому набору планировщиков, и запрос будет использовать только заданное DOP число процессоров независимо от общего числа потоков.

Ссылки по теме

Помощь
Задать вопрос
программы
обучение
экзамены
компьютеры
ICQ-консультанты
Skype-консультанты
Общая справка
Как оформить заказ
Тарифы доставки
Способы оплаты
Прайс-лист
Карта сайта
Популярные статьи
Информационная безопасность Антивирусное ПО и защита от спама Eset Software Лаборатория Касперского
Бестселлеры
Курсы обучения "Atlassian JIRA — система управления проектами и задачами на предприятии"
Microsoft Office 365 для Дома 32-bit/x64. 5 ПК/Mac + 5 Планшетов + 5 Телефонов. Подписка на 1 год. Электронный ключ
Microsoft Windows 10 Профессиональная 32-bit/64-bit. Все языки. Электронный ключ
Microsoft Office для Дома и Учебы 2019. Все языки. Электронный ключ
Курс "Oracle. Программирование на SQL и PL/SQL"
Курс "Основы TOGAF® 9"
Microsoft Windows Professional 10 Sngl OLP 1 License No Level Legalization GetGenuine wCOA (FQC-09481)
Microsoft Office 365 Персональный 32-bit/x64. 1 ПК/MAC + 1 Планшет + 1 Телефон. Все языки. Подписка на 1 год. Электронный ключ
Windows Server 2016 Standard
Курс "Нотация BPMN 2.0. Ее использование для моделирования бизнес-процессов и их регламентации"
Антивирус ESET NOD32 Antivirus Business Edition
Corel CorelDRAW Home & Student Suite X8
О нас
Интернет-магазин ITShop.ru предлагает широкий спектр услуг информационных технологий и ПО.

На протяжении многих лет интернет-магазин предлагает товары и услуги, ориентированные на бизнес-пользователей и специалистов по информационным технологиям.

Хорошие отзывы постоянных клиентов и высокий уровень специалистов позволяет получить наивысший результат при совместной работе.

В этой статье я собираюсь рассмотреть то, как SQL Server распараллеливает просмотр таблицы (сканирования — scans). Оператор просмотра — один из немногих операторов, которые адаптированы к параллелизму. Большинство других операторов ничего не знают о параллелизме, и не заботятся о том, выполняются ли они параллельно; оператор просмотра является в этом случае исключением.

Как же в действительности работает распараллеленный просмотр?

Потоки, которые составляют распараллеленный просмотр, сообща трудятся над тем, чтобы выполнить полный просмотр всех строк в таблице. Априори, нет никакого явного закрепления строк или страниц за конкретными потоками. Вместо этого движок хранилища раздаёт страницы потокам динамически. Доступ к страницам таблицы координирует поставщик распараллеленных страниц (parallel page supplier). Он гарантирует, что каждая страница будет отдана только одному потоку и, таким образом, попадёт на обработку только один раз.

В начале распараллеленного просмотра каждый поток запрашивает у поставщика несколько страниц. После этого, потоки начинают обработку полученных строк и возвращают обработанные строки на выходе оператора. Когда поток заканчивает обработку полученного набора строк, он запрашивает у поставщика следующий набор.

У этого алгоритма есть пара преимуществ:

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

Давайте начнём с простого примера. Чтобы получить распараллеленный план, нам понадобится довольно большая таблица; если таблица будет слишком маленькой, то оптимизатор может прийти к заключению, что лучше подходит последовательный план исполнения. Показанный ниже сценарий создаёт таблицу из 1000000 строк, которые (благодаря фиксированной длине столбца char (200)) займут приблизительно 27000 страниц.
Предупреждение: Если Вы решаете выполнить этот пример, учтите, что его исполнение может занять несколько минут, которые понадобятся для заполнения таблицы данными. create table T (a int, x char(200))

set nocount on
declare @i int
set @i = 0
while @i

После этого, для самого простого запроса:

Мы получаем последовательный план! Почему же мы не получили распараллеленный план? Параллелизм используется для ускорения запросов, за счёт использования нескольких процессоров в одной задаче. Стоимость же этого запроса зависит от стоимости чтения страниц с диска (которая облегчается упреждающим чтением, а не параллелизмом), и последующего возврата обработанных строк клиенту. Для исполнения этого запроса используется сравнительно небольшое число процессорных циклов и, фактически, вероятно он работал бы медленнее, если бы мы его распараллелили.

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

select * from T where a

/—Parallelism(Gather Streams)
/—Table Scan(OBJECT:([T]), WHERE:([T].[a]

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

Как я писал выше, алгоритм распараллеленного просмотра выделяет страницы потокам динамически. Мы можем наблюдать это с помощью следующего примера. Рассмотрим запрос, который возвращает все строки таблицы:

select * from T where a % 2 = 0 or a % 2 = 1

"Хитрый" предикат запутывает оптимизатор, который неправильно оценивает количество элементов и генерирует параллельный план:

/—Parallelism(Gather Streams)
/—Table Scan(OBJECT:([T]), WHERE:([T].[a]%(2)=(0) OR [T].[a]%(2)=(1)))

На SQL Server 2005 используя "SET STATISTICS XML ON" мы можем узнать, сколько строк обрабатывает каждый поток. Вот результирующий XML для двухпроцессорной системы:

Как видно, оба потока (1 и 2), обрабатывают примерно половину строк. Поток 0 является координатором, или ещё его называют основным потоком. Он выполняет только ту часть плана исполнения запроса, которая выше самого верхнего итератора обмена. Таким образом, мы не ожидаем, что какие либо строки будут обработаны ещё какими-либо операторами с распараллеливанием.
Давайте повторим эксперимент, но теперь выполним одновременно ещё один последовательный запрос. Этот запрос перекрёстного соединения будет работать в течение довольно продолжительного времени (он должен обработать один триллион строк), и будет использовать очень много процессорных циклов:

select min(T1.a + T2.a) from T T1 cross join T T2 option(maxdop 1)

Такой последовательный запрос использует только один из двух процессоров. Давайте снова выполним другой запрос во время его работы:

select * from T where a % 2 = 0 or a % 2 = 1

На этот раз распараллеленный поток с идентификатором 1 обработал больше 90% строк, в то время как поток 2, который был занят исполнением показанного выше запроса с последовательным планом, обработал заметно меньше строк. Распараллеленный просмотр автоматически сбалансировал работу между двумя потоками. Так как у потока 1 было больше свободных циклов (он не конкурировал с последовательным планом), он запросил и просмотрел больше страниц.
Если Вы пробуете воспроизвести этот эксперимент, не забудьте потом уничтожить последовательный запрос! Иначе, он будет продолжать выполняться и тратить впустую процессорное время в течение довольно длительного времени.
Похожая балансировка нагрузки применима в равной мере в тех случаях, когда поток замедляется из-за внешних факторов (наподобие последовательного запроса в нашем примере) или из-за внутренних факторов. Например, если обработка некоторых строк будет обходиться дороже, чем других, то мы также увидим похожее поведение.

По материалам статьи Craig Freedman: Parallel Scan

Перевод Ирины Наумовой и Александра Гладченко

Ссылка на основную публикацию
Как разблокировать айфон зная apple id
Пользователи популярных смартфонов от Apple часто ставят на гаджет пароль, чтобы повысить безопасность мобильного устройства и избежать неприятностей – кражи,...
Как поставить напоминалку на андроиде
Привет всем. Нужно ли вам напоминать о каких-либо событиях? Я думаю напоминания не помешают никому. В силу своей занятости или...
Как поставить пароль на покупку фильмов ростелеком
Интерактивное ТВ от Ростелеком предлагает абонентам огромное многообразие телеканалов различного содержания. Многие из них совершенно не рассчитаны на младшую аудиторию....
Как разблокировать домофон если отключили
Домофон — вещь нужная и полезная. Установленная в подъезде система отлично защищает жилище обывателей от проникновения посторонних людей. Второе преимущество...
Adblock detector