Горизонтальное Масштабирование Реальной Базы Данных Проекта С Использованием Федераций Sql Azure.

Шардинг Вопрос масштабирования приложений в облаке возникает очень часто.

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

Любой уважающий себя облачный провайдер поддерживает соответствующие функции.

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

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

Однако этот метод может быть довольно дорогим, трудоемким и имеет ограничения.

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

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

То есть, если ваше приложение ранее располагалось на одном сервере, и в какой-то момент оно перестало «тянуть» нагрузку, вы можете просто купить второй сервер точно такой же.

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

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

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

Если рассматривать возможности облачной платформы от Microsoft, то они достаточно широки.

Есть автомасштабирование, масштабирование по требованию, и все это доступно как с помощью пользовательского интерфейса, так и с помощью SDK, REST API и PowerShell.

Однако если с масштабированием приложения (PaaS) или виртуальных машин (IaaS) все довольно просто, вы указываете, сколько экземпляров вам нужно, и их будет столько, то если ваше приложение использует базы данных MS SQL, возникает несколько вопросов.

Конечно, первое, что приходит на ум, — это организовать кластер виртуальных машин SQL Server. Решение довольно простое и всем известное.

А что, если приложение использует базу данных как услугу (SaaS)? Что, если мы не хотим заморачиваться с настройкой кластера SQL Server?

Конечно, если мы говорим о Windows Azure, то в качестве базы данных SQL будет использоваться SQL Azure.

Эта база данных поддерживает технологию горизонтального масштабирования (шардинг), называемую SQL Azure Federations.

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

Самый простой пример:

Горизонтальное Масштабирование Реальной Базы Данных Проекта С Использованием Федераций Sql Azure.

Это одна и та же таблица, данные которой хранятся в разных экземплярах базы данных (шардах).

То есть данные аккаунта с идентификатором 1 хранятся в первой базе данных, с идентификатором 2 – во второй и т.д.

Ограничения SQL Azure

Так что же это нам дает? Во-первых, изолируя данные друг от друга.

Данные одного аккаунта никак не связаны с данными другого.

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

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

Однако любая технология имеет свои недостатки.

Шардинг не является исключением.

Давайте подумаем, с какими недостатками можно столкнуться при использовании технологии шардинга на примере описанной выше базы данных? Если вы помните архитектуру SQL Azure , то как вы знаете сервис не поддерживает получение данных из нескольких баз одновременно.

То есть одна база данных — одно соединение.

И осколки не исключение.

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

Исходный запрос: SELECT Count(*) FROM Account Пример запроса на конкретный шард: USE FEDERATION Accounts(AccountId = 4) WITH RESET, FILTERING = OFF GO SELECT Count(*) FROM Account Логику суммирования значений, возвращаемых этим запросом, необходимо разместить в приложении.

То есть в результате использования федераций часть кода «уйдет» в приложение, поскольку на уровне базы данных некоторые возможности обычного SQL Server ограничены.

Предисловие

Конечно, федерации SQL Azure — не панацея, и вы можете реализовать собственный принцип горизонтального масштабирования базы данных.

Допустим, мультитенантный подход — это тоже своего рода горизонтальное масштабирование базы данных.

Потому что данные одного пользователя отделены не только «логически» от данных другого пользователя, но и «физически».

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

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

То есть приложение должно знать, с какой базой данных оно в данный момент работает. Но давайте вернемся к федерациям SQL Azure. Сама идея Microsoft достойна всяческих похвал.

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

А ещё хотелось бы сделать автомасштабирование, по результатам определённых запросов (ну это уже фантастика)…

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

Кажется, с теорией мы разобрались.

Однако, как правило, на практике существует достаточно большое количество граблей, на которые можно наступить.

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

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

В общем, не переключайтесь! Всем хорошего начала рабочей недели! Теги: #Microsoft Azure #sharding #sql azure #sql azure Federations #sql azure Federations

Последнее изменение: 2024-12-19 05:12:58

Вместе с данным постом часто просматривают: