Мультитенантное SaaS приложение

Добрый день, коллеги.
Проектируем мультитенантное saas приложение. Предполагается в пределах 1000 клиентов.
Думаем как избавиться от client_id в каждом запросе.
Наследование для большого количества клиентов, видимо, не самый лучший вариант. Но есть еще RLS. Поэкспериментировал - работает, но на практике никогда не работал с RLS. Может ли кто поделиться опытом использования для SAAS?
Насколько это удобно на практике?
Как с производительностью?

0

Неужели никто с этим не работал?

0

Попробуйте приспособить CURRENT_USER и завернуть все в представления относительно CURRENT_USER. Может это спасет как-то.

Ну и еще комментарий. Если в каждом запросе требуется client_id, значит что-то у вас не совсем так в схеме базе данных (см. нормализацию), а значит вероятно требуется рефакторинг.

0

Спасибо за ответ.

Попробуйте приспособить CURRENT_USER и завернуть все в представления относительно CURRENT_USER. Может это спасет как-то.

Как реализовать я знаю. Представления не нужны. Интересует реальный опыт: в интернете есть статьи по теории, но дальше синтетических примеров информации не нашел. На сколько это удобно на практике? Сколько дополнительно ресурсов потребуется? На сколько это надежно разделяет данные. Вот это меня интересует.

Если в каждом запросе требуется client_id, значит что-то у вас не совсем так в схеме базе данных (см. нормализацию), а значит вероятно требуется рефакторинг.

Я написал что "проектируем" базу данных. То есть ее еще нет. Для мультитенантных приложений характерно что у каждого клиента свой набор данных, отсюда классический способ разделить эти данные: добавлять везде client_id. Но это не надежно и обременительно. Другой вариант - для каждого клиента наследовать свою схему, но с этим тоже связан ряд проблем (решаемых, конечно). Ну и наконец rls, который может взять на себя заботу по добавлению "where client_id=12345" ко всем запросам.

0

По вашему примеру одно из основных архитектурных решений приложения, на которую завязано RLS, это то, что у вас каждый пользователь приложения должен быть пользователем базы данных. А соответственно аутентификация и прочие системные вещи доступа нужно будет продумывать для использования RLS.

Учитывая, что так обычно не делают и пользователей приложения содержат в самом приложении - собственно Ваш случай с отдельным client_id и т.д., то тут возникает вопрос применимости / полезности RLS. Если у вас свои пользователи приложения, то уж лучше тогда и в приложении позаботиться о разграничении доступа к данным.

0

Я может быть один глупый вещь скажу.
Насколько данные пользователя должны быть изолированны? Один пользователь должен иметь возможность получить доступ к данным других?
Если такое не надо, то может, каждому клиенту своя база данных/кластер баз данных, попробуйте рассмотреть? Тогда можно продумать и о балансировке нагрузок(а-ля горизонтальное масштабирование). И изоляцию виртуалками или вообще на отдельные машины.
Для общей статистики/учёта пользователей и прав - отдельная узловая БД, в неё же можно отчёты запихнуть, материальные вьюхи.
Создаём юзера в узловой БД, генерим базу скриптом, прописываем доступ и уаля.

Добавлено через 9 минут
Прикладуха лезет на узловую БД, авторизуется там, получает либо через прокси-функции по айдишнику пользователя, либо как-то ещё доступ. Или не получает.
По айдишнику внутри вычисляется авторизационная инфа для базы конкретного пользователя(он её не получает, если узловая БД проксирующая).
Кстати, и пароль пользователя postgres-хозяина бд может быть индивидуальный в случае, если каждая БД развёрнута на индивидуальной виртуалке(кластер постгреса тоже индивидуальный для каждого клиента)
Или как вариант пользователь---хозяин базы не postgres, но только своей. Но тогда с правами доступа надо повнимательнее.
Короче, в любом случае вариантов куча.

0

Сообщение от grgdvo каждый пользователь приложения должен быть пользователем базы данных

В этом нет необходимости: сначала происходит аутентификация клиента, при которой становится известен client_id. Далее в postgres устанавливается переменная окружения, содержащая этот client_id и в последствии RLS "цепляется" к этой переменной окружения.

Добавлено через 4 минуты

Сообщение от oktogen то может, каждому клиенту своя база данных/кластер баз данных

В самом первом посте я написал, что клиентов может быть тысяча. И могут быть регистрации "просто посмотреть", когда клиента можно удалить через несколько дней. Создавать каждый раз базу данных - очень накладно. Я уже не говорю о сложностях с миграциями. Есть решение получше: для каждого клиента выделять отдельную схему в одной базе данных. Для 1000 клиентов это работает. И 1000 пользователей в базе данных - это не проблема. Но есть проблемы с администрированием и бэкапами. Опять же миграции нужно накатывать на все схемы.

0

Сообщение от cia Но есть проблемы с администрированием и бэкапами. Опять же миграции нужно накатывать на все схемы.

Вот именно поэтому и стоит одному пользователю выделять базу. И админить легко и бэкапить и обновления накатывать.
Это ОЧЕНЬ облегчает администрирование и сопровождение. И самое главное всё автоматизируется на лету.
Тысяча БД - не проблема. И 3 и 5 тысяч тоже.

Добавлено через 4 минуты
Просто посмотреть - не проблема - снёс базу и пользователя-хозяина. И всё.
И создать демку тоже - запустил скрипт создания пользователя и базы.
Сопровождаться легко будет. И самое главное - можно продумать политику бэкапов и их хранения.
Если размеры баз небольшие - порядка несколько гигабайт - то ваще пестня.

0

Сообщение от oktogen Вот именно поэтому и стоит одному пользователю выделять базу. И админить легко и бэкапить и обновления накатывать. Это ОЧЕНЬ облегчает администрирование и сопровождение. И самое главное всё автоматизируется на лету. Тысяча БД - не проблема. И 3 и 5 тысяч тоже.

+1

ЗЫ: RLS нужен, когда к одной записи в таблице нужен доступ разных пользователей с разными правами, чего в данном случае не предполагается...

0

Сообщение от oktogen И админить легко и бэкапить и обновления накатывать.

Спасибо за рекомендации.
Но почему легко бэкапить и накатывать? Бэкапить нужно кучу баз данных - это не то чтобы большая проблема, но если разделять клиентов на уровне схем, то трудозатраты и проблемы такие же: постгрес позволяет бэкапить отдельные схемы одной базы данных, что плюс-минус равносильно бэкапу большого количества отдельных баз данных.
Тоже касается и миграций: при появлении новой миграции её нужно накатывать на каждую базу данных, что плюс-минус равносильно варианту с отдельными схемами для каждого клиента.
Но вариант со схемами я считаю более выгодным по сравнению с отдельными базами данных, так как каждая база данных накладывает дополнительные издержки на поддержание подключений и менее эффективную работу кеша (ввиду того что общего кеша не будет). Кроме того нужно отдельное хранилище для общих для всех данных (на самом деле для них и nosql вполне подходит).

(!) Важно заметить, что данные всех клиентов будут на одном сервере. Достижение такой нагрузки, что один сервер СУБД не справляется видится только в очень отдалённой перспективе. Но в любом случае при варианте со схемами вынести часть клиентов на отдельные сервера не представляется сложным.

Сообщение от fte65 ЗЫ: RLS нужен, когда к одной записи в таблице нужен доступ разных пользователей с разными правами, чего в данном случае не предполагается...

Почему же? Именно такой сценарий и предполагается: в одной таблице содержатся данные для разных клиентов.

З.Ы. Я не пытаюсь доказать свою точку зрения, а пытаюсь понять чем отдельная БД на каждого клиента лучше RLS или отдельной схемы на каждого клиента. Убедите, пожалуйста, буду очень благодарен.

0

Сообщение от cia Почему же? Именно такой сценарий и предполагается: в одной таблице содержатся данные для разных клиентов.

Потому, что в первом топике

Сообщение от cia Думаем как избавиться от client_id в каждом запросе.

отсюда вывод, что один клиент не видит данных другого...
Что касается RLS, вот пример простейшей политики
1. В каждой таблице должно быть поле client_id
2. При очень большом кол-ве записей в таблице нужен индекс по client_id, он поможет, но не надолго.
3. Cледующий этап оптимизации создание cоставного индекса (client_id,fieldN), конечно Вы скажете, что postgresql умеет Bitand
для индексов, но это далеко не всегда так, и возможно придётся client_id "протащить" через кучу индексов
4. А вообще нужен ли RLS? даёт тот же результат

Ещё раз, RLS нужен когда необходимо организовать более сложную логику доступа к одной записи в таблице, например: клиент "user1" видит все записи клиента "user2" и может редактировать только записи с rec_id in (1,2,10,20), а удалять с rec_id in (5,10,15), клиент "user3" видит записи с rec_id in (30,35,38) клиента "user2", но не может их редактировать, ну т.п.

1

fte65, спасибо за ответ. Ваше мнение понятно и полезно.
А что скажете про вариант с отдельными схемами на каждого клиента?

0

Обновление превратятся в адЪ. Так вы можете соединиться к базе, прокатить скрипт обновления отсоединиться, а со схемами вам придётся писать как минимум цикл, который будет пробегать по всем схемам. Возможно, блоча работающих пользователей. Когда базы независимы, то можно планировать как угодно и код не будет привязываться ко схемам.

Добавлено через 9 минут
20 с лишним мегабайт на пустую базу не стоят затраченных усилий.
20-30 гигабайт это не тот объём, когда я бы заморачивался экономией на спичках.

0

Сообщение от cia А что скажете про вариант с отдельными схемами на каждого клиента?

ИМХО в Вашем случае как раз вариант с отдельными схемами наиболее подходящий, ограничение не более 1000 клиентов, не так сильно раздует системные таблицы. Да, придётся поколдовать с автоматизацией архивирования схем пользователей, но не думаю, что это архи-сложная задача, в остальном одни плюсы, тем более параметр path_search изначально так настроен

Сообщение от oktogen Обновление превратятся в адЪ. Так вы можете соединиться к базе, прокатить скрипт обновления отсоединиться

А вот этого не надо, накатить скрипт обновления даже на одной "боевой" базе это далеко не тривиальная задача и никак не может быть преимуществом по сравнению, с вариантом использования схем для каждого пользователя.

1

Сообщение от oktogen со схемами вам придётся писать как минимум цикл, который будет пробегать по всем схемам

Разве не придётся делать тоже самое, чтобы пробегать по всем базам данных?

[del]

	Комментарий модератора
	Нарушение правил форума п. 4.6

Добавлено через 9 минут
Ну и ещё одна проблема с отдельными базами данных - это сложность построения отчётов. Это далеко не главное, но несомненно понадобится какая-то статистическая информация по всем клиентам. Тут либо техническую базу данных формировать либо из каждой базы выгружать требуемую информацию и потом её суммировать. Конечно и это решаемо, но с одной базой явно проще.

0

Сообщение от cia Ну и ещё одна проблема с отдельными базами данных - это сложность построения отчётов. Это далеко не главное, но несомненно понадобится какая-то статистическая информация по всем клиентам. Тут либо техническую базу данных формировать либо из каждой базы выгружать требуемую информацию и потом её суммировать. Конечно и это решаемо, но с одной базой явно проще.

Для учёта пользователей, отчётов и статистики делается отдельная база, условно центральная.
Там же можно хранить инфу по базам и коннектам.
У нас больше 10 тысяч объектов(сооружений) и расчётов по ним, и примерно 100 архивных баз на нескольких машинах.

Добавлено через 2 минуты
База правда очень небольшая, около 2 терабайт

0