Multitenancy-patronen voor SaaS-data base met meerdere tenantsMulti-tenant SaaS database tenancy patterns

In dit artikel worden de verschillende pacht modellen beschreven die beschikbaar zijn voor een SaaS-toepassing met meerdere tenants.This article describes the various tenancy models available for a multi-tenant SaaS application.

Bij het ontwerpen van een multi tenant SaaS-toepassing moet u zorgvuldig het pacht-model kiezen dat het beste past bij de behoeften van uw toepassing.When designing a multi-tenant SaaS application, you must carefully choose the tenancy model that best fits the needs of your application. Een pacht model bepaalt hoe de gegevens van elke Tenant worden toegewezen aan de opslag.A tenancy model determines how each tenant’s data is mapped to storage. Uw keuze van het pacht-model is van invloed op het ontwerp en beheer van toepassingen.Your choice of tenancy model impacts application design and management. Het is ook mogelijk dat u later overschakelt naar een ander model.Switching to a different model later is sometimes costly.

A.A. SaaS-concepten en terminologieSaaS concepts and terminology

In het SaaS-model (Software as a Service) verkoopt uw bedrijf geen licenties voor uw software.In the Software as a Service (SaaS) model, your company does not sell licenses to your software. In plaats daarvan brengt elke klant rente betaling aan uw bedrijf en maakt elke klant een Tenant van uw bedrijf.Instead, each customer makes rent payments to your company, making each customer a tenant of your company.

Bij het retour neren van huren ontvangt elke Tenant toegang tot uw SaaS-toepassings onderdelen en zijn de gegevens opgeslagen in het SaaS-systeem.In return for paying rent, each tenant receives access to your SaaS application components, and has its data stored in the SaaS system.

Het term pacht-model verwijst naar de manier waarop tenants opgeslagen gegevens zijn ingedeeld:The term tenancy model refers to how tenants' stored data is organized:

  • Enkel pacht:   Elke Data Base slaat gegevens op uit slechts één Tenant.Single-tenancy:  Each database stores data from only one tenant.
  • Multitenancy:   Elke Data Base slaat gegevens op uit meerdere afzonderlijke tenants (met mechanismen voor het beveiligen van de privacy van gegevens).Multi-tenancy:  Each database stores data from multiple separate tenants (with mechanisms to protect data privacy).
  • Er zijn ook Hybrid pacht-modellen beschikbaar.Hybrid tenancy models are also available.

B.B. Het juiste pacht-model kiezenHow to choose the appropriate tenancy model

In het algemeen heeft het pacht-model geen invloed op de werking van een toepassing, maar dit is waarschijnlijk van invloed op andere aspecten van de algemene oplossing.In general, the tenancy model does not impact the function of an application, but it likely impacts other aspects of the overall solution. De volgende criteria worden gebruikt voor het evalueren van elk model:The following criteria are used to assess each of the models:

  • Schaalbaarheid:Scalability:

    • Aantal tenants.Number of tenants.
    • Opslag per Tenant.Storage per-tenant.
    • Opslag in samen voeging.Storage in aggregate.
    • Werklast.Workload.
  • Tenant isolatie:   Gegevens isolatie en prestaties (of de werk belasting van een Tenant invloed heeft op andere).Tenant isolation:  Data isolation and performance (whether one tenant’s workload impacts others).

  • Kosten per Tenant:   Database kosten.Per-tenant cost:  Database costs.

  • Complexiteit van de ontwikkeling:Development complexity:

    • Wijzigingen in het schema.Changes to schema.
    • Wijzigingen in query's (vereist voor het patroon).Changes to queries (required by the pattern).
  • Operationele complexiteit:Operational complexity:

    • Prestaties bewaken en beheren.Monitoring and managing performance.
    • Schema beheer.Schema management.
    • Een Tenant herstellen.Restoring a tenant.
    • Herstel na noodgevallen.Disaster recovery.
  • Aanpassings mogelijkheden  Eenvoudige ondersteuning van schema aanpassingen die specifiek zijn voor een Tenant of Tenant.Customizability:  Ease of supporting schema customizations that are either tenant-specific or tenant class-specific.

De pacht-discussie is gericht op de gegevenslaag.The tenancy discussion is focused on the data layer. Houd echter rekening met de laag van de toepassingslaag .But consider for a moment the application layer. De toepassingslaag wordt behandeld als een monolithische-entiteit.The application layer is treated as a monolithic entity. Als u de toepassing verdeelt in veel kleine onderdelen, kan uw keuze van het pacht-model veranderen.If you divide the application into many small components, your choice of tenancy model might change. U kunt sommige onderdelen anders behandelen dan andere met betrekking tot de pacht en de opslag technologie of het gebruikte platform.You could treat some components differently than others regarding both tenancy and the storage technology or platform used.

C.C. Zelfstandige app met één Tenant met een Data Base met één TenantStandalone single-tenant app with single-tenant database

Isolatie op toepassings niveauApplication level isolation

In dit model wordt de hele toepassing herhaaldelijk geïnstalleerd en eenmaal voor elke Tenant.In this model, the whole application is installed repeatedly, once for each tenant. Elk exemplaar van de app is een zelfstandig exemplaar, dus het werkt nooit met een wille keurig ander zelfstandig exemplaar.Each instance of the app is a standalone instance, so it never interacts with any other standalone instance. Elk exemplaar van de app heeft slechts één Tenant en heeft daarom slechts één data base nodig.Each instance of the app has only one tenant, and therefore needs only one database. De Tenant heeft de data base allemaal aan zichzelf.The tenant has the database all to itself.

Ontwerp van een zelfstandige app met precies één Tenant database.Design of standalone app with exactly one single-tenant database.

Elk exemplaar van de app wordt geïnstalleerd in een afzonderlijke Azure-resource groep.Each app instance is installed in a separate Azure resource group. De resource groep kan behoren tot een abonnement dat eigendom is van de software leverancier of de Tenant.The resource group can belong to a subscription that is owned by either the software vendor or the tenant. In beide gevallen kan de leverancier de software voor de Tenant beheren.In either case, the vendor can manage the software for the tenant. Elk toepassings exemplaar is geconfigureerd om verbinding te maken met de bijbehorende data base.Each application instance is configured to connect to its corresponding database.

Elke Tenant database wordt als één data base geïmplementeerd.Each tenant database is deployed as a single database. Dit model biedt de grootste database isolatie.This model provides the greatest database isolation. Maar de isolatie vereist dat er voldoende resources worden toegewezen aan elke Data Base om de piek belastingen te kunnen afhandelen.But the isolation requires that sufficient resources be allocated to each database to handle its peak loads. Hier ziet u dat elastische Pools niet kunnen worden gebruikt voor data bases die in verschillende resource groepen of op verschillende abonnementen worden geïmplementeerd.Here it matters that elastic pools cannot be used for databases deployed in different resource groups or to different subscriptions. Deze beperking maakt deze zelfstandige app voor één Tenant de meest dure oplossing van een algemeen data base-kosten perspectief.This limitation makes this standalone single-tenant app model the most expensive solution from an overall database cost perspective.

Leveranciers beheerVendor management

De leverancier heeft toegang tot alle data bases in alle zelfstandige app-instanties, zelfs als de app-exemplaren in verschillende Tenant abonnementen zijn geïnstalleerd.The vendor can access all the databases in all the standalone app instances, even if the app instances are installed in different tenant subscriptions. De toegang wordt bereikt via SQL-verbindingen.The access is achieved via SQL connections. Deze cross-instance Access kan de leverancier in staat stellen schema beheer en query's voor meerdere data bases te centraliseren voor rapportage-of analyse doeleinden.This cross-instance access can enable the vendor to centralize schema management and cross-database query for reporting or analytics purposes. Als dit soort gecentraliseerd beheer gewenst is, moet er een catalogus worden geïmplementeerd waarmee Tenant-id's worden toegewezen aan data base-Uri's.If this kind of centralized management is desired, a catalog must be deployed that maps tenant identifiers to database URIs. Azure SQL Database biedt een sharding-bibliotheek die in combi natie met een SQL database wordt gebruikt om een catalogus op te geven.Azure SQL Database provides a sharding library that is used together with a SQL database to provide a catalog. De sharding-bibliotheek heeft formeel de naam van de Elastic database-client bibliotheek.The sharding library is formally named the Elastic Database Client Library.

D.D. Multi tenant-app met data base per TenantMulti-tenant app with database-per-tenant

Dit volgende patroon maakt gebruik van een toepassing met meerdere tenants met veel data bases, allemaal data bases met één Tenant.This next pattern uses a multi-tenant application with many databases, all being single-tenant databases. Er wordt een nieuwe data base ingericht voor elke nieuwe Tenant.A new database is provisioned for each new tenant. De toepassingslaag wordt verticaal omhoog geschaald door meer resources per knoop punt toe te voegen.The application tier is scaled up vertically by adding more resources per node. Of de app is horizon taal geschaald door meer knoop punten toe te voegen.Or the app is scaled out horizontally by adding more nodes. De schaal is gebaseerd op de werk belasting en is onafhankelijk van het aantal of de schaal van de afzonderlijke data bases.The scaling is based on workload, and is independent of the number or scale of the individual databases.

Ontwerp van een app met meerdere tenants met data base-per-Tenant.Design of multi-tenant app with database-per-tenant.

Aanpassen voor een TenantCustomize for a tenant

Net als bij het patroon van de zelfstandige app biedt het gebruik van data bases met één Tenant een sterke isolatie van tenants.Like the standalone app pattern, the use of single-tenant databases gives strong tenant isolation. In een app waarvan het model alleen single tenant-data bases bevat, kan het schema voor een wille keurige Data Base worden aangepast en geoptimaliseerd voor de Tenant.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. Deze aanpassing heeft geen invloed op andere tenants in de app.This customization does not affect other tenants in the app. Misschien heeft een Tenant mogelijk gegevens nodig die groter zijn dan de basis gegevens velden die alle tenants nodig hebben.Perhaps a tenant might need data beyond the basic data fields that all tenants need. Het is ook mogelijk dat het extra gegevens veld een index vereist.Further, the extra data field might need an index.

Met data base-per-Tenant kan het schema voor een of meer afzonderlijke tenants eenvoudig worden gerealiseerd.With database-per-tenant, customizing the schema for one or more individual tenants is straightforward to achieve. De leverancier van de toepassing moet procedures ontwerpen voor het zorgvuldig beheren van schema aanpassingen op schaal.The application vendor must design procedures to carefully manage schema customizations at scale.

Elastische poolsElastic pools

Wanneer data bases in dezelfde resource groep worden geïmplementeerd, kunnen ze worden gegroepeerd in elastische Pools.When databases are deployed in the same resource group, they can be grouped into elastic pools. De groepen bieden een kosteneffectieve manier om resources te delen in veel data bases.The pools provide a cost-effective way of sharing resources across many databases. Deze groeps optie is goed koper dan vereist dat elke Data Base groot genoeg is om te voldoen aan de gebruiks pieken die het ondervindt.This pool option is cheaper than requiring each database to be large enough to accommodate the usage peaks that it experiences. Hoewel gepoolde data bases toegang tot resources delen, kunnen ze nog steeds een hoge mate van prestaties isoleren.Even though pooled databases share access to resources they can still achieve a high degree of performance isolation.

Ontwerp van een app met meerdere tenants met een Data Base per Tenant, met behulp van elastische pool.Design of multi-tenant app with database-per-tenant, using elastic pool.

Azure SQL Database biedt de hulpprogram ma's die nodig zijn voor het configureren, bewaken en beheren van het delen.Azure SQL Database provides the tools necessary to configure, monitor, and manage the sharing. De metrische gegevens voor de prestaties op groeps niveau en op database niveau zijn beschikbaar in het Azure Portal en via Azure Monitor-Logboeken.Both pool-level and database-level performance metrics are available in the Azure portal, and through Azure Monitor logs. De metrische gegevens kunnen zeer inzicht geven in zowel geaggregeerde als Tenant-specifieke prestaties.The metrics can give great insights into both aggregate and tenant-specific performance. Afzonderlijke data bases kunnen tussen Pools worden verplaatst om gereserveerde resources te bieden aan een specifieke Tenant.Individual databases can be moved between pools to provide reserved resources to a specific tenant. Met deze hulpprogram ma's kunt u op een rendabele manier goede prestaties garanderen.These tools enable you to ensure good performance in a cost effective manner.

Bewerkings schaal voor data base per TenantOperations scale for database-per-tenant

Het Azure SQL Database platform heeft veel beheer functies die zijn ontworpen om grote aantallen data bases op schaal te beheren, zoals veel meer dan 100.000 data bases.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. Deze functies maken het plausible van de data base per Tenant.These features make the database-per-tenant pattern plausible.

Stel bijvoorbeeld dat een systeem een Data Base van 1000-Tenant heeft als één data base.For example, suppose a system has a 1000-tenant database as its only one database. De data base kan 20 indexen bevatten.The database might have 20 indexes. Als het systeem wordt geconverteerd naar data bases met één Tenant van 1000, wordt het aantal indexen tot 20.000.If the system converts to having 1000 single-tenant databases, the quantity of indexes rises to 20,000. In SQL Database als onderdeel van automatisch afstemmen, zijn de functies voor automatisch indexeren standaard ingeschakeld.In SQL Database as part of Automatic tuning, the automatic indexing features are enabled by default. Met automatisch indexeren worden alle 20.000 indexen en de huidige optimalisaties voor maken en verwijderen beheerd.Automatic indexing manages for you all 20,000 indexes and their ongoing create and drop optimizations. Deze geautomatiseerde acties vinden plaats in een afzonderlijke data base en ze worden niet gecoördineerd of beperkt door soort gelijke acties in andere data bases.These automated actions occur within an individual database, and they are not coordinated or restricted by similar actions in other databases. Bij automatische indexering worden indexen anders in een bezette data base verwerkt dan in een Data Base die minder bezet is.Automatic indexing treats indexes differently in a busy database than in a less busy database. Dit type aanpassing van index beheer zou niet praktisch kunnen zijn bij het schalen van de data base per Tenant als deze enorme beheer taak hand matig moet worden uitgevoerd.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.

Andere beheer functies die goed schaalbaar zijn, zijn als volgt:Other management features that scale well include the following:

  • Ingebouwde back-ups.Built-in backups.
  • Hoge beschikbaarheid.High availability.
  • Versleuteling op schijf.On-disk encryption.
  • Telemetrie van prestaties.Performance telemetry.

AutomationAutomation

De beheer bewerkingen kunnen worden gescripteerd en aangeboden via een devops -model.The management operations can be scripted and offered through a devops model. De bewerkingen kunnen zelfs geautomatiseerd en beschikbaar zijn in de toepassing.The operations can even be automated and exposed in the application.

U kunt bijvoorbeeld het herstel van één Tenant naar een eerder tijdstip automatiseren.For example, you could automate the recovery of a single tenant to an earlier point in time. Het herstel hoeft alleen maar één Tenant database te herstellen waarin de Tenant wordt opgeslagen.The recovery only needs to restore the one single-tenant database that stores the tenant. Deze herstel bewerking heeft geen invloed op andere tenants, waarmee wordt bevestigd dat beheer bewerkingen op het nauw keurigste niveau van elke afzonderlijke 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 met multi tenant-data basesMulti-tenant app with multi-tenant databases

Een ander beschikbaar patroon is het opslaan van veel tenants in een Data Base met meerdere tenants.Another available pattern is to store many tenants in a multi-tenant database. Het toepassings exemplaar kan een wille keurig aantal multi tenant-data bases hebben.The application instance can have any number of multi-tenant databases. Het schema van een Data Base met meerdere tenants moet een of meer Tenant-id-kolommen hebben, zodat de gegevens van een bepaalde Tenant selectief kunnen worden opgehaald.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. Het schema kan verder een aantal tabellen of kolommen vereisen die alleen worden gebruikt door een subset van tenants.Further, the schema might require a few tables or columns that are used by only a subset of tenants. Statische code en referentie gegevens worden echter slechts één keer opgeslagen en worden gedeeld door alle tenants.However, static code and reference data is stored only once and is shared by all tenants.

Tenant isolatie wordt gedoodTenant isolation is sacrificed

Gegevens  Een multi tenant-data base bewaart per onechte Tenant isolatie.Data:  A multi-tenant database necessarily sacrifices tenant isolation. De gegevens van meerdere tenants worden samen in één data base opgeslagen.The data of multiple tenants is stored together in one database. Zorg er tijdens de ontwikkeling voor dat query's nooit gegevens van meer dan één Tenant beschikbaar maken.During development, ensure that queries never expose data from more than one tenant. SQL Database ondersteunt beveiliging op rijniveau, wat kan afdwingen dat de gegevens die door een query zijn geretourneerd, binnen het bereik van één Tenant vallen.SQL Database supports row-level security, which can enforce that data returned from a query be scoped to a single tenant.

Bezig  Een multi tenant-data base deelt reken-en opslag resources over alle tenants.Processing:  A multi-tenant database shares compute and storage resources across all its tenants. De hele data base kan worden bewaakt om ervoor te zorgen dat deze acceptabel wordt uitgevoerd.The database as a whole can be monitored to ensure it is performing acceptably. Het Azure-systeem heeft echter geen ingebouwde manier om het gebruik van deze resources door een afzonderlijke Tenant te controleren of te beheren.However, the Azure system has no built-in way to monitor or manage the use of these resources by an individual tenant. Daarom heeft de multi tenant-Data Base een groter risico op het ontstaan van ruiserende neighbors, waarbij de werk belasting van een overactieve Tenant invloed heeft op de prestatie ervaring van andere tenants in dezelfde data base.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. Extra bewaking op toepassings niveau kan prestaties op Tenant niveau bewaken.Additional application-level monitoring could monitor tenant-level performance.

Lagere kostenLower cost

In het algemeen hebben multi tenant-data bases de laagste kosten per Tenant.In general, multi-tenant databases have the lowest per-tenant cost. De resource kosten voor één Data Base zijn lager dan voor de elastische pool met een vergelijk bare grootte.Resource costs for a single database are lower than for an equivalently sized elastic pool. Voor scenario's waarbij tenants alleen maar beperkte opslag nodig hebben, kunnen mogelijk miljoenen tenants worden opgeslagen in één data base.In addition, for scenarios where tenants need only limited storage, potentially millions of tenants could be stored in a single database. Geen elastische pool kan miljoenen data bases bevatten.No elastic pool can contain millions of databases. Een oplossing met 1000-data bases per pool, met 1000-groepen, kan echter de schaal van miljoenen bereiken tegen het risico dat u het beheer onoverzichtelijk maakt.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.

Twee varianten van een model voor multi tenant-data bases worden in de volgende stappen beschreven, waarbij het Shard multi tenant-model het meest flexibel en schaalbaar is.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 met één multi tenant-data baseMulti-tenant app with a single multi-tenant database

Het eenvoudigste multi tenant-database patroon maakt gebruik van één Data Base voor het hosten van gegevens voor alle tenants.The simplest multi-tenant database pattern uses a single database to host data for all tenants. Naarmate er meer tenants worden toegevoegd, wordt de data base omhoog geschaald met meer opslag-en reken resources.As more tenants are added, the database is scaled up with more storage and compute resources. Deze schaal kan allemaal nodig zijn, hoewel er altijd een limiet voor een ultieme schaal is.This scale up might be all that is needed, although there is always an ultimate scale limit. Lang voordat deze limiet is bereikt, wordt de data base lastig te beheren.However, long before that limit is reached the database becomes unwieldy to manage.

Beheer bewerkingen die zijn gericht op afzonderlijke tenants zijn complexer om te worden geïmplementeerd in een Data Base met meerdere tenants.Management operations that are focused on individual tenants are more complex to implement in a multi-tenant database. En op schaal kunnen deze bewerkingen onaanvaardbaar langzaam worden.And at scale these operations might become unacceptably slow. Een voor beeld hiervan is een herstel bewerking van de gegevens voor slechts één Tenant.One example is a point-in-time restore of the data for just one tenant.

G.G. Multi tenant-app met Shard multi tenant-data basesMulti-tenant app with sharded multi-tenant databases

De meeste SaaS-toepassingen hebben per keer toegang tot de gegevens van slechts één Tenant.Most SaaS applications access the data of only one tenant at a time. Met dit toegangs patroon kunnen Tenant gegevens worden gedistribueerd over meerdere data bases of Shards, waarbij alle gegevens voor een Tenant in één Shard zijn opgenomen.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. In combi natie met een database patroon met meerdere tenants kan een Shard-model bijna onbeperkte schalen.Combined with a multi-tenant database pattern, a sharded model allows almost limitless scale.

Ontwerp van een multi tenant-app met Shard multi tenant-data bases.Design of multi-tenant app with sharded multi-tenant databases.

Shards beherenManage shards

Sharding voegt complexiteit toe aan het ontwerp en operationeel beheer.Sharding adds complexity both to the design and operational management. Er is een catalogus vereist waarin u de toewijzing tussen tenants en data bases kunt onderhouden.A catalog is required in which to maintain the mapping between tenants and databases. Daarnaast zijn er beheer procedures vereist voor het beheren van de Shards en de Tenant populatie.In addition, management procedures are required to manage the shards and the tenant population. Procedures moeten bijvoorbeeld zijn ontworpen om Shards toe te voegen en te verwijderen en om Tenant gegevens tussen Shards te verplaatsen.For example, procedures must be designed to add and remove shards, and to move tenant data between shards. U kunt ook schalen door een nieuwe Shard toe te voegen en deze te vullen met nieuwe tenants.One way to scale is to by adding a new shard and populating it with new tenants. Op andere momenten kunt u een Shard met een hoge dichtheid splitsen in twee minder weinig Shards gevulde gegevens.At other times you might split a densely populated shard into two less-densely populated shards. Nadat er meerdere tenants zijn verplaatst of uit gebruik zijn genomen, kunt u de Shards met sparse gevuld samen voegen.After several tenants have been moved or discontinued, you might merge sparsely populated shards together. Het samen voegen zou leiden tot een rendabeler resource gebruik.The merge would result in more cost-efficient resource utilization. Tenants kunnen ook tussen Shards worden verplaatst om de werk belasting te verdelen.Tenants might also be moved between shards to balance workloads.

SQL Database biedt een hulp programma voor splitsen en samen voegen dat werkt in combi natie met de sharding-bibliotheek en de catalogus database.SQL Database provides a split/merge tool that works in conjunction with the sharding library and the catalog database. De gegeven app kan Shards splitsen en samen voegen, en kan de Tenant gegevens verplaatsen tussen Shards.The provided app can split and merge shards, and it can move tenant data between shards. De app houdt ook de catalogus tijdens deze bewerkingen bij, waarbij de betrokken tenants als offline worden gemarkeerd voordat ze worden verplaatst.The app also maintains the catalog during these operations, marking affected tenants as offline prior to moving them. Na de verplaatsing werkt de app de catalogus opnieuw bij met de nieuwe toewijzing en wordt de Tenant als weer online gemarkeerd.After the move, the app updates the catalog again with the new mapping, and marking the tenant as back online.

Kleinere data bases eenvoudiger te beherenSmaller databases more easily managed

Door tenants over meerdere data bases te distribueren, resulteert de Shard multi tenant-oplossing in kleinere data bases die eenvoudiger te beheren zijn.By distributing tenants across multiple databases, the sharded multi-tenant solution results in smaller databases that are more easily managed. Als u bijvoorbeeld een specifieke Tenant naar een eerder tijdstip herstelt, moet u nu één kleinere data base herstellen vanaf een back-up in plaats van een grotere data base met alle tenants.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. De grootte van de data base en het aantal tenants per data base kunnen worden gekozen om de werk belasting en de beheer taken te verdelen.The database size, and number of tenants per database, can be chosen to balance the workload and the management efforts.

Tenant-id in het schemaTenant identifier in the schema

Afhankelijk van de gebruikte sharding-aanpak kunnen er aanvullende beperkingen worden opgelegd voor het database schema.Depending on the sharding approach used, additional constraints may be imposed on the database schema. De SQL Database splitsen/samen voegen-toepassing vereist dat het schema de sharding-sleutel bevat. Dit is meestal de Tenant-id.The SQL Database split/merge application requires that the schema includes the sharding key, which typically is the tenant identifier. De Tenant-id is het voorloop element in de primaire sleutel van alle Shard-tabellen.The tenant identifier is the leading element in the primary key of all sharded tables. Met de Tenant-id kan de toepassing splitsen/samen voegen snel gegevens vinden en verplaatsen die zijn gekoppeld aan een specifieke Tenant.The tenant identifier enables the split/merge application to quickly locate and move data associated with a specific tenant.

Elastische pool voor ShardsElastic pool for shards

Shard multi tenant-data bases kunnen in elastische Pools worden geplaatst.Sharded multi-tenant databases can be placed in elastic pools. Over het algemeen is het zo dat veel tenants met één Tenant in een pool rendabel zijn, omdat er in een paar data bases met meerdere tenants een aantal pachters zijn.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-data bases zijn handig wanneer er sprake is van een groot aantal relatief inactieve tenants.Multi-tenant databases are advantageous when there are a large number of relatively inactive tenants.

H.H. Model voor de multi tenant-data base hybride ShardHybrid sharded multi-tenant database model

In het hybride model hebben alle data bases de Tenant-id in hun schema.In the hybrid model, all databases have the tenant identifier in their schema. De data bases zijn allemaal geschikt om meer dan één Tenant op te slaan en de data bases kunnen worden Shard.The databases are all capable of storing more than one tenant, and the databases can be sharded. In het schema gevoel zijn ze dus alle data bases met meerdere tenants.So in the schema sense, they are all multi-tenant databases. In de praktijk kunnen sommige van deze data bases slechts één Tenant bevatten.Yet in practice some of these databases contain only one tenant. Ongeacht het aantal tenants dat in een bepaalde data base is opgeslagen, heeft geen invloed op het database schema.Regardless, the quantity of tenants stored in a given database has no effect on the database schema.

Tenants verplaatsenMove tenants around

U kunt op elk gewenst moment een bepaalde Tenant verplaatsen naar een eigen multi tenant-data base.At any time, you can move a particular tenant to its own multi-tenant database. U kunt op elk gewenst moment van gedachten veranderen en de Tenant weer verplaatsen naar een Data Base die meerdere tenants bevat.And at any time, you can change your mind and move the tenant back to a database that contains multiple tenants. U kunt ook een Tenant toewijzen aan een nieuwe Data Base met één Tenant wanneer u de nieuwe data base inricht.You can also assign a tenant to new single-tenant database when you provision the new database.

Het hybride model schijnt wanneer er grote verschillen zijn tussen de resource behoeften van Identificeer bare groepen tenants.The hybrid model shines when there are large differences between the resource needs of identifiable groups of tenants. Stel bijvoorbeeld dat tenants die deel uitmaken van een gratis proef versie, niet kunnen worden gegarandeerd op hetzelfde hoge prestatie niveau als bij het abonneren van tenants.For example, suppose that tenants participating in a free trial are not guaranteed the same high level of performance that subscribing tenants are. Het beleid kan voor tenants in de gratis proef versie worden opgeslagen in een multi tenant-data base die wordt gedeeld door alle tenants van de gratis proef versie.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. Wanneer een gratis proef versie van een Tenant zich abonneert op de Basic-servicelaag, kan de Tenant worden verplaatst naar een andere data base met meerdere tenants die mogelijk minder tenants hebben.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. Een abonnee die betaalt voor de Premium-servicelaag, kan worden verplaatst naar de eigen nieuwe Data Base met één Tenant.A subscriber that pays for the premium service tier could be moved to its own new single-tenant database.

GroepenPools

In dit hybride model kunnen de data bases met één Tenant voor Subscriber-tenants in resource groepen worden geplaatst om de database kosten per Tenant te verlagen.In this hybrid model, the single-tenant databases for subscriber tenants can be placed in resource pools to reduce database costs per tenant. Dit gebeurt ook in het model data base-per Tenant.This is also done in the database-per-tenant model.

I.I. Pacht modellen vergelekenTenancy models compared

De volgende tabel bevat een overzicht van de verschillen tussen de belangrijkste pacht modellen.The following table summarizes the differences between the main tenancy models.

MetingMeasurement Zelfstandige appStandalone app Database-per-tenantDatabase-per-tenant Shard multi tenantSharded multi-tenant
SchalenScale GemiddeldMedium
1-100s1-100s
Zeer hoogVery high
1-100, per 10.0001-100,000s
OnbeperktUnlimited
1-1, 000, per 10.0001-1,000,000s
Tenant isolatieTenant isolation Zeer hoogVery high HoogHigh Gebrek behalve voor één Tenant (die zich alleen in een MT-Data Base bevindt).Low; except for any single tenant (that is alone in an MT db).
Database kosten per TenantDatabase cost per tenant Hogesnelheidsnet het formaat voor pieken.High; is sized for peaks. Gebrek gebruikte groepen.Low; pools used. Laagst, voor kleine tenants in MT Db's.Lowest, for small tenants in MT DBs.
Prestaties bewaken en beherenPerformance monitoring and management Alleen per TenantPer-tenant only Aggregatie + per TenantAggregate + per-tenant Vatting Hoewel dit per Tenant geldt, is dat alleen voor singles.Aggregate; although is per-tenant only for singles.
Complexiteit van ontwikkelingDevelopment complexity LaagLow LaagLow Drager vanwege sharding.Medium; due to sharding.
Operationele complexiteitOperational complexity Laag-hoog.Low-High. Afzonderlijk eenvoudig, complex op schaal.Individually simple, complex at scale. Low-Medium.Low-Medium. Patronen herkennen de complexiteit op schaal.Patterns address complexity at scale. Laag-hoog.Low-High. Het beheer van afzonderlijke tenants is complex.Individual tenant management is complex.
 

Volgende stappenNext steps