Архитектура SQL Server (объяснение)

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

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

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

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

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

Общая память

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

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

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

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

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

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

Для подключения к локальной БД – В Студия управления SQL, опция «Имя сервера» может быть

""

«локальный хост»

"127.0.0.1"

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

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

TCP / IP

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

TCP / IP

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

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

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

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

TCP / IP

Именованные трубы

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

Именованные трубы

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

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

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

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

Что такое TDS?

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

  • TDS означает поток табличных данных.
  • Все три протокола используют пакеты TDS. TDS инкапсулируется в сетевые пакеты. Это позволяет передавать данные с клиентского компьютера на серверный компьютер.
  • TDS был впервые разработан компанией Sybase и сейчас принадлежит Microsoft

Реляционный движок

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

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

CMD-парсер

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

CMD-парсер

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

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

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

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

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

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

SELECT * from <TABLE_NAME>;

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

SELECR * from <TABLE_NAME>

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

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

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

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

Давайте поймем это с помощью приведенного ниже примера –

SELECT * from USER_ID

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

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

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

Оптимизатор

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

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

Задача оптимизатора – найти самый дешевый, но не лучший и экономически эффективный план реализации.

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

Это критически важно для анализа и выбора наиболее эффективных ключевых слов для улучшения рейтинга вашего сайта.

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

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

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

Оптимизатор

Фаза 0: Поиск тривиального плана:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Типы файлов

Типы файлов

  1. Основной файл
  • Каждая база данных содержит один первичный файл.
  • Здесь хранятся все важные данные, связанные с таблицами, представлениями, триггерами и т. д.
  • Расширение есть.МДФ обычно, но может иметь любое расширение.
  1. Вторичный файл
  • База данных может содержать или не содержать несколько вторичных файлов.
  • Это необязательно и содержит данные, специфичные для пользователя.
  • Расширение есть.NDF обычно, но может иметь любое расширение.
  1. Журнальный файл
  • Также известен как журналы опережающей записи.
  • Расширение есть.LDF
  • Используется для управления транзакциями.
  • Это используется для восстановления после любых нежелательных экземпляров. Выполните важную задачу по откату к незафиксированным транзакциям.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кэш плана

  • Существующий план запроса: Диспетчер буферов проверяет, имеется ли план выполнения в сохраненном кэше планов. Если да, то используется кеш плана запроса и связанный с ним кеш данных.
  • План кэширования при первом использовании: Откуда берется существующий кэш плана? Если план выполнения первого запроса запускается и используетсяplex, имеет смысл хранить его в кэше Plane. Это обеспечит более быструю доступность, когда SQL-сервер в следующий раз получит тот же запрос. Таким образом, это не что иное, как сам запрос, в котором хранится выполнение плана, если он запускается впервые.

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

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

Буферный кеш – мягкий анализ:

Буферный кеш — мягкий анализ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Диспетчер журналов начинает регистрацию, а диспетчер блокировок блокирует связанные данные.
  • Копия данных хранится в буферном кеше.
  • Копия данных, которые должны быть обновлены, сохраняется в буфере журнала, а все события обновляют данные в буфере данных.
  • Страницы, на которых хранятся данные, также известны как Грязные страницы.
  • Контрольная точка и журнал упреждающей записи: Этот процесс запускается и помечает все страницы с «Грязных страниц» на диск, но страница остается в кеше. Частота примерно 1 запуск в минуту. Но страница сначала помещается на страницу данных файла журнала из журнала буфера. Это известно как Запись вперед.
  • Ленивый писатель: Грязная страница может остаться в памяти. Когда SQL-сервер обнаруживает огромную нагрузку и для новой транзакции требуется буферная память, он освобождает грязные страницы из кеша. Он действует на ЛРУ – Последний раз использовался алгоритм очистки страницы из пула буферов на диск.

Итоги

  • Существует три типа архитектуры клиент-сервер: 1) Общая память 2) TCP/IP 3) Именованные каналы
  • TDS, разработанный Sybase и ныне принадлежащий Microsoft, — это пакет, инкапсулированный в сетевые пакеты для передачи данных с клиентского компьютера на серверный компьютер.
  • Реляционный движок содержит три основных компонента:CMD-парсер: Это отвечает за синтаксическую и семантическую ошибку и, наконец, создает дерево запросов.Оптимизатор: Роль оптимизатора состоит в том, чтобы найти самый дешевый, а не самый лучший и экономически эффективный план выполнения.

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

  • Существует три типа файлов: первичный файл, вторичный файл и файлы журнала.
  • Механизм хранения: имеет следующееwing важные компонентыМетод доступа: Этот компонент определяет, является ли запрос оператором выбора или невыбора. Вызывает Buffer и Transfer Manager соответственно.Менеджер буферов: Диспетчер буферов управляет основными функциями Plan Cache, Data Parsing и Dirty Page.

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