Объяснение архитектуры SQL Server: именованные каналы, оптимизатор, диспетчер буферов

Содержание:

Anonim

MS SQL Server - это архитектура клиент-сервер. Процесс MS SQL Server начинается с того, что клиентское приложение отправляет запрос. SQL Server принимает, обрабатывает и отвечает на запрос обработанными данными. Давайте подробно обсудим всю архитектуру, показанную ниже:

Как показано на диаграмме ниже, в архитектуре SQL Server есть три основных компонента:

  1. Уровень протокола
  2. Реляционный двигатель
  3. Механизм хранения
Схема архитектуры SQL Server

Давайте подробно обсудим все три вышеупомянутых основных модуля. В этом уроке вы узнаете.

  • Уровень протокола - SNI
    • Общая память
    • TCP / IP
    • Именованные каналы
    • Что такое TDS?
  • Реляционный двигатель
    • CMD Parser
    • Оптимизатор
    • Исполнитель запросов
  • Механизм хранения
    • Типы файлов
    • Метод доступа
    • Диспетчер буфера
    • Кэш плана
    • Анализ данных: буферный кеш и хранилище данных
    • Менеджер транзакций

Уровень протокола - SNI

СЛОЙ ПРОТОКОЛА СЕРВЕРА MS SQL поддерживает 3 типа клиент-серверной архитектуры. Мы начнем с « трех типов клиент-серверной архитектуры», которые поддерживает MS SQL Server.

Общая память

Давайте пересмотрим сценарий разговора ранним утром.

МАМА и ТОМ - Здесь Том и его мама были в одном логическом месте, то есть в своем доме. Том мог попросить кофе, а мама подала его горячим.

СЕРВЕР MS SQL - здесь сервер MS SQL предоставляет ПРОТОКОЛ ОБЩЕЙ ПАМЯТИ . Здесь КЛИЕНТ и сервер MS SQL работают на одной машине. Оба могут обмениваться данными по протоколу общей памяти.

Аналогия: давайте сопоставим объекты в двух вышеупомянутых сценариях. Мы можем легко сопоставить Тома с клиентом, маму с SQL-сервером, от дома к машине и вербальную связь с протоколом общей памяти.

Со стола настройки и установки:

Для подключения к локальной БД - в SQL Management Studio параметр «Имя сервера» может быть

"."

"localhost"

«127.0.0.1»

"Машина \ Экземпляр"

TCP / IP

А теперь представьте, что к вечеру Том настроен на вечеринку. Он хочет заказать кофе в известной кофейне. Кофейня находится в 10 км от его дома.

Здесь Том и Старбак находятся в другом физическом месте. Том дома, а Starbucks на оживленном рынке. Они общаются через сотовую сеть. Точно так же MS SQL SERVER предоставляет возможность взаимодействия по протоколу TCP / IP, где КЛИЕНТ и MS SQL Server являются удаленными друг от друга и устанавливаются на отдельном компьютере.

Аналогия: давайте сопоставим объекты в двух вышеупомянутых сценариях. Мы можем легко сопоставить Тома с клиентом, Starbuck с SQL-сервером, дом / рынок с удаленным местоположением и, наконец, сотовую сеть с протоколом TCP / IP.

Примечания со стола настройки / установки:

  • В SQL Management Studio - для подключения через TCP \ IP параметр «Имя сервера» должен быть «Машина \ Экземпляр сервера».
  • SQL-сервер использует порт 1433 в TCP / IP.

Именованные каналы

Теперь, наконец, ночью Том захотел выпить светло-зеленого чая, который ее соседка Сьерра очень хорошо приготовила.

Здесь Том и его сосед Сьерра находятся в одном физическом месте, будучи соседом друг друга. Они общаются через внутреннюю сеть. Точно так же MS SQL SERVER предоставляет возможность взаимодействия через протокол Named Pipe . Здесь КЛИЕНТ и MS SQL СЕРВЕР соединяются через LAN .

Аналогия: давайте сопоставим объекты в двух вышеупомянутых сценариях. Мы можем легко сопоставить Тома с клиентом, Sierra с сервером SQL, соседом с локальной сетью и, наконец, внутри сети с протоколом именованных каналов.

Примечания со стола настройки / установки:

  • Для подключения через именованный канал. По умолчанию этот параметр отключен, и его необходимо включить в диспетчере конфигурации SQL.

Что такое TDS?

Теперь, когда мы знаем, что существует три типа клиент-серверной архитектуры, давайте взглянем на TDS:

  • TDS расшифровывается как Tabular Data Stream.
  • Все 3 протокола используют пакеты TDS. TDS инкапсулируется в сетевые пакеты. Это позволяет передавать данные с клиентского компьютера на сервер.
  • TDS был впервые разработан Sybase, а теперь принадлежит Microsoft.

Реляционный двигатель

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

Как показано на архитектурной схеме, реляционный движок состоит из трех основных компонентов . Детально изучим составляющие:

CMD Parser

Данные, однажды полученные от уровня протокола, затем передаются в Relational Engine. «CMD Parser» - это первый компонент Relational Engine, получающий данные запроса. Основная задача CMD Parser - проверить запрос на синтаксические и семантические ошибки. Наконец, он генерирует дерево запросов . Обсудим подробнее.

Синтаксическая проверка:

  • Как и любой другой язык программирования, MS SQL также имеет предопределенный набор ключевых слов. Кроме того, SQL Server имеет собственную грамматику, которую понимает SQL-сервер.
  • SELECT, INSERT, UPDATE и многие другие относятся к предопределенным спискам ключевых слов MS SQL.
  • CMD Parser выполняет синтаксическую проверку. Если вводимые пользователем данные не соответствуют этим синтаксису языка или правилам грамматики, возвращается ошибка.

Пример: допустим, русский пошел в японский ресторан. Заказывает фастфуд на русском языке. К сожалению, официант понимает только японский. Каков был бы наиболее очевидный результат?

Ответ - официант не может дальше обрабатывать заказ.

Не должно быть никаких отклонений в грамматике или языке, который принимает SQL-сервер. Если есть, SQL-сервер не сможет его обработать и, следовательно, вернет сообщение об ошибке.

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

SELECT * from ;

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

SELECR * from

Обратите внимание, что вместо «SELECT» пользователь ввел «SELECR».

Результат: синтаксический анализатор CMD проанализирует этот оператор и выдаст сообщение об ошибке. Поскольку «SELECR» не следует за предопределенным именем ключевого слова и грамматикой. Здесь CMD Parser ожидал «ВЫБРАТЬ».

Семантическая проверка:

  • Это выполняется Нормализатором .
  • В своей простейшей форме он проверяет, существует ли имя столбца, имя запрашиваемой таблицы в схеме. И если он существует, привяжите его к Query. Это также известно как привязка .
  • Сложность возрастает, когда пользовательские запросы содержат ВИД. Нормализатор выполняет замену внутренним сохраненным определением представления и многим другим.

Давайте разберемся в этом с помощью примера ниже -

SELECT * from USER_ID

Результат: синтаксический анализатор CMD проанализирует этот оператор для семантической проверки. Синтаксический анализатор выдаст сообщение об ошибке, поскольку нормализатор не найдет запрошенную таблицу (USER_ID), поскольку она не существует.

Создать дерево запросов:

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

Оптимизатор

Работа оптимизатора заключается в создании плана выполнения запроса пользователя. Это план, который определит, как будет выполняться пользовательский запрос.

Обратите внимание, что не все запросы оптимизированы. Оптимизация сделана для команд DML (языка модификации данных), таких как SELECT, INSERT, DELETE и UPDATE. Такие запросы сначала помечаются, а затем отправляются оптимизатору. Команды DDL, такие как CREATE и ALTER, не оптимизированы, но вместо этого они компилируются во внутреннюю форму. Стоимость запроса рассчитывается на основе таких факторов, как использование ЦП, использование памяти и потребности ввода / вывода.

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

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

Пример:

Допустим, вы хотите открыть счет в онлайн-банке. Вы уже знаете об одном банке, который открывает счет максимум за 2 дня. Но у вас также есть список из 20 других банков, что может занять или не занять менее 2 дней. Вы можете начать взаимодействовать с этими банками, чтобы определить, на какие из них потребуется менее 2 дней. Теперь вы можете не найти банк, который занимает менее 2 дней, и есть дополнительное время, потерянное из-за самой активности поиска. Лучше было бы открыть счет в самом первом банке.

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

Аналогичным образом MS SQL Optimizer работает со встроенными исчерпывающими / эвристическими алгоритмами. Цель состоит в том, чтобы минимизировать время выполнения запроса. Все алгоритмы оптимизатора являются собственностью Microsoft и являются секретом. Несмотря на то , ниже приведены шаги высокого уровня , выполняемые MS SQL Optimizer. Поиск по оптимизации проходит в три этапа, как показано на диаграмме ниже:

Этап 0: поиск банального плана:

  • Это также известно как этап предварительной оптимизации .
  • В некоторых случаях может быть только один практический, работоспособный план, известный как тривиальный план. Нет необходимости создавать оптимизированный план. Причина в том, что поиск большего количества приведет к обнаружению того же плана выполнения во время выполнения. Это также связано с дополнительными затратами на поиск оптимизированного плана, которые вообще не требовались.
  • Если Тривиальный план не найден, начинается 1- я фаза.

Этап 1. Поиск планов обработки транзакций

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

Фаза 2: параллельная обработка и оптимизация.

  • Если ни одна из вышеперечисленных стратегий не работает, Оптимизатор ищет возможности параллельной обработки. Это зависит от возможностей обработки и конфигурации Машины.
  • Если это все еще невозможно, то начинается заключительный этап оптимизации. Теперь конечная цель оптимизации - найти все другие возможные варианты наилучшего выполнения запроса. Заключительный этап оптимизации. Алгоритмы являются собственностью Microsoft.

Исполнитель запросов

Исполнитель запроса вызывает метод доступа. Он предоставляет план выполнения для логики выборки данных, необходимой для выполнения. После получения данных от Storage Engine результат публикуется на уровне протокола. Наконец, данные отправляются конечному пользователю.

Механизм хранения

Работа Storage Engine заключается в хранении данных в системе хранения, такой как диск или SAN, и получении данных при необходимости. Прежде чем мы углубимся в механизм хранения, давайте посмотрим, как данные хранятся в базе данных и какие типы файлов доступны.

Файл данных и объем:

Файл данных физически хранит данные в виде страниц данных, причем каждая страница данных имеет размер 8 КБ, образуя наименьшую единицу хранения в SQL Server. Эти страницы данных логически сгруппированы в экстенты. Ни одному объекту не назначается страница в SQL Server.

Обслуживание объекта осуществляется экстентально. На странице есть раздел под названием Заголовок страницы размером 96 байт, содержащий информацию метаданных о странице, такую ​​как тип страницы, номер страницы, размер используемого пространства, размер свободного пространства и указатель на следующую страницу и предыдущую страницу. , так далее.

Типы файлов

  1. Первичный файл
  • Каждая база данных содержит один первичный файл.
  • В нем хранятся все важные данные, относящиеся к таблицам, представлениям, триггерам и т. Д.
  • Расширение есть. mdf обычно, но может иметь любое расширение.
  1. Дополнительный файл
  • База данных может содержать или не содержать несколько дополнительных файлов.
  • Это необязательно и содержит пользовательские данные.
  • Расширение есть. ndf обычно, но может иметь любое расширение.
  1. Лог-файл
  • Также известен как журналы упреждающей записи.
  • Расширение есть. ldf
  • Используется для управления транзакциями.
  • Это используется для восстановления после любых нежелательных экземпляров. Выполните важную задачу отката к незафиксированным транзакциям.

Storage Engine состоит из 3 компонентов; давайте рассмотрим их подробнее.

Метод доступа

Он действует как интерфейс между исполнителем запросов и диспетчером буферов / журналами транзакций.

Сам метод доступа не выполняет никаких действий.

Первое действие - определить, является ли запрос:

  1. Оператор выбора (DDL)
  2. Оператор без выбора (DDL и DML)

В зависимости от результата метод доступа выполняет следующие действия:

  1. Если запрос является оператором DDL , SELECT, запрос передается диспетчеру буферов для дальнейшей обработки.
  2. И если запросить, если оператор DDL, NON-SELECT , запрос передается диспетчеру транзакций. В основном это включает оператор UPDATE.

Диспетчер буфера

Диспетчер буферов управляет основными функциями следующих модулей:

  • Кэш плана
  • Анализ данных: буферный кеш и хранилище данных
  • Грязная страница

В этом разделе мы изучим план, буфер и кеш данных. Мы рассмотрим грязные страницы в разделе «Транзакции».

Кэш плана

  • Существующий план запроса: диспетчер буферов проверяет, есть ли план выполнения в сохраненном кэше планов. Если да, то используется кеш плана запроса и связанный с ним кеш данных.
  • Первый план кеширования : откуда берется существующий кеш плана?

    Если план выполнения первого запроса выполняется и является сложным, имеет смысл сохранить его в кэше Plane. Это обеспечит более быструю доступность, когда в следующий раз SQL-сервер получит тот же запрос. Итак, это не что иное, как сам запрос, выполнение плана которого сохраняется, если он запускается впервые.

Анализ данных: буферный кеш и хранилище данных

Диспетчер буферов обеспечивает доступ к необходимым данным. Ниже возможны два подхода в зависимости от того, существуют ли данные в кэше данных или нет:

Буферный кэш - программный анализ:

Buffer Manager ищет данные в буфере в кэше данных. Если они присутствуют, то эти данные используются Query Executor. Это улучшает производительность, поскольку количество операций ввода-вывода уменьшается при выборке данных из кеша по сравнению с выборкой данных из хранилища данных.

Хранение данных - жесткий анализ:

Если данные отсутствуют в диспетчере буферов, поиск необходимых данных выполняется в хранилище данных. If также сохраняет данные в кэше данных для будущего использования.

Грязная страница

Он хранится как логика обработки Transaction Manager. Подробно узнаем в разделе «Менеджер транзакций».

Менеджер транзакций

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

Диспетчер журналов

  • Диспетчер журналов отслеживает все обновления, сделанные в системе, с помощью журналов в журналах транзакций.
  • Журналы имеют порядковый номер журнала с идентификатором транзакции и записью изменения данных .
  • Это используется для отслеживания зафиксированной транзакции и отката транзакции .

Менеджер блокировок

  • Во время транзакции связанные данные в хранилище данных находятся в состоянии блокировки. Этот процесс обрабатывается диспетчером блокировок.
  • Этот процесс обеспечивает целостность и изоляцию данных . Также известны как свойства ACID.

Процесс исполнения

  • Диспетчер журналов запускает ведение журнала, а диспетчер блокировок блокирует связанные данные.
  • Копия данных хранится в буферном кеше.
  • Копия данных, которые предполагается обновить, сохраняется в буфере журнала, а все события обновляют данные в буфере данных.
  • Страницы, на которых хранятся данные, также известны как грязные страницы .
  • Ведение журнала контрольных точек и упреждающей записи: этот процесс запускает и помечает всю страницу с грязных страниц на диск, но страница остается в кеше. Частота составляет примерно 1 запуск в минуту, но сначала страница перемещается на страницу данных файла журнала из журнала буфера. Это известно как ведение журнала с упреждающей записью.
  • Lazy Writer: грязная страница может оставаться в памяти. Когда SQL-сервер обнаруживает огромную нагрузку и для новой транзакции требуется буферная память, он освобождает грязные страницы из кеша. Он работает с LRU - наименее используемым алгоритмом очистки страницы из пула буферов на диск.

Резюме:

  • Существует три типа клиент-серверной архитектуры: 1) общая память 2) TCP / IP 3) именованные каналы.
  • TDS, разработанный Sybase и теперь принадлежащий Microsoft, представляет собой пакет, который инкапсулируется в сетевые пакеты для передачи данных с клиентского компьютера на серверный.
  • Relational Engine состоит из трех основных компонентов:

    CMD Parser: отвечает за синтаксические и семантические ошибки и, наконец, генерирует дерево запросов.

    Оптимизатор: роль оптимизатора - найти самый дешевый, а не самый лучший и экономичный план выполнения.

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

  • Существует три типа файлов: основной файл, дополнительный файл и файлы журнала.
  • Механизм хранения: имеет следующие важные компоненты

    Метод доступа: этот компонент. Определите, является ли запрос оператором Select или Non-Select. Вызывает соответственно Buffer и Transfer Manager.

    Диспетчер буферов: диспетчер буферов управляет основными функциями для кеширования планов, анализа данных и грязных страниц.

    Диспетчер транзакций: он управляет транзакцией без выбора с помощью диспетчеров журналов и блокировок. Кроме того, облегчает важную реализацию ведения журнала Write Ahead и ленивых писателей.