În prezent, căutăm cum am putea scala un sistem în care avem mulți utilizatori, fiecare cu propria sa schemă postgres și propriile acreditări de utilizator DB pentru a asigura izolarea. Totuși, aceasta înseamnă că fiecare utilizator va avea nevoie efectiv de propria sa conexiune la baza de date și, deoarece numărul de conexiuni deschise simultane la un server postgres este destul de limitat din cauza supraîncărcării de memorie pentru fiecare conexiune de pe server, căutăm potențiale soluții. pgBouncer Ar fi fost plăcut să utilizați și să multiplexați mai multe conexiuni de intrare la un pool de conexiuni fix la baza de date reală, cu toate acestea, nu am putut confirma că izolarea utilizatorului pe baza acreditărilor utilizatorului și a schemei bazei de date poate fi mapată la acel scenariu.
Sesiunile de utilizator și, prin urmare, durata de viață a conexiunii, au o durată de câteva minute, dar nu sunt foarte utilizate (tranzacție DB unică cu explozie asociată de interogări la fiecare două secunde), iar interogările sunt nu sensibil la latență, astfel încât să ne putem deconecta din punct de vedere tehnic între tranzacții și să ne reconectam la cerere, cu un proxy precum pgBouncer păstrarea stării de conectare. Vorbind despre stare, aplicația nu folosește declarații pregătite cu nume, astfel încât starea serverului nu este oricum mare, dar fiind o bază de date găzduită în cloud, nu putem modifica cu ușurință. max_connections config pe server.
Există vreo modalitate de a mapa acest scenariu pgBouncer sau un proxy similar?
