Questo documento descrive vari modi per implementare la multitenancy in Cloud Spanner. Illustra anche i modelli di gestione dei dati e la gestione del ciclo di vita dei tenant.
La tenancy si verifica quando una o più 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.
Pensa alla multitenancy come a una forma di partizionamento basato su risorse di computing condivise, come i database. Un'analogia è il tenant in un condominio: infrastruttura condivisa, ma spazio tenant dedicato. La multitenancy fa parte della maggior parte delle applicazioni Software-as-a-Service (SaaS), se non tutte.
Questo documento è rivolto a database architect, data architect e engineer che implementano applicazioni multi-tenant su Spanner come loro database relazionale. Questo contesto illustra vari approcci per l'archiviazione dei dati multi-tenant. I termini "tenant", "customer" e "organization" sono usati in modo intercambiabile in tutto l'articolo per indicare l'entità che accede all'applicazione multi-tenant.
In questo articolo viene utilizzato 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 Sa SaS HR devono accedere all'applicazione multi-tenant. Questi clienti vengono chiamati tenant.
Spanner è il database di Google Cloud completamente gestito, di livello aziendale, distribuito e coerente 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 SQL ANSI 2011.
Spanner offre tempi di inattività pari a zero per errori di manutenzione pianificata o regione, con uno SLA disponibile del 99,999%. Supporta applicazioni moderne multi-tenant fornendo disponibilità e scalabilità elevate. Questo articolo illustra i diversi approcci all'architettura per implementare la multitenancy 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 diversi approcci di architettura nel database Spanner sottostante. L'elenco seguente illustra i diversi approcci dell'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 risiede in un database in una singola istanza di Spanner contenente più database.
- Schema: un tenant si trova in tabelle esclusive all'interno di un database, mentre diversi tenant si trovano nello stesso database.
- Tabella: i dati tenant sono righe nelle tabelle del database. Le tabelle sono condivise con altri tenant.
I criteri precedenti sono chiamati pattern di gestione dei dati e sono discussi 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 tra più tenant è una considerazione importante per la multitenancy. L'isolamento è determinato dalle scelte effettuate per i criteri in altre categorie, ad esempio determinati requisiti normativi e di conformità possono richiedere un maggior grado di isolamento.
- Agilità: la facilità di attività di onboarding e offboarding per un tenant in relazione alla creazione di un'istanza, un database o una tabella.
- Operazioni: la disponibilità o la complessità dell'implementazione di operazioni tipiche e specifiche del tenant e delle attività di amministrazione del database, ad esempio manutenzione regolare, logging, backup o operazioni di ripristino di emergenza.
- Scalabilità: la possibilità di scalare senza problemi per consentire la crescita futura. La descrizione di ogni pattern contiene il numero di tenant che il pattern può supportare.
- Prestazioni: la possibilità di allocare risorse esclusive a ogni tenant, risolvere il problema del nossiy Neighbor e abilitare prestazioni di lettura e scrittura prevedibili 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 relativi alla residenza dei dati per la Francia, richiedono che le informazioni che consentono l'identificazione personale siano archiviate fisicamente esclusivamente in Francia.
Ogni pattern di gestione dei dati correlato a questi criteri è descritto 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 multitenancy
Le seguenti sezioni descrivono i quattro pattern di gestione dei dati principali: 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 nella propria istanza Spanner e nel proprio database. Un'istanza di Spanner può avere uno o più database. In questo pattern viene creato un solo database. Per l'applicazione HR discussa in precedenza, viene creata un'istanza di Spanner separata con un database per ciascuna organizzazione del cliente.
Come mostrato nel diagramma seguente, il pattern di gestione dei dati ha un tenant per istanza.
La presenza di istanze separate per ogni tenant consente l'utilizzo di progetti Google Cloud separati per raggiungere limiti di attendibilità separati per i tenant diversi. Un ulteriore vantaggio è che la configurazione di ogni istanza può essere scelta in base alla località di ogni tenant (a livello di una o più aree geografiche), ottimizzando la flessibilità e le prestazioni della località.
L'architettura può essere facilmente scalata a un numero qualsiasi di tenant. I provider di SaaS possono creare un numero qualsiasi di istanze nelle regioni desiderate, senza limiti rigidi.
La seguente tabella mostra in che modo il pattern di gestione dei dati dell'istanza influisce sui diversi criteri.
| Criteri | Istanza: un pattern di gestione dei dati per tenant per istanza |
|---|---|
| Isolamento |
|
| Agilità |
|
| Suite operativa |
|
| Scala |
|
| Prestazioni |
|
| Requisiti normativi e di conformità |
|
In breve, i punti chiave sono:
- Vantaggio:il più alto livello di isolamento
- Svantaggio: sovraccarico operativo massimo
Il pattern di gestione dei dati dell'istanza è più adatto per i seguenti scenari:
- Diversi tenant sono distribuiti in un'ampia gamma di regioni e richiedono una soluzione localizzata.
- I requisiti normativi e di conformità per alcuni tenant richiedono livelli più elevati di protocolli di sicurezza e controllo.
- Le dimensioni degli inquilini variano in modo significativo, tanto che la condivisione delle risorse tra tenant ad alto volume e con traffico elevato potrebbe causare contese e degrado 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 un'unica istanza. Se un'istanza non è sufficiente per il numero di tenant, crea più istanze. Questo pattern implica 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 l'isolamento logico a livello di database per i dati di tenant diversi. Tuttavia, poiché si tratta di una singola istanza di Spanner, tutti i database tenant condividono la stessa configurazione a livello di regione e la configurazione di archiviazione e calcolo sottostante.
La seguente tabella mostra in che modo il pattern di gestione dei dati del database influisce sui diversi criteri.
| Criteri | Database: un pattern di tenant per la gestione dei dati del database |
|---|---|
| Isolamento |
|
| Agilità |
|
| Suite operativa |
|
| Scala |
|
| Prestazioni |
|
| Requisiti normativi e di conformità |
|
In breve, i punti chiave sono:
- Vantaggio: livello di isolamento più elevato
- Svantaggio: numero limitato di tenant per istanza; inflessibilità della 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 Francia o Regno Unito, e/o sono soggetti alla stessa autorità di regolamentazione.
- I tenant richiedono la separazione dei dati basata sul sistema e il backup/ripristino, ma sono accurati 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 un unico schema, e viene utilizzato un set separato di tabelle per i dati di ogni tenant. È possibile distinguere queste tabelle includendo
tenant ID nei nomi delle tabelle come prefisso o suffisso.
Questo pattern di gestione dei dati che utilizza 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à e gli indici di riferimento associati.
Un aspetto importante è il fatto che le autorizzazioni di accesso per Spanner tramite Identity and Access Management (IAM) vengono fornite solo a livello di istanza o database. Non è possibile fornire le 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'utilizzo di tabelle separate per ciascun cliente può comportare un grande backlog di operazioni di aggiornamento dello schema. La risoluzione di questo backlog richiede molto tempo.
Per l'applicazione HR, il provider SaaS può creare una serie 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 seguente tabella mostra 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 del tenant |
|---|---|
| Isolamento |
|
| Agilità |
|
| Suite operativa |
|
| Scala |
|
| Prestazioni |
|
| Requisiti normativi e di conformità |
|
In breve, i punti 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 destinate a reparti diversi in cui l'isolamento di sicurezza dei dati rigoroso non è un problema di rilievo rispetto alla facilità di manutenzione.
- Applicazioni multi-tenant in cui i dati non richiedono una separazione rigorosa in base a requisiti legali o normativi.
Sebbene sia possibile creare diversi set di tabelle (ognuno 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, IDE e strumenti di migrazione dello schema) devono comprendere la convenzione di denominazione. Inoltre, se il numero di tabelle è ragionevolmente elevato per tenant, il pattern di gestione dei dati dello schema non fornisce una 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 insieme comune di tabelle. Ogni tabella contiene dati relativi a diversi tenant. Questo pattern di gestione dei dati rappresenta un livello estremo di multitenancy in cui ogni cosa, dall'infrastruttura allo schema al modello dei dati, viene condivisa tra più tenant. All'interno di una tabella, le righe vengono partizionate in base alle chiavi primarie, con tenant ID come primo elemento della chiave. Dal punto di vista della scalabilità, Spanner supporta meglio questo pattern perché può scalare le tabelle senza limitazioni.
Per l'applicazione HR, la chiave primaria della tabella buste 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 dello 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, l'onboarding e l'offboarding.
La seguente tabella illustra in che modo il pattern di gestione dei dati della tabella influisce sui diversi criteri.
| Criteri | Tabella: una tabella per il pattern di gestione dei dati di diversi tenant |
|---|---|
| Isolamento |
|
| Agilità |
|
| Suite operativa |
|
| Scala |
|
| Prestazioni |
|
| Requisiti normativi e di conformità |
|
In breve, i punti chiave sono:
- Vantaggio: alta scalabilità, carico di lavoro operativo ridotto
- Svantaggio: elevata contesa delle risorse; mancanza di controlli di sicurezza per ogni tenant
Questo pattern è adatto alle seguenti situazioni:
- Applicazioni interne destinate a reparti diversi, in cui l'isolamento della sicurezza dei dati non è un problema rilevante rispetto alla facilità di manutenzione.
- Condivisione massima delle risorse per i tenant che utilizzano la funzionalità delle applicazioni di livello gratuito quando riduci al minimo il provisioning delle risorse contemporaneamente.
Modelli di gestione dei dati e gestione del ciclo di vita dei tenant
Nella tabella seguente sono riportati a livello generale i vari modelli di gestione dei dati per tutti i criteri.
| Istanza | Database | Schema | Tabella | |
|---|---|---|---|---|
| Isolamento | Completata | Completata | Bassi | Più bassa |
| Agilità | Bassi | Moderata | Moderata | Più alta |
| Facilità d'uso | Alti | Alti | Bassi | Bassi |
| Scala | Alti | Limitata | Potenzialmente molto limitato | Alti |
| Rendimento* | Alti | Moderata | Moderata | Potenzialmente alto |
| Normative e conformità | Più alta | Alti | Bassi | Bassi |
* Le prestazioni dipendono fortemente dalla progettazione dello schema e dalle best practice per le query. I valori riportati qui rappresentano solo un'aspettativa media.
I pattern di gestione dei dati migliori per una specifica applicazione multi-tenant sono quelli che soddisfano la maggior parte dei requisiti in base ai criteri. Se non è richiesto un criterio particolare, puoi ignorare la riga in cui si trova.
Pattern combinati di gestione dei dati
Spesso, un singolo pattern di gestione dei dati è sufficiente per soddisfare i requisiti di un'applicazione multi-tenant. In questo caso, il progetto può assumere un singolo pattern di gestione dei dati.
Tuttavia, alcune applicazioni multi-tenant richiedono più 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 dei dati
- Di solito supporta funzionalità limitate
- Il modello di gestione dei dati della tabella è un buon candidato per il livello gratuito
- La gestione degli inquilini è 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 dello schema o del database
è un buon candidato per il livello normale
- 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à all'esterno di Spanner
Livello aziendale:
- Solitamente un livello di fascia alta con autonomia completa sotto tutti gli aspetti
- Lo tenant ha risorse dedicate che includono la scalabilità dedicata e il pieno isolamento
- Il pattern di gestione dei dati dell'istanza è adatto per il livello aziendale
Una best practice consiste nel mantenere pattern di gestione dei dati diversi in database diversi. Sebbene sia possibile combinare diversi pattern di gestione dei dati in un database Spanner, complicare l'implementazione della logica di accesso e delle operazioni del ciclo di vita dell'applicazione.
La sezione Progettazione applicazione delinea 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. Pertanto, devi implementare le operazioni di gestione corrispondenti all'interno della tua applicazione multi-tenant. Oltre alle operazioni di base per creare, aggiornare ed eliminare tenant, considera le seguenti operazioni aggiuntive relative ai dati:
Esporta i dati tenant:
- Quando elimini un tenant, è buona norma esportare prima i dati e, se possibile, rendere disponibile il set di dati.
- Quando si utilizza il modello di gestione dei dati della tabella o dello schema, il sistema applicativo multi-tenant deve implementare l'esportazione o mapparla alla funzionalità del database (esportazione del database).
Backup dei dati del tenant:
- Quando utilizzi il pattern di gestione dei dati dell'istanza o del database e fai il backup dei dati per i singoli tenant, utilizza le funzioni di esportazione o backup del database.
- Quando si utilizza il pattern di gestione dei dati dello schema o della tabella e si esegue il backup dei dati per singoli tenant, l'applicazione multi-tenant deve implementare questa operazione. Il database di Spanner non è in grado di determinare quali dati appartengono a quale tenant.
Spostamento dei dati dei tenant:
Lo spostamento di un tenant da un pattern di gestione dei dati a un altro (o 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 non è possibile questo tempo di inattività, esegui una migrazione dei database per il tempo di inattività pari a zero.
La riduzione della situazione di rumorosità dei vicini è un altro motivo per spostare i tenant.
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 dell'applicazione significa che ogni query deve essere eseguita in base al pattern di gestione dei dati in cui risiede il tenant. Le seguenti sezioni mettono in evidenza alcuni dei concetti centrali della progettazione di applicazioni multi-tenant.
Connessione tenant dinamica e configurazione della query
La mappatura dinamica dei dati del tenant alle richieste dell'applicazione tenant utilizza una configurazione di mappatura:
- Per i pattern di gestione dei dati di database o pattern delle istanze dei dati, è 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 di tabella corretti.
- 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 qualsiasi dei quattro pattern di gestione dei dati. La seguente implementazione di mappatura riguarda una configurazione di connessione per il caso generale 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 dei dati per tutti i tenant. Questa richiesta è trattata 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 delle tabelle (per il pattern dello schema).
Questa logica dell'applicazione richiede la mappatura del pattern da tenant a gestione dei dati. Nel seguente esempio di codice, connection string si riferisce al database in cui risiedono i dati del tenant. L'esempio identifica l'istanza 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 le query:
tenant id -> (data management pattern,
database connection string,
[table_prefix])
È necessaria una progettazione aggiuntiva per i pattern di gestione dei dati di schema e tabella.
Pattern di gestione dei dati dello schema
Per il pattern di gestione dei dati dello schema ci sono diversi tenant all'interno dello stesso database. Ogni tenant ha il proprio set di tabelle. Le tabelle sono distinte per nome. Quale tabella appartiene a quale tenant è deterministico.
Un approccio è 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 ciascuna tabella con il prefisso Ttenant ID prima di inviare la query al database restituito dalla mappatura.
Un altro approccio è anteporre un elemento table_prefix alla mappatura utilizzata dalla query, in modo da trovare 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 eseguita la mappatura predefinita (anteponi i nomi delle tabelle con ID tenant).
Pattern di gestione dei dati della tabella
Un pattern simile è necessario per il pattern di gestione dei dati della tabella. In questo pattern è presente un singolo schema. I dati tenant 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 consiste nell'utilizzare una colonna denominata 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 del tenant deve essere disponibile nella logica dell'applicazione. Può essere trasmesso come parametro o archiviato come contesto del thread.
Alcune operazioni del ciclo di vita richiedono di modificare la configurazione di mappatura pattern da tenant a gestione dei dati, 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 del database. Potrebbe anche essere necessario aggiornare il prefisso della tabella.
Generazione di query e attribuzione
Uno dei principi fondamentali alla base delle applicazioni multi-tenant è che più tenant possono condividere una singola risorsa cloud. I precedenti modelli di gestione dei dati 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 monitorati anche il logging e il logging: ad esempio, nel pattern di gestione dei dati della tabella e nel pattern di gestione dei dati dello schema, tutte le query per tutti i tenant vengono registrate nello stesso audit log.
Se una query viene registrata, il testo della query deve essere esaminato per determinare a 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 pattern di gestione dei dati dell'istanza, il testo della query non ha informazioni sul tenant. Per ottenere informazioni sul tenant per questi pattern, devi eseguire una query sulla tabella di mappatura tra tenant e gestione dei dati.
Sarebbe più facile analizzare log e query determinando il tenant per una determinata 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 è aggiungere un commento al testo della query che contiene tenant ID e (facoltativamente) un label.
La query seguente 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 SQL.
select * from EMPLOYEE
-- TENANT 356
where TENANT = 'T356';
o
select * from T356_EMPLOYEE;
-- TENANT 356
Con questa progettazione, ogni query eseguita per un tenant viene attribuita a tale tenant indipendentemente dal pattern di gestione dei dati. Se un tenant viene spostato da un pattern 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 è inserire un oggetto JSON come commento invece di un'etichetta e un valore:
select * from T356_EMPLOYEE;
-- {"TENANT": 356}
Operazioni del ciclo di vita dell'accesso in 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 o creare uno strumento di amministrazione di tenant separato.
Indipendentemente dalla strategia di implementazione, potrebbe essere necessario eseguire le operazioni del ciclo di vita senza che la logica dell'applicazione sia in esecuzione contemporaneamente: 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 si trovano in un unico database. Se i dati non si trovano in un unico database, sono necessarie due operazioni aggiuntive dal punto di vista dell'applicazione:
- Arresta un tenant: disabilita l'accesso a tutte le logiche dell'applicazione mentre consenti 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 sono disabilitate.
Sebbene la frequenza non sia spesso utilizzata, l'arresto di un tenant di emergenza potrebbe rappresentare un'altra operazione importante del ciclo di vita. Usa questa chiusura 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. Una simile 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 diversi gradi di isolamento dei dati dei tenant. Dal livello più isolato (istanza) a quello 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 possibile pattern di gestione dei dati) utilizzando lo stesso deployment dell'applicazione? 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 nel caso dei pattern di gestione dei dati, tenant diversi potrebbero essere indirizzati a deployment di applicazioni diverse. I tenant di grandi dimensioni potrebbero avere accesso a un deployment di applicazioni esclusivo, mentre i tenant più piccoli o i tenant nel livello gratuito condividono il deployment di un'applicazione.
Invece di far corrispondere direttamente i pattern di gestione dei dati illustrati in questo articolo con pattern di gestione dei dati equivalenti, puoi utilizzare il pattern di gestione dei dati del database in modo che tutti i tenant condividano la distribuzione di una singola applicazione. È possibile che il pattern di gestione dei dati del database e tutti questi tenant condividano il deployment di una singola applicazione.
La multitenancy è un pattern importante per la gestione dei dati, delle applicazioni e delle applicazioni, in particolare quando l'efficienza delle risorse svolge un ruolo fondamentale. Spanner supporta diversi pattern di gestione dei dati: utilizzalo per l'implementazione di applicazioni multi-tenant. Grazie all'estrema scalabilità e agli SLA rigorosi, è un database ideale per il deployment di applicazioni multi-tenant di Spanner.
Passaggi successivi
- Esplora architetture di riferimento, diagrammi e best practice su Google Cloud. Dai un'occhiata al nostro Cloud Architecture Center.