Кассандра как база данных для системы контроля доступа на основе ролей

Question

Хотелось бы узнать ваше мнение об использовании Кассандры для реализации RBAC-подобная модель аутентификации и авторизации. Мы упростили центральное отношение общей модели (http://en.wikipedia.org/wiki/Role-based_access_control) до:

пользователь --- n: m --- роль --- n: m --- ресурс

пользователи и ресурсы индексируются внешне видимыми идентификаторами. Эти идентификаторы также должны быть «переустанавливаемыми» (например, псевдонимы почты).

Основная причина рассмотреть Cassandra - доступность, масштабируемость и (глобальная) геоизбыточность. Этого трудно достичь с помощью RBDMS.

С другой стороны, RBAC имеет много отношений m: n. Хотя некоторые несоответствия могут быть приемлемыми, владение ресурсами (то есть роль = владелец) никогда не должен быть перепутан.

Что ты думаешь? Является ли такая реляционная модель антипаттерном для Кассандры? использование? Знаете ли вы подобные решения на основе Cassandra?

Answer 1

Я собираюсь пойти дальше и превратить мои комментарии в ответ, чтобы они были в одном месте.

Несмотря на то, что у вас большой звучащий набор данных, 100 000 000 учетных записей для управления, если я правильно читаю это, у вас также есть ограничение необходимости обеспечения некоторого уровня согласованности, чтобы гарантировать, что конкретные отношения никогда не выйдут из синхронизации.У вас также есть ситуация с множеством отношений один-ко-многим (ресурс -> пользователи или m: n сверху), которые вам необходимо применить.Кроме того, похоже, что вы будете читать из набора данных больше, чем писать в него.Впоследствии, я думаю, что СУБД с горячим резервным копированием решит ваши проблемы лучше, чем пользовательское развертывание Cassandra.Причины этого:

1. Отношения «один ко многим» в СУБД могут быть выражены как оператор SQL, который объединяет таблицы, и вам нужно только сохранить данные один раз.В Cassandra, в зависимости от настроек, вам придется хранить одну и ту же информацию в нескольких местах, чтобы правильно отражать отношения.Это привело бы к довольно грязной и избыточной модели данных.

2. Согласованность - Кассандра в конечном итоге последовательна, что хорошо при работе с большинством типов данных, ИМХО.Однако при работе с чем-то вроде безопасности, которая всегда требует согласованности, СУБД (множественное число?) Имеют значительное преимущество в транзакциях, чтобы гарантировать, что ваши данные всегда синхронизированы.Что-то, что я считаю важным с точки зрения безопасности.

3. Скорость чтения - Использование индексов в RDBMS значительно ускорит чтение из БД, поэтому я бы не стал принимать это за решениефактор, пока вы не сможете определить эмпирически, станет существенным узким местом.Модель чтения кворума Кассандры может, в некотором смысле, быть медленнее, поскольку вам придется ждать на N машинах (где N> = 1), чтобы вернуть ответ и исправить его, если он не синхронизирован.

4. Резервирование - СУБД с «горячим» резервированием (копирование мастер-мастер) решит проблемы избыточности.

Кассандра - отличный инструмент, и яоднако, в этом случае, мне кажется, что ваша модель лучше работает с RDBMS, чем с Cassandra.

Удачи!