Le prestazioni non sono necessariamente peggiori. Come spiega l'articolo, esistono condizioni specifiche che rendono lo schema migliore o peggiore a seconda della progettazione dell'applicazione e del carico di lavoro. Lascia che ti spieghi i compromessi tra gli approcci "schema tenant" e "tabella condivisa":
schema tenant è meglio quando si dispone di un numero relativamente piccolo di inquilini abbastanza grandi. Un esempio potrebbe essere un'applicazione di contabilità, con solo utenti con abbonamento a pagamento. Le cose che lo rendono l'opzione più performante per te includono:
- un piccolo numero di tenant con molti dati ciascuno
- uno schema relativamente semplice senza molte tabelle per tenant
- necessità di personalizzare gli schemi di alcuni tenant
- capacità di utilizzare i ruoli del database per tenant
- requisito per migrare i dati di un tenant da un server a un altro
- possibilità di creare un app server dedicato nel cloud per ogni tenant
Le cose che la rendono un'opzione con scarse prestazioni includono:
- molti inquilini con pochissimi dati ciascuno
- Approccio stateless alle connessioni in cui ogni richiesta potrebbe essere qualsiasi tenant
- libreria client o orm che memorizza nella cache i metadati per tutte le tabelle (come ActiveRecord)
- un requisito per un pool di connessioni e/o una memorizzazione nella cache efficienti e ad alte prestazioni
- problemi con VACUUM e altre operazioni amministrative di PostgreSQL con scarsa scalabilità su migliaia di tabelle.
Il fatto che lo schema tenant sia dannoso per migrazioni/modifiche allo schema dipende davvero da come le stai facendo. Non è utile per implementare rapidamente una modifica dello schema universale, ma è utile per implementare le modifiche dello schema come un'implementazione graduale tra i tenant.
tabella condivisa funziona meglio per le situazioni in cui hai molti tenant e molti dei tuoi tenant hanno pochissimi dati. Un esempio di ciò potrebbe essere un'applicazione mobile social media che consente account gratuiti e quindi ha migliaia di account abbandonati. Altre cose che rendono vantaggioso il modello di tabella condivisa sono:
- meglio per il pool di connessioni, poiché tutte le connessioni possono utilizzare lo stesso pool
- migliore per l'amministrazione di PostgreSQL, grazie al minor numero di tabelle totali
- meglio per migrazioni e modifiche dello schema, poiché esiste un solo "set" di tabelle
Lo svantaggio principale della tabella condivisa è la necessità di aggiungere la condizione del filtro tenant a ogni singola query nel livello dell'applicazione. È anche problematico perché:
- Le query che si uniscono a molte tabelle possono funzionare male perché il filtro tenant annulla la pianificazione delle query
- le tabelle che raggiungono i 100 milioni di righe possono causare problemi specifici di prestazioni e manutenzione
- nessun modo per apportare modifiche alle applicazioni o aggiornamenti dello schema specifici del tenant
- più costoso migrare tenant tra server
Quindi quale modello "funziona meglio" dipende davvero da quali compromessi ti danneggiano di più.
Esiste anche un modello ibrido, "tenant-view", in cui i dati effettivi sono archiviati in tabelle condivise, ma ogni connessione dell'applicazione utilizza viste barriera di sicurezza per visualizzare i dati. Questo ha alcuni dei compromessi di ogni modello. In primo luogo, presenta i vantaggi in termini di sicurezza del modello con schema tenant con alcuni degli svantaggi di prestazioni di entrambi i modelli.
