In questo documento vengono descritti vari modi per implementare la multi-tenancy in Cloud Spanner. Illustra anche i pattern di gestione dei dati e la gestione del ciclo di vita dei tenant.
Multi-tenant è quando una o alcune istanze di un'applicazione software servono più tenant o clienti. Questo pattern software può scalare da un singolo tenant o cliente a centinaia o migliaia. Questo approccio è fondamentale per le piattaforme di cloud computing in cui l'infrastruttura sottostante è condivisa tra più organizzazioni.
Pensare alla multi-tenancy come a una forma di partizionamento basata su risorse di calcolo condivise, come i database. Un'analogia è il tenant in un condominio: infrastruttura condivisa, ma spazio tenant dedicato. La multi-tenancy fa parte della maggior parte delle applicazioni Software-as-a-Service (SaaS), se non tutte.
Questo documento è destinato agli architetti di database, data engineer e a tecnici che implementano applicazioni multi-tenant in Spanner come database relazionale. In questo contesto, delinea vari approcci per archiviare i dati multi-tenant. I termini "tenant" e "cliente" e "organizzazione" vengono utilizzati in modo intercambiabile nell'intero articolo per indicare l'entità che accede all'applicazione multi-tenant.
Questo articolo utilizza un provider SaaS delle risorse umane (HR) che implementa la sua applicazione multi-tenant su Google Cloud come esempio. Nell'esempio, diversi clienti del provider HR SaaS devono accedere all'applicazione multi-tenant. Questi clienti vengono chiamati tenant.
SPANer è il database completamente gestito, di livello aziendale, distribuito e coerente di Google Cloud, che combina i vantaggi del modello di database relazionale con la scalabilità orizzontale non relazionale. Spanner ha una semantica relazionale con schemi, tipi di dati applicati, elevata coerenza, transazioni ACID con più dichiarazioni e un linguaggio di query SQL che implementa ANSI 2011 SQL.
Spanner offre un tempo di inattività zero per la manutenzione pianificata o guasti regionali, con uno SLA di disponibilità del 99,999%. Supporta applicazioni moderne e multi-tenant offrendo disponibilità elevata e scalabilità. Questo articolo illustra i diversi approcci all'architettura per implementare la multi-tenancy con Spanner.
Criteri per la mappatura dei dati del tenant
In un'applicazione multi-tenant, i dati di ogni tenant sono isolati in uno dei vari approcci di 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 si trova esclusivamente in un'istanza Spanner, con esattamente un database per quel tenant.
- Database: un tenant si trova in un database in un'unica istanza Spanner che contiene più database.
- Schema: un tenant si trova in tabelle esclusive all'interno di un database, mentre diversi tenant possono trovarsi nello stesso database.
- Tabella: i dati tenant sono righe nelle tabelle di database. Le tabelle sono condivise con altri tenant.
I criteri precedenti sono chiamati pattern di gestione dei dati e sono illustrati in dettaglio nella sezione Pattern di gestione dei dati multi-tenancy. Tale discussione si basa sui seguenti criteri:
- Isolamento: il grado di isolamento dei dati tra più tenant è un fattore determinante per la multi-tenancy. L'isolamento è determinato dalle scelte effettuate per i criteri in altre categorie, ad esempio determinati requisiti normativi e di conformità possono stabilire un grado di isolamento più elevato.
- Agilità: la facilità di onboarding e di onboarding di un tenant in relazione alla creazione di un'istanza, un database o una tabella.
- Operazioni: la disponibilità o la complessità dell'implementazione di attività gestionali e di amministrazione tipiche specifiche del tenant, ad esempio manutenzione regolare, logging, backup o operazioni di ripristino di emergenza.
- Scalabilità: la capacità di scalare senza interruzioni per consentire una crescita futura. La descrizione di ogni pattern contiene il numero di tenant che può essere supportato dal pattern.
- Prestazioni: la capacità di allocare risorse esclusive a ogni tenant, risolvere il fenomeno del vicino rumoroso nelle vicinanze e abilitare prestazioni prevedibili di lettura e scrittura per ogni tenant.
- Normative e conformità: la possibilità di soddisfare i requisiti di settori e paesi altamente regolamentati che richiedono l'isolamento completo delle risorse e le operazioni di manutenzione, ad esempio i requisiti per la residenza dei dati per la Francia, richiedono che le informazioni personali siano archiviate esclusivamente in Francia.
Ogni modello di gestione dei dati in relazione a questi criteri è descritto in dettaglio nella sezione successiva. Utilizza gli stessi criteri quando selezioni un pattern di gestione dei dati per un insieme 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 dell'istanza archivia i dati di ogni tenant in una propria istanza e database di Spanner. Un'istanza di Spanner può avere uno o più database. In questo pattern viene creato un solo database. Per l'applicazione HR descritta in precedenza, viene creata un'istanza Separatore con un database per ogni organizzazione del cliente.
Come mostrato nel diagramma seguente, il pattern di gestione dei dati ha un tenant per istanza.
Avere istanze distinte per ogni tenant consente l'utilizzo di progetti Google Cloud separati per raggiungere limiti di attendibilità separati per i diversi tenant. Un vantaggio aggiuntivo è che la configurazione di ogni istanza può essere scelta in base alla località di ogni tenant (a livello di area geografica o a livello di più aree geografiche), ottimizzando la flessibilità e le prestazioni della località.
L'architettura è facilmente scalabile in qualsiasi numero di tenant. I provider di servizi SaaS possono creare qualsiasi numero di istanze nelle aree geografiche desiderate, senza limiti rigidi.
La tabella seguente illustra in che modo il pattern di gestione dei dati dell'istanza influisce su criteri diversi.
| Criteri | Istanza: un tenant per pattern di gestione dei dati per istanza |
|---|---|
| Isolamento |
|
| Agilità |
|
| Suite operativa |
|
| Scalabilità |
|
| Prestazioni |
|
| Requisiti normativi e di conformità |
|
In breve, i concetti chiave sono:
- Vantaggio: il massimo livello di isolamento
- Svantaggio: sovraccarico operativo massimo
Il pattern di gestione dei dati dell'istanza è più adatto per i seguenti scenari:
- Diversi inquilini sono distribuiti in una vasta 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 protocolli di sicurezza e di controllo.
- Le dimensioni dei tenant variano notevolmente, in modo tale che la condivisione delle risorse tra tenant ad alto volume e traffico elevato potrebbe causare contese e deterioramento reciproco.
Database
Nel pattern di gestione dei dati del database, ogni tenant si trova in un database all'interno di una singola istanza Spanner. Più database possono risiedere 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 fisso di 100 database per istanza. Questo limite significa che, se il provider SaaS deve scalare oltre 100 clienti, deve creare e utilizzare più istanze Spanner.
Per l'applicazione HR, il provider SaaS crea e gestisce ogni tenant con un database separato in un'istanza Spanner.
Come mostrato nel diagramma seguente, il pattern 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 dati diversi di tenant. Tuttavia, poiché si tratta di una singola istanza di Spanner, tutti i database tenant condividono la stessa configurazione a livello di area geografica e la configurazione di calcolo e archiviazione sottostante.
La tabella seguente illustra in che modo il pattern di gestione dei dati del database influisce su criteri diversi.
| Criteri | Database: un tenant per pattern di gestione dei dati del database |
|---|---|
| Isolamento |
|
| Agilità |
|
| Suite operativa |
|
| Scalabilità |
|
| Prestazioni |
|
| Requisiti normativi e di conformità |
|
In breve, i concetti chiave sono:
- Vantaggio: livello di isolamento più elevato
- Contro: numero limitato di tenant per istanza; flessibilità di località
Il pattern di gestione dei dati del database è più adatto per i seguenti scenari:
- Più clienti risiedono nella stessa residenza dei dati, ad esempio in Francia o nel Regno Unito, e/o sono sotto la stessa autorità di regolamentazione.
- I tenant richiedono la separazione dei dati basata sul sistema e il backup/ripristino, ma sono compatibili con la condivisione delle risorse dell'infrastruttura.
Schema
Nel pattern di gestione dei dati dello schema, per più tenant viene utilizzato un singolo database, che implementa uno schema singolo, e un set di tabelle separato per ogni dato del tenant. Puoi distinguere queste tabelle includendo
tenant ID nei nomi delle tabelle come prefisso o suffisso.
Questo pattern di gestione dei dati dell'utilizzo di un set separato di tabelle per ogni tenant fornisce un livello di isolamento molto più basso rispetto alle opzioni precedenti (i pattern di gestione di istanze e database). Il pattern semplifica anche le operazioni preliminari, prevede la creazione di nuove tabelle e l'integrità referenziale e gli indici associati.
Un'importante avvertenza è che le autorizzazioni di accesso per Spanner mediante Identity and Access Management (IAM) vengono fornite solo a livello di istanza o di database. Non è possibile fornire autorizzazioni di accesso a livello di tabella. Esiste anche un limite di 5000 tabelle per database. Per molti clienti questo limite limita l'utilizzo dell'applicazione.
Inoltre, l'uso di tabelle separate per ogni cliente può comportare un elevato backlog di operazioni di aggiornamento dello schema. Un backlog così lungo richiede un lungo tempo di risoluzione.
Per l'applicazione HR, il provider SaaS può creare un set di tabelle per ogni
cliente con tenant ID come prefisso nei nomi delle tabelle, ad esempio
customer1_employee, customer1_payroll, customer1_department.
Come mostrato nel diagramma seguente, il pattern di gestione dei dati dello 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 in tenant |
|---|---|
| Isolamento |
|
| Agilità |
|
| Suite operativa |
|
| Scalabilità |
|
| Prestazioni |
|
| Requisiti normativi e di conformità |
|
In breve, i concetti chiave sono:
- Vantaggio: l'onboarding è banale
- Svantaggio: sovraccarico operativo maggiore, nessun controllo di sicurezza a livello di tabella
Il pattern di gestione dei dati dello schema è più adatto per i seguenti scenari:
- Applicazioni interne adatte a diversi reparti in cui il rigoroso isolamento della sicurezza dei dati non è un problema rilevante rispetto alla facilità di manutenzione.
- Applicazioni multi-tenant in cui i dati non richiedono una rigida separazione in base a requisiti legali o normativi.
Sebbene sia possibile creare più set di tabelle (ogni set che rappresenta un tenant) in un database, è il pattern meno ideale dal punto di vista del database. Il motivo principale è che le tabelle devono seguire le convenzioni di denominazione. L'applicazione e gli strumenti di database (ad esempio gli IDE e gli strumenti di migrazione dello schema) devono comprendere la convenzione di denominazione. Inoltre, se il numero di tabelle è abbastanza grande per tenant, il pattern di gestione dei dati dello schema non fornisce scalabilità significativa.
Un approccio migliore consiste nel 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 finale di gestione dei dati gestisce più tenant con un set comune di tabelle. Ogni tabella contiene i dati di diversi tenant. Questo pattern di gestione dei dati rappresenta un livello estremo di multi-tenancy, in cui tutto, dall'infrastruttura allo schema al modello dei dati, viene condiviso tra più tenant. All'interno di una tabella, le righe sono partizionate in base alle chiavi primarie, con tenant ID come primo elemento della chiave. Per quanto riguarda la scalabilità, Spanner supporta meglio questo pattern perché è in grado di scalare le tabelle senza limitazioni.
Per l'applicazione HR, la chiave primaria della tabella dei libri paga può essere una combinazione di
customerID e payrollID.
Come mostrato nel diagramma seguente, il pattern di gestione dei dati della tabella ha una tabella per diversi tenant.
Analogamente al pattern schema, l'accesso ai dati nel pattern della tabella non può essere controllato separatamente per tenant diversi. Se utilizzi meno tabelle, le operazioni di aggiornamento dello schema vengono completate più velocemente quando ogni tenant ha le proprie tabelle di database. In larga misura, questo approccio semplifica le operazioni preliminari, offboarding e operazioni.
La tabella seguente illustra in che modo il pattern di gestione dei dati della tabella influisce su criteri diversi.
| Criteri | Tabella: una tabella per lo schema di gestione dei dati di più tenant |
|---|---|
| Isolamento |
|
| Agilità |
|
| Suite operativa |
|
| Scalabilità |
|
| Prestazioni |
|
| Requisiti normativi e di conformità |
|
In breve, i concetti chiave sono:
- Vantaggio: scalabilità elevata; costi operativi ridotti
- Svantaggio: livello elevato di risorse, mancanza di controlli di sicurezza per ogni tenant
Questo pattern è più adatto per i seguenti scenari:
- Applicazioni interne destinate a reparti diversi, in cui la massima isolamento dei dati non è di per sé importante rispetto alla facilità di manutenzione.
- Condivisione massima delle risorse per i tenant che utilizzano la funzionalità dell'applicazione di livello gratuito riducendo contemporaneamente il provisioning delle risorse.
Pattern di gestione dei dati e gestione del ciclo di vita dei tenant
La tabella seguente mette a confronto i vari modelli di gestione dei dati di tutti i criteri a un livello generale.
| Istanza | Database | Schema | Tabella | |
|---|---|---|---|---|
| Isolamento | Completata | Completata | Basse | Più bassa |
| Agilità | Basse | Moderata | Moderata | Posizione più alta |
| Facilità operative | Alte | Alte | Basse | Basse |
| Scala | Alte | Limitata | Potenzialmente molto limitato | Alte |
| Prestazioni* | Alte | Moderata | Moderata | Potenzialmente alto |
| Norme e conformità | Posizione più alta | Alte | Basse | Basse |
* Le prestazioni dipendono fortemente dalla progettazione dello schema e dalle best practice per le query. I valori riportati sono solo un'aspettativa media.
I pattern di gestione dei dati migliori per un'applicazione multi-tenant specifica sono quelli che soddisfano la maggior parte dei suoi requisiti in base ai criteri. Se non è richiesto un criterio particolare, puoi ignorare la riga in cui è inserito.
Pattern di gestione dei dati combinati
Spesso, è sufficiente un singolo pattern di gestione dei dati per soddisfare i requisiti di un'applicazione multi-tenant. In questo caso, la progettazione può assumere un singolo pattern di gestione dei dati.
Alcune applicazioni multi-tenant richiedono, invece, diversi pattern di gestione dei dati contemporaneamente, 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 della tabella è un buon candidato di livello gratuito
- La gestione dell'inquilino è semplice
- Non è necessario creare risorse tenant specifiche o esclusive
Livello normale:
- Utile per i clienti paganti che non hanno requisiti di scalabilità o isolamento specifici
- Il pattern di gestione dei dati dello schema o il pattern di gestione dei dati del database è un buon candidato di livello 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 del tenant deve essere implementato come utilità al di fuori di Spanner
Livello Enterprise:
- Solitamente un livello esclusivo con completa autonomia sotto tutti gli aspetti
- Lo tenant ha risorse dedicate che includono scalabilità dedicata e isolamento completo
- Il pattern di gestione dei dati dell'istanza è adatto al livello aziendale
Una best practice consiste nel mantenere pattern di gestione dei dati diversi in database diversi. Sebbene sia possibile combinare diversi modelli di gestione dei dati in un database Spanner, rendendo difficile l'implementazione della logica di accesso e delle operazioni del ciclo di vita dell'applicazione.
La sezione Progettazione applicazione illustra alcune considerazioni sulla progettazione di applicazioni multi-tenant che si applicano quando si utilizza un singolo pattern di gestione dei dati o più pattern di gestione dei dati.
Gestisci il ciclo di vita del tenant
Gli inquilini hanno un ciclo di vita. Di conseguenza, devi implementare le operazioni di gestione corrispondenti all'interno dell'applicazione multi-tenant. Oltre alle operazioni di base per la creazione, l'aggiornamento e l'eliminazione dei tenant, prendi in considerazione le seguenti operazioni aggiuntive relative ai dati:
Esporta i dati del tenant:
- Quando elimini un tenant, è buona norma esportare prima i dati e rendere disponibile il set di dati.
- Quando utilizzi il pattern di gestione dei dati della tabella o dello schema, il sistema multi-tenant deve implementare l'esportazione o mapparlo alla funzionalità di database (esportazione del database).
Backup dei dati del tenant:
- Quando utilizzi i pattern di gestione dei dati dell'istanza o del database e il backup dei dati per i singoli tenant, utilizza le funzioni di esportazione o backup del database.
- Quando utilizzi il pattern di gestione dei dati di schema o tabella e il backup dei dati per singoli tenant, l'applicazione multi-tenant deve implementare questa operazione. Il database di Spanner non può determinare quali dati appartengono a quale tenant.
Sposta dati tenant:
Lo spostamento di un tenant da un pattern di gestione dei dati a un altro (o lo spostamento di un tenant all'interno dello stesso pattern di gestione dei dati tra istanze o database) richiede l'estrazione dei dati dal pattern di gestione dei dati della tabella e l'inserimento di tali dati nel pattern di gestione dei dati del database.
- Quando è possibile il tempo di inattività dell'applicazione, esegui un'esportazione/importazione.
- Quando il tempo di inattività non è possibile, esegui una migrazione dei database per tempo di inattività.
La mitigazione di una situazione di rumore nelle vicinanze è un altro motivo per spostare gli inquilini.
Progettazione di applicazioni
Quando progetti un'applicazione multi-tenant, implementa la logica di business sensibile al tenant. Ciò significa che ogni volta che l'applicazione esegue la logica di business, deve sempre essere nel contesto di un tenant noto.
Dal punto di vista del database, la progettazione di applicazioni significa che ogni query deve essere eseguita in base al pattern di gestione dei dati in cui risiede il tenant. Le seguenti sezioni evidenziano alcuni dei concetti principali della progettazione di applicazioni multi-tenant.
Connessione dinamica tenant e configurazione delle query
Per la mappatura dinamica dei dati tenant alle richieste di applicazioni tenant, viene utilizzata una configurazione di mappatura:
- Per i pattern di gestione dei dati del database o i pattern di gestione dei dati delle istanze, una stringa di connessione è sufficiente per accedere ai dati di un tenant.
- Per i pattern di gestione dei dati degli schemi, è necessario determinare i nomi delle tabelle corretti.
- Per i pattern di gestione dei dati della tabella, 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 qualsiasi dei quattro pattern di gestione dei dati. La seguente implementazione della mappatura risolve una configurazione di connessione per il caso generico di un'applicazione multi-tenant che utilizza contemporaneamente tutti i pattern di gestione dei dati. Quando un determinato tenant risiede in un pattern, alcune applicazioni multi-tenant utilizzano un pattern di gestione dati per tutti i tenant. Questa richiesta viene coperta implicitamente 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 pattern di gestione dei dati del tenant, la posizione dei dati per un determinato ID tenant e, facoltativamente, la convenzione di denominazione della tabella (per il pattern schema).
Questa logica dell'applicazione richiede la mappatura dei pattern da tenant a gestione dei dati. Nel seguente esempio di codice, connection string fa riferimento al database in cui si trovano i dati del tenant. L'esempio identifica l'istanza di Spanner e il database. Per l'istanza e il database per lo schema di gestione dei dati, il seguente codice è sufficiente per consentire all'applicazione di connettersi ed eseguire query:
tenant id -> (data management pattern,
database connection string,
[table_prefix])
Per gli schemi di gestione dei dati di schema e tabella è richiesta una progettazione aggiuntiva.
Pattern di gestione dei dati dello schema
Per lo schema di gestione dei dati dello schema, esistono diversi tenant nello stesso database. Ogni tenant ha il proprio set di tabelle. Le tabelle sono distinte dal nome. Quale tabella appartiene a quale tenant è deterministico.
Un approccio consiste nell'anteporre i nomi delle tabelle con l'ID tenant, ad esempio la tabella EMPLOYEE è chiamata T356_EMPLOYEE per il tenant con ID 356. L'applicazione deve anteporre a ogni tabella il prefisso Ttenant ID prima di inviare la query al database restituito.
Un altro approccio è anteporre un table_prefix alla mappatura utilizzata dalla query in modo che trovi le tabelle corrette per un tenant.
È possibile anche utilizzare un approccio misto: se il pattern di gestione dei dati è il pattern dello schema e il prefisso della tabella è vuoto, viene applicata la mappatura predefinita (anteponi i nomi delle tabelle con ID tenant).
Pattern di gestione dei dati della tabella
Un pattern simile è obbligatorio per il pattern di gestione dei dati della tabella. In questo motivo, c'è un unico schema. I dati degli inquilini vengono 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 è quello di avere una colonna chiamata TENANT in ogni tabella. Il valore della colonna è tenant ID. Ogni query deve aggiungere un predicato 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 trasmessa come parametro o archiviata come contesto del thread.
Alcune operazioni del ciclo di vita richiedono la modifica della configurazione della mappatura "tenant-to-data-management-pattern", ad esempio quando si sposta un tenant tra i pattern di gestione dei dati, è necessario aggiornare il pattern di gestione dei dati e la stringa di connessione del database. Potrebbe anche essere necessario aggiornare il prefisso della tabella.
Generazione di query e attribuzione
Un principio fondamentale delle applicazioni multi-tenant è che diversi tenant possono condividere una singola risorsa cloud. I pattern di gestione dei dati precedenti rientrano in questa categoria, tranne nel caso in cui un singolo tenant sia assegnato a una singola istanza di Spanner.
La condivisione delle risorse va oltre la condivisione dei dati. Vengono inoltre condivisi monitoraggio e logging, ad esempio nel modello di gestione dei dati della tabella e nel modello di gestione dei dati dello schema, tutte le query per tutti i tenant vengono registrate nello stesso log di controllo.
Se una query viene registrata, il testo della query deve essere esaminato per determinare per quale tenant è stata eseguita la query. Nel pattern di gestione dei dati della tabella, devi analizzare il predicato. Nel pattern di gestione dei dati dello schema, devi analizzare uno dei nomi della tabella.
Nel pattern di gestione dei dati del database o nel modello di gestione dei dati dell'istanza, il testo della query non contiene informazioni del tenant. Per ottenere informazioni sul tenant per questi pattern, devi eseguire una query sulla tabella di mappatura tenant-to-data-management-pattern.
Sarebbe più semplice analizzare log e query determinando il tenant per una determinata query senza analizzare il testo della query. Un modo per identificare uniformemente un tenant per una query in tutti i pattern di gestione dei dati consiste nell'aggiungere un commento al testo della query con tenant ID e, facoltativamente, un label.
La query seguente seleziona tutti i dati dei dipendenti per il tenant identificato da
TENANT 356. Per evitare di analizzare la sintassi SQL e di estrarre l'ID tenant dal predicato, l'ID tenant viene aggiunto come commento. Un commento può essere estratto senza dover analizzare la sintassi 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 è attribuita a quel tenant indipendentemente dal pattern di gestione dei dati. Se un tenant è spostato da un pattern di gestione dati a un altro, il testo della query potrebbe cambiare, ma l'attribuzione rimane invariata.
L'esempio di codice precedente è un solo metodo. Un altro metodo è inserire un oggetto JSON come commento anziché un'etichetta e un valore:
select * from T356_EMPLOYEE;
-- {"TENANT": 356}
Operazioni del ciclo di vita dell'accesso inquilini
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 o creare uno strumento di amministrazione tenant separato.
Indipendentemente dalla strategia di implementazione, le operazioni del ciclo di vita potrebbero dover essere eseguite senza la logica dell'applicazione in esecuzione, ad esempio durante lo spostamento di un tenant da un pattern di gestione dei dati a un altro, la logica dell'applicazione non può essere eseguita perché i dati non sono in un unico database. Quando i dati non sono in un unico database, sono necessarie due operazioni aggiuntive dal punto di vista dell'applicazione:
- Arresto di un tenant: disabilita tutti gli accessi alla logica dell'applicazione mentre consente l'esecuzione delle 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 interferisce con la logica dell'applicazione sono disabilitate.
Sebbene non vengano utilizzati spesso, la chiusura di un tenant di emergenza potrebbe essere un'altra operazione importante del ciclo di vita. Utilizza questa disattivazione quando sospetti una violazione e devi vietare ogni accesso 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 del ciclo di vita corrispondente che rimuove lo stato di emergenza. Questa operazione può richiedere che due o più amministratori accedano contemporaneamente per implementare il controllo reciproco.
Isolamento delle applicazioni
I vari pattern di gestione dei dati supportano gradi diversi di isolamento dei dati tenant. Dal livello più isolato (istanza) al livello meno isolato (tabella) sono possibili diversi livelli di isolamento.
Nel contesto di un'applicazione multi-tenant, è necessario prendere una decisione di deployment simile: tutti i tenant accedono ai propri dati (in potenziali modelli di gestione dei dati) utilizzando lo stesso deployment di applicazioni? Ad esempio, un singolo cluster Kubernetes potrebbe supportare tutti i tenant e, quando un tenant accede ai propri dati, lo stesso cluster esegue la logica di business.
In alternativa, come per i pattern di gestione dei dati, i tenant diversi possono essere indirizzati a deployment di applicazioni differenti. I tenant di grandi dimensioni potrebbero avere accesso a un deployment di applicazioni esclusivo, mentre i tenant più piccoli o di livello inferiore condividono il deployment di un'applicazione.
Anziché utilizzare direttamente i pattern di gestione dei dati illustrati in questo articolo con i pattern di gestione dei dati dell'applicazione equivalenti, puoi utilizzare il pattern di gestione dei dati del database in modo che tutti i tenant condividano una singola implementazione dell'applicazione. È possibile che il pattern di gestione dei dati del database sia condiviso da tutti i tenant.
La multi-tenancy è un modello di gestione dei dati per la progettazione e l'applicazione importante, soprattutto quando l'efficienza delle risorse svolge un ruolo fondamentale. Spanner supporta diversi modelli di gestione dei dati, lo utilizza per implementare applicazioni multi-tenant. Grazie all'estrema scalabilità e agli SLA (accordi sul livello del servizio) di Spanner, è un database ideale per i deployment di applicazioni multi-tenant di grandi dimensioni.
Passaggi successivi
- Esplora architetture di riferimento, diagrammi, tutorial e best practice su Google Cloud. Dai un'occhiata al nostro Cloud Architecture Center.