Questo documento descrive vari modi per implementare il multi-tenancy in Cloud Spanner. Spiega inoltre i pattern di gestione dei dati e la gestione del ciclo di vita dei tenant.
Multi-tenancy è quando una singola istanza o alcune istanze di un'applicazione software serve più tenant o clienti. Questo modello di software può scalare da un singolo tenant o da un cliente a centinaia o migliaia. Questo approccio è fondamentale per le piattaforme di cloud computing in cui l'infrastruttura sottostante è condivisa tra più organizzazioni.
Pensa all'architettura multi-tenancy come forma di partizione basata su risorse di computing condivise, come i database. Un'analogia è tenant in un edificio un edificio: un'infrastruttura condivisa, ma un ambiente tenant dedicato. La multi-tenancy fa parte della maggior parte, se non tutte, le applicazioni Software as a Service (SaaS).
Questo documento è dedicato agli architetti di database, ai data scientist e agli ingegneri che implementano applicazioni multi-tenant su Spanner come il loro database relazionale. In questo contesto, definisce diversi approcci per archiviare i dati multi-tenant. I termini "tenant", "cliente" e "organizzazione" sono utilizzati in modo intercambiabile in tutto l'articolo per indicare l'entità che accede all'applicazione multi-tenant.
Questo articolo utilizza un provider SaaS per risorse umane che implementa la sua applicazione multi-tenant su Google Cloud come esempio. In questo esempio, diversi clienti del provider SaaS HR devono accedere all'applicazione multi-tenant. Questi clienti sono chiamati tenant.
Spanner è il database completamente gestito, di livello aziendale, distribuito e coerente di Google Cloud che unisce i vantaggi del modello di database relazionale con scalabilità orizzontale non relazionale. Spanner utilizza la semantica relazionale, con schemi, tipi di dati applicati, coerenza elevata, transazioni ACID a più dichiarazioni e linguaggio di query SQL che implementa l'ANSI 2011 SQL.
Spanner offre zero tempi di inattività per errori di manutenzione o area geografica programmati, con uno SLA (accordo sul livello del servizio) con disponibilità del 99,999%. Supporta applicazioni moderne multi-tenant fornendo alta disponibilità e scalabilità. Questo articolo illustra i diversi approcci architetturali al fine di implementare il multi-tenant con Spanner.
Criteri per i criteri di mappatura dei dati del tenant
In un'applicazione multi-tenant, i dati di ciascun tenant sono isolati in uno dei vari approcci dell'architettura nel database Spanner sottostante. Il seguente elenco illustra i diversi approcci di architettura utilizzati per mappare i dati di un tenant a Spanner:
- Istanza: un tenant risiede esclusivamente in un'istanza di Spanner, con un solo database per tale tenant.
- Database: un tenant risiede in un database in una singola istanza Spanner contenente più database.
- Schema: un tenant risiede in tabelle esclusive all'interno di un database e diversi tenant possono trovarsi nello stesso database.
- Tabella: i dati tenant sono righe nelle tabelle di database. Queste tabelle sono condivise con altri tenant.
I criteri precedenti sono chiamati pattern di gestione dei dati e vengono descritti in dettaglio nella sezione Pattern di gestione dei dati multi-tenancy. Questa discussione si basa sui seguenti criteri:
- Isolamento: il grado di isolamento dei dati in più tenant è una considerazione fondamentale per l'architettura multi-tenancy. L'isolamento è determinato dalle scelte effettuate per i criteri in altre categorie, ad esempio, alcuni requisiti specifici di conformità e normative possono determinare un maggiore grado di occultamento.
- Agilità: la facilità di onboarding e l'offboarding per un tenant rispetto alla creazione di un'istanza, un database o una tabella.
- Operazioni: la disponibilità o la complessità nell'implementazione di attività di amministrazione e di amministrazione tipiche di un tenant, ad esempio normali manutenzione, logging, backup o ripristino di emergenza.
- Scala: la capacità di scalare in modo uniforme per consentire la crescita futura. La descrizione di ogni pattern contiene il numero di tenant che può essere supportato dal pattern.
- Prestazioni: la capacità di assegnare risorse esclusive a ciascun tenant, di risolvere il problema del annoneo anenza tenant.
- Normative e conformità: la capacità di soddisfare i requisiti dei settori e dei paesi altamente regolamentati che richiedono l'aggregazione completa delle risorse e delle operazioni di manutenzione, ad esempio i requisiti di residenza dei dati per In Francia, le informazioni personali sono memorizzate fisicamente in Francia.
Ogni modello di gestione dei dati in relazione a questi criteri è descritto nella sezione successiva. Utilizza gli stessi criteri per selezionare un pattern di gestione dei dati per un gruppo specifico di tenant.
Pattern di gestione dei dati multi-tenancy
Le seguenti sezioni descrivono i quattro principali pattern di gestione dei dati: istanza, database, schema e tabella.
Istanza
Per fornire l'isolamento completo, il pattern di gestione dei dati delle istanze memorizza i dati di ciascun tenant nella sua istanza e nel suo database Spanner. Un'istanza Spanner può avere uno o più database. In questo pattern, viene creato un solo database. Per l'applicazione delle risorse umane spiegate in precedenza, viene creata un'istanza Spanner separata con un database per ogni organizzazione del cliente.
Come mostrato nel diagramma seguente, il modello di gestione dei dati ha un tenant per istanza.
Avere istanze separate per ogni tenant consente l'utilizzo di progetti Google Cloud separati per ottenere limiti di attendibilità distinti per tenant diversi. Un ulteriore vantaggio è che ciascuna configurazione di istanza può essere scelta in base alla località di ciascun tenant (a livello di area geografica o di più aree geografiche), ottimizzando la flessibilità e le prestazioni della località.
L'architettura può scalare facilmente per qualunque numero di tenant. I provider SaaS possono creare qualsiasi numero di istanze nelle aree geografiche desiderate, senza alcun limite rigido.
La seguente tabella illustra in che modo il pattern di gestione dei dati delle istanze influisce su criteri diversi.
| Criteri | Istanza: un pattern tenant per pattern di gestione dei dati delle istanze |
|---|---|
| Isolamento |
|
| Agilità |
|
| Operazioni |
|
| Scala |
|
| Prestazioni |
|
| Requisiti normativi e di conformità |
|
In sintesi, i punti principali sono:
- Vantaggio: il massimo livello di isolamento
- Svantaggio: overhead operativo minimo
Il pattern di gestione dei dati delle istanze è più adatto per i seguenti scenari:
- Diversi tenant sono distribuiti in un'ampia gamma di aree geografiche e hanno bisogno di una soluzione localizzata.
- I requisiti normativi e di conformità per alcuni tenant richiedono livelli più elevati di protocollo di sicurezza e controllo.
- La dimensione dei tenant varia in modo significativo e la condivisione delle risorse tra i tenant elevati e il traffico ad alto traffico potrebbe causare conflitti tra i contenuti e la riduzione delle vittime.
Database
Nel pattern di gestione dei dati del database, ogni tenant risiede in un database all'interno di una singola istanza di Spanner. Più database possono trovarsi in una singola istanza. Se un'istanza è insufficiente per il numero di tenant, crea più istanze. Questo pattern presuppone che una singola istanza di Spanner sia condivisa tra più tenant.
Spanner ha un limite rigido di 100 database per istanza. Questo limite significa che se il provider SaaS deve scalare per superare 100 clienti, deve creare e utilizzare più istanze di panoramica.
Per l'applicazione delle risorse umane, il provider SaaS crea e gestisce ogni tenant con un database separato in un'istanza di Spanner.
Come mostrato nel diagramma seguente, il modello di gestione dei dati ha un tenant per database.
Il pattern di gestione dei dati del database raggiunge un isolamento logico a livello di database per i dati di tenant diversi. Tuttavia, poiché è una singola istanza Spanner, tutti i database tenant condividono la stessa configurazione regionale e la stessa configurazione di calcolo e archiviazione.
La tabella seguente illustra in che modo il pattern di gestione dei dati del database influisce sui diversi criteri.
| Criteri | Database: un tenant per pattern di gestione dei dati del database |
|---|---|
| Isolamento |
|
| Agilità |
|
| Operazioni |
|
| Scala |
|
| Prestazioni |
|
| Requisiti normativi e di conformità |
|
In sintesi, i punti principali sono:
- Vantaggio: massimo isolamento
- Svantaggio: numero limitato di tenant per istanza; uniformità della posizione
Il pattern di gestione dei dati del database è più adatto per i seguenti scenari:
- Più clienti hanno la stessa residenza, ad esempio Francia o Regno Unito, e/o rientrano nella stessa autorità normativa.
- I tenant richiedono una separazione dei dati basata sul sistema e una copia di backup/ripristino, ma anche la condivisione delle risorse dell'infrastruttura.
Schema
Nel pattern di gestione dei dati dello schema, un singolo database, che implementa un singolo schema, viene utilizzato per più tenant e un set separato di tabelle per i dati di ciascun tenant. Queste tabelle possono essere distinte includendo tenant ID nei nomi delle tabelle come prefisso o suffisso.
Questo modello di gestione dei dati di utilizzo di un set separato di tabelle per ogni tenant offre un livello di isolamento molto più basso rispetto alle opzioni precedenti (modelli di gestione di database e istanze). Inoltre, il pattern semplifica le operazioni preliminari, poiché crea nuove tabelle e l'integrità e gli indici di riferimento relativi.
Un'importante precisazione è che le autorizzazioni di accesso per Spanner tramite Identity and Access Management (IAM) vengono fornite solo a livello di istanza o database. Le autorizzazioni di accesso non possono essere specificate a livello di tabella. Esiste un limite di 5000 tabelle per database. Per molti clienti, questo limite limita il loro utilizzo dell'applicazione.
Inoltre, l'utilizzo di tabelle separate per ogni cliente può comportare un backlog di operazioni di aggiornamento dello schema di grandi dimensioni. Questo backlog richiede tempo sufficiente per la risoluzione.
Per l'applicazione delle risorse umane, il provider SaaS può creare un set di tabelle per ogni cliente con il prefisso tenant ID nei nomi delle tabelle, ad esempio customer1_employee, customer1_payroll e customer1_department.
Come mostrato nel diagramma seguente, il modello di gestione dei dati di schema ha un set di tabelle per ogni tenant.
La tabella seguente illustra in che modo il pattern di gestione dei dati dello schema influisce sui diversi criteri.
| Criteri | Schema: un set di tabelle per ogni pattern di gestione dei dati tenant |
|---|---|
| Isolamento |
|
| Agilità |
|
| Operazioni |
|
| Scala |
|
| Prestazioni |
|
| Requisiti normativi e di conformità |
|
In sintesi, i punti principali sono:
- Vantaggio: la fase di onboarding è difficile.
- Svantaggio: overhead operativo più elevato; nessun controllo di sicurezza a livello di tabella
Il pattern di gestione dei dati dello schema è più adatto per i seguenti scenari:
- Le applicazioni interne che si riferiscono a diversi reparti in cui l'isolamento rigido della sicurezza dei dati non è una questione di notevole rilievo rispetto alla facilità di manutenzione.
- Applicazioni multi-tenant in cui i dati non richiedono una separazione basata su requisiti legali o normativi.
Sebbene sia possibile creare diversi set di tabelle (ogni set che rappresenta un tenant) in un database, costituisce il pattern ideale da un punto di vista del database. La causa principale è che le tabelle devono seguire le convenzioni di denominazione. L'applicazione e qualsiasi strumentazione di database (ad esempio, IDE e strumenti di migrazione di schema) devono comprendere la convenzione di denominazione. Inoltre, se il numero di tabelle è ragionevolmente ampio per tenant, il pattern di gestione dei dati dello schema non permette una scalabilità significativa.
Un approccio migliore è quello di passare a un database per tenant e aumentare il numero di istanze oppure passare al pattern di gestione dei dati della tabella.
Tabella
Il pattern di gestione finale dei dati serve più tenant con un set comune di tabelle. Ogni tabella contiene dati per diversi tenant. Questo pattern di gestione dei dati rappresenta un livello estreme di multi-tenancy in cui ogni cosa, dall'infrastruttura allo schema, fino al modello di dati, è condivisa tra più tenant. All'interno di una tabella, le righe vengono partizionate in base alle chiavi principali e tenant ID come primo elemento della chiave. Dal punto di vista della scalabilità, Spanner supporta meglio questo pattern perché riesce a scalare le tabelle senza limitazioni.
Per l'applicazione delle risorse umane, la chiave primaria della tabella patrimoniale può essere composta da customerID e payrollID.
Come mostrato nel diagramma seguente, il modello di gestione dei dati delle tabelle ha una tabella per diversi tenant.
Analogamente al pattern schema, l'accesso ai dati nel pattern della tabella non può essere controllato separatamente per diversi tenant. Se utilizzi un numero inferiore di tabelle, le operazioni di aggiornamento degli schemi vengono completate più velocemente quando ogni tenant dispone di tabelle di database proprie. In generale, questo approccio semplifica le operazioni preliminari, l'offboarding e le operazioni.
La seguente tabella illustra come il modello di gestione dei dati delle tabelle influisce su criteri diversi.
| Criteri | Tabella: una tabella per i diversi modelli di gestione dei dati di tenant |
|---|---|
| Isolamento |
|
| Agilità |
|
| Operazioni |
|
| Scala |
|
| Prestazioni |
|
| Requisiti normativi e di conformità |
|
In sintesi, i punti principali sono:
- Vantaggio: altamente scalabile; presenta un overhead operativo basso
- Svantaggio: contenuti di alta qualità. mancanza di controlli di sicurezza per ogni tenant
Questo modello è particolarmente adatto per i seguenti scenari:
- Applicazioni interne che si occupano di diversi reparti in cui l'isolamento rigido della sicurezza dei dati non è una questione di rilievo notevole rispetto alla facilità di manutenzione.
- Condivisione massima delle risorse per i tenant che utilizzano la funzionalità delle applicazioni a livello gratuito quando si riducono al minimo il provisioning delle risorse.
Pattern di gestione dei dati e gestione del ciclo di vita dei tenant
La tabella seguente confronta i vari modelli di gestione dei dati per tutti i criteri a un livello elevato.
| Istanza | Database | Schema | Tabella | |
|---|---|---|---|---|
| Isolamento | Completate | Completate | Basso | Più basso |
| Agilità | Basso | Moderata | Moderata | Più alto |
| Facilità di gestione | Alto | Alto | Basso | Basso |
| Scala | Alto | Limitata | Potenzialmente molto limitata | Alto |
| Prestazioni* | Alto | Moderata | Moderata | Potenzialmente elevato |
| Normative e conformità | Più alto | Alto | Basso | Basso |
* Le prestazioni dipendono fortemente dal design schema e dalle best practice per le query. Questi valori sono solo un'aspettativa media.
I migliori pattern di gestione dei dati per una specifica applicazione multi-tenant sono quelli che soddisfano la maggior parte dei requisiti in base ai criteri. Se un particolare criterio non è necessario, puoi ignorare la riga in cui si trova.
Modelli di gestione dei dati combinati
Spesso un singolo pattern di gestione dei dati è sufficiente per soddisfare i requisiti di un'applicazione multi-tenant. In tal caso, la struttura può sembrare un singolo pattern di gestione dei dati.
Tuttavia, alcune applicazioni multi-tenant richiedono contemporaneamente più pattern di gestione dei dati, ad esempio un'applicazione multi-tenant che supporta un livello gratuito, un livello normale e un livello aziendale.
Livello gratuito:
- Deve essere conveniente
- Deve avere un limite superiore per il volume di dati
- Di solito supporta funzionalità limitate
- Il modello di gestione dei dati delle tabelle è un buon candidato gratuito.
- La gestione tenant è semplice
- Non è necessario creare risorse tenant specifiche o esclusive
Livello normale:
- Ideale per i clienti paganti che non hanno requisiti di scalabilità o isolamento specifici
- Il modello di gestione dei dati schema o il modello di gestione
dei dati del database sono un buon candidato regolare
- Tabelle e indici sono esclusivi per il tenant
- Il backup è facile nel pattern di gestione dei dati del database
- Il backup non è supportato per il pattern di gestione dei dati dello schema
- Il backup di tenant deve essere implementato come utilità all'esterno di Spanner
Livello enterprise:
- Generalmente un livello esclusivo con autonomia completa in tutti gli aspetti
- Tenant dispone di risorse dedicate che includono scalabilità dedicata e isolamento completo
- Il pattern di gestione dei dati delle istanze è adatto al livello aziendale
Una best practice consiste nel mantenere i diversi modelli di gestione dei dati in database diversi. Anche se è possibile combinare diversi pattern di gestione dei dati in un database Spanner, rendendo difficile l'implementazione delle operazioni di accesso e di ciclo di vita dell'applicazione.
Nella sezione Progettazione dell'applicazione sono riportate alcune considerazioni sulla progettazione delle applicazioni multi-tenant che si applicano quando si utilizza un singolo modello di gestione dei dati o diversi pattern di gestione dei dati.
Gestire il ciclo di vita di tenant
I tenant hanno un ciclo di vita. Di conseguenza, devi implementare le operazioni di gestione corrispondenti all'interno della tua applicazione multi-tenant. Oltre alle operazioni di base per la creazione, l'aggiornamento e l'eliminazione di tenant, considera le seguenti operazioni aggiuntive relative ai dati:
Esporta dati tenant:
- Quando elimini un tenant, sarebbe opportuno esportare prima i relativi dati e, se possibile, renderli disponibili al set di dati.
- Quando utilizzi il pattern di gestione dei dati della tabella o dello schema, il sistema di applicazione multi-tenant deve implementare l'esportazione o mapparlo alla funzionalità del database (esportazione del database).
Backup dei dati tenant:
- Quando utilizzi il pattern di gestione dei dati di istanza o database e esegui il backup dei dati per singoli tenant, utilizza le funzioni di esportazione o di backup del database.
- Quando si utilizza il pattern di gestione dei dati di schema o tabella e si esegue il backup dei dati per singoli tenant, l'applicazione multi-tenant deve implementare questa operazione. Il database Spanner non è in grado di determinare quali dati appartengono a un determinato tenant.
Sposta i dati tenant:
Lo spostamento di un tenant da un modello di gestione dei dati a un altro (o lo spostamento di un tenant all'interno dello stesso modello di gestione dei dati tra istanze o database) richiede l'estrazione dei dati dal pattern di gestione dei dati della tabella e l'inserimento dei dati in il pattern di gestione dei dati del database.
- Quando è possibile che si verifichino tempi di inattività delle applicazioni, esegui un'esportazione/importazione.
- Se non è possibile, esegui una migrazione del database dei tempi di inattività.
Simulare una situazione rumorosa è un altro motivo per spostare i tenant.
Progettazione delle applicazioni
Quando progetti un'applicazione multi-tenant, implementa la logica di business tenant. Questo significa che ogni volta che l'applicazione esegue una logica di business, deve sempre essere presente nel contesto di un tenant noto.
Dal punto di vista del database, la progettazione delle applicazioni fa sì che ogni query deve essere eseguita sul modello di gestione dei dati in cui risiede il tenant. Le seguenti sezioni evidenziano alcuni concetti fondamentali della progettazione di applicazioni multi-tenant.
Connessione tenant e configurazione tenant dinamica
Mappare in modo dinamico i dati tenant alle richieste di applicazioni tenant utilizza una configurazione di mappatura:
- Per i pattern di gestione dei dati del database o i pattern di gestione dei dati delle istanze, è sufficiente una stringa di connessione per accedere ai dati di un tenant.
- Per i pattern di gestione dei dati di schema, è necessario determinare i nomi corretti delle tabelle.
- Per i pattern di gestione dei dati delle tabelle, le query devono essere eseguite sul database. Utilizza i predicati appropriati per recuperare i dati di un tenant specifico.
Un tenant può risiedere in uno dei quattro modelli di gestione dei dati. La seguente implementazione di mappatura risolve una configurazione di connessione al caso generale di un'applicazione multi-tenant che utilizza tutti i pattern di gestione dei dati contemporaneamente. Quando un determinato tenant risiede in un pattern, alcune applicazioni multi-tenant utilizzano un modello di gestione dei dati per tutti i tenant. Questo caso è coperto in modo implicito dalla seguente mappatura.
Se un tenant esegue la logica di business (ad esempio un dipendente che accede con il proprio ID tenant), la logica dell'applicazione deve determinare il modello di gestione dei dati del tenant, la posizione dei dati per un determinato ID tenant e Se vuoi, la convenzione di denominazione delle tabelle (per il pattern schema).
Questa logica dell'applicazione richiede la mappatura del pattern tenant-to-data-management. Nel
esempio di codice seguente, connection string si riferisce al database in cui
si trovano i dati tenant. Il codice di esempio identifica l'istanza di Spanner e il database. Per l'istanza e il database del pattern di gestione dei dati, il codice seguente è sufficiente per consentire all'applicazione di connettersi ed eseguire query:
tenant id -> (data management pattern,
database connection string,
[table_prefix])
È necessario un design aggiuntivo per i pattern di gestione dei dati di schema e tabella.
Schema di gestione dei dati dello schema
Per il modello di gestione dei dati di schema, esistono diversi tenant all'interno dello stesso database. Ogni tenant dispone di un proprio insieme di tabelle. Le tabelle sono suddivise per nome. A quale tabella appartiene l'tenant.
Un approccio è quello di anteporre i nomi delle tabelle all'ID tenant, ad esempio, la tabella EMPLOYEE è denominata T356_EMPLOYEE per il tenant con ID 356. L'applicazione deve anteporre ogni tabella al prefisso Ttenant ID prima di inviare la query al database restituito dalla mappatura.
Un altro approccio consiste nell'antemettere un table_prefix alla mappatura utilizzata dalla query in modo da trovare le tabelle corrette per un tenant.
È possibile, inoltre, scegliere un approccio misto: se il pattern di gestione dei dati è il pattern schema e il prefisso della tabella è vuoto, viene eseguita la mappatura predefinita (premetti i nomi delle tabelle con ID tenant).
Modello di gestione dei dati della tabella
È richiesto un design simile per il modello di gestione dei dati della tabella. In questo modello c'è un unico schema. I dati di Tenant sono archiviati come righe. Per accedere correttamente ai dati, aggiungi un predicato a ogni query per selezionare il tenant appropriato.
Un approccio per trovare il tenant appropriato è avere una colonna chiamata TENANT in ogni tabella. Il valore della colonna è tenant ID. Ogni query deve aggiungere un operatore AND TENANT = tenant ID a una clausola WHERE esistente o aggiungere una clausola WHERE con il predicato AND TENANT = tenant ID.
Per connettersi al database e creare le query appropriate, l'identificatore tenant deve essere disponibile nella logica dell'applicazione. Può essere trasmesso come parametro o memorizzato come contesto del thread.
Alcune operazioni del ciclo di vita richiedono di modificare la configurazione di mappatura del modello tenant-to-data-management-pattern. Ad esempio, quando sposti un tenant tra i pattern di gestione dei dati, devi aggiornare il pattern di gestione dei dati e la stringa di connessione al database. Potrebbe anche essere necessario aggiornare il prefisso della tabella.
Generazione di query e attribuzione
Un principio fondamentale di applicazioni multi-tenant consiste nel fatto che diversi tenant possono condividere una singola risorsa cloud. I modelli di gestione dei dati precedenti rientrano in questa categoria, ad eccezione del caso in cui un singolo tenant viene allocato a una singola istanza di Spanner.
La condivisione delle risorse non si limita a condividere i dati. Anche il monitoraggio e il logging sono condivisi, ad esempio, nel pattern di gestione dei dati delle tabelle e nel modello di gestione dei dati di schema, tutte le query per tutti i tenant vengono registrate nello stesso log di controllo.
Se viene registrata una query, il testo della query deve essere esaminato per determinare quale tenant è stata eseguita. Nel modello di gestione dei dati della tabella, è necessario analizzare il predicato. Nel pattern di gestione dei dati dello schema, è necessario analizzare uno dei nomi di tabella.
Nel modello di gestione dei dati del database o nel pattern di gestione dei dati dell'istanza, il testo della query non contiene informazioni tenant. Per ottenere le informazioni del tenant per questi pattern, devi eseguire una query sulla tabella di mappatura tenant-data-management-pattern.
Sarebbe più semplice analizzare i log e le query determinando il tenant per una data query senza analizzare il testo della query. Un modo per identificare in modo uniforme un tenant per una query in tutti i pattern di gestione dei dati consiste nell'aggiungere un commento al testo della query che presenta tenant ID e (facoltativamente) un label.
La seguente query seleziona tutti i dati dei dipendenti per il tenant identificati da
TENANT 356. Per evitare di analizzare la sintassi SQL ed estrarre l'ID tenant dal predicato, l'ID tenant viene aggiunto come commento. Un commento può essere estratto
senza dover analizzare la sintassi di SQL.
select * from EMPLOYEE
-- TENANT 356
where TENANT = 'T356';
o
select * from T356_EMPLOYEE;
-- TENANT 356
Con questo progetto, ogni query eseguita per un tenant viene attribuita a tale tenant indipendentemente dal modello di gestione dei dati. Se un tenant viene spostato da un modello di gestione dei dati a un altro, il testo della query potrebbe cambiare, ma l'attribuzione rimane la stessa nel testo della query.
L'esempio di codice precedente è solo un metodo. Un altro metodo consiste nell'inserire un oggetto JSON come commento anziché come etichetta e valore:
select * from T356_EMPLOYEE;
-- {"TENANT": 356}
Operazioni del ciclo di accesso di Tenant
A seconda della tua filosofia di progettazione, un'applicazione multi-tenant può implementare direttamente le operazioni del ciclo di vita dei dati descritte in precedenza oppure creare uno strumento di amministrazione tenant separato.
Indipendentemente dalla strategia di implementazione, le operazioni del ciclo di vita potrebbero essere eseguite senza la logica dell'applicazione in esecuzione nello stesso momento, ad esempio, trasferendo un tenant da un modello di gestione dei dati a un altro, la logica dell'applicazione non può essere eseguito perché i dati non si trovano in un singolo database, Quando i dati non si trovano in un singolo database, sono necessarie due operazioni aggiuntive da un punto di vista dell'applicazione:
- Arresto di un tenant: disabilita tutto l'accesso a logica di applicazioni al fine di limitare le operazioni del ciclo di vita dei dati.
- Avvio di un tenant: la logica dell'applicazione può accedere ai dati di un tenant mentre le operazioni del ciclo di vita che interferiscono con la logica dell'applicazione vengono disabilitate.
Quando non viene usato di frequente, una chiusura del tenant di emergenza potrebbe essere un'altra operazione importante del ciclo di vita. Utilizza questa arresto se sospetti una violazione e devi consentire l'accesso completo ai dati di un tenant, non solo la logica dell'applicazione, ma anche le operazioni del ciclo di vita. Una violazione può provenire dall'interno o dall'esterno del database.
Deve essere disponibile anche un'operazione di ciclo di vita corrispondente che rimuova lo stato di emergenza. Questa operazione può richiedere a due o più amministratori di accedere contemporaneamente per implementare il controllo graduale.
Isolamento delle applicazioni
I vari pattern di gestione dei dati supportano diversi gradi di isolamento dei dati tenant. Dal livello più isolato (istanza) al livello meno isolato (tabella), sono possibili diversi gradi di isolamento.
Nel contesto di un'applicazione multi-tenant, è necessario prendere una decisione di deployment simile: tutti i tenant accedono ai propri dati (in probabilmente schemi di gestione dei dati diversi) utilizzando lo stesso deployment delle applicazioni? Ad esempio, un singolo cluster Kubernetes potrebbe supportare tutti i tenant e quando un tenant accede ai suoi dati, lo stesso cluster esegue la logica aziendale.
In alternativa, come nel caso dei pattern di gestione dei dati, diversi tenant potrebbero essere indirizzati a deployment di applicazioni diversi. I tenant di grandi dimensioni potrebbero avere accesso a un deployment di applicazioni esclusivo per loro, mentre tenant o tenant più piccoli nel livello gratuito condividono un deployment delle applicazioni.
Invece di confrontare direttamente i pattern di gestione dei dati illustrati in questo articolo con pattern di gestione dei dati delle applicazioni equivalenti, puoi utilizzare il pattern di gestione dei dati del database in modo che tutti i tenant condividano un singolo deployment di applicazione. È possibile che il pattern di gestione dei dati del database e tutti questi tenant condividano un deployment di una singola applicazione.
Il multi-tenancy è un importante pattern di gestione dei dati di progettazione di applicazioni, in particolare quando l'efficienza delle risorse svolge un ruolo fondamentale. Spanner supporta diversi pattern di gestione dei dati, da utilizzare per implementare le applicazioni multi-tenant. Con la notevole scalabilità e gli rigorosi SLA di Spanner, il database è un database ideale per i deployment di applicazioni multi-tenant di grandi dimensioni.
Passaggi successivi
- Esplora le architetture di riferimento, i diagrammi, i tutorial e le best practice su Google Cloud. Dai un'occhiata al nostro Cloud Architecture Center.