Масштабирование с базой данных SQL Azure

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

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

• Клиентская библиотека эластичной базы данных является компонентом, который позволяет создавать и обслуживать сегментированные базы данных. См. статью "Начало работы с средствами эластичной базы данных".
• Перемещение данных между масштабируемыми облачными базами данных: перемещает данные между сегментированных баз данных. Это средство полезно для перемещения данных из мультитенантной базы данных в базу данных с одним клиентом (или наоборот). См. раздел "Развертывание службы разделения слияния" для перемещения данных между сегментированных баз данных.
• Эластичные задания в База данных SQL Azure. Использование заданий для управления большим количеством баз данных в База данных SQL Azure. Легко выполняйте административные операции, такие как изменение схем, управление учетными данными, обновления ссылочных данных, сбор данных о производительности или сбор данных телеметрии клиента (пользователя) с помощью заданий.
• База данных SQL Azure обзор эластичных запросов (предварительная версия) (предварительная версия): позволяет выполнять запрос Transact-SQL, охватывающий несколько баз данных. Это позволяет подключить средства создания отчетов, например Excel, Power BI, Tableau и т. д.
• Распределенные транзакции между облачными базами данных: эта функция позволяет выполнять транзакции, охватывающие несколько баз данных. Транзакции эластичной базы данных доступны для приложений .NET, использующих ADO.NET. Кроме того, транзакции можно объединить с уже знакомыми приемами программирования, используя классы System.Transaction.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мультитенантная и однотенантная

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

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

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

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

Примечание.

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

Примеры и руководства

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

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

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

Связанный контент

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