2

我目前正在考虑为 couchbase 组合一个 .NET 角色提供程序，以便在项目中使用。我希望在 2 种文档类型中对此进行建模。

第一个文档类型是应用程序中所有可用角色的简单列表。这使得支持 Add、Delete、GetAllRoles 等变得很容易。这个文档对于每个应用程序都有一个固定的密钥，因此“applicationname_roles”因此从代码的角度来看是众所周知的并且可以快速检索。

第二个文档将用户映射到角色，例如

{“类型”：“roleprovider.user-role”，“用户”：“user1”，“角色”：“role1”，“应用程序”：“app1”}

此文档类型的键将采用“applicationname_roles_username_rolename”格式，这使得测试用户是否处于特定角色的最常见操作变得简单而快速。

为了支持 .NET 角色提供程序的 GetRolesForUser 或 GetUsersInRole 方法，我正在查看使用表单的视图。

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 提供者只需要根据是否查询 GetRolesForUser 或 GetUsersInRole 来为“user:”或“role:”添加前缀，以筛选出它需要的内容。

所以现在的问题是，这一切似乎都是微不足道和合乎逻辑的，但这是我第一次与 Couchbase 合作，想知道我是否陷入了任何陷阱？一个明显的替代方法是使用 2 个视图，但在我的阅读中，我看到它提到最好减少设计文档的数量以及其中的视图数量，请参阅 Perry Krug 在沙发库视图中的回复根据桶讨论，他在此提到尝试“从一个索引生成多个不同的查询”。所以基本上我想知道我上面描述的方法是否是对佩里所说的话的规定，或者我是否只是在欺骗自己并会让自己痛苦。

感谢您的任何指示。

4

1 回答 1

0

（注意：复活一个古老的问题，因为它还没有被回答，它可能会引起其他人的兴趣。）

总的来说，您的方法是合理的。但是，除非您确实遇到性能问题，否则在这种情况下，我会坚持每种查询类型使用一个视图。虽然将多个查询组合到一个视图中会减少 Couchbase 构建视图所需的工作量，但它会增加每个查询的成本，因为它必须扫描两倍大的索引。如果您没有同时使用许多其他视图，我会将这些视图分开。事实上，我什至会将它们放在不同的设计文档中，以便 Couchbase 将由不同的索引器线程同时处理它们。无需针对尚不存在的性能问题过早地进行优化；首先使用简单的解决方案，然后在必要时进行优化。

如果您确实遇到查询读取的性能问题，您可能需要考虑从视图转移到基于键/值的方法。具体来说，为每个应用程序用户和应用程序角色对存储一个单独的文档，并将角色列表附加到前者，将用户附加到后者。这意味着您基本上最终会自己维护索引，但它会使您的读取延迟提高一个数量级。看看这个关于使用附加操作维护集合的博客。

是的，我确实看到了在一段中提倡反对过早优化并在下一段中建议进行性能优化的讽刺。所以我想强调的是，您应该首先测试视图方法是否能提供可接受的性能 - 对于大多数合理的应用程序来说，它会 - 如果确实如此，请坚持下去，因为它更简单。如果您发现您毕竟需要更好的性能，然后开始寻找第二种选择。

于 2015-05-13T17:40:27.540 回答