Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # 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 un cluster PostgreSQL separato per ogni tenant. + Bridge con database separati: un database separato per ogni tenant in una singola istanza o cluster 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 i tenant in un'unica istanza e schema. **** | **** | **Silo** | **Bridge con database separati** | **Bridge con schemi separati** | **Pool** | | --- | --- | --- | --- | --- | | Caso d’uso | L'isolamento dei dati con il pieno controllo dell'utilizzo delle risorse è un requisito fondamentale, altrimenti si hanno inquilini molto grandi e molto sensibili alle prestazioni. | L'isolamento dei dati è un requisito fondamentale e sono necessari riferimenti incrociati limitati o nulli ai 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 inquilino. | | Agilità di onboarding dei nuovi inquilini | Molto lento. (È richiesta una nuova istanza o cluster per ogni tenant.) | Moderatamente lento. (Richiede la creazione di un nuovo database per ogni tenant per archiviare gli oggetti dello schema.) | Moderatamente lento. (Richiede la creazione di un nuovo schema per ogni tenant per archiviare gli oggetti.) | L'opzione più veloce. (È richiesta una configurazione minima). | | Impegno ed efficienza di configurazione del pool di connessioni al database | È richiesto uno sforzo significativo. (Un pool di connessioni per tenant). Meno efficiente. (Nessuna condivisione della connessione al database tra i tenant.) | È richiesto uno sforzo significativo. (Una configurazione di pool di connessioni per tenant a meno che non si utilizzi [Amazon RDS Proxy.](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-proxy.html)) Meno efficiente. (Nessuna condivisione della connessione al database tra tenant e numero totale di connessioni. L'utilizzo tra tutti i tenant è limitato in base alla classe dell'istanza DB.) | È richiesto un minore sforzo. (Una configurazione del pool di connessioni per tutti i tenant.) Moderatamente efficiente. (Riutilizzo della connessione tramite il `SET SCHEMA` comando `SET ROLE` or solo in modalità pool di sessioni. `SET`i comandi causano anche il blocco della sessione quando si utilizza Amazon RDS Proxy, ma i pool di connessioni client possono essere eliminati ed è possibile effettuare connessioni dirette per ogni richiesta di efficienza.) | Minimo sforzo richiesto. Il più efficiente. (Un pool di connessioni per tutti gli inquilini e riutilizzo efficiente delle connessioni tra tutti i tenant. I limiti di connessione al database si basano sulla classe dell'istanza DB.) | | Manutenzione del database ([gestione del vuoto](https://www.postgresql.org/docs/current/routine-vacuuming.html)) e utilizzo delle risorse | Gestione più semplice. | Complessità media. (Potrebbe comportare un elevato consumo di risorse, poiché successivamente è necessario avviare un aspirapolvere per ogni databasevacuum\$1naptime, il che comporta un elevato utilizzo della CPU dell'Autovacuum Launcher. Potrebbe inoltre esserci un sovraccarico aggiuntivo associato all'eliminazione delle tabelle del catalogo del sistema PostgreSQL per ogni database.) | Tabelle di catalogo del sistema PostgreSQL di grandi dimensioni. (pg\$1catalogDimensione totale in decine di GBs, a seconda del numero di inquilini e delle relazioni. Probabilmente richiederà modifiche ai parametri relativi all'aspirazione per controllare l'ingombro del tavolo.) | Le tabelle potrebbero essere di grandi dimensioni, a seconda del numero di inquilini e dei dati per inquilino. (È probabile che richieda modifiche ai parametri relativi all'aspirazione per controllare l'ingrossamento della tabella.) | | Impegno di gestione delle estensioni | Impegno significativo (per ogni database in istanze separate). | Impegno significativo (a ogni livello di database). | Sforzo minimo (una volta nel database comune). | Sforzo minimo (una volta nel database comune). | | Modifica lo sforzo di implementazione | Impegno significativo. (Connect a ciascuna istanza separata e implementa le modifiche). | Sforzo significativo. (Connect a ogni database e schema e implementa le modifiche). | Sforzo moderato. (Connect al 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 gestione delle prestazioni delle query | Prestazioni gestibili delle query. | Prestazioni gestibili delle query. | Prestazioni gestibili delle query. | 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 la suddivisione del database per mantenere le prestazioni.) | | Impatto sulle risorse tra i 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 pesante. (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 determinato tenant) | Possibile. | Piuttosto possibile. (È possibile apportare modifiche a livello di schema per ogni tenant, ma i parametri del database sono globali per tutti i tenant.) | In qualche modo 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.) | | Riequilibra gli sforzi per gli inquilini sensibili alle prestazioni | Minimo. (Non è necessario riequilibrare. Ridimensiona server e I/O risorse per gestire questo scenario.) | Moderato. (Utilizzate la replica logica o pg\$1dump 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 di Amazon RDS for PostgreSQL per copiare database tra istanze più velocemente.) | Moderato ma probabile che comporti tempi di inattività prolungati. (Utilizza la replica logica o pg\$1dump per esportare lo schema, ma i tempi di inattività potrebbero essere lunghi a seconda delle dimensioni dei dati). | Significativo, perché tutti i tenant condividono le stesse tabelle. (La suddivisione del database richiede la copia di tutto su un'altra istanza e un passaggio aggiuntivo per ripulire i dati dei tenant.) Molto probabilmente richiede una modifica della logica dell'applicazione. | | Tempi di inattività del database per gli aggiornamenti delle versioni principali | Tempo 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 del sistema PostgreSQL vengono duplicate anche tra i database) | Probabilmente tempi di inattività più lunghi. (A seconda della dimensione del catalogo del sistema PostgreSQL, il tempo può variare.) | Tempo di inattività standard. (Dipende dalla dimensione del catalogo del sistema PostgreSQL.) | | Sovraccarico di amministrazione (ad esempio, per l'analisi dei log del database o il monitoraggio dei processi di backup) | Impegno significativo | Sforzo minimo | Sforzo minimo. | Sforzo minimo. | | Disponibilità a livello di tenant | Massima. (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 di ciascun inquilino in modo indipendente.) | Sforzo moderato. (Utilizza l'esportazione e l'importazione logiche per ogni tenant. Sono necessarie alcune operazioni di codifica e automazione.) | Sforzo moderato. (Utilizza l'esportazione e l'importazione logiche per ogni tenant. Sono necessarie alcune operazioni di codifica e automazione.) | Sforzo significativo. (Tutti gli inquilini condividono gli stessi tavoli.) | | Sforzo di ripristino a livello di inquilino point-in-time | Sforzo minimo. (Utilizza il ripristino point-in-time utilizzando istantanee o utilizza il backtracking in Amazon Aurora.) | Sforzo moderato. (Usa il ripristino delle istantanee, seguito da esportazione/importazione. Tuttavia, questa sarà un'operazione lenta.) | Sforzo moderato. (Usa il ripristino delle istantanee, seguito da esportazione/importazione. Tuttavia, questa sarà un'operazione lenta.) | Sforzo e complessità significativi. | | Nome dello schema uniforme | Stesso nome dello schema per ogni inquilino. | Stesso nome dello schema per ogni tenant. | Schema diverso per ogni inquilino. | Schema comune. | | Personalizzazione per tenant (ad esempio, colonne di tabella aggiuntive per un tenant specifico) | Possibile. | Possibile. | Possibile. | Complicato (perché tutti gli inquilini condividono gli stessi tavoli). | | 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 per un database). | Moderatamente efficiente. (A seconda dell'ORM utilizzato, del modello di user/role sicurezza e della search\$1path configurazione, il client a volte memorizza nella cache i metadati per tutti i tenant, con conseguente utilizzo elevato della memoria di connessione DB.) | Efficiente (perché tutti i tenant condividono le stesse tabelle). | | Attività consolidata di rendicontazione degli inquilini | Sforzo significativo. (È necessario utilizzare data wrapper esterni [FDWs] per consolidare i dati in tutti i tenant o estrarre, trasformare e caricare [ETL] su un altro database di reporting.) | Sforzo significativo. (È necessario utilizzarli per FDWs consolidare i dati di tutti gli inquilini o ETL in un altro database di reporting.) | Sforzo moderato. (È possibile aggregare i dati in tutti gli schemi utilizzando i sindacati.) | Sforzo minimo. (Tutti i dati degli inquilini si trovano nelle stesse tabelle, quindi la creazione di report è semplice.) | | Istanza di sola lettura specifica per il tenant per la generazione di report (ad esempio, basata sull'abbonamento) | Minimo sforzo. (Crea una replica di lettura). | Sforzo moderato. (È possibile utilizzare la replica logica o il AWS Database Migration Service [AWS DMS] per la configurazione.) | Sforzo moderato. (È possibile utilizzare la replica logica o AWS DMS la configurazione.) | Complicato (perché tutti i tenant condividono le stesse tabelle). | | Isolamento dei dati | Migliore. | Meglio. (È possibile gestire le autorizzazioni a livello di database utilizzando i ruoli PostgreSQL.) | Meglio. (Puoi 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 dello storage specifica per il tenant | Possibile (Ogni cluster PostgreSQL può avere la AWS Key Management Service propria chiave AWS 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). | Non è possibile. (Tutti i tenant condividono la stessa chiave KMS per la crittografia dello storage). | | Utilizzo di AWS 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 i tenant). | | Costo dell'infrastruttura | Il più alto (perché nulla è condiviso). | Moderato. | Moderato. | Il più basso. | | Duplicazione dei dati e utilizzo dello storage | L'aggregato più elevato tra tutti gli inquilini. (Le tabelle del catalogo del sistema PostgreSQL e i dati statici e comuni dell'applicazione vengono duplicati su 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 vengono duplicati su tutti i tenant.) | Moderato. (I dati statici e comuni dell'applicazione possono trovarsi in uno schema comune e possono accedervi altri tenant.) | Minimo. (Nessuna duplicazione dei dati. I dati statici e comuni dell'applicazione possono trovarsi nello stesso schema.) | | Monitoraggio incentrato sul tenant (scopri rapidamente quale tenant 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 controllare l'attività di un inquilino specifico.) | Sforzo moderato. (Poiché tutti gli inquilini condividono la stessa risorsa fisica, è necessario applicare filtri aggiuntivi per controllare l'attività di un inquilino specifico.) | Sforzo significativo. (Poiché tutti i tenant condividono tutte le risorse, incluse le tabelle, è necessario utilizzare bind variable capture per verificare a quale tenant appartiene una specifica query SQL.) | | Gestione e monitoraggio centralizzati health/activity | Impegno significativo (per configurare il 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 i tenant condividono le stesse risorse, incluso lo schema). | | Possibilità di incrociare l'identificatore dell'oggetto (OID) e l'ID della transazione (XID) | Minimo. | Elevato. (Poiché OID, XID è un singolo contatore a livello di cluster PostgreSQL e possono verificarsi problemi di evacuazione efficace tra 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 colonne.) out-of-line |