Мультитенантные шаблоны клиента в базе данных SaaSMulti-tenant SaaS database tenancy patterns

В этой статье описываются различные модели аренды, доступные для приложения SaaS с несколькими клиентами.This article describes the various tenancy models available for a multi-tenant SaaS application.

При разработке мультитенантного приложения SaaS необходимо тщательно выбрать клиентскую модель, которая лучше всего соответствует требованиям приложения.When designing a multi-tenant SaaS application, you must carefully choose the tenancy model that best fits the needs of your application. Клиентская модель определяет способ сопоставления данных каждого клиента с хранилищем.A tenancy model determines how each tenant’s data is mapped to storage. Выбор клиентской модели влияет на проектирование приложения и управление им.Your choice of tenancy model impacts application design and management. Последующее переключение на другую модель иногда является дорогостоящим.Switching to a different model later is sometimes costly.

О.A. Понятия и терминология SaaSSaaS concepts and terminology

В модели "Программное обеспечение как услуга (SaaS)" компания не продает лицензии на свое программное обеспечение.In the Software as a Service (SaaS) model, your company does not sell licenses to your software. Вместо этого каждый из пользователей платит компании аренду, что делает их ее клиентами.Instead, each customer makes rent payments to your company, making each customer a tenant of your company.

В обмен на осуществление арендных платежей каждый клиент получает доступ к компонентам приложения SaaS и возможность хранить свои данные в системе SaaS.In return for paying rent, each tenant receives access to your SaaS application components, and has its data stored in the SaaS system.

Термин клиентская модель относится к тому, каким способом организовано хранение данных у клиентов.The term tenancy model refers to how tenants' stored data is organized:

  • Однопользовательская модель.   В каждой базе данных хранятся данные только от одного клиента.Single-tenancy:  Each database stores data from only one tenant.
  • Многопользовательская модель.   В каждой базе данных хранятся данные нескольких отдельных клиентов (с механизмами защиты конфиденциальности данных).Multi-tenancy:  Each database stores data from multiple separate tenants (with mechanisms to protect data privacy).
  • Доступны также гибридные клиентские модели.Hybrid tenancy models are also available.

B.B. Как выбрать соответствующую клиентскую модельHow to choose the appropriate tenancy model

Как правило, клиентская модель не влияет на функции приложения, но влияет на другие аспекты решения в целом.In general, the tenancy model does not impact the function of an application, but it likely impacts other aspects of the overall solution. Для оценки каждой модели используются критерии ниже.The following criteria are used to assess each of the models:

  • Масштабируемость:Scalability:

    • число клиентов;Number of tenants.
    • хранилище на клиент;Storage per-tenant.
    • хранилище в статистической обработке;Storage in aggregate.
    • рабочая нагрузка.Workload.
  • Изоляция клиента:   изоляция данных и производительность (влияет ли рабочая нагрузка одного клиента на другие).Tenant isolation:  Data isolation and performance (whether one tenant’s workload impacts others).

  • Стоимость каждого клиента:   затраты на базу данных.Per-tenant cost:  Database costs.

  • Сложность разработки:Development complexity:

    • изменения схемы;Changes to schema.
    • изменения запросов (требуемые шаблоном).Changes to queries (required by the pattern).
  • Сложность эксплуатации:Operational complexity:

    • Мониторинг производительности и управление ею.Monitoring and managing performance.
    • Управление схемами.Schema management.
    • восстановление клиента;Restoring a tenant.
    • Аварийное восстановление.Disaster recovery.
  • Возможность настройки:   доступная поддержка настроек схемы — для клиента или его определенного класса.Customizability:  Ease of supporting schema customizations that are either tenant-specific or tenant class-specific.

В обсуждении клиента больше рассматривается слой данных.The tenancy discussion is focused on the data layer. Но следует вкратце рассмотреть слой приложения.But consider for a moment the application layer. Слой приложения рассматривается как монолитная сущность.The application layer is treated as a monolithic entity. Если разделить приложение на несколько небольших компонентов, выбор клиентской модели может измениться.If you divide the application into many small components, your choice of tenancy model might change. Обработка некоторых компонентов отличается от обработки других с учетом используемых клиента и технологии или платформы хранения.You could treat some components differently than others regarding both tenancy and the storage technology or platform used.

C.C. Изолированное однотенантное приложение с однотенантной базой данныхStandalone single-tenant app with single-tenant database

Изоляция на уровне приложенияApplication level isolation

В этой модели установка всего приложения выполняется несколько раз, один раз для каждого клиента.In this model, the whole application is installed repeatedly, once for each tenant. Каждый экземпляр приложения представляет собой автономный экземпляр, поэтому он никогда не взаимодействует с каким-либо другим автономным экземпляром.Each instance of the app is a standalone instance, so it never interacts with any other standalone instance. Каждый экземпляр приложения имеет только один клиент, поэтому ему необходима только одна база данных.Each instance of the app has only one tenant, and therefore needs only one database. Эта база данных предназначена только для этого клиента.The tenant has the database all to itself.

Структура изолированного приложения с однотенантной базой данных.Design of standalone app with exactly one single-tenant database.

Каждый экземпляр приложения устанавливается в отдельной группе ресурсов Azure.Each app instance is installed in a separate Azure resource group. Каждая группа ресурсов может принадлежать подписке, владельцем которой является поставщик программного обеспечения или клиент.The resource group can belong to a subscription that is owned by either the software vendor or the tenant. В любом случае поставщик может управлять программным обеспечением клиента.In either case, the vendor can manage the software for the tenant. Каждый экземпляр приложения настроен для подключения к соответствующей базе данных.Each application instance is configured to connect to its corresponding database.

Каждая база данных клиента развертывается как отдельная.Each tenant database is deployed as a single database. Эта модель обеспечивает наивысшую степень изоляции базы данных.This model provides the greatest database isolation. Однако для каждой базы данных требуется выделять достаточно ресурсов, чтобы обрабатывать ее пиковые нагрузки.But the isolation requires that sufficient resources be allocated to each database to handle its peak loads. Важно, что эластичные пулы не могут использоваться для баз данных, развернутых в других группах ресурсов или подписках.Here it matters that elastic pools cannot be used for databases deployed in different resource groups or to different subscriptions. Такое ограничение делает эту изолированную модель однотенантного приложения самым дорогостоящим решением с точки зрения общих затрат на базу данных.This limitation makes this standalone single-tenant app model the most expensive solution from an overall database cost perspective.

Управление со стороны поставщикаVendor management

У поставщика есть доступ ко всем базам данных во всех изолированных экземплярах приложения, даже если эти экземпляры установлены в других подписках клиента.The vendor can access all the databases in all the standalone app instances, even if the app instances are installed in different tenant subscriptions. Доступ осуществляется через подключения SQL.The access is achieved via SQL connections. С помощью этого перекрестного доступа поставщик может централизовать управление схемой и межбазовые запросы для задач отчетности и аналитики.This cross-instance access can enable the vendor to centralize schema management and cross-database query for reporting or analytics purposes. Если требуется такой вид централизованного управления, должен быть развернут каталог для сопоставления идентификаторов клиентов с URI баз данных.If this kind of centralized management is desired, a catalog must be deployed that maps tenant identifiers to database URIs. База данных SQL Azure предоставляет библиотеку сегментирования, которая используется вместе с базой данных SQL для предоставления каталога.Azure SQL Database provides a sharding library that is used together with a SQL database to provide a catalog. Библиотека сегментирования формально называется клиентской библиотекой эластичной базы данных.The sharding library is formally named the Elastic Database Client Library.

D.D. Мультитенантное приложение с однотенантной базой данныхMulti-tenant app with database-per-tenant

Этот шаблон использует мультитенантное приложение с несколькими однотенантными базами данных.This next pattern uses a multi-tenant application with many databases, all being single-tenant databases. Новая база данных подготавливается для каждого нового клиента.A new database is provisioned for each new tenant. Можно вертикально увеличивать масштаб уровня приложения, добавляя больше ресурсов для каждого узла.The application tier is scaled up vertically by adding more resources per node. Или же горизонтально уменьшать масштаб, добавляя большее число узлов.Or the app is scaled out horizontally by adding more nodes. Масштабирование зависит от рабочей нагрузки и не зависит от количества или масштаба отдельных баз данных.The scaling is based on workload, and is independent of the number or scale of the individual databases.

Структура мультитенантного приложения с однотенантной базой данных.Design of multi-tenant app with database-per-tenant.

Настройка клиентаCustomize for a tenant

Как и при изолированном шаблоне приложения использование однотенантных баз данных обеспечивает надежную изоляцию клиента.Like the standalone app pattern, the use of single-tenant databases gives strong tenant isolation. В любом приложении, модель которого определяет только однотенантные базы данных, можно оптимизировать и настроить схему любой базы данных для ее клиента.In any app whose model specifies only single-tenant databases, the schema for any one given database can be customized and optimized for its tenant. Такая настройка не влияет на другие клиенты в приложении.This customization does not affect other tenants in the app. Возможно, клиенту потребуются данные помимо основных полей данных, которые нужны всем клиентам.Perhaps a tenant might need data beyond the basic data fields that all tenants need. Кроме того, дополнительному полю данных может понадобиться индекс.Further, the extra data field might need an index.

С помощью отдельной однотенантной базы данных можно настроить схему для одного или нескольких клиентов.With database-per-tenant, customizing the schema for one or more individual tenants is straightforward to achieve. Поставщик приложения должен разработать процедуры, чтобы соответствующим образом управлять настройками схемы в нужном масштабе.The application vendor must design procedures to carefully manage schema customizations at scale.

Пулы эластичных БДElastic pools

При развертывании баз данных в одной группе ресурсов их можно группировать в эластичные пулы.When databases are deployed in the same resource group, they can be grouped into elastic pools. Пулы обеспечивают экономичный способ совместного использования ресурсов между несколькими базами данных.The pools provide a cost-effective way of sharing resources across many databases. Использование пула обходится дешевле, чем баз данных большого размера, необходимого, чтобы справиться с пиками использования.This pool option is cheaper than requiring each database to be large enough to accommodate the usage peaks that it experiences. Несмотря на то что базы данных в пуле имеют совместный доступ к ресурсам, по-прежнему возможна высокая степень изоляции производительности.Even though pooled databases share access to resources they can still achieve a high degree of performance isolation.

Структура мультитенантного приложения с однотенантной базой данных с использованием эластичного пула.Design of multi-tenant app with database-per-tenant, using elastic pool.

База данных SQL Azure предоставляет средства, необходимые для настройки и мониторинга совместного доступа, а также управления им.Azure SQL Database provides the tools necessary to configure, monitor, and manage the sharing. Метрики производительности уровня пула и базы данных доступны в портал Azure и с помощью журналов Azure Monitor.Both pool-level and database-level performance metrics are available in the Azure portal, and through Azure Monitor logs. С помощью этих метрик можно получить подробные сведения об общей производительности и производительности отдельного клиента.The metrics can give great insights into both aggregate and tenant-specific performance. Отдельные базы данных можно перемещать между пулами, чтобы предоставить зарезервированные ресурсы конкретным клиентам.Individual databases can be moved between pools to provide reserved resources to a specific tenant. Эти инструменты позволяют обеспечить оптимальную производительность без лишних затрат.These tools enable you to ensure good performance in a cost effective manner.

Масштабирование операций для однотенантной базы данныхOperations scale for database-per-tenant

Платформа Базы данных SQL Azure предлагает множество функций управления, разработанных для управления большим количеством баз данных, например свыше 100 000.The Azure SQL Database platform has many management features designed to manage large numbers of databases at scale, such as well over 100,000 databases. Эти функции делают вероятный шаблон однотенантной базы данных.These features make the database-per-tenant pattern plausible.

Предположим, что в системе имеется база данных с 1000 клиентов — только одна база данных.For example, suppose a system has a 1000-tenant database as its only one database. У базы данных может быть 20 индексов.The database might have 20 indexes. Если система выполнит преобразование для получения 1000 однотенантных баз данных, количество индексов возрастет до 20 000.If the system converts to having 1000 single-tenant databases, the quantity of indexes rises to 20,000. В базе данных SQL в ходе автоматической настройкифункции автоматического индексирования включены по умолчанию.In SQL Database as part of Automatic tuning, the automatic indexing features are enabled by default. С помощью автоматического индексирования выполняется управление всеми 20 000 индексами и их текущими операциями создания и удаления.Automatic indexing manages for you all 20,000 indexes and their ongoing create and drop optimizations. Эти автоматические действия применяются в отдельной базе данных и не координируются или ограничиваются подобными действиями в других базах данных.These automated actions occur within an individual database, and they are not coordinated or restricted by similar actions in other databases. Автоматическое индексирование неодинаково обрабатывает индексы в базах данных с разными нагрузками.Automatic indexing treats indexes differently in a busy database than in a less busy database. Такой тип настройки управления индексами был бы крайне неэффективным для масштабирования однотенантной базы данных, если задача по такому управлению должна была бы выполняться вручную.This type of index management customization would be impractical at the database-per-tenant scale if this huge management task had to be done manually.

Ниже приведены другие функции управления, которые поддерживают масштабирование:Other management features that scale well include the following:

  • встроенные резервные копии;Built-in backups.
  • обеспечение высокой доступности;High availability.
  • шифрование дисков;On-disk encryption.
  • телеметрия производительности.Performance telemetry.

АвтоматизацияAutomation

Операции управления можно создавать в скриптах и предлагать через модель devops .The management operations can be scripted and offered through a devops model. Их даже можно автоматизировать и реализовывать в приложении.The operations can even be automated and exposed in the application.

Например, вы можете автоматизировать восстановление отдельного клиента до более ранней точки во времени.For example, you could automate the recovery of a single tenant to an earlier point in time. Для восстановления необходимо только восстановить однотенантную базу данных, в которой хранится клиент.The recovery only needs to restore the one single-tenant database that stores the tenant. Такое восстановление не оказывает влияние на другие клиенты, что подтверждает выполнение операций управления на более глубоком уровне каждого отдельного клиента.This restore has no impact on other tenants, which confirms that management operations are at the finely granular level of each individual tenant.

E.E. Мультитенантное приложение с мультитенантными базами данныхMulti-tenant app with multi-tenant databases

Другой доступный шаблон — хранение нескольких клиентов в мультитенантной базе данных.Another available pattern is to store many tenants in a multi-tenant database. Экземпляр приложения может иметь любое количество мультитенантных баз данных.The application instance can have any number of multi-tenant databases. Схема мультитенантной базы данных должна иметь один или несколько столбцов идентификаторов клиентов, чтобы можно было выборочно извлечь данные из любого соответствующего клиента.The schema of a multi-tenant database must have one or more tenant identifier columns so that the data from any given tenant can be selectively retrieved. Кроме того, схеме может потребоваться несколько таблиц или столбцов, используемых только подмножеством клиентов.Further, the schema might require a few tables or columns that are used by only a subset of tenants. Однако статический код и эталонные данные сохраняются только раз и совместно используются всеми клиентами.However, static code and reference data is stored only once and is shared by all tenants.

Потеря изоляции клиентаTenant isolation is sacrificed

Данные:   мультитенантная база данных по необходимости "жертвует" изоляцией клиента.Data:  A multi-tenant database necessarily sacrifices tenant isolation. Данные нескольких клиентов совместно хранятся в одной базе данных.The data of multiple tenants is stored together in one database. Во время разработки запросы никогда не должны предоставлять данные из более чем одного клиента.During development, ensure that queries never expose data from more than one tenant. База данных SQL поддерживает безопасность на уровне строк, что позволяет принудительно ограничить данные, возвращаемые запросом, в один клиент.SQL Database supports row-level security, which can enforce that data returned from a query be scoped to a single tenant.

Обработка:   мультитенантная база данных предоставляет совместный доступ к вычислительным ресурсам и ресурсам хранения для всех своих клиентов.Processing:  A multi-tenant database shares compute and storage resources across all its tenants. Вы можете отслеживать всю базу данных, чтобы наблюдать за ее работой.The database as a whole can be monitored to ensure it is performing acceptably. Тем не менее система Azure не имеет встроенной функции мониторинга или контроля использования этих ресурсов отдельным клиентом.However, the Azure system has no built-in way to monitor or manage the use of these resources by an individual tenant. Таким образом, мультитенантная база данных повышает риск возникновения "шумных соседей", где рабочая нагрузка одного активного клиента влияет на производительность других клиентов в этой базе данных.Therefore, the multi-tenant database carries an increased risk of encountering noisy neighbors, where the workload of one overactive tenant impacts the performance experience of other tenants in the same database. С помощью дополнительного мониторинга на уровне приложения можно отслеживать производительность на уровне клиента.Additional application-level monitoring could monitor tenant-level performance.

Низкая стоимостьLower cost

Как правило, мультитенантные базы данных имеют наименьшую стоимость на каждого клиента.In general, multi-tenant databases have the lowest per-tenant cost. Затраты на ресурсы для отдельной базы данных ниже, чем для эластичного пула аналогичного размера.Resource costs for a single database are lower than for an equivalently sized elastic pool. Кроме того, в сценариях, где клиентам требуется только ограниченный объем хранилища, потенциально миллионы клиентов могут храниться в одной базе данных.In addition, for scenarios where tenants need only limited storage, potentially millions of tenants could be stored in a single database. Эластичный пул не может содержать миллионы баз данных.No elastic pool can contain millions of databases. Однако рассмотрим решение, содержащее 1000 баз данных на пул. С 1000 пулами можно достичь масштабируемости, обеспечиваемой миллионом клиентов, с риском трудоемкого управления.However, a solution containing 1000 databases per pool, with 1000 pools, could reach the scale of millions at the risk of becoming unwieldy to manage.

Есть два варианта модели мультитенантной базы данных, которые описываются ниже. Наиболее гибкой и масштабируемой является сегментированная мультитенантная модель.Two variations of a multi-tenant database model are discussed in what follows, with the sharded multi-tenant model being the most flexible and scalable.

F.F. Мультитенантное приложение с отдельной мультитенантной базой данныхMulti-tenant app with a single multi-tenant database

Самый простой шаблон мультитенантной базы данных использует отдельную базу данных для размещения данных всех клиентов.The simplest multi-tenant database pattern uses a single database to host data for all tenants. По мере добавления дополнительных клиентов база данных масштабируется и, соответственно, увеличивается объем хранилища и вычислительных ресурсов.As more tenants are added, the database is scaled up with more storage and compute resources. Даже такая масштабируемость является ограниченной.This scale up might be all that is needed, although there is always an ultimate scale limit. Тем не менее к тому моменту, когда будет достигнут предел масштабируемости, управление базой данных станет очень трудоемким процессом.However, long before that limit is reached the database becomes unwieldy to manage.

В мультитенантной базе данных гораздо сложнее реализовать операции управления, ориентированные на отдельных клиентов.Management operations that are focused on individual tenants are more complex to implement in a multi-tenant database. И в рамках масштабирования они могут работать очень медленно.And at scale these operations might become unacceptably slow. В качестве примера можно привести восстановление данных до точки во времени только для одного клиента.One example is a point-in-time restore of the data for just one tenant.

Ж.G. Мультитенантное приложение с сегментированными мультитенантными базами данныхMulti-tenant app with sharded multi-tenant databases

Большинство приложений SaaS получают доступ к данным только одного клиента за раз.Most SaaS applications access the data of only one tenant at a time. Этот шаблон доступа позволяет распределять данные клиента между несколькими базами данных или сегментами, где все данные для любого отдельного клиента содержатся в одном сегменте.This access pattern allows tenant data to be distributed across multiple databases or shards, where all the data for any one tenant is contained in one shard. Вместе с шаблоном мультитенантной базы данных сегментированная модель обеспечивает практически неограниченное масштабирование.Combined with a multi-tenant database pattern, a sharded model allows almost limitless scale.

Структура мультитенантного приложения с сегментированными мультитенантными базами данных.Design of multi-tenant app with sharded multi-tenant databases.

Управление сегментамиManage shards

Сегментирование усложняет проектирование и эксплуатационное управление.Sharding adds complexity both to the design and operational management. Для поддержки сопоставления между клиентами и базами данных требуется каталог.A catalog is required in which to maintain the mapping between tenants and databases. Кроме того, процедуры управления необходимы для управления сегментами и заполнения клиента.In addition, management procedures are required to manage the shards and the tenant population. Например, должны быть разработаны процедуры для добавления и удаления сегментов, а также перемещения данных клиента между сегментами.For example, procedures must be designed to add and remove shards, and to move tenant data between shards. Способом масштабирования является добавление нового сегмента и его заполнение новыми клиентами.One way to scale is to by adding a new shard and populating it with new tenants. В других случаях можно разделить плотно заполненный сегмент на два менее заполненных сегмента.At other times you might split a densely populated shard into two less-densely populated shards. После перемещения нескольких клиентов или прекращения их использования можно объединить менее заполненные сегменты.After several tenants have been moved or discontinued, you might merge sparsely populated shards together. Так можно достичь более экономически выгодного использования ресурсов.The merge would result in more cost-efficient resource utilization. Клиенты также можно перемещать между сегментами, чтобы распределять рабочую нагрузку.Tenants might also be moved between shards to balance workloads.

База данных SQL предоставляет средство разделения и объединения, которое работает в сочетании с библиотекой сегментирования и базой данных каталога.SQL Database provides a split/merge tool that works in conjunction with the sharding library and the catalog database. Предоставленное приложение может разделять, объединять сегменты и перемещать между ними данные клиента.The provided app can split and merge shards, and it can move tenant data between shards. Приложение также поддерживает каталог во время выполнения этих операций, помечая затронутые клиенты как автономные перед их перемещением.The app also maintains the catalog during these operations, marking affected tenants as offline prior to moving them. После перемещения каталог снова обновляется и образуется новое сопоставление, а отмеченный клиент снова становится активным.After the move, the app updates the catalog again with the new mapping, and marking the tenant as back online.

Небольшими базами данных проще управлятьSmaller databases more easily managed

Распределяя клиенты между несколькими базами данных, сегментированное мультитенантное решение формирует небольшие базы данных, управлять которыми гораздо проще.By distributing tenants across multiple databases, the sharded multi-tenant solution results in smaller databases that are more easily managed. Например, восстановление конкретного клиента до предыдущей точки во времени теперь включает восстановление отдельной небольшой базы данных из резервной копии, а не большой базы данных со всеми клиентами.For example, restoring a specific tenant to a prior point in time now involves restoring a single smaller database from a backup, rather than a larger database that contains all tenants. Для балансировки рабочей нагрузки и распределения действий по управлению можно выбрать размер базы данных и количество клиентов на нее.The database size, and number of tenants per database, can be chosen to balance the workload and the management efforts.

Идентификатор клиента в схемеTenant identifier in the schema

В зависимости от используемого подхода к сегментированию на схему базы данных могут быть наложены дополнительные ограничения.Depending on the sharding approach used, additional constraints may be imposed on the database schema. Приложение разделения и объединения базы данных SQL требует, чтобы схема включала ключ сегментирования, которым обычно является идентификатор клиента.The SQL Database split/merge application requires that the schema includes the sharding key, which typically is the tenant identifier. Идентификатор клиента является ведущим элементом в первичном ключе всех сегментированных таблиц.The tenant identifier is the leading element in the primary key of all sharded tables. Он позволяет приложению разделения и объединения быстро найти и переместить данные, связанные с конкретным клиентом.The tenant identifier enables the split/merge application to quickly locate and move data associated with a specific tenant.

Эластичный пул для сегментовElastic pool for shards

Сегментированные мультитенантные базы данных можно поместить в эластичные пулы.Sharded multi-tenant databases can be placed in elastic pools. Как правило, наличие нескольких однотенантных баз данных в пуле так же экономически выгодно, как и наличие нескольких клиентов в нескольких мультитенантных базах данных.In general, having many single-tenant databases in a pool is as cost efficient as having many tenants in a few multi-tenant databases. Мультитенантные базы данных выгодны, если имеется большое число относительно неактивных клиентов.Multi-tenant databases are advantageous when there are a large number of relatively inactive tenants.

З.H. Гибридная модель сегментированной мультитенантной базы данныхHybrid sharded multi-tenant database model

В гибридной модели все базы данных содержат идентификатор клиента в своей схеме.In the hybrid model, all databases have the tenant identifier in their schema. Все базы данных могут хранить более одного клиента, и их можно сегментировать.The databases are all capable of storing more than one tenant, and the databases can be sharded. Таким образом, в рамках схемы все они являются мультитенантными базами данных.So in the schema sense, they are all multi-tenant databases. Однако на практике некоторые из этих баз данных содержат только один клиент.Yet in practice some of these databases contain only one tenant. Тем не менее количество клиентов, хранящихся в определенной базе данных, не оказывает влияния на схему базы данных.Regardless, the quantity of tenants stored in a given database has no effect on the database schema.

Перемещение клиентовMove tenants around

Вы можете переместить конкретный клиент в его собственную мультитенантную базу данных в любое время.At any time, you can move a particular tenant to its own multi-tenant database. И также в любой момент можно изменить свое решение и переместить клиент обратно в базу данных, в которой содержится несколько клиентов.And at any time, you can change your mind and move the tenant back to a database that contains multiple tenants. При подготовке новой базы данных можно также назначить клиент новой однотенантной базе данных.You can also assign a tenant to new single-tenant database when you provision the new database.

Гибридная модель оптимальна, когда присутствуют большие различия в отношении потребностей ресурсов в идентифицируемых группах клиентов.The hybrid model shines when there are large differences between the resource needs of identifiable groups of tenants. Предположим, что клиенты, доступные в бесплатной пробной версии, не гарантируют такой же высокий уровень производительности, как клиенты в подписке.For example, suppose that tenants participating in a free trial are not guaranteed the same high level of performance that subscribing tenants are. Политика для клиентов на этапе бесплатной пробной версии должна храниться в мультитенантной базе данных, которая совместно используется всеми клиентами бесплатной пробной версии.The policy might be for tenants in the free trial phase to be stored in a multi-tenant database that is shared among all the free trial tenants. Когда клиент бесплатной пробной версии подписывается на базовый уровень служб, его можно переместить в другую мультитенантную базу данных с меньшим количеством клиентов.When a free trial tenant subscribes to the basic service tier, the tenant can be moved to another multi-tenant database that might have fewer tenants. Подписчика, который приобретает уровень служб "Премиум", можно переместить в его собственную новую однотенантную базу данных.A subscriber that pays for the premium service tier could be moved to its own new single-tenant database.

ПулыPools

В этой гибридной модели однотенантные базы данных для клиентов подписчика можно поместить в пулы ресурсов, чтобы снизить затраты на однотенантную базу данных.In this hybrid model, the single-tenant databases for subscriber tenants can be placed in resource pools to reduce database costs per tenant. Это также актуально для модели однотенантной базы данных.This is also done in the database-per-tenant model.

1.I. Сравнение клиентских моделейTenancy models compared

В следующей таблице приведены различия между основными клиентскими моделями.The following table summarizes the differences between the main tenancy models.

ИзмеренияMeasurement Изолированное приложениеStandalone app Однотенантная база данныхDatabase-per-tenant Сегментированная мультитенантная база данныхSharded multi-tenant
МасштабированиеScale СреднийMedium
1–1001-100s
Очень высокаяVery high
1–100 0001-100,000s
Без ограниченийUnlimited
1–1 000 0001-1,000,000s
Изоляция клиентовTenant isolation Очень высокаяVery high ВысокийHigh Низкая. За исключением одноэлементного клиента (одного в базе данных MT).Low; except for any single tenant (that is alone in an MT db).
Стоимость на базу данных для каждого клиентаDatabase cost per tenant Высокая. Размер зависит от пиков.High; is sized for peaks. Низкая. Используются пулы.Low; pools used. Наименьшая. Для небольших клиентов в базах данных MT.Lowest, for small tenants in MT DBs.
Мониторинг производительности и управление еюPerformance monitoring and management Только для каждого клиентаPer-tenant only Общая статистическая обработка + для каждого клиентаAggregate + per-tenant Статистическая обработка. Для каждого клиента только для одноэлементных экземпляров.Aggregate; although is per-tenant only for singles.
Сложность разработкиDevelopment complexity НизкийLow НизкийLow Средняя из-за сегментирования.Medium; due to sharding.
Сложность эксплуатацииOperational complexity Варьируется от низкой до высокой.Low-High. Отдельные клиенты — низкая, высокая при масштабировании.Individually simple, complex at scale. Варьируется от низкой до средней.Low-Medium. Сложность зависит от масштабирования.Patterns address complexity at scale. Варьируется от низкой до высокой.Low-High. Сложное управление отдельным клиентом.Individual tenant management is complex.
 

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