Matrice decisionale

Per decidere quale modello di partizionamento SaaS multi-tenant utilizzare con PostgreSQL, consulta la seguente matrice decisionale. La matrice analizza queste quattro opzioni di partizionamento:

• Silo: un'istanza o cluster di PostgreSQL separato per ciascun tenant.

• Bridge con database separati: un database separato per ogni tenant in una singola istanza o cluster di PostgreSQL.

• Bridge con schemi separati: uno schema separato per ogni tenant in un singolo database PostgreSQL, in una singola istanza o cluster PostgreSQL.

• Pool: tabelle condivise per gli inquilini in un'unica istanza e schema.

	Silo	Bridge con database separati	Ponte con schemi separati	Piscina
Caso d'uso	L'isolamento dei dati con il pieno controllo dell'utilizzo delle risorse è un requisito fondamentale; in caso contrario, si dispone di tenant molto grandi e molto sensibili alle prestazioni.	L'isolamento dei dati è un requisito fondamentale ed è richiesto un riferimento incrociato limitato o nullo dei dati degli inquilini.	Numero moderato di inquilini con una quantità moderata di dati. Questo è il modello preferito se devi fare riferimenti incrociati ai dati degli inquilini.	Grande numero di inquilini con meno dati per tenant.
Nuova agilità di onboarding degli inquilini	Log molto lenti. (È necessaria una nuova istanza o cluster per ogni tenant.)	Log moderatamente lenti. (Richiede la creazione di un nuovo database per ogni tenant per memorizzare gli oggetti dello schema.)	Log moderatamente lenti. (Richiede la creazione di un nuovo schema per ogni tenant per memorizzare gli oggetti.)	L'opzione più veloce. (È richiesta una configurazione minima.)
Impegno ed efficienza nella configurazione del pool di connessioni del database	È richiesto uno sforzo significativo. (Un pool di connessioni per tenant.) Meno efficiente. (Nessuna condivisione della connessione al database tra tenant.)	È richiesto uno sforzo significativo. (Una configurazione del pool di connessioni per tenant, a meno che non utilizzi il proxy Amazon RDS.) Meno efficiente. (Nessuna condivisione della connessione al database tra tenant e numero totale di connessioni. L'utilizzo in tutti i tenant è limitato in base alla classe dell'istanza database.)	Richiede meno sforzo. (Una configurazione del pool di connessioni per tutti i tenant.) Moderatamente efficiente. (Riutilizzo della connessione tramite ilSET SCHEMA comandoSET ROLE or solo in modalità pool di sessioni. SETi comandi causano anche il blocco delle sessioni quando si utilizza il proxy Amazon RDS, ma è possibile eliminare i pool di connessioni client e stabilire connessioni dirette per ogni richiesta di efficienza.)	Minimo sforzo richiesto. Il massimo dell'efficienza. (Un pool di connessioni per tutti i tenant e riutilizzo efficiente della connessione tra tutti i tenant. I limiti di connessione al database sono basati sulla classe dell'istanza database.)
Manutenzione del database (gestione del vuoto) e utilizzo delle risorse	Gestione più semplice.	Complessità media. (Potrebbe comportare un elevato consumo di risorse, poiché è necessario avviare un aspirapolvere per ogni database successivovacuum_naptime, il che comporta un elevato utilizzo della CPU del launcher autovacuum. Potrebbe anche esserci un sovraccarico aggiuntivo associato all'aspirazione delle tabelle del catalogo di sistema PostgreSQL per ciascun database.)	Callout di grandi dimensioni del sistema PostgreSQL. (pg_catalogDimensione totale in decine di GB, a seconda del numero di inquilini e delle relazioni. Probabilmente richiederà modifiche ai parametri relativi all'aspirapolvere per controllare il gonfiore del tavolo.)	Le tabelle potrebbero essere di grandi dimensioni, a seconda del numero di tenant e dei dati per tenant. (Probabilmente richiederà modifiche ai parametri relativi all'aspirapolvere per controllare il gonfiore del tavolo.)
Impegno di gestione delle estensioni	Impegno significativo (per ogni database in istanze separate).	Impegno significativo (a ogni livello di database).	Impegno minimo (una volta nel database comune).	Impegno minimo (una volta nel database comune).
Cambia lo sforzo di implementazione	Sforzo significativa. (Connect a ciascuna istanza separata e implementa le modifiche.)	Sforzo significativa. (Connect a ogni database e schema e implementa le modifiche.)	Sforzo moderato. (Connect a un database comune e implementa le modifiche per ogni schema.)	Sforzo minimo. (Connect a un database comune e implementa le modifiche.)
Implementazione delle modifiche: ambito di impatto	Minimo. (Singolo inquilino interessato.)	Minimo. (Singolo inquilino interessato.)	Minimo. (Singolo inquilino interessato.)	Molto grande. (Tutti gli inquilini interessati.)
Gestione e impegno delle prestazioni delle query	Prestazioni di interrogazione gestibili.	Prestazioni di interrogazione gestibili.	Prestazioni di interrogazione gestibili.	Probabilmente è necessario uno sforzo significativo per mantenere le prestazioni delle query. (Nel tempo, le query potrebbero essere eseguite più lentamente a causa delle maggiori dimensioni delle tabelle. È possibile utilizzare il partizionamento delle tabelle e lo sharding del database per mantenere le prestazioni.)
Impatto sulle risorse tra tenant	Nessun impatto. (Nessuna condivisione delle risorse tra gli inquilini.)	Impatto moderato. (I tenant condividono risorse comuni come la CPU e la memoria dell'istanza.)	Impatto moderato. (I tenant condividono risorse comuni come la CPU e la memoria dell'istanza.)	Impatto forte. (Gli inquilini si influenzano a vicenda in termini di risorse, conflitti di blocco e così via.)
Ottimizzazione a livello di tenant (ad esempio, creazione di indici aggiuntivi per tenant o modifica dei parametri del DB per un particolare tenant)	possibile.	Un po' possibile. (È possibile apportare modifiche a livello di schema per ogni tenant, ma i parametri del database sono globali per tutti i tenant.)	Un po' possibile. (È possibile apportare modifiche a livello di schema per ogni tenant, ma i parametri del database sono globali per tutti i tenant.)	Non possibile. (Le tabelle sono condivise da tutti gli inquilini.)
Impegno di riequilibrio per inquilini sensibili alle prestazioni	Minimo. (Non è necessario riequilibrare. Scalate le risorse di server e I/O per gestire questo scenario.)	Moderato. (Utilizzate la replica logica opg_dump per esportare il database, ma i tempi di inattività potrebbero essere lunghi a seconda delle dimensioni dei dati. Puoi utilizzare la funzionalità di database trasportabile in Amazon RDS for PostgreSQL per copiare più velocemente i database tra le istanze.)	Moderato ma probabilmente comporta lunghi tempi di inattività. (Utilizzate la replica logica opg_dump per esportare lo schema, ma i tempi di inattività potrebbero essere lunghi a seconda delle dimensioni dei dati.)	Significativo, perché tutti gli inquilini condividono le stesse tabelle. (La condivisione del database richiede la copia di tutto in un'altra istanza e un passaggio aggiuntivo per ripulire i dati del tenant.) Molto probabilmente richiede una modifica della logica dell'applicazione.
Tempo di inattività del database per gli aggiornamenti di versione principali	Tempi di inattività standard. (Dipende dalla dimensione del catalogo del sistema PostgreSQL.)	Probabilmente tempi di inattività più lunghi. (A seconda delle dimensioni del catalogo di sistema, il tempo può variare. Le tabelle del catalogo di sistema PostgreSQL sono anche duplicate nei database)	Probabilmente tempi di inattività più lunghi. (A seconda delle dimensioni del catalogo del sistema PostgreSQL, il tempo può variare.)	Tempi di inattività standard. (Dipende dalla dimensione del catalogo del sistema PostgreSQL.)
Sovraccarico amministrativo (ad esempio, per l'analisi dei log del database o il monitoraggio dei processi di backup)	Sforzo significativa	Sforzo minimo.	Sforzo minimo.	Sforzo minimo.
Disponibilità a livello di tenant	Elevato. (Ogni inquilino fallisce e si riprende in modo indipendente.)	Ambito di impatto più elevato. (Tutti gli inquilini falliscono e si ripristinano insieme in caso di problemi hardware o di risorse.)	Ambito di impatto più elevato. (Tutti gli inquilini falliscono e si ripristinano insieme in caso di problemi hardware o di risorse.)	Ambito di impatto più elevato. (Tutti gli inquilini falliscono e si ripristinano insieme in caso di problemi hardware o di risorse.)
Attività di backup e ripristino a livello di tenant	Minimo sforzo. (È possibile eseguire il backup e il ripristino in modo indipendente.)	Sforzo moderato. (Usa l'esportazione e l'importazione logiche per ogni tenant. Sono necessarie alcune codifiche e automatizzazioni.)	Sforzo moderato. (Usa l'esportazione e l'importazione logiche per ogni tenant. Sono necessarie alcune codifiche e automatizzazioni.)	Sforzo significativa. (Tutti gli inquilini condividono le stesse tabelle.)
Impegno di point-in-time ripristino a livello di inquilino	Sforzo minimo. (Usa il ripristino temporale temporale utilizzando le istantanee o usa il backtracking in Amazon Aurora.)	Sforzo moderato. (Usa il ripristino delle istantanee, seguito dall'esportazione/importazione. Tuttavia, si tratterà di un'operazione lenta.)	Sforzo moderato. (Usa il ripristino delle istantanee, seguito dall'esportazione/importazione. Tuttavia, si tratterà di un'operazione lenta.)	Impegno e complessità significativi.
Nome uniforme dello schema uniforme	Lo stesso nome dello schema per ogni tenant.	Lo stesso nome dello schema per ogni tenant.	Schema diverso per ogni tenant.	Schema comune.
Personalizzazione per tenant (ad esempio, colonne di tabella aggiuntive per un tenant specifico)	possibile.	possibile.	possibile.	Complicato (perché tutti gli inquilini condividono le stesse tabelle).
Efficienza della gestione del catalogo a livello di mappatura relazionale degli oggetti (ORM) (ad esempio Ruby)	Efficiente (perché la connessione client è specifica per un tenant).	Efficiente (perché la connessione client è specifica a un database).	Moderatamente efficiente. (A seconda dell'ORM utilizzato, del modello di sicurezza utente/ruolo e dellasearch_path configurazione, il client a volte memorizza nella cache i metadati di tutti i tenant, con conseguente elevato utilizzo della memoria di connessione al DB.)	Efficiente (perché tutti gli inquilini condividono le stesse tabelle).
Attività consolidata di rendicontazione degli inquilini	Sforzo significativa. (È necessario utilizzare wrapper di dati esterni [FDW] per consolidare i dati in tutti i tenant o estrarre, trasformare e caricare [ETL] in un altro database di reporting.)	Sforzo significativa. (È necessario utilizzare FDW per consolidare i dati in tutti i tenant o ETL in un altro database di reporting.)	Sforzo moderato. (È possibile aggregare i dati in tutti gli schemi utilizzando le unioni.)	Sforzo minimo. (Tutti i dati degli inquilini sono nelle stesse tabelle, quindi la creazione di report è semplice.)
Istanza di sola lettura specifica per il tenant per la segnalazione (ad esempio, in base all'abbonamento)	Minimo sforzo. (Creare una replica di lettura.)	Sforzo moderato. (È possibile utilizzare la replica logica o ilAWS Database Migration Service [AWS DMS] per configurare.)	Sforzo moderato. (È possibile utilizzare la replica logica oAWS DMS configurare.)	Complicato (perché tutti gli inquilini condividono le stesse tabelle).
Isolamento dei dati	Migliore.	Migliore. (È possibile gestire le autorizzazioni a livello di database utilizzando i ruoli PostgreSQL.)	Migliore. (È possibile gestire le autorizzazioni a livello di schema utilizzando i ruoli PostgreSQL.)	Peggio. (Poiché tutti i tenant condividono le stesse tabelle, è necessario implementare funzionalità come la sicurezza a livello di riga [RLS] per l'isolamento dei tenant.)
Chiave di crittografia di storage specifica per il tenant	possibile. (Ogni cluster PostgreSQL può avere la propria chiaveAWS Key Management Service [AWS KMS] per la crittografia dell'archiviazione.)	Non possibile. (Tutti i tenant condividono la stessa chiave KMS per la crittografia dello storage.)	Non possibile. (Tutti i tenant condividono la stessa chiave KMS per la crittografia dello storage.)	Non possibile. (Tutti i tenant condividono la stessa chiave KMS per la crittografia dello storage.)
UtilizzoAWS Identity and Access Management (IAM) per l'autenticazione del database per ogni tenant	possibile.	possibile.	Possibile (avendo utenti PostgreSQL separati per ogni schema).	Non possibile (perché le tabelle sono condivise da tutti gli inquilini).
Costo dell'infrastruttura	Il più alto (perché nulla è condiviso).	Moderato.	Moderato.	Minimo.
Duplicazione dei dati e utilizzo dello storage	L'aggregato più alto tra tutti gli inquilini. (Le tabelle del catalogo del sistema PostgreSQL e i dati statici e comuni dell'applicazione sono duplicati in tutti i tenant.)	L'aggregato più alto tra tutti gli inquilini. (Le tabelle del catalogo del sistema PostgreSQL e i dati statici e comuni dell'applicazione sono duplicati in tutti i tenant.)	Moderato. (I dati statici e comuni dell'applicazione possono trovarsi in uno schema comune e possono essere accessibili da altri tenant.)	Minimo. (Nessuna duplicazione dei dati. I dati statici e comuni dell'applicazione possono essere nello stesso schema.)
Monitoraggio incentrato sull'inquilino (scopri rapidamente quale inquilino sta causando problemi)	Minimo sforzo. (Poiché ogni inquilino viene monitorato separatamente, è facile controllare l'attività di un inquilino specifico.)	Sforzo moderato. (Poiché tutti gli inquilini condividono la stessa risorsa fisica, è necessario applicare filtri aggiuntivi per verificare l'attività di un inquilino specifico.)	Sforzo moderato. (Poiché tutti gli inquilini condividono la stessa risorsa fisica, è necessario applicare filtri aggiuntivi per verificare l'attività di un inquilino specifico.)	Sforzo significativa. (Poiché tutti i tenant condividono tutte le risorse, comprese le tabelle, è necessario utilizzare l'acquisizione delle variabili bind per verificare a quale tenant appartiene una specifica query SQL.)
Gestione centralizzata e monitoraggio della salute/attività	Sforzo significativo (per creare un monitoraggio centrale e un centro di comando centrale).	Sforzo moderato (perché tutti gli inquilini condividono la stessa istanza).	Sforzo moderato (perché tutti gli inquilini condividono la stessa istanza).	Impegno minimo (perché tutti gli inquilini condividono le stesse risorse, incluso lo schema).
Possibilità di ripartizione dell'identificatore dell'oggetto (OID) e dell'ID della transazione (XID)	Minimo.	Elevato. (Poiché OID, XID è un singolo contatore PostgreSQL a livello di cluster e possono esserci problemi che si verificano in modo efficace tra i database fisici).	Moderato. (Poiché OID, XID è un singolo contatore PostgreSQL a livello di cluster).	Elevato. (Ad esempio, una singola tabella può raggiungere il limite TOAST OID di 4 miliardi, a seconda del numero di out-of-line colonne.)