Возможно ли иметь тысячи пользователей в Postgres?

9

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

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

Дэвид
источник
2
Вы не сможете выполнять пулы соединений, если используете аутентификацию БД, не так ли? Для производительности важной проблемой является количество одновременных соединений и количество ресурсов, которые они используют, а не количество пользователей в БД.
говорит Джек, попробуйте topanswers.xyz
2
@JackDouglas Да, вы можете использовать пул соединений. Тогда подключитесь как «обычный пользователь»set role actualUser
Нил Макгиган
2
@ Конечно, но это не аутентификация БД. Если вы проходите аутентификацию, используя пароль пользователя базы данных, вам нужно будет использовать какую-то внешнюю аутентификацию в postgres.
Джек говорит, попробуйте topanswers.xyz
2
@JackDouglas вы правы, это прокси-аутентификация, а не db-аутентификация.
Нил Макгиган
Пока ответы предполагают большое количество одновременных пользователей, будет ли это так?
Джек говорит, попробуйте topanswers.xyz

Ответы:

12

Да, все должно быть в порядке. Вы должны использовать пул соединений, так как pg использует достаточное количество памяти на соединение (около 10 МБ AFAIK).

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

Ваше SaaS-приложение должно подключаться как один пользователь, затем set roleк реальному пользователю. Это позволяет использовать пул соединений, так как строка соединения будет одинаковой, но использовать разных пользователей. Вы должны reset roleпри возврате соединения в пул.

Это на самом деле не аутентификация базы данных. Это проверка подлинности прокси (иначе Олицетворение).

Вы также можете рассмотреть отдельные пулы для каждой компании или для каждой роли.

Чтобы упростить администрирование, вы можете объединять пользователей в группы и устанавливать права доступа через группы. Это называется RBAC.

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

Нил Макгиган
источник
Большое спасибо за ваши исследования. Можно ли было вообще работать в PGAdmin? Это была большая проблема с производительностью там?
Дэвид
@ Дэвид PGAdmin был в порядке, просто медленно. PSQL должно быть хорошо. Может быть в состоянии настроить PGAdmin, чтобы ускорить процесс.
Нил Макгиган
2

Производительность: тысячи одновременных подключений будут поглощать вашу память, примерно на сумму более 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также регистрируется в триггере аудита, который вы хотите применить. Подробнее здесь .

Надеюсь, поможет.

Сони Харрис
источник
4
Как администрирование 50000 пользователей БД сложнее, чем 50000 пользователей приложения?
Нил Макгиган