6

My current id keys contains from 3 or 4 segments:

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

Solution 1. Use complex id's and create views by searching in id for a key

function (doc, meta) {

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


}

Solution 2. For every document add fields like "type", "namespace" And creat views using them

function (doc, meta) {

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


}

If i choose Solution 2, I have to maintain id's on my application and probably i will do as in solution 1.

Does anyone have experience in naming id's and creating views from them? what problems you had with each of these solutions. Or maybe indexOf() function is not recommended?

Edmhs
  • 3,645
  • 27
  • 39
  • 1
    You can also post your question or link to it on [couchbase forums](http://www.couchbase.com/forums/). There are some couchbase developers that are not registered on stackoverflow. – m03geek Jun 07 '13 at 14:13
  • As @xqterry said, if your application can handle all that you need without views, you should use only the first solution. – m03geek Jun 14 '13 at 12:46

2 Answers2

4

Couchbase builds view index in background, so if you don't use stale=false parameter, you'll get same performance on getting docs from view in both solutions.

In first solution you can probably get keys with more length than in the second one, because in 2 solution you can strore type in doc, not meta. Couchbase holds all metadata in memeory, so longer keys you have, more memory is needed. Also indexOf is slower than == or ===, so building index can take more time.

So as for me the second solution is better.

Also you can improve disk usage of your views by emmiting just emit(doc.source_id, null) and use IncludeDocs in your client library. It will reduce their size and almost would not affect the performance.

Here is also a link for "best practice". May be it will also help.

m03geek
  • 2,508
  • 1
  • 21
  • 41
1

I am using like your solution 1.

In my case (social game backend server), key name indicates the stored data type, for example, "player:{zone_id}:{uid}", "playerchar:{zone_id}:{player_uid}:{char_id}" etc. So I didn't add type field in document because application knows what it wants, never require information from value content for reflection.

About Performance/Speed, sorry I could not give any suggestion, I have no requirement of query data with view, all views I created only works on development & backup environment, and data analysitic & stats jobs runs with other system not on Couchbase.

xqterry
  • 632
  • 4
  • 10