c# - 对于使用 couchbase 的解决方案，这是 .NET 自定义角色提供程序的合理方法吗？

Question

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

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

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

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

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

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

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 行发送到 View 中。第一个允许我们查询用户所处角色的 View 。第二个允许我们查询用户所处角色的 View 。 .NET 提供者只需根据其查询 GetRolesForUser 或 GetUsersInRole 是否为“user:”或“role:”添加前缀，以筛选出它需要的内容。

那么现在问题来了，这一切看起来相当微不足道且合乎逻辑，但这是我第一次使用 Couchbase 并想知道我是否陷入了任何陷阱？一个明显的替代方法是使用 2 个 View ，但在我的阅读中我看到它提到最好减少设计文档的数量以及其中的 View 数量，请参阅 Perry Krug 在 couchbase views per bucket discussion 中的回复，在此他提到尝试“从一个索引生成多个不同的查询”。所以基本上我想知道我上面描述的方法是否是对 Perry 所说的的规定，或者我是否只是在欺骗自己并让自己痛苦下去。

感谢您的指点。

Answer 1

(注意:复活一个古老的问题，因为它还没有被回答，可能其他人会感兴趣。)

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

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

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