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à.
Modello di pool PostgreSQL
Il modello del pool viene implementato fornendo una singola istanza PostgreSQL (Amazon RDS o Aurora) e utilizzando la sicurezza a livello di riga (RLS)SELECT query o le righe interessate daiINSERTDELETE comandi e dai comandi.UPDATE Il modello del pool centralizza tutti i dati dei tenant in un unico schema PostgreSQL, quindi è significativamente più conveniente e richiede meno costi operativi per la manutenzione. Il monitoraggio di questa soluzione è anche notevolmente più semplice grazie alla sua centralizzazione. Tuttavia, il monitoraggio degli impatti specifici degli inquilini nel modello del pool di solito richiede una strumentazione aggiuntiva nell'applicazione. Questo perché PostgreSQL per impostazione predefinita non è a conoscenza di quale tenant stia consumando risorse. L'onboarding degli inquilini è semplificato perché non è necessaria alcuna nuova infrastruttura. Questa agilità semplifica l'esecuzione di flussi di lavoro di onboarding dei tenant rapidi e automatizzati.
Sebbene il modello del pool sia generalmente più conveniente e più semplice da amministrare, presenta alcuni svantaggi. Il fenomeno dei vicini rumorosi non può essere completamente eliminato in un modello a piscina. Tuttavia, può essere mitigato assicurando che le risorse appropriate siano disponibili sull'istanza PostgreSQL e utilizzando strategie per ridurre il carico in PostgreSQL, ad esempio scaricando le query per leggere repliche o su Amazon ElastiCache. Un monitoraggio efficace svolge anche un ruolo nel rispondere ai problemi di isolamento delle prestazioni degli inquilini, 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.
