Pro e contro dell'utilizzo di molti schemi in PostgreSQL rispetto a uno solo?

Per un'applicazione SAAS di grandi dimensioni (supportata da PostgreSql 9.4), con oltre 300.000 account (e in crescita), quali sono i pro e i contro dell'utilizzo di uno schema per account per partizionare i dati e mettere tutti i dati in uno schema e usare chiavi esterne per partizionarlo nelle query?

So che in passato pg_dump è stato dolorosamente lento quando si lavora con molti schemi, ma non sono sicuro che sia così oggi. Sono anche consapevole che qualsiasi cambiamento nella struttura del database dovrà essere fatto su tutti gli schemi. E so che sul lato positivo, spostare uno schema da un server fisico a un altro è facile, oltre a ripristinare uno schema dal backup, per non parlare del fatto che ha senso partizionare i dati in quel modo.

Quindi quali sono i pro e i contro che mi mancano?

— Harel
fonte

Nessuno dei due sembra buono. Un unico enorme tavolo ("crescita verticale") è difficile da gestire e anche un numero enorme di schemi ("crescita orizzontale") è difficile da gestire.

— Daniel Vérité,

Sto ricostruendo un vecchio sistema che ha quel numero di account (e un numero ancora maggiore di utenti). Sta usando un approccio condiviso (usando mySql) e funziona bene per quanto riguarda le prestazioni. La mia preoccupazione è quella di mantenere quel livello di prestazioni ma aggiungere manutenibilità ad esso.

— Harel

@Harel Sono curioso, l'hai provato con schemi da 400k o sei passato a un'altra architettura / tecnologia?

— Sthzg

Ho rinunciato all'idea dopo aver esaminato più a fondo. La quantità di schemi che avrei creato avrebbe sconfitto qualsiasi uso pratico di questo. Sono andato con il buon vecchio campo ID account in ogni record. Ciò che ho fatto anche, tuttavia, è stato quello di eliminare gli ID numerici di incremento automatico a favore degli UUID, il che significa che posso prendere un intero account da un db all'altro abbastanza facilmente senza doversi preoccupare di infrangere l'integrità.

— Harel,

Ovviamente, hai a che fare con le stesse tabelle in ogni schema utente. Hai considerato l' eredità per questo? Può darti il meglio di entrambi i mondi per alcuni casi d'uso. Ci sono anche alcune limitazioni . È possibile disporre di uno schema separato per ciascun utente e cercare comunque tutte le tabelle utente contemporaneamente in modo molto conveniente.

Relazionato:

A parte questo, bisogna menzionare almeno la concessione / revoca dei privilegi, che è molto più semplice con schemi separati.

— Erwin Brandstetter
fonte

Guarderò in eredità. Tuttavia, la mia preoccupazione è con la scala qui. Ovunque legga, le persone parlano della strategia dello schema multi-tenant ma si riferiscono a decine, centinaia o migliaia di schemi. Un posto menzionato schemi 20K. La domanda è: gli schemi 400K sono troppo? Causerà un folle descrittore di file e ucciderà il server? Lo sto spingendo?

— Harel

Inoltre, intendevo mantenere i dati dei tenant (account e utenti) nello schema pubblico, mantenendo gli schemi stessi come dati utente effettivi. Tali dati non sono e non saranno mai condivisi tra schemi.

— Harel

L'ereditarietà non mi aiuterà qui, non credo. L'approccio condiviso utilizza un singolo schema con chiavi esterne obbligatorie per l'utente o l'inquilino, quindi non ho paura di ottenere nulla dall'ereditarietà.

— Harel

Da questo articolo influitive.io/… penso che la modalità multi-schema non sia un buon modo per gli inquilini di grandi numeri. La colonna tenant_id (la via antica) migliora.

— Xiaohui Zhang,