È possibile avere migliaia di utenti in Postgres?

Stiamo creando SAAS dove avremo al massimo 50.000 clienti. Stiamo valutando la possibilità di creare un utente nel database Postgres per ciascun cliente. Mapperemo ogni utente che accede al nostro servizio a un utente nel database al fine di essere molto sicuri che abbiano accesso solo ai propri dati. Vogliamo anche implementare una pista di controllo direttamente nel database da questa soluzione , che utilizza i trigger. Se ogni cliente ha il proprio utente di database, sarebbe molto facile vedere chi ha fatto cosa, anche se due clienti condividessero gli stessi dati.

Incontreremo alcuni problemi imprevisti perché abbiamo 50.000 utenti nel nostro database? Dal punto di vista delle prestazioni o dell'amministrazione. Forse il pool di connessioni sarebbe più difficile, ma non so davvero se ne avremmo bisogno.

— David
fonte

Non sarai in grado di fare alcun tipo di pool di connessioni se stai usando l'autorizzazione DB, vero? Per quanto riguarda le prestazioni, il problema importante è il numero di connessioni simultanee e la quantità di risorse che utilizzano anziché il numero di utenti nel DB.

— Jack dice di provare topanswers.xyz il

@JackDouglas Sì, è possibile utilizzare il pool di connessioni. Connettiti come "commonUser" quindiset role actualUser

— Neil McGuigan il

@Neil certo, ma non è autenticazione DB. Se stai eseguendo l'autenticazione utilizzando la password dell'utente del database, dovrai utilizzare una sorta di autenticazione esterna in Postgres.

— Jack dice di provare topanswers.xyz il

@JackDouglas hai ragione, è un'autorizzazione proxy anziché un'autorizzazione db.

— Neil McGuigan,

Le risposte finora stanno assumendo un numero elevato di utenti simultanei, sarà questo il caso?

— Jack dice di provare topanswers.xyz il

Risposte:

Sì, dovrebbe andare bene. Tuttavia, è necessario utilizzare il pool di connessioni, poiché pg utilizza una discreta quantità di memoria per connessione (circa 10 MB AFAIK).

Tuttavia, saranno più di 500 le connessioni simultanee per scatola (come interrogare attivamente il database nello stesso momento). Più cpus / core è meglio. Usa SSD con RAID 10.

L'applicazione SaaS dovrebbe connettersi come un utente, quindi set roleall'utente reale. Ciò consente di utilizzare il pool di connessioni, poiché la stringa di connessione sarà la stessa, ma utilizza utenti diversi. È necessario reset rolerestituire la connessione al pool.

Questa non è in realtà l'autenticazione del database. È l'autenticazione proxy (aka Impersonation).

È inoltre possibile prendere in considerazione pool separati per azienda o per ruolo.

Per semplificare l'amministratore, puoi mettere gli utenti in gruppi e impostare le autorizzazioni tramite i gruppi. Questo si chiama RBAC.

Aggiornamento: sono stato in grado di creare 50.000 utenti in 2,4 secondi. PGAdmin è notevolmente più lento, a causa del numero di utenti. Tuttavia, la connessione tramite JDBC è più veloce di prima. Non ero in grado di eliminare 50.000 utenti contemporaneamente, ma potevo fare circa 10.000 alla volta.

— Neil McGuigan
fonte

Grazie mille per le tue ricerche. È stato possibile lavorare in PGAdmin? È stato un grosso problema con le prestazioni lì?

— David,

@David PGAdmin andava bene, solo lentamente. psql dovrebbe andare bene. Potrebbe essere in grado di modificare PGAdmin per accelerare le cose.

— Neil McGuigan,

Prestazioni: migliaia di connessioni simultanee consumeranno la tua memoria, circa un valore superiore a 1.000 connessioni simultanee consigliate di utilizzare il pool di connessioni, pgbouncer è una buona, sviluppato da skype.

Amministrazione: amministrare 50.000 utenti sarà un grande lavoro IMO. Che ne dici di differenziare cliente con lo stesso accesso ai dati usando diversi application_name, quindi ogni cliente si collegherà al database usando lo stesso nome utente.

Esempio :

usando il nome utente diverso, la stringa di connessione di ogni cliente sarebbe: --user user1, --user user2, etc.

Ma utilizzando diversi application_name, la stringa di connessione di ogni cliente sarebbe: --user user1 --application_name costumer1, --user user1 --aplication_name costumer2, etc.

Il application_nameè registrato in pg_stat_activitye potrebbe anche essere registrato. Penso che sarebbe più facile da implementare. E application_nameviene anche registrato il trigger di controllo che si desidera applicare. Maggiori dettagli qui .

Spero che sia d'aiuto.

— Soni Harriz
fonte

In che modo amministrare 50.000 utenti di database è più difficile di 50.000 utenti di app?

— Neil McGuigan,