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à.
# Modelli di partizionamento SaaS multi-tenant per PostgreSQL
Il metodo migliore per realizzare la multi-tenancy dipende dai requisiti dell'applicazione SaaS. Le sezioni seguenti illustrano i modelli di partizionamento per implementare con successo la multi-tenancy in PostgreSQL.
**Nota**
I modelli descritti in questa sezione sono applicabili sia ad Amazon RDS for PostgreSQL che a Aurora PostgreSQL. I riferimenti a *PostgreSQL* in questa sezione si applicano a entrambi i servizi.
Esistono tre modelli di alto livello che è possibile utilizzare in PostgreSQL per il partizionamento SaaS: silo, bridge e pool. L'immagine seguente riassume i compromessi tra i modelli silo e pool. Il modello a ponte è un ibrido tra i modelli silo e pool.
****
| **Modello di partizionamento** | **Vantaggi** | **Svantaggi** |
| --- | --- | --- |
| Silo | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) |
| Pool | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) |
| Ponte | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) |
Le sezioni seguenti illustrano ciascun modello in modo più dettagliato.
**Topics**
+ [
# Modello di silo PostgreSQL
](silo.md)
+ [
# Modello di pool PostgreSQL
](pool.md)
+ [
# Modello bridge PostgreSQL
](bridge.md)
+ [
# Matrice decisionale
](matrix.md)
# Modello di silo PostgreSQL
Il modello silo viene implementato fornendo un'istanza PostgreSQL per ogni tenant di un'applicazione. *Il modello silo eccelle in termini di prestazioni dei tenant e isolamento della sicurezza ed elimina completamente il fenomeno dei rumorosi vicini.* Il fenomeno Noisy Neighbor si verifica quando l'utilizzo di un sistema da parte di un inquilino influisce sulle prestazioni di un altro inquilino. Il modello a silo consente di personalizzare le prestazioni in modo specifico per ciascun tenant e di limitare potenzialmente le interruzioni al silo di un tenant specifico. Tuttavia, ciò che generalmente guida l'adozione di un modello a silo sono i rigorosi vincoli normativi e di sicurezza. Questi vincoli possono essere motivati dai clienti SaaS. Ad esempio, i clienti SaaS potrebbero richiedere l'isolamento dei propri dati a causa di vincoli interni e i provider SaaS potrebbero offrire tale servizio a un costo aggiuntivo.
![\[SaaS PostgreSQL silo model\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/images/saas-postgresql-silo.png)
Sebbene il modello a silo possa essere necessario in alcuni casi, presenta molti inconvenienti. Spesso è difficile utilizzare il modello a silo in modo conveniente, perché la gestione del consumo di risorse su più istanze PostgreSQL può essere complicata. Inoltre, la natura distribuita dei carichi di lavoro dei database in questo modello rende più difficile mantenere una visione centralizzata dell'attività dei tenant. La gestione di così tanti carichi di lavoro gestiti in modo indipendente aumenta il sovraccarico operativo e amministrativo. Il modello a silo rende inoltre l'onboarding dei tenant più complicato e dispendioso in termini di tempo, poiché è necessario fornire risorse specifiche per il tenant. Inoltre, l'intero sistema SaaS può essere più difficile da scalare, perché il numero sempre crescente di istanze PostgreSQL specifiche per tenant richiederà più tempo operativo per l'amministrazione. Un'ultima considerazione è che un'applicazione o un livello di accesso ai dati dovrà mantenere una mappatura dei tenant alle istanze PostgreSQL associate, il che aumenta la complessità dell'implementazione di questo modello.
# Modello di pool PostgreSQL
Il modello pool viene implementato effettuando il provisioning di una singola istanza PostgreSQL (Amazon RDS o Aurora) [e utilizzando la sicurezza a livello di riga](https://aws.amazon.com/blogs/database/multi-tenant-data-isolation-with-postgresql-row-level-security/) (RLS) per mantenere l'isolamento dei dati dei tenant. Le politiche RLS limitano quali righe di una tabella vengono restituite dalle `SELECT` query o quali righe sono interessate da e comandi. `INSERT` `UPDATE` `DELETE` Il modello di pool centralizza tutti i dati dei tenant in un unico schema PostgreSQL, quindi è significativamente più conveniente e richiede meno sovraccarico operativo per la manutenzione. Il monitoraggio di questa soluzione è inoltre notevolmente più semplice grazie alla sua centralizzazione. Tuttavia, il monitoraggio degli impatti specifici dei tenant nel modello di pool richiede in genere una strumentazione aggiuntiva nell'applicazione. Questo perché PostgreSQL per impostazione predefinita non è a conoscenza di quale tenant stia consumando risorse. L'onboarding dei tenant è semplificato perché non è richiesta alcuna nuova infrastruttura. Questa agilità semplifica la realizzazione di flussi di lavoro di onboarding dei tenant rapidi e automatizzati.
![\[SaaS PostgreSQL pool model\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/images/saas-postgresql-pool.png)
Sebbene il modello di pool sia generalmente più economico e più semplice da amministrare, presenta alcuni svantaggi. Il fenomeno dei vicini rumorosi non può essere completamente eliminato in un modello di piscina. Tuttavia, può essere mitigato assicurando che siano disponibili risorse appropriate sull'istanza PostgreSQL e utilizzando strategie per ridurre il carico in PostgreSQL, come l'offloading delle query su repliche di lettura o su Amazon. ElastiCache Un monitoraggio efficace svolge anche un ruolo nel rispondere ai problemi di isolamento delle prestazioni dei tenant, poiché la strumentazione applicativa può registrare e monitorare le attività specifiche del tenant. Infine, alcuni clienti SaaS potrebbero non ritenere sufficiente la separazione logica fornita da RLS e potrebbero richiedere ulteriori misure di isolamento.
# Modello bridge PostgreSQL
Il modello bridge PostgreSQL è una combinazione di approcci in pool e in silos. Analogamente al modello in pool, esegui il provisioning di una singola istanza PostgreSQL per ogni tenant. Per mantenere l'isolamento dei dati dei tenant, si utilizzano costrutti logici PostgreSQL. Nel diagramma seguente, i database PostgreSQL vengono utilizzati per separare logicamente i dati.
**Nota**
Un database PostgreSQL non fa riferimento a un'istanza DB separata compatibile con Amazon RDS for PostgreSQL o Aurora PostgreSQL. Si riferisce invece a un costrutto logico del sistema di gestione del database PostgreSQL per separare i dati.
![\[SaaS PostgreSQL bridge model with separate databases\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/images/saas-postgresql-bridge-dbs.png)
È inoltre possibile implementare il modello bridge utilizzando un singolo database PostgreSQL, con schemi specifici del tenant in ogni database, come illustrato nel diagramma seguente.
![\[SaaS PostgreSQL bridge model with separate schemas\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/images/saas-postgresql-bridge-schemas.png)
Il modello bridge presenta gli stessi problemi di isolamento delle prestazioni dei rumorosi vicini e dei tenant del modello pool. Inoltre, comporta un sovraccarico operativo e di provisioning aggiuntivo in quanto richiede il provisioning di database o schemi separati su base per-tenant. Richiede un monitoraggio efficace per rispondere rapidamente ai problemi relativi alle prestazioni degli inquilini. Richiede inoltre una strumentazione applicativa per monitorare l'utilizzo specifico del tenant. Nel complesso, il modello bridge può essere visto come un'alternativa a RLS che aumenta leggermente lo sforzo di onboarding dei tenant richiedendo nuovi database o schemi PostgreSQL. Come per il modello a silo, un'applicazione o un livello di accesso ai dati dovrà mantenere una mappatura dei tenant ai database o agli schemi PostgreSQL associati.
# 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 |