Чтобы спроектировать хранилище данных в Cassandra, вам нужно начать с запросов, которые вы планируете выполнить , и сделать так, чтобы вы могли получить всю необходимую вам информацию сразу. Денормализация это название игры здесь; если вы не реплицируете эту информацию о роли в каждом пользовательском узле, вы не будете избегать поиска диска, и ваша производительность чтения снизится. Объединения не имеют смысла; если вам нужна реляционная база данных, используйте реляционную базу данных.
По-видимому, вы будете задавать много вопросов о том, какие роли имеют пользователи и что им следует делать с ними, поэтому вы определенно хотите, чтобы информация о ролях дублировалась в каждой записи пользователя - возможно, с каждой ролью. получить свой собственный столбец (role-ROLE_KEY => serialized-capability-info вместо roles => [serialized array of capability info]). Вашему приложению потребуется какой-то способ перебора всех этих столбцов.
Возможно, вы захотите посмотреть, какие пользователи играют роль, и поэтому вам, вероятно, следует хранить всю информацию о пользователях, которая вам понадобится для этого представления, также в семействе столбцов ролей (хотя это подмножество полной пользовательской записи). будет делать).
Когда вы запускаете обновления и добавляете / удаляете пользователей из ролей, вам необходимо убедиться, что вы одновременно обновляете как список пользователей, так и роли пользователей. Поскольку для каждого отношения используется столбец, а не один общий сериализованный большой двоичный объект, это должно работать, даже если вы редактируете две разные роли, которые совместно используют одного и того же пользователя: Cassandra может объединять обновления, включая удаления .
Если запрос должен быть асинхронным, тогда сделайте так, чтобы ваше приложение обрабатывало его. Помните, что Cassandra - это хранилище данных с возможной непротиворечивостью, и вы не должны ожидать, что обновления будут видны везде сразу.