Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, VladiCh, Вы писали:

НС>>>Если речь про row level security — эта задача на любом типе БД очень непростая. Если без привлечения объектов — там все прекрасно кешируется в редисе.
VC>>Нет, не row level security.

НС>Тогда не вижу проблем. БД описывающая права на уровне операций обычно редко меняется и без проблем влазит в память.

Я же написал — RBAC — role based access control — на уровне объектов и операций над ними (описываемых ролями).
Нет, в память не влазит — сотни миллионов пользователей, миллионы организаций, десятки миллионов групп (группы существуют на уровне организаций).
Там довольно большая база и растет быстро.

VC>>На этом типе задачи я столкнулся с ограничениями,

НС>Как будто бывает иначе с каким то другим типом БД.

Ну если делать все вручную опять же, используя domain knowledge а не статистику оптимизатора, то все работает куда надежнее.
Удобства использования конечно меньше, но это не самое важное в подобных сервисах.
Соответственно более простые и дубовые базы данных могут в данном случае выигрывать.

VC>>У Postgres кстати довольно хороший оптимизатор,

НС>Смотря с чем сравнивать. Если с большой тройкой — то крайне примитивный он. С другой стороны он, конечно, более предсказуем и ближе к тому что ты хочешь, чтобы часть работы приходилось делать за него.

VC>>Для Postgres есть расширения позволяющие использовать хинты и сохранять планы, но они довольно убогие, к сожалению.

НС>О чем я и говорил — проблема не в РСУБД, проблема конкретно в постгри.

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

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, VladiCh, Вы писали:

НС>>>Если речь про row level security — эта задача на любом типе БД очень непростая. Если без привлечения объектов — там все прекрасно кешируется в редисе.
VC>>Нет, не row level security.

НС>Тогда не вижу проблем. БД описывающая права на уровне операций обычно редко меняется и без проблем влазит в память.

Я же написал — RBAC — role based access control — на уровне объектов и операций над ними (описываемых ролями).
Нет, в память не влазит — сотни миллионов пользователей, миллионы организаций, десятки миллионов групп (группы существуют на уровне организаций, пользователи глобальны).
Количество объектов — тоже сотни миллионов (в будущем миллиарды). Количество прав — это пересечение между этими всеми сущностями (плюс еще роли, но их относительно мало).
Прав опять же сотни миллионов в данный момент, но в перспективе тоже будут миллиарды. Есть еще наследуемые права и прочие сложности, так что запросы получаются не самые простые.
Там довольно большая база и растет быстро.

VC>>На этом типе задачи я столкнулся с ограничениями,

НС>Как будто бывает иначе с каким то другим типом БД.

Ну если делать все вручную опять же, используя domain knowledge а не статистику оптимизатора, то все работает куда надежнее.
Удобства использования конечно меньше, но это не самое важное в подобных сервисах.
Соответственно более простые и дубовые базы данных могут в данном случае выигрывать.

VC>>У Postgres кстати довольно хороший оптимизатор,

НС>Смотря с чем сравнивать. Если с большой тройкой — то крайне примитивный он. С другой стороны он, конечно, более предсказуем и ближе к тому что ты хочешь, чтобы часть работы приходилось делать за него.

VC>>Для Postgres есть расширения позволяющие использовать хинты и сохранять планы, но они довольно убогие, к сожалению.

НС>О чем я и говорил — проблема не в РСУБД, проблема конкретно в постгри.

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