有什么更好/更快的复杂的couchbase ID或内联文档type="my_document_type“

Question

我当前的id key包含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.为每个文档添加"type“、"namespace”等字段，并使用它们创建视图

function (doc, meta) {

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


}

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

有没有人有命名id和创建视图的经验？您在这些解决方案中遇到了哪些问题。或者可能不推荐使用indexOf()函数？

Answer 1

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

在第一个方案中，你可能会得到比第二个方案更长的键，因为在第二个方案中，你可以存储文档中的类型，而不是meta。Couchbase将所有元数据保存在内存中，因此您拥有的键越长，需要的内存就越多。此外，indexOf比==或===慢，所以建立索引可能需要更多时间。

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

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

这里还有一个“最佳实践”的link。也许这也会有所帮助。

Answer 2

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

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

关于性能/速度，很抱歉我不能给出任何建议，我没有用视图查询数据的要求，我创建的所有视图只在开发和备份环境下工作，数据分析和统计作业运行在其他系统上而不是Couchbase上。