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

Можно легко развертывать базы данных SQL Azure с помощью инструментов эластичной базы данных .You can easily scale out Azure SQL databases using the Elastic Database tools. Эти инструменты и компоненты позволяют использовать ресурсы Базы данных SQL Azure для создания решений для транзакционных рабочих нагрузок и, в частности, приложений SaaS (программное обеспечение как услуга).These tools and features let you use the database resources of Azure SQL Database to create solutions for transactional workloads, and especially Software as a Service (SaaS) applications. Возможности эластичных баз данных включают в себя следующее.Elastic Database features are composed of the:

На рисунке ниже показана архитектура, которая включает в себя возможности эластичных баз данных по отношению к коллекции баз данных.The following graphic shows an architecture that includes the Elastic Database features in relation to a collection of databases.

Цвета баз данных на этой иллюстрации представляют схемы.In this graphic, colors of the database represent schemas. Базы данных одного цвета используют одинаковые схемы.Databases with the same color share the same schema.

  1. Набор баз данных Azure SQL размещается в Azure с использованием архитектуры сегментирования.A set of Azure SQL databases are hosted on Azure using sharding architecture.
  2. Клиентская библиотека эластичных баз данных используется для управления набором сегментов.The Elastic Database client library is used to manage a shard set.
  3. Подмножество баз данных помещается в эластичный пул.A subset of the databases are put into an elastic pool. (См. статью Что такое пул эластичных БД Azure?)(See What is a pool?).
  4. Задание обработки эластичных баз данных запускает запланированные или динамические сценарии T-SQL для всех баз данных.An Elastic Database job runs scheduled or ad hoc T-SQL scripts against all databases.
  5. Служба разбиения на части и объединения используется для перемещения данных из одного сегмента в другой.The split-merge tool is used to move data from one shard to another.
  6. Запрос к эластичной базе данных позволяет создать запрос, который охватывает все базы данных в наборе сегментов.The Elastic Database query allows you to write a query that spans all databases in the shard set.
  7. Эластичные транзакции позволяют выполнять транзакции, охватывающие несколько баз данных.Elastic transactions allow you to run transactions that span several databases.

Инструменты эластичных баз данных

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

Для виртуальных машин и хранилища BLOB-объектов эластичность и масштабирование облачных приложений легко реализуются путем простого добавления и удаления вычислительных единиц либо увеличения мощности.Achieving elasticity and scale for cloud applications has been straightforward for VMs and blob storage - simply add or subtract units, or increase power. Однако для обработки данных в реляционных базах данных с отслеживанием состояния их реализация по-прежнему представляет сложности.But it has remained a challenge for stateful data processing in relational databases. Сложности появились в следующих сценариях.Challenges emerged in these scenarios:

  • Увеличение и уменьшение производительности реляционной базы данных как части рабочей нагрузки решения.Growing and shrinking capacity for the relational database part of your workload.
  • Управление хот-спотами при влиянии на конкретное подмножество данных, например загруженный пользователь (клиент).Managing hotspots that may arise affecting a specific subset of data - such as a busy end-customer (tenant).

В большинстве случаев такие сценарии решаются путем приобретения дополнительных серверов баз данных для поддержки приложения.Traditionally, scenarios like these have been addressed by investing in larger-scale database servers to support the application. Тем не менее реализация этого варианта ограничена облаком, в котором вся обработка выполняется на предустановленном стандартном оборудовании.However, this option is limited in the cloud where all processing happens on predefined commodity hardware. Использование вместо этого распределения и обработки данных в нескольких идентично структурированных базах данных (метод масштабирования, известный как сегментирование) является убедительной альтернативой традиционным подходам к масштабированию с точки зрения затрат и гибкости.Instead, distributing data and processing across many identically structured databases (a scale-out pattern known as "sharding") provides an alternative to traditional scale-up approaches both in terms of cost and elasticity.

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

На рисунке ниже показаны горизонтальные и вертикальные измерения масштабирования, которые представляют собой базовые способы масштабирования эластичных баз данных.The following figure shows the horizontal and vertical dimensions of scaling, which are the basic ways the elastic databases can be scaled.

Горизонтальное и вертикальное развертывание

Горизонтальное масштабирование означает добавление или удаление баз данных для настройки емкости или общей производительности.Horizontal scaling refers to adding or removing databases in order to adjust capacity or overall performance. Оно также называется "расширением".This is also called “scaling out”. Сегментирование, в которым данные разделяются по набору идентично структурированных баз данных, является наиболее распространенным методом горизонтального масштабирования.Sharding, in which data is partitioned across a collection of identically structured databases, is a common way to implement horizontal scaling.

Вертикальное масштабирование означает увеличение или уменьшение уровня производительности отдельной базы данных. Оно также называется "увеличением масштаба".Vertical scaling refers to increasing or decreasing the performance level of an individual database—this is also known as “scaling up.”

В большей части баз данных облачных приложений для масштабирования используется сочетание этих двух стратегий.Most cloud-scale database applications use a combination of these two strategies. Например, приложение "программное обеспечение как сервис" может использовать горизонтальное масштабирование для подготовки новых конечных пользователей и вертикальное масштабирование для увеличения или уменьшения ресурсов базы данных каждого конечного клиента, согласно требованиям рабочей нагрузки.For example, a Software as a Service application may use horizontal scaling to provision new end-customers and vertical scaling to allow each end-customer’s database to grow or shrink resources as needed by the workload.

  • Для управления горизонтальным масштабированием используется клиентская библиотека эластичных баз данных.Horizontal scaling is managed using the Elastic Database client library.
  • Вертикальное масштабирование осуществляется с помощью командлетов Azure PowerShell для изменения уровня служб или путем помещения баз данных в пул эластичных БД.Vertical scaling is accomplished using Azure PowerShell cmdlets to change the service tier, or by placing databases in an elastic pool.

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

Сегментирование — это методика распределения больших объемов данных с одинаковой структурой по множеству независимых баз данных.Sharding is a technique to distribute large amounts of identically structured data across a number of independent databases. Она пользуется особенной популярностью среди разработчиков облачных технологий, создающих решения SaaS для пользователей или предприятий.It is especially popular with cloud developers creating Software as a Service (SAAS) offerings for end customers or businesses. Эти конечные пользователи часто называются "клиентами".These end customers are often referred to as “tenants”. Сегментирование может потребоваться по ряду причин:Sharding may be required for any number of reasons:

  • общий объем данных слишком велик для размещения в пределах отдельной базы данных;The total amount of data is too large to fit within the constraints of a single database
  • пропускная способность транзакций общей рабочей нагрузки превышает возможности отдельной базы данных;The transaction throughput of the overall workload exceeds the capabilities of a single database
  • клиентам может потребоваться физическая изоляция друг от друга, для чего требуются отдельные базы данных для каждого клиента;Tenants may require physical isolation from each other, so separate databases are needed for each tenant
  • разные части базы данных могут размещаться в разных регионах по соображениям соответствия требованиям законодательства, производительности или по геополитическим причинам.Different sections of a database may need to reside in different geographies for compliance, performance, or geopolitical reasons.

В других сценариях, например в приеме данных из распределенных устройств, сегментирование может использоваться для заполнения набора баз данных по временному признаку.In other scenarios, such as ingestion of data from distributed devices, sharding can be used to fill a set of databases that are organized temporally. Например, отдельная база данных может выделяться под каждый день или неделю.For example, a separate database can be dedicated to each day or week. В этом случае ключом сегментирования может быть целое число, представляющее дату (присутствующую во всех строках сегментированных таблиц), а запросы получения информации о диапазоне дат должны передаваться приложением в подмножество баз данных, которые покрывают рассматриваемый диапазон.In that case, the sharding key can be an integer representing the date (present in all rows of the sharded tables) and queries retrieving information for a date range must be routed by the application to the subset of databases covering the range in question.

Сегментирование лучше всего работает, когда каждая транзакция в приложении может ограничиваться одним значением ключа сегментирования.Sharding works best when every transaction in an application can be restricted to a single value of a sharding key. Это гарантирует, что все транзакции будут осуществляться в пределах отдельной базы данных.That ensures that all transactions are local to a specific database.

Мультитенантные и с одним клиентомMulti-tenant and single-tenant

Некоторые приложения используют простой способ создания отдельной базы данных для каждого клиента.Some applications use the simplest approach of creating a separate database for each tenant. Это шаблон сегментирования для одного клиента, который предоставляет возможность изолирования, архивации и восстановления, а также масштабирования ресурсов в соответствии со степенью детализации клиента.This is the single tenant sharding pattern that provides isolation, backup/restore ability, and resource scaling at the granularity of the tenant. Благодаря сегментированию для одного клиента каждая база данных привязывается к отдельному идентификатору клиента (или значению ключа клиента), но этот ключ не должен постоянно присутствовать в самих данных.With single tenant sharding, each database is associated with a specific tenant ID value (or customer key value), but that key need not always be present in the data itself. За направление каждого запроса к соответствующей базе данных отвечает само приложение, а клиентская библиотека эластичных баз данных может упростить этот процесс.It is the application’s responsibility to route each request to the appropriate database - and the client library can simplify this.

Сравнение многопользовательских версий одного клиента

Другие сценарии объединяют несколько клиентов вместе в базах данных вместо изолирования их в отдельных базах данных.Others scenarios pack multiple tenants together into databases, rather than isolating them into separate databases. Это типичный шаблон сегментирования для нескольких клиентов. Он может использоваться при обработке приложением большого числа маленьких клиентов.This is a typical multi-tenant sharding pattern - and it may be driven by the fact that an application manages large numbers of small tenants. При сегментировании на несколько клиентов строки таблиц базы данных спроектированы для хранения ключа, идентифицирующего пользователя, или ключа сегментирования.In multi-tenant sharding, the rows in the database tables are all designed to carry a key identifying the tenant ID or sharding key. Кроме того, уровень приложения отвечает за направление запроса клиента к соответствующей базе данных, что поддерживается клиентской библиотекой эластичной базы данных.Again, the application tier is responsible for routing a tenant’s request to the appropriate database, and this can be supported by the elastic database client library. Кроме того, для ограничения строк, доступных для каждого клиента, можно воспользоваться безопасностью на уровне строк. Дополнительные сведения см. в статье Мультитенантные приложения со средствами эластичных баз данных и безопасностью на уровне строк.In addition, row-level security can be used to filter which rows each tenant can access - for details, see Multi-tenant applications with elastic database tools and row-level security. Перераспределение данных между базами данных может потребоваться при использовании шаблона многопользовательского сегментирования и обеспечивается службой разбиения и объединения эластичной базы данных.Redistributing data among databases may be needed with the multi-tenant sharding pattern, and this is facilitated by the elastic database split-merge tool. Дополнительные сведения о шаблонах разработки для приложений SaaS, использующих пулы эластичных БД, см. в статье Шаблоны разработки для мультитенантных приложений SaaS с использованием базы данных Azure SQL.To learn more about design patterns for SaaS applications using elastic pools, see Design Patterns for Multi-tenant SaaS Applications with Azure SQL Database.

Перемещение данных из многопользовательских баз данных в однопользовательскую базу данныхMove data from multiple to single-tenancy databases

При создании приложения SaaS потенциальным клиентам обычно предлагается пробная версия программного обеспечения.When creating a SaaS application, it is typical to offer prospective customers a trial version of the software. В этом случае для хранения данных экономически выгодно использовать многопользовательскую базу данных.In this case, it is cost-effective to use a multi-tenant database for the data. Однако, когда потенциальный клиент становится реальным, предпочтительнее однопользовательская база данных, так как она обеспечивает лучшую производительность.However, when a prospect becomes a customer, a single-tenant database is better since it provides better performance. Если клиент создал данные в течение пробного периода, используйте средство разбиения и объединения для перемещения данных из базы данных с несколькими клиентами в новую базу данных с одним клиентом.If the customer had created data during the trial period, use the split-merge tool to move the data from the multi-tenant to the new single-tenant database.

Дальнейшие действияNext steps

Пример приложения, демонстрирующий клиентскую библиотеку, приведен в статье Приступая к работе с инструментами эластичных баз данных.For a sample app that demonstrates the client library, see Get started with Elastic Database tools.

Сведения о том, как преобразовать имеющиеся базы данных, чтобы использовать эти инструменты, см. в статье Перенос существующих баз данных для масштабирования.To convert existing databases to use the tools, see Migrate existing databases to scale out.

Сведения об особенностях эластичного пула см. в статье Когда следует использовать эластичный пул?. Вы можете также создать эластичные пулы.To see the specifics of the elastic pool, see Price and performance considerations for an elastic pool, or create a new pool with elastic pools.

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

Еще не используете средства эластичных баз данных?Not using elastic database tools yet? Ознакомьтесь с нашим руководством по началу работы.Check out our Getting Started Guide. Все возникшие вопросы задавайте на форуме по базам данных SQL, а запросы новых функций оставляйте на форуме отзывов и предложений по базам данных SQL.For questions, please reach out to us on the SQL Database forum and for feature requests, please add them to the SQL Database feedback forum.