Развертывание с помощью Базы данных SQL Azure

Применимо к:База данных SQL Azure

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

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

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

  1. Набор баз данных SQL размещается в Azure с использованием архитектуры сегментирования.
  2. Клиентская библиотека эластичных баз данных используется для управления набором сегментов.
  3. Подмножество баз данных помещается в эластичный пул. (См. статью Что такое пул эластичных БД Azure?)
  4. Задание обработки эластичных баз данных запускает запланированные или динамические сценарии T-SQL для всех баз данных.
  5. Служба разбиения на части и объединения используется для перемещения данных из одного сегмента в другой.
  6. Запрос к эластичной базе данных позволяет создать запрос, который охватывает все базы данных в наборе сегментов.
  7. Эластичные транзакции позволяют выполнять транзакции, охватывающие несколько баз данных.

Elastic Database tools

Зачем использовать эти инструменты?

Для виртуальных машин и хранилища BLOB-объектов эластичность и масштабирование облачных приложений легко реализуются путем простого добавления и удаления вычислительных единиц либо увеличения мощности. Однако для обработки данных в реляционных базах данных с отслеживанием состояния их реализация по-прежнему представляет сложности. Сложности появились в следующих сценариях.

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

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

Горизонтальное и вертикальное масштабирование

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

Horizontal versus vertical scale-out

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

Вертикальное масштабирование означает увеличение или уменьшение объема вычислительных ресурсов отдельной базы данных. Оно также называется "увеличением масштаба".

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

  • Для управления горизонтальным масштабированием используется клиентская библиотека эластичных баз данных.
  • Вертикальное масштабирование осуществляется с помощью командлетов Azure PowerShell для изменения уровня служб или путем помещения баз данных в пул эластичных БД.

Сегментирование

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

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

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

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

Мультитенантные и с одним клиентом

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

Single tenant versus multi-tenant

Другие сценарии объединяют несколько клиентов вместе в базах данных вместо изолирования их в отдельных базах данных. Это типичный шаблон сегментирования для нескольких клиентов. Он может использоваться при обработке приложением большого числа маленьких клиентов. При сегментировании на несколько клиентов строки таблиц базы данных спроектированы для хранения ключа, идентифицирующего пользователя, или ключа сегментирования. Кроме того, уровень приложения отвечает за направление запроса клиента к соответствующей базе данных, что поддерживается клиентской библиотекой эластичной базы данных. Кроме того, для ограничения строк, доступных для каждого клиента, можно воспользоваться безопасностью на уровне строк. Дополнительные сведения см. в статье Мультитенантные приложения со средствами эластичных баз данных и безопасностью на уровне строк. Перераспределение данных между базами данных может потребоваться при использовании шаблона многопользовательского сегментирования и обеспечивается службой разбиения и объединения эластичной базы данных. Дополнительные сведения о шаблонах разработки для приложений SaaS, использующих пулы эластичных БД, см. в статье Шаблоны разработки для мультитенантных приложений SaaS с использованием Базы данных Azure SQL.

Перемещение данных из многопользовательских баз данных в однопользовательскую базу данных

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

Примечание.

Восстановление из мультитенантных баз данных в один клиент невозможно.

Следующие шаги

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

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

Сведения об особенностях эластичного пула см. в статье Когда следует использовать эластичный пул?. Вы можете также создать эластичные пулы.

Дополнительные ресурсы

Еще не используете средства эластичных баз данных? Ознакомьтесь с нашим руководством по началу работы. Возникшие вопросы вы можете задать нам на странице вопросов Microsoft Q&A по Базе данных SQL. Что касается запросов новых функций, вы можете поделиться новыми идеями или проголосовать за существующие на форуме отзывов по Базе данных SQL.