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

В настоящее время я рассматриваю возможность создания поставщика ролей .NET для Couchbase для использования в проекте. Я хочу смоделировать это в 2 типах документов.

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

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

{ "type": "roleprovider.user-role", "user": "user1", "role": "role1", "application": "app1" }

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

Для поддержки методов 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 для каждой корзины, в этом он упоминает попытку "создать несколько разных запросы от одного индекса». Так что в основном мне интересно, является ли подход, который я описал выше, предписывающим то, что говорит Перри, или я просто обманываю себя и собираюсь причинить себе боль в будущем.

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


c# couchbase couchbase-view roleprovider
person Neil F    schedule 16.10.2014    source источник

Ответы (1)


arrow_upward
0
arrow_downward

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

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

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

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

person David Ostrovsky    schedule 13.05.2015