Чи можливо мати тисячі користувачів у Postgres?

Ми створюємо SAAS, де маємо максимум 50 000 клієнтів. Ми розглядаємо можливість створення користувача в базі даних Postgres для кожного клієнта. Ми будемо картографувати кожного користувача, який входить у наш сервіс, користувачеві в базі даних, щоб бути впевненим, що він має доступ лише до власних даних. Ми також хочемо реалізувати аудиторський слід безпосередньо в базі даних за допомогою цих рішень , що використовує тригери. Якщо у кожного замовника є власний користувач бази даних, то було б дуже легко зрозуміти, хто що робив, навіть якщо двоє клієнтів поділяться однаковими даними.

Чи будемо мати якісь несподівані проблеми, оскільки в нашій базі даних є 50 000 користувачів? Продуктивність або адміністрація. Може бути, об'єднання з'єднань буде складніше, але я не знаю, чи потрібен він нам.

Так, це повинно бути добре. Вам слід використовувати об'єднання з'єднань, оскільки pg використовує достатню кількість пам'яті на з'єднання (близько 10 Мб AFAIK).

Більше 500 одночасних з'єднань у коробці будуть проблемою (як, наприклад, активно запитуючи базу даних в той самий час). Більше cpus / ядер краще. Використовуйте SSD з RAID 10.

Ваш додаток SaaS має підключитися як один користувач, а потім set roleреальний користувач. Це дозволяє використовувати об'єднання з'єднань, оскільки рядок з'єднання буде однаковою, але використовувати різні користувачі. Ви повинні reset roleповернути з'єднання з басейном.

Це насправді не автентифікація бази даних. Це аутентифікація проксі-сервера (також імперсонація).

Ви також можете розглянути окремі пули для кожної компанії чи за роллю.

Щоб полегшити адміністратор, ви можете розмістити користувачів у групи та встановити дозволи через групи. Це називається RBAC.

Оновлення: мені вдалося створити 50 000 користувачів за 2,4 секунди. PGAdmin помітно повільніше, через кількість користувачів. Однак підключення через JDBC проходить так само швидко, як і раніше. Я не зміг одразу скинути 50 000 користувачів, але міг зробити приблизно 10 000 одночасно.

Продуктивність: тисяча паралельних з'єднань з'їсть вашу пам’ять, приблизно значення, що перевищує 1000 одночасних з'єднань, радимо використовувати об'єднання з'єднань, гарний pgbouncer, розроблений Skype.

Адміністрація: Адміністрація 50 000 користувачів стане великою роботою IMO. Як щодо диференціювання клієнта з одним і тим же доступом до даних, використовуючи різні application_name, тож кожен клієнт підключиться до бази даних, використовуючи те саме ім’я користувача.

Приклад:

використовуючи інше ім'я користувача, то рядок підключення кожного клієнта буде: --user user1, --user user2і т.д.

Але , використовуючи різні application_name, то рядок підключення кожного клієнта буде: --user user1 --application_name costumer1, --user user1 --aplication_name costumer2і т.д.

Цей application_nameзапис записаний pg_stat_activityі може бути також ввійшов до журналу. Я думаю, що це було б легше здійснити. А application_nameтакож записується в тригер аудиту, який ви хочете застосувати. Детальніше тут .

Сподіваюся, це допомагає.