Как правильно организовать структуру базы данных PostgreSQL для разных аккаунтов?
Пишу финансовый сервис на java. Вопрос следующий. Есть структура таблиц разработанная для одного аккаунта, где хранятся все данные необходимые для его работы. Но сервис многопользовательский. Как сделать лучше. При регистрации аккаунта создавать для него "одноимённый" каталог и хранить все его данные в этой же базе или создавать отдельную базу данных, чтобы каждый аккаунт работал со своей бд? В принципе можно и так и так, но что сейчас используется при хранении и доступе к данным на сервере разными пользователями. И если есть какие статьи по этому вопросу или литература прошу помочь. Спасибо.
Непонятно. У каждого пользователя строго одна "личная" БД? Несколько пользователей для одной БД? Несколько "личных" БД у одного пользователя? Вообще сетка доступов?
Akina, Я наверное не совсем понятно написал вопрос, но все вопросы которые вы мне задаете в комментарии именно на них я и хочу получит ответ. А что касается многопользовательского - это значит, что много аккаунтов каждый из которых содержит одинаковую структуру для хранения на сервере. И к этим данным (назовём их аккаунтами) будут обращаться пользователи в рамках прав, предоставленных админом клиентской части. Вот как-то так. И вопрос, как лучше выстроить структуру бд.
DDwrt100, Ну вот смотрите, финансовый сервис. Если в скриптах, которые обслуживают аккаунт будет дырень, владелец аккаунта сможет получить доступ к данным других пользователей - база-то одна.
Сейчас не модно на каждого юзера БД создавать свою учетку в БД и нарезать права (да и вообще делать в базе что-то умнее простой свалки данных - некоторые даже забивают на Foreign Key) - следовательно, все юзеры будут сидеть на одном аккаунте БД.
Далее ( учитывая потенциально косые руки разрабов), юзер находит инъекцию и получает доступ к данным других юзеров. Или просто подменяет в запросе свой ID на чужой (потому что по причине, опять же, незнания основ инфобеза разрабами, маловероятно, что они дотумкают не ставить SERIAL на ключи и будут использовать рандомизацию/хэши)
Так что принципы реализации информационной безопасности как на корабле или подлодке - чем крепче изоляция между несвязанными величинами, тем лучше.
Здесь имеется ввиду, что для каждого аккаунта создавать отдельную базу данных и уже админ этого аккаунта будет устанавливать отдельные права для получения информации хранящейся в этом аккаунте для пользователей. Вот регистрирует пользователь аккаунт на сервисе, сервер проверяет имя аккаунта на уникальность, и если все ок, то создается отдельная база данных и туда уже можно будет запускать пользователей с расписанными правами доступа к этой бд. Затем создает другой аккаунт, сервер создает еще одну бд с идентичной структурой. И т.д. Короче сколько аккаунтов столько и бд.
Бобби Шифер, как проводить бизнес аналитику в такой структуре ? Как реализовать регистрацию пользователей ?
безопасность это хорошо, но что то у меня есть сомнения, что база не скажет ой при 10000 пользователей.
DDwrt100, А этих данных в задаче не было. Вы доуточняете авторский вопрос таким образом, чтобы мой ответ максимально перестал к нему подходить.
Тут получается сложный баланс между затратами на безопасный код и проверки доступа и изначально дубовым решением. А вопрос аналитики можно решить, выгружая данные из пользовательских баз в аналитическую.
Тогда под пользовательские базы можно выделить минимальные конфигурации серверов подешовке.
Бобби Шифер, да нет, не выворачиваю. Думаю это первый или второй вопрос , который возникнет, после ввода в эксплуатацию системы.
Мне интересно посмотреть на лицо DataScientist когда ему скажут, что все пользователи лежат по разным базам данных, причем в каждой базе один пользователь.
И еще интереснее , посмотреть на запрос который будет вытягивать всех пользователей.
Или вот еще кейс, как в такой структуре найти самого старого пользователя, или у кого больше денег сейчас на счету..
Безопасность это хорошо, но не надо выворачивать инструменты ради нее, после таких действий они начинают плохо работать.
UPD еще в голову пришло, всеми любимые индексы, как их делать ?
DDwrt100, как я выше уже сказал, для дата-сайентиста (хотя более корректно было бы сказать "статистика") делается агрегирование, в котором можно и индексы построить (которые, кстати, не будут влиять на работу отдельных юзеров).
Бобби Шифер, Честно мне жуткой представить , как такая система будет справляться с ростом пользователей. Когда перевалить их хотя бы за 1000. Потом вылезут проблемы с тем что нам надо будет мапить пользователей к каким-нибудь продуктам(другим таблицам(например к покупкам)).
DDwrt100, обратите внимание, что в исходной задаче нет ни 10k пользователей, ни аналитики. Это уже ваши конструкции, нужные только для поддержания спора со мной.
В реальности есть:
- уже готовый сервис, написанный под одного пользователя (скорее всего, организацию)
- необходимость сделать его многопользовательским.
При этом, такая переделка уже готового сервиса вполне может означать "все снести и написать заново".
Бобби Шифер, Ну если все делать по честному, то нужно идти к автору на работу, всех опрашивать, и оценивать бизнес процесс, после уже предлагать решение ;)
То что я вижу из сообщения, сервис начал расти, и его функционал требуется расширить на несколько пользователей(опять непонятно на сколько ?). То есть динамика и курс идет на увеличение нагрузки. А дальше я просто продолжил Ваше решение на рост. И в таком случае веселье начинается даже не на 10к . а когда пользователей станет от 50. Резко вырастают накладные расходы на администрировании, не говоря уже о смежных случаях аналитики, или быстрых запросов, а сколько пользователей сегодня логинилось.
Да и со стороны проектирования баз данных, я бы не сказал что такое решение правильно.
DDwrt100, Бобби Шифер, Прошу меня простить за не совсем конкретное изложение вопроса. Раз такие споры разродились. Просто писал я сервис под один аккаунт. Представьте. Есть одна бд (ранее я использовал SQLite) и к ней могут подключаться пользователи, допустим до 50 человек, но эта бд содержит информацию и бизнес процессы одной организации. И это нормально работает. Затем я стал масштабировать ее на несколько аккаунтов, чтобы зарегистрированные пользователи могли создавать свои аккаунты и приглашать туда пользователей для работы. И здесь возник вопрос как лучше организовать архитектуру бд при том, что структура таблиц для аккаунтов идентична. Вот в этом и состоял мой вопрос. Что касается системной бд которая хранит пользователей, аккаунты и прочие общие веще, все это находится в другой базе данным, здесь стоит вопрос лишь об клиентский данных, как их лучше организовать. Но все равно я много почерпнул из вашего диалога. Спасибо!
Простой
