Является ли это разумным подходом к поставщику роли пользовательской роли .NET для решения, использующего couchbase?

Question

В настоящее время я рассматриваю создание поставщика роли .NET для couchbase для использования в проекте. Я хотел бы моделировать это в двух типах документов.

Первый тип документа представляет собой простой список всех ролей, доступных в приложении. Это упрощает поддержку Add, Delete, GetAllRoles и т. Д. Этот документ будет иметь фиксированный ключ для каждого приложения, поэтому «applicationname_roles» так хорошо известен с точки зрения кодов и быстро извлекается.

Второй документ отображает пользователю роли, так, например

{ "типа": "roleprovider.user-роль", "пользователь": "user1", "роль" : «role1», «приложение»: «app1» }

ключ для данного типа документа будет иметь формат «applicationname_roles_username_rolename», что делает наиболее распространенную операцию тестирования, если пользователь находится в конкретной Роль тривиальная и быстрая.

Для поддержки методов GetRolesForUser или GetUsersInRole поставщика роли .NET. Я рассматриваю использование вида формы.

function (doc, meta) { 
if(meta.type != 'json') 
{ 
    return; 
} 

if (doc.type == "roleprovider.user-role") 
{ 
    if(doc.application && doc.user && doc.role) 
    { 
     emit([doc.application, "user:" + doc.user, doc.role]); 
     emit([doc.application, "role:" + doc.role, doc.user]); 
    } 
}} 

Таким образом, для каждого пользователя для сопоставления ролей мы получаем 2 строки, выпущенные в виде. Первый позволяет нам запрашивать представление о том, для каких ролей принадлежит пользователь. Второй, для которого пользователи играют роль. Поставщику .NET просто нужно префикс либо «user:», либо «role:» на основании того, что он не запрашивает GetRolesForUser или GetUsersInRole, чтобы отфильтровывать то, что ему нужно.

Итак, теперь на вопрос, все это кажется достаточно тривиальным и логичным, однако в первый раз я работал с Couchbase и задавался вопросом, попадал ли я в какие-либо ловушки с этим? Очевидным альтернативным подходом было бы использовать 2 взгляда, но в своем чтении я видел, что он упомянул, что лучше всего уменьшить количество проектных документов и количество просмотров внутри них, см. Ответ Перри Круг в couchbase views per bucket discussion, в этом он упоминает, пытаясь «сгенерировать несколько разных запросов от одного индекса». Поэтому в основном мне интересно, относится ли описанный выше подход к тому, что говорит Перри, или если я просто обманываю себя и собираюсь причинить себе боль вниз.

Спасибо за любые указатели.

Answer 1

. (Примечание: воскресить древний вопрос, потому что он не был дан ответ еще, и это может заинтересовать кого-то еще)

Ваш подход в целом звук. Но, если у вас на самом деле не возникают проблемы с производительностью, в этом случае я буду придерживаться одного вида для каждого типа запроса. Объединение нескольких запросов в один вид уменьшит объем работы Couchbase, необходимой для построения представлений, что увеличит стоимость каждого запроса, так как ему придется сканировать индекс, который в два раза больше. Если вы не используете много других представлений одновременно, я бы сохранил мнения отдельно. Фактически, я бы даже поместил их в разные проектные документы, чтобы Couchbase обрабатывал их одновременно разными потоками индексатора. Нет необходимости преждевременно оптимизировать проблему производительности, которая еще не существует; сначала попробуйте прямое решение, затем при необходимости оптимизируйте.

Если вы столкнулись с проблемой производительности при чтении запросов, вам может потребоваться переходить от представлений к подходу, основанному на ключевом значении.В частности, хранение отдельного документа для каждой пары приложений и пользователей и приложений и роли, а также добавление списка ролей для первого и пользователей к последним. Это означает, что вы по существу в конечном итоге поддерживаете индексы самостоятельно, но это даст вам порядок улучшения латентности чтения. Посмотрите на this blog об обслуживании наборов с добавлением операций.

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