6

我当前的 id 键包含 3 或 4 个段：

namespace::my_key::id
namespace::my_key::my_second_key::id

解决方案 1. 使用复杂的 id 并通过在 id 中搜索键来创建视图

function (doc, meta) {

  if(meta.id.indexOf("::my_key::") !== -1){
    emit([doc.source_id], [doc.name,doc.title,doc.ui]);
  }


}

解决方案 2. 为每个文档添加“类型”、“命名空间”等字段并使用它们创建视图

function (doc, meta) {

  if(doc.type=='my_key'){
    emit([doc.source_id], [doc.name,doc.title,doc.ui]);
  }


}

如果我选择解决方案 2，我必须在我的应用程序中维护 id，我可能会像解决方案 1 那样做。

有没有人有命名 id 并从中创建视图的经验？您在使用这些解决方案时遇到了什么问题。或者也许不推荐使用 indexOf() 函数？

4

2 回答 2

4

Couchbase 在后台构建视图索引，因此如果您不使用stale=false参数，您将在两种解决方案中从视图中获取文档时获得相同的性能。

在第一个解决方案中，您可能会获得比第二个解决方案更长的密钥，因为在 2 个解决方案中，您可以在 doc 中存储类型，而不是 meta。Couchbase 将所有元数据保存在内存中，因此您拥有的密钥越长，就需要更多内存。AlsoindexOf比==or慢===，因此构建索引可能需要更多时间。

所以对我来说，第二种解决方案更好。

您还可以通过在客户端库中emit(doc.source_id, null)使用和使用来提高视图的磁盘使用率。IncludeDocs它将减小它们的大小并且几乎不会影响性能。

这也是“最佳实践”的链接。也许它也会有所帮助。

于 2013-06-04T06:16:59.823 回答
1

我正在使用您的解决方案 1。

在我的例子中（社交游戏后端服务器），键名表示存储的数据类型，例如“player:{zone_id}:{uid}”、“playerchar:{zone_id}:{player_uid}:{char_id}”等。所以我没有在文档中添加类型字段，因为应用程序知道它想要什么，从不需要来自值内容的信息进行反射。

关于性能/速度，对不起，我不能给出任何建议，我不需要使用视图查询数据，我创建的所有视图仅适用于开发和备份环境，数据分析和统计作业与不在 Couchbase 上的其他系统一起运行。

于 2013-06-13T11:50:14.377 回答